[U-Boot] [PATCH 2/2] vexpress64: juno: add default NOR flash boot
Tom Rini
trini at ti.com
Mon Feb 23 23:22:00 CET 2015
On Mon, Feb 23, 2015 at 04:12:47PM +0100, Linus Walleij wrote:
> On Thu, Feb 19, 2015 at 5:50 PM, Tom Rini <trini at ti.com> wrote:
> > On Thu, Feb 19, 2015 at 05:19:54PM +0100, Linus Walleij wrote:
> >
> >> This modifies the vexpress64 Juno configuration so that
> >> it will by default load and boot a kernel and a device tree
> >> from the pre-defined location in the NOR flash. When we are
> >> at it, also define the proper command line for the Juno and
> >> indicate that the USB stick (/dev/sda1) is the default
> >> root file system.
> >>
> >> Signed-off-by: Linus Walleij <linus.walleij at linaro.org>
> >
> > Is there a reason to not enable mtdparts and define + pass in the
> > partition map on NOR?
>
> I've looked closer at this, and the ARM reference designs actually
> have a special "partition" format and does not rely on fixed
> offsets that e.g the bootloader hardcodes and pass to the
> kernel.
>
> The format is implemented in the Linux kernel in
> drivers/mtd/afs.c
>
> I also made a stand-alone implementation at one point
> to create these flash images:
> http://www.df.lth.se/~triad/krad/integrator/arm-header.c
>
> It involves scanning over the eraseblocks of the flash, reading
> out the last 20 bytes of each, scanning for a magic
> number indicating a footer. So this footer is added to
> the last erase block for the "partition", not preceding
> of the flash image, instead following it. Meaning XIP &c
> will still work fine.
>
> By scanning all erase blocks, all images in the flash can
> be identified.
>
> The proper implementation for U-Boot interaction with
> the flash would be to copy over/implement this as AFS
> partitions instead of MTD partitions, and select that
> exclusively for the ARM Reference designs.
>
> This image format has been used by ARM reference since
> the first ARM Integrator in ~2001 and is still used in the
> latest Juno design from last year, so it's likely not going
> away.
>
> Shall I just go ahead and implement this for U-boot?
>
> It can be incremental on top of this patch.
Sounds like a plan to me, thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150223/2d857bbe/attachment.sig>
More information about the U-Boot
mailing list