LKML Archive on lore.kernel.org
 help / color / Atom feed
From: James Hogan <jhogan@kernel.org>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Paul Burton <paul.burton@mips.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs
Date: Wed, 17 Jan 2018 23:58:47 +0000
Message-ID: <20180117235846.GA25314@saruman> (raw)
In-Reply-To: <20171129163819.GN21126@piout.net>

[-- Attachment #1: Type: text/plain, Size: 5043 bytes --]

On Wed, Nov 29, 2017 at 05:38:19PM +0100, Alexandre Belloni wrote:
> 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?

That basically matches what YAMON provides. I can't see a nice way to
support both in the same kernel.

Processor ID is no good since Malta (not yet mainline added to
"generic") uses the same address for the ID, and can support a much
bigger range of cores.

Poking at random I/O always feels a bit risky.

Some safety checked environment checking (Paul says modetty0 should
always be in there for YAMON) might work.

Does Ocelot have a read-only ID register with a specific value? We'd
have to add prioritisation of the legacy board detection to rely on
that.

If all else fails, we could still make them mutually exclusive,
something roughly like below would work but its a bit clumsy as all the
ocelot config options would still get enabled when sead3 is enabled,
even though some of the drivers may not be useful. The detection &
co-existence can always be improved later. What do you think?

We can't #require CONFIG_LEGACY_BOARD_SEAD3=n unfortunately since it
only checks the base config, not the already merged board configs.

Cheers
James

diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 0f20f84de53b..bfdefc013358 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -537,6 +537,10 @@ generic_defconfig:
 # now that the boards have been converted to use the generic kernel they are
 # wrappers around the generic rules above.
 #
+.PHONY: ocelot_defconfig
+ocelot_defconfig:
+	$(Q)$(MAKE) -f $(srctree)/Makefile 32r2el_defconfig BOARDS=ocelot
+
 .PHONY: sead3_defconfig
 sead3_defconfig:
 	$(Q)$(MAKE) -f $(srctree)/Makefile 32r2el_defconfig BOARDS=sead-3
diff --git a/arch/mips/configs/generic/board-ocelot.config b/arch/mips/configs/generic/board-ocelot.config
new file mode 100644
index 000000000000..b22a4570d05c
--- /dev/null
+++ b/arch/mips/configs/generic/board-ocelot.config
@@ -0,0 +1,3 @@
+# require CONFIG_32BIT=y
+
+CONFIG_LEGACY_BOARD_OCELOT=y
diff --git a/arch/mips/generic/Kconfig b/arch/mips/generic/Kconfig
index 52e0286a1612..fac8b936c468 100644
--- a/arch/mips/generic/Kconfig
+++ b/arch/mips/generic/Kconfig
@@ -27,6 +27,14 @@ config LEGACY_BOARD_SEAD3
 	  Enable this to include support for booting on MIPS SEAD-3 FPGA-based
 	  development boards, which boot using a legacy boot protocol.
 
+comment "MSCC Ocelot doesn't work with SEAD3 enabled"
+	depends on LEGACY_BOARD_SEAD3
+
+config LEGACY_BOARD_OCELOT
+	bool "Support MSCC Ocelot boards"
+	depends on LEGACY_BOARD_SEAD3=n
+	select LEGACY_BOARDS
+
 comment "FIT/UHI Boards"
 
 config FIT_IMAGE_FDT_BOSTON

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply index

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28 15:26 [PATCH 00/13] MIPS: add support for the " Alexandre Belloni
2017-11-28 15:26 ` [PATCH 01/13] dt-bindings: Add vendor prefix for Microsemi Corporation Alexandre Belloni
2017-11-28 16:10   ` James Hogan
2017-11-28 16:22     ` Alexandre Belloni
2017-12-01  1:14       ` Rob Herring
2017-11-28 15:26 ` [PATCH 02/13] dt-bindings: interrupt-controller: Add binding for the Microsemi Ocelot interrupt controller Alexandre Belloni
2017-12-01  1:15   ` Rob Herring
2017-11-28 15:26 ` [PATCH 03/13] irqchip: Add a driver for the Microsemi Ocelot controller Alexandre Belloni
2017-11-28 15:26 ` [PATCH 04/13] dt-bindings: pinctrl: Add bindings for Microsemi Ocelot Alexandre Belloni
2017-12-01  1:16   ` Rob Herring
2017-11-28 15:26 ` [PATCH 05/13] pinctrl: Add Microsemi Ocelot SoC driver Alexandre Belloni
2017-11-28 15:26 ` [PATCH 06/13] dt-bindings: power: reset: Document ocelot-reset binding Alexandre Belloni
2017-12-01  1:54   ` Rob Herring
2017-11-28 15:26 ` [PATCH 07/13] power: reset: Add a driver for the Microsemi Ocelot reset Alexandre Belloni
2017-11-28 15:26 ` [PATCH 08/13] dt-bindings: mips: Add bindings for Microsemi SoCs Alexandre Belloni
2017-11-28 19:14   ` Florian Fainelli
2017-11-28 15:26 ` [PATCH 09/13] MIPS: mscc: Add initial support for Microsemi MIPS SoCs Alexandre Belloni
2017-11-28 16:01   ` James Hogan
2017-11-28 16:53     ` Alexandre Belloni
2017-11-28 17:31       ` James Hogan
2017-11-28 19:50         ` Paul Burton
2017-11-29 16:38           ` Alexandre Belloni
2018-01-17 23:58             ` James Hogan [this message]
2018-03-02 15:22               ` Alexandre Belloni
2017-11-28 15:26 ` [PATCH 10/13] MIPS: mscc: add ocelot dtsi Alexandre Belloni
2017-11-28 18:40   ` Florian Fainelli
2017-11-28 15:26 ` [PATCH 11/13] MIPS: mscc: add ocelot PCB123 device tree Alexandre Belloni
2017-11-28 15:26 ` [PATCH 12/13] MIPS: defconfigs: add a defconfig for Microsemi SoCs Alexandre Belloni
2017-11-28 15:26 ` [PATCH 13/13] MAINTAINERS: Add entry for Microsemi MIPS SoCs Alexandre Belloni
2017-11-28 15:34   ` Joe Perches
2017-11-28 15:44     ` Alexandre Belloni

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180117235846.GA25314@saruman \
    --to=jhogan@kernel.org \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@mips.com \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git