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

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

[Stephen Warren]

Update rpi-common.h's documentation that describes the rationale for
choosing various addresses for standardized variables used by boot
scripts. This comment was correct when written, but not updated when some
of the values were changed.

Fixes: 14006a567105 ("rpi: set fdt_addr_r to 0x00000100 to match default
...device_tree_address")
Cc: Jonathan Liu <net147@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
---
 include/configs/rpi-common.h | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h
index 72f1e2d60b8f..00a5266dad15 100644
--- a/include/configs/rpi-common.h
+++ b/include/configs/rpi-common.h
@@ -144,8 +144,14 @@
 /*
  * Memory layout for where various images get loaded by boot scripts:
  *
- * scriptaddr can be pretty much anywhere that doesn't conflict with something
- *   else. Put it low in memory to avoid conflicts.
+ * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
+ *
+ * fdt_addr_r simply shouldn't overlap anything else. However, the RPi's
+ *   binary firmware loads a DT to address 0x100, so we choose this address to
+ *   match it. This allows custom boot scripts to pass this DT on to Linux
+ *   simply by not over-writing the data at this address. When using U-Boot,
+ *   U-Boot (and scripts it executes) typicaly ignore the DT loaded by the FW
+ *   and loads its own DT from disk (triggered by boot.scr or extlinux.conf).
  *
  * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
  *   something else. Put it low in memory to avoid conflicts.
@@ -159,11 +165,11 @@
  *   this up to 16M allows for a sizable kernel to be decompressed below the
  *   compressed load address.
  *
- * fdt_addr_r simply shouldn't overlap anything else. Choosing 32M allows for
- *   the compressed kernel to be up to 16M too.
+ * scriptaddr can be pretty much anywhere that doesn't conflict with something
+ *   else. Choosing 32M allows for the compressed kernel to be up to 16M.
  *
  * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows
- *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
+ *   for any boot script to be up to 1M, which is hopefully plenty.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
 	"fdt_addr_r=0x00000100\0" \
-- 
1.9.1

[U-Boot] [PATCH 2/2] ARM: rpi: set fdt_high in the default environment

[Stephen Warren]

The ARM Linux kernel requires the DT to be in memory accessible early
during the boot process. This always happens naturally on the RPi 1,
since the maximum memory size of 512MiB, and additionally some of that
is reserved for use by the GPU. The RPi 2 has 1GiB of RAM (minus some
GPU usage), and so if the DT is relocated to the top of RAM, Linux cannot
access it. Prevent this from happening by setting fdt_high.

Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
---
 include/configs/rpi-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h
index 00a5266dad15..b564eb690633 100644
--- a/include/configs/rpi-common.h
+++ b/include/configs/rpi-common.h
@@ -172,6 +172,7 @@
  *   for any boot script to be up to 1M, which is hopefully plenty.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
+	"fdt_high=ffffffff\0" \
 	"fdt_addr_r=0x00000100\0" \
 	"pxefile_addr_r=0x00100000\0" \
 	"kernel_addr_r=0x01000000\0" \
-- 
1.9.1

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

[Jonathan Liu]

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.

Regards,
Jonathan

On Saturday, 6 February 2016, Stephen Warren <swarren at wwwdotorg.org
<javascript:_e(%7B%7D,'cvml','swarren@wwwdotorg.org');>> wrote:

> Update rpi-common.h's documentation that describes the rationale for
> choosing various addresses for standardized variables used by boot
> scripts. This comment was correct when written, but not updated when some
> of the values were changed.
>
> Fixes: 14006a567105 ("rpi: set fdt_addr_r to 0x00000100 to match default
> ...device_tree_address")
> Cc: Jonathan Liu <net147@gmail.com>
> Cc: Daniel Stone <daniels@collabora.com>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
>  include/configs/rpi-common.h | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/include/configs/rpi-common.h b/include/configs/rpi-common.h
> index 72f1e2d60b8f..00a5266dad15 100644
> --- a/include/configs/rpi-common.h
> +++ b/include/configs/rpi-common.h
> @@ -144,8 +144,14 @@
>  /*
>   * Memory layout for where various images get loaded by boot scripts:
>   *
> - * scriptaddr can be pretty much anywhere that doesn't conflict with
> something
> - *   else. Put it low in memory to avoid conflicts.
> + * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
> + *
> + * fdt_addr_r simply shouldn't overlap anything else. However, the RPi's
> + *   binary firmware loads a DT to address 0x100, so we choose this
> address to
> + *   match it. This allows custom boot scripts to pass this DT on to Linux
> + *   simply by not over-writing the data at this address. When using
> U-Boot,
> + *   U-Boot (and scripts it executes) typicaly ignore the DT loaded by
> the FW
> + *   and loads its own DT from disk (triggered by boot.scr or
> extlinux.conf).
>   *
>   * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
>   *   something else. Put it low in memory to avoid conflicts.
> @@ -159,11 +165,11 @@
>   *   this up to 16M allows for a sizable kernel to be decompressed below
> the
>   *   compressed load address.
>   *
> - * fdt_addr_r simply shouldn't overlap anything else. Choosing 32M allows
> for
> - *   the compressed kernel to be up to 16M too.
> + * scriptaddr can be pretty much anywhere that doesn't conflict with
> something
> + *   else. Choosing 32M allows for the compressed kernel to be up to 16M.
>   *
>   * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M
> allows
> - *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
> + *   for any boot script to be up to 1M, which is hopefully plenty.
>   */
>  #define ENV_MEM_LAYOUT_SETTINGS \
>         "fdt_addr_r=0x00000100\0" \
> --
> 1.9.1
>
>

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

[Stephen Warren]

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.

[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@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.
>

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

[Tom Rini]

On Fri, Feb 05, 2016 at 10:45:46PM -0700, Stephen Warren wrote:

> Update rpi-common.h's documentation that describes the rationale for
> choosing various addresses for standardized variables used by boot
> scripts. This comment was correct when written, but not updated when some
> of the values were changed.
> 
> Fixes: 14006a567105 ("rpi: set fdt_addr_r to 0x00000100 to match default
> ...device_tree_address")
> Cc: Jonathan Liu <net147@gmail.com>
> Cc: Daniel Stone <daniels@collabora.com>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

Applied to u-boot/master, 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/20160208/6e020ce4/attachment.sig>

[U-Boot] [U-Boot, 2/2] ARM: rpi: set fdt_high in the default environment

[Tom Rini]

On Fri, Feb 05, 2016 at 10:45:47PM -0700, Stephen Warren wrote:

> The ARM Linux kernel requires the DT to be in memory accessible early
> during the boot process. This always happens naturally on the RPi 1,
> since the maximum memory size of 512MiB, and additionally some of that
> is reserved for use by the GPU. The RPi 2 has 1GiB of RAM (minus some
> GPU usage), and so if the DT is relocated to the top of RAM, Linux cannot
> access it. Prevent this from happening by setting fdt_high.
> 
> Cc: Daniel Stone <daniels@collabora.com>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>

Applied to u-boot/master, 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/20160208/4b00a70c/attachment.sig>