[U-Boot] [PATCH 1/2] ARM: rpi: update memory layout env. var. documentation

[Jonathan Liu]

Hi Stephen,

Looks good to me then. I wasn't sure how U-Boot was typically used on the
RPi.

Regards,
Jonathan

On Sunday, 7 February 2016, Stephen Warren <swarren at wwwdotorg.org> wrote:

> On 02/06/2016 12:30 AM, Jonathan Liu wrote:
> > Hi Stephen,
> >
> > I actually read the DT loaded by RPi's binary firmware on an RPi 2 in a
> > U-Boot script:
> > fdt addr ${fdt_addr_r} && fdt get value bootargs /chosen bootargs
> > fatload mmc 0:1 ${kernel_addr_r} uImage
> > bootm ${kernel_addr_r} - ${fdt_addr_r}
> >
> > Essentially this loads the kernel with the same arguments and DT that
> > RPi's binary firmware would have used if it booted the kernel directly
> > with device tree support. This allows for the normal patching of the
> > kernel arguments and device tree to be done by the RPi binary firmware
> > so that things like reading the serial number in /proc/cpuinfo works.
> >
> > A trailer is added to u-boot.bin with "mkknlimg --dtok u-boot.bin
> > u-boot.bin" for the FW to enable device tree support and load the
> > patched device tree to 0x00000100.
> >
> > So I am not sure about the comment that the DT loaded by the FW is
> > typically ignored by U-Boot scripts.
>
> This is a very unusual use-case. Typically the reason for using U-Boot
> in the first place is so that U-Boot has full control over the kernel,
> DT, and command-line. This way, users can configure all these aspects
> the exact same way on an RPi running U-Boot as on any other system
> running U-Boot. Mixing configuration between config.txt and the
> scripts/config-files that U-Boot reads/executes isn't typical, since it
> involves board-specific config file. As such, I believe the comment is
> correct for the common case, and already admits that other cases are
> possible.
>