From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933618AbdK2QiW (ORCPT ); Wed, 29 Nov 2017 11:38:22 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:38452 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932190AbdK2QiV (ORCPT ); Wed, 29 Nov 2017 11:38:21 -0500 Date: Wed, 29 Nov 2017 17:38:19 +0100 From: Alexandre Belloni To: Paul Burton Cc: James Hogan , Ralf Baechle , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs Message-ID: <20171129163819.GN21126@piout.net> References: <20171128152643.20463-1-alexandre.belloni@free-electrons.com> <20171128152643.20463-10-alexandre.belloni@free-electrons.com> <20171128160137.GF27409@jhogan-linux.mipstec.com> <20171128165359.GJ21126@piout.net> <20171128173151.GD5027@jhogan-linux.mipstec.com> <20171128195002.dcq7i2wqmstkn3rr@pburton-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171128195002.dcq7i2wqmstkn3rr@pburton-laptop> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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