On 03/03/2018 at 00:25:29 +0000, James Hogan wrote:
> Similarly if the platform is little endian only, you could also add:

It supports big endian.

> > +
> > +
> Hmm, can this break any other generic platforms that already make the
> DTB command line override the arcs_cmdline? Paul?
> I.e. In arch_mem_init() the condition of copying arcs_cmdline to
> boot_command_line would switch from !boot_command_line[0] to
> arcs_cmdline[0]. I suppose arcs_cmdline[] may not have been written in
> those cases. If its safe then it should probably be a standard thing
> selected by MIPS_GENERIC instead of a board specific thing.

Actually, this is not needed so I'm removing it.

> Perhaps its worth adding this to the base generic_defconfig if its
> useful to have.

Our test automation tool is using it to reboot the platform but I don't
know if this is useful for anybody else.

> > +static __init bool ocelot_detect(void)
> > +{
> > +   u32 rev;
> > +
> > +   rev = __raw_readl((void *)DEVCPU_GCB_CHIP_REGS_CHIP_ID);
> Isn't that an address in the user segment, i.e. TLB mapped virtual
> memory? Does the bootloader set up a wired mapping for it or something?
> The address looks similar to UART_UART which is given to ioremap so must
> be a physical address. Perhaps the mapping you're using is 1:1
> virtual:physical address?
> If its using a TLB mapping, then:
> 1) That isn't safe this early to run on other platforms, as it'll give a
>    TLB refill exception. It should be quite possible to detect such a
>    mapping to make it safer though.
> 2) If yamon initialises the TLB to a known state, then that may well be
>    a hacky but workable way to distinguish yamon (sead3) from redboot
>    (mscc) in future.

Yes, this is an identity mapping that is installed by redboot because
all the peripherals are in the user segment.

Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering

Reply via email to