linux-kernel - Re: [PATCH 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171129163819.GN21126@piout.net>
Date:   Wed, 29 Nov 2017 17:38:19 +0100
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Paul Burton <paul.burton@...s.com>
Cc:     James Hogan <james.hogan@...s.com>,
        Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...ux-mips.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/13] MIPS: mscc: Add initial support for Microsemi MIPS
 SoCs

Hi Paul,

On 28/11/2017 at 11:50:02 -0800, Paul Burton wrote:
> On Tue, Nov 28, 2017 at 05:31:51PM +0000, James Hogan wrote:
> > On Tue, Nov 28, 2017 at 05:53:59PM +0100, Alexandre Belloni wrote:
> > > On 28/11/2017 at 16:01:38 +0000, James Hogan wrote:
> > > > On Tue, Nov 28, 2017 at 04:26:39PM +0100, Alexandre Belloni wrote:
> > > > > Introduce support for the MIPS based Microsemi Ocelot SoCs.
> > > > > As the plan is to have all SoCs supported only using device tree, the
> > > > > mach directory is simply called mscc.
> > > > 
> > > > Nice. Have you considered adding this to the existing multiplatform
> > > > "generic" platform? See for example commit b35565bb16a5 ("MIPS: generic:
> > > > Add support for MIPSfpga") for the latest platform to be converted.
> > > > 
> > > 
> > > I didn't because we are currently booting using an old redboot with its
> > > own boot protocol and at boot, the register read by the sead3 code is
> > > completely random (it actually matched once).
> > > 
> > > Do you consider that mandatory to get the platform upstream?
> > 
> > No, however if it is practical to do so I think it might be the best way
> > forward (even if generic+YAMON support is mutually exclusive of
> > generic+redboot, though hopefully there is some way to avoid that).
> > 
> > Paul on Cc, he may have thoughts on this one.
> 
> We could certainly look at tightening the checks in the SEAD-3 code to
> avoid the false positive.
> 
> Could you share any details of the boot protocol you're using with
> redboot? One option might be for the SEAD-3 code to check that the
> arguments the bootloader provided look "YAMON-like", so long as the 2
> protocols differ sufficiently.
> 

I didn't look closely at the redboot code yet but it ends up with
something like:
 - argc == fw_arg0
 - argv == fw_arg1
    - not sure yet what is in argv[0]
    - kernel commande line in argv[1]
 - fw_arg2 is a pointer to a structure like:
        struct parmblock {
            t_env_var memsize;
        };
    with:
        typedef struct
        {
            char *name;
            char *val;
        } t_env_var;
   this is the size of the RAM but I'm not using it because it is in the
   device tree.

Does that help?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com