[meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[Jonathan Liu]

A patch is added to check if the firmware loaded a device tree blob
into memory and set the fdt_addr_r variable if it is found. The U-Boot
script will then read the command line arguments generated by the
firmware from the device tree and boot the kernel with the command
line arguments and the loaded device tree.

This allows things like MAC address, board revision and serial number
to be correctly configured and options in config.txt to be used.

Signed-off-by: Jonathan Liu <net147@gmail.com>
---
Changes in v3:
 - Removed incorrect check if fdt_addr_r is already set. The check
   condition was inverted and fdt_addr_r variable is always set to
   0x100 by default.
Changes in v2:
 - Instead of setting device_tree_address to 0x100 in config.txt, patch
   U-Boot to detect the device tree blob address if it was loaded.

 recipes-bsp/rpi-u-boot-scr/files/boot.cmd          |  3 +
 .../rpi-u-boot-scr/files/raspberrypi/boot.cmd      |  6 --
 .../rpi-u-boot-scr/files/raspberrypi0/boot.cmd     |  6 --
 .../rpi-u-boot-scr/files/raspberrypi2/boot.cmd     |  6 --
 .../rpi-u-boot-scr/files/raspberrypi3/boot.cmd     |  6 --
 recipes-bsp/u-boot/files/rpi-fdt-addr.patch        | 77 ++++++++++++++++++++++
 recipes-bsp/u-boot/u-boot_%.bbappend               |  2 +
 7 files changed, 82 insertions(+), 24 deletions(-)
 create mode 100644 recipes-bsp/rpi-u-boot-scr/files/boot.cmd
 delete mode 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
 delete mode 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
 delete mode 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
 delete mode 100644 recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
 create mode 100644 recipes-bsp/u-boot/files/rpi-fdt-addr.patch

diff --git a/recipes-bsp/rpi-u-boot-scr/files/boot.cmd b/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
new file mode 100644
index 0000000..3f7e3b6
--- /dev/null
+++ b/recipes-bsp/rpi-u-boot-scr/files/boot.cmd
@@ -0,0 +1,3 @@
+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}
diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
deleted file mode 100644
index c86c758..0000000
--- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd
+++ /dev/null
@@ -1,6 +0,0 @@
-setenv fdtfile bcm2708-rpi-b.dtb
-setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd'
-mmc dev 0
-fatload mmc 0:1 ${kernel_addr_r} uImage
-fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
-bootm ${kernel_addr_r} - ${fdt_addr_r}
diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
deleted file mode 100644
index c86c758..0000000
--- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd
+++ /dev/null
@@ -1,6 +0,0 @@
-setenv fdtfile bcm2708-rpi-b.dtb
-setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd'
-mmc dev 0
-fatload mmc 0:1 ${kernel_addr_r} uImage
-fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
-bootm ${kernel_addr_r} - ${fdt_addr_r}
diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
deleted file mode 100644
index aa4ea64..0000000
--- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd
+++ /dev/null
@@ -1,6 +0,0 @@
-setenv fdtfile bcm2709-rpi-2-b.dtb
-setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd'
-mmc dev 0
-fatload mmc 0:1 ${kernel_addr_r} uImage
-fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
-bootm ${kernel_addr_r} - ${fdt_addr_r}
diff --git a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd b/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
deleted file mode 100644
index 2950856..0000000
--- a/recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd
+++ /dev/null
@@ -1,6 +0,0 @@
-setenv fdtfile bcm2710-rpi-3-b.dtb
-setenv bootargs 'earlyprintk console=tty0 console=ttyAMA0 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait noinitrd'
-mmc dev 0
-fatload mmc 0:1 ${kernel_addr_r} uImage
-fatload mmc 0:1 ${fdt_addr_r} ${fdtfile}
-bootm ${kernel_addr_r} - ${fdt_addr_r}
diff --git a/recipes-bsp/u-boot/files/rpi-fdt-addr.patch b/recipes-bsp/u-boot/files/rpi-fdt-addr.patch
new file mode 100644
index 0000000..5dd370a
--- /dev/null
+++ b/recipes-bsp/u-boot/files/rpi-fdt-addr.patch
@@ -0,0 +1,77 @@
+From 0bb380da174f9372a706b5a4914a4c06ad7fbfdf Mon Sep 17 00:00:00 2001
+From: Jonathan Liu <net147@gmail.com>
+Date: Sat, 5 Nov 2016 12:43:47 +1100
+Subject: [PATCH] rpi: Set fdt_addr_r to device tree address from firmware
+
+The Raspberry Pi firmware will load a patched device tree blob into
+memory if a trailer is added to the U-Boot binary indicating it is
+DT-capable using "mkknlimg --dtok" or if using firmware release 4.4
+or later and no trailer is present.
+
+In this case, U-Boot is executed as if it were the Linux kernel and
+the r2 register is set to the address of the patched device tree blob
+in memory. We can check if the blob is loaded by checking for the
+device tree magic constant 0xedfe0dd0 (little endian equivalent of
+the big endian 0xd00dfeed constant) at the address stored in r2.
+If the magic constant is present, the fdt_addr_r variable is set to
+r2 so that U-Boot scripts can access the patched device tree blob.
+
+Upstream-Status: Pending
+
+Signed-off-by: Jonathan Liu <net147@gmail.com>
+---
+ board/raspberrypi/rpi/rpi.c | 22 ++++++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
+index 6245b36..53cf9e5 100644
+--- a/board/raspberrypi/rpi/rpi.c
++++ b/board/raspberrypi/rpi/rpi.c
+@@ -23,8 +23,18 @@
+ #include <asm/armv8/mmu.h>
+ #endif
+ 
++void save_boot_params_ret(void);
++
+ DECLARE_GLOBAL_DATA_PTR;
+ 
++static u32 dtb_address __attribute__ ((section(".data")));
++
++void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
++{
++	dtb_address = r2;
++	save_boot_params_ret();
++}
++
+ static const struct bcm2835_gpio_platdata gpio_platdata = {
+ 	.base = BCM2835_GPIO_BASE,
+ };
+@@ -274,6 +284,17 @@ int dram_init(void)
+ 	return 0;
+ }
+ 
++static void set_fdt_addr(void)
++{
++	u32 *dt_magic = dtb_address;
++	char s[11];
++
++	if (*dt_magic == 0xedfe0dd0) {
++		snprintf(s, sizeof(s), "0x%x", dtb_address);
++		setenv("fdt_addr_r", s);
++	}
++}
++
+ static void set_fdtfile(void)
+ {
+ 	const char *fdtfile;
+@@ -356,6 +377,7 @@ static void set_serial_number(void)
+ 
+ int misc_init_r(void)
+ {
++	set_fdt_addr();
+ 	set_fdtfile();
+ 	set_usbethaddr();
+ #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+-- 
+2.10.1
+
diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u-boot/u-boot_%.bbappend
index 3781666..fbb29e9 100644
--- a/recipes-bsp/u-boot/u-boot_%.bbappend
+++ b/recipes-bsp/u-boot/u-boot_%.bbappend
@@ -1 +1,3 @@
+FILESEXTRAPATHS_prepend_rpi := "${THISDIR}/files:"
 RDEPENDS_${PN}_append_rpi = " rpi-u-boot-scr"
+SRC_URI_append_rpi = " file://rpi-fdt-addr.patch"
-- 
2.10.1

Re: [meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[Tom Rini]

On Sat, Nov 05, 2016 at 12:50:07PM +1100, Jonathan Liu wrote:

[snip]
> +++ b/recipes-bsp/u-boot/files/rpi-fdt-addr.patch
> @@ -0,0 +1,77 @@
> +From 0bb380da174f9372a706b5a4914a4c06ad7fbfdf Mon Sep 17 00:00:00 2001
> +From: Jonathan Liu <net147@gmail.com>
> +Date: Sat, 5 Nov 2016 12:43:47 +1100
> +Subject: [PATCH] rpi: Set fdt_addr_r to device tree address from firmware
> +
> +The Raspberry Pi firmware will load a patched device tree blob into
> +memory if a trailer is added to the U-Boot binary indicating it is
> +DT-capable using "mkknlimg --dtok" or if using firmware release 4.4
> +or later and no trailer is present.
> +
> +In this case, U-Boot is executed as if it were the Linux kernel and
> +the r2 register is set to the address of the patched device tree blob
> +in memory. We can check if the blob is loaded by checking for the
> +device tree magic constant 0xedfe0dd0 (little endian equivalent of
> +the big endian 0xd00dfeed constant) at the address stored in r2.
> +If the magic constant is present, the fdt_addr_r variable is set to
> +r2 so that U-Boot scripts can access the patched device tree blob.
> +
> +Upstream-Status: Pending

Please note that upstream we are looking at:
https://patchwork.ozlabs.org/patch/690769/
https://patchwork.ozlabs.org/patch/690770/

-- 
Tom

Re: [meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[Paul Barker]

On Sat,  5 Nov 2016 12:50:07 +1100
Jonathan Liu <net147@gmail.com> wrote:

> A patch is added to check if the firmware loaded a device tree blob
> into memory and set the fdt_addr_r variable if it is found. The U-Boot
> script will then read the command line arguments generated by the
> firmware from the device tree and boot the kernel with the command
> line arguments and the loaded device tree.
> 
> This allows things like MAC address, board revision and serial number
> to be correctly configured and options in config.txt to be used.
> 
> Signed-off-by: Jonathan Liu <net147@gmail.com>
> ---
> Changes in v3:
>  - Removed incorrect check if fdt_addr_r is already set. The check
>    condition was inverted and fdt_addr_r variable is always set to
>    0x100 by default.
> Changes in v2:
>  - Instead of setting device_tree_address to 0x100 in config.txt, patch
>    U-Boot to detect the device tree blob address if it was loaded.
> 

I'm still getting the same "Could not find a valid device tree" failure
on the model B+.

I've tried running vcdbg but got the following error from the kernel

    vc_mem_mmap: length 4096 is too big

vcdbg itself then said:

    debug_sym: AccessVideoCoreMemory: mmap failed: Invalid argument(22)
    debug_sym: OpenVideoCoreMemoryFileWithOffset: ReadVideoCoreMemory @VC_SYMBOL_BASE_OFFSET (0x00002800) failed

    Unable to open videocore memory access: -5

This was after adding "dtdebug=on" to config.txt

Not sure where to go next with this. I might need to go off on a Yak
shaving mission and find out why the mmap is failing.

Thanks,
Paul

Re: [meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[Jonathan Liu]

Hi Paul,

On 6 November 2016 at 22:57, Paul Barker <paul@paulbarker.me.uk> wrote:
> On Sat,  5 Nov 2016 12:50:07 +1100
> Jonathan Liu <net147@gmail.com> wrote:
>
>> A patch is added to check if the firmware loaded a device tree blob
>> into memory and set the fdt_addr_r variable if it is found. The U-Boot
>> script will then read the command line arguments generated by the
>> firmware from the device tree and boot the kernel with the command
>> line arguments and the loaded device tree.
>>
>> This allows things like MAC address, board revision and serial number
>> to be correctly configured and options in config.txt to be used.
>>
>> Signed-off-by: Jonathan Liu <net147@gmail.com>
>> ---
>> Changes in v3:
>>  - Removed incorrect check if fdt_addr_r is already set. The check
>>    condition was inverted and fdt_addr_r variable is always set to
>>    0x100 by default.
>> Changes in v2:
>>  - Instead of setting device_tree_address to 0x100 in config.txt, patch
>>    U-Boot to detect the device tree blob address if it was loaded.
>>
>
> I'm still getting the same "Could not find a valid device tree" failure
> on the model B+.
>
> I've tried running vcdbg but got the following error from the kernel
>
>     vc_mem_mmap: length 4096 is too big
>
> vcdbg itself then said:
>
>     debug_sym: AccessVideoCoreMemory: mmap failed: Invalid argument(22)
>     debug_sym: OpenVideoCoreMemoryFileWithOffset: ReadVideoCoreMemory @VC_SYMBOL_BASE_OFFSET (0x00002800) failed
>
>     Unable to open videocore memory access: -5
>
> This was after adding "dtdebug=on" to config.txt
>
> Not sure where to go next with this. I might need to go off on a Yak
> shaving mission and find out why the mmap is failing.

A patch is being worked on upstream - https://patchwork.ozlabs.org/patch/692412/
I think we will wait until it is accepted upstream and then backport it.

Regards,
Jonathan

Re: [meta-raspberrypi][PATCH v3] u-boot: Simplify boot script

[Paul Barker]

On Thu, 10 Nov 2016 12:57:02 +1100
Jonathan Liu <net147@gmail.com> wrote:

> Hi Paul,
> 
> On 6 November 2016 at 22:57, Paul Barker <paul@paulbarker.me.uk> wrote:
> > On Sat,  5 Nov 2016 12:50:07 +1100
> > Jonathan Liu <net147@gmail.com> wrote:
> >
> >> A patch is added to check if the firmware loaded a device tree blob
> >> into memory and set the fdt_addr_r variable if it is found. The U-Boot
> >> script will then read the command line arguments generated by the
> >> firmware from the device tree and boot the kernel with the command
> >> line arguments and the loaded device tree.
> >>
> >> This allows things like MAC address, board revision and serial number
> >> to be correctly configured and options in config.txt to be used.
> >>
> >> Signed-off-by: Jonathan Liu <net147@gmail.com>
> >> ---
> >> Changes in v3:
> >>  - Removed incorrect check if fdt_addr_r is already set. The check
> >>    condition was inverted and fdt_addr_r variable is always set to
> >>    0x100 by default.
> >> Changes in v2:
> >>  - Instead of setting device_tree_address to 0x100 in config.txt, patch
> >>    U-Boot to detect the device tree blob address if it was loaded.
> >>
> >
> > I'm still getting the same "Could not find a valid device tree" failure
> > on the model B+.
> >
> > I've tried running vcdbg but got the following error from the kernel
> >
> >     vc_mem_mmap: length 4096 is too big
> >
> > vcdbg itself then said:
> >
> >     debug_sym: AccessVideoCoreMemory: mmap failed: Invalid argument(22)
> >     debug_sym: OpenVideoCoreMemoryFileWithOffset: ReadVideoCoreMemory @VC_SYMBOL_BASE_OFFSET (0x00002800) failed
> >
> >     Unable to open videocore memory access: -5
> >
> > This was after adding "dtdebug=on" to config.txt
> >
> > Not sure where to go next with this. I might need to go off on a Yak
> > shaving mission and find out why the mmap is failing.
> 
> A patch is being worked on upstream - https://patchwork.ozlabs.org/patch/692412/
> I think we will wait until it is accepted upstream and then backport it.
> 

Ok that makes sense. I'm happy to test that out once it's ready for
backport.

Thanks,
Paul