Re: [PATCH 3/5] arm: initial support for Marvell Dove SoCs

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Dear Lucas Stach,

On Wed, 15 May 2013 10:03:07 +0200, Lucas Stach wrote:

> > So to me, Barebox should do the 0xf1 remapping as soon as possible in
> > its initialization, for all Marvell EBU platforms, and give up the idea
> > of being able to chainload a second stage Barebox.
> > 
> > Is there anything I'm missing?
> 
> If you are indicating that the remapping was done through a specific
> CP15 entry, barebox should equally be able to read this bit out and
> decide if remapping has to be applied or not.

This CP15 bit thing will only ever be valid for Armada 370/XP. For
Kirkwood, Dove, Orion5x, there is no really reliable way to detect
whether the remapping has occurred or not.

> Is this CP15 bit persistent? Even if not you may be able to set it in
> bootm, just before you jump to the chainloaded image.

The one that was chosen is persistent until the first call to the wfi
instruction, which has the effect of clearing this bit back to 0.

Anyway, if people are concerned by being able to chainload Barebox from
Barebox, or chainload Barebox from U-Boot, we can always add a Kconfig
option to say "I want to do the remapping" (to be enabled when Barebox
is used as the real primary bootloader), or "I don't want to do the
remapping and I'll assume it has already been done before I'm
loaded" (to be enabled when Barebox is chainloaded from another
bootloader that has already done the remapping). I suppose people
willing to do chainloading should be smart enough to understand what
this Kconfig option means, and in which situation is should be enabled
or disabled.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox