u-boot: Simplify boot script

PATCH Superseded Jonathan Liu 3 participants 5 messages Nov 5, 2016 – Nov 12, 2016 Broadcom BCM2711/BCM2835 Arm architecture

lore

Share & tools

lore

Jonathan Liu

author

2016-11-05 01:50 UTC #0 lore raw

PATCH v3 1/1 u-boot: Simplify boot script

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 <[email protected]>

---
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

recipes-bsp/rpi-u-boot-scr/files/boot.cmd new file +3 -0

new file mode 100644
index 0000000..3f7e3b6
@@ -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}

recipes-bsp/rpi-u-boot-scr/files/raspberrypi/boot.cmd deleted +0 -6

deleted file mode 100644
index c86c758..0000000
@@ -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}

recipes-bsp/rpi-u-boot-scr/files/raspberrypi0/boot.cmd deleted +0 -6

deleted file mode 100644
index c86c758..0000000
@@ -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}

recipes-bsp/rpi-u-boot-scr/files/raspberrypi2/boot.cmd deleted +0 -6

deleted file mode 100644
index aa4ea64..0000000
@@ -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}

recipes-bsp/rpi-u-boot-scr/files/raspberrypi3/boot.cmd deleted +0 -6

deleted file mode 100644
index 2950856..0000000
@@ -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}

recipes-bsp/u-boot/files/rpi-fdt-addr.patch new file +77 -0

77 lines not on this page · raw message

recipes-bsp/u-boot/u-boot_%.bbappend +2 -0

index 3781666..fbb29e9 100644
@@ -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"

Signature · 1 line

2.10.1

Tom Rini

2016-11-05 17:47 UTC #1 lore raw

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

[snip]

Quoted 11 lines

+++ b/recipes-bsp/u-boot/files/rpi-fdt-addr.patch

recipes-bsp/u-boot/files/rpi-fdt-addr.patch new file +9 -0

@@ -0,0 +1,77 @@
+From 0bb380da174f9372a706b5a4914a4c06ad7fbfdf Mon Sep 17 00:00:00 2001
+From: Jonathan Liu <[email protected]>
+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.

recipes-bsp/u-boot/files/rpi-fdt-addr.patch line 19

Quoted 10 lines

recipes-bsp/u-boot/files/rpi-fdt-addr.patch new file +10 -0

+
+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/

Signature · 1 line

Tom

Paul Barker

2016-11-06 12:13 UTC #2 lore raw

In reply to Jonathan Liu

Quoted 10 lines · On Sat, 5 Nov 2016 12:50:07 +1100 Jonathan Liu <[email protected]> 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 <[email protected]>

Quoted 9 lines

---
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

Jonathan Liu

author

2016-11-10 01:57 UTC #3 lore raw

Hi Paul,

Quoted 35 lines · Paul Barker

Quoted 10 lines · On Sat, 5 Nov 2016 12:50:07 +1100 Jonathan Liu <[email protected]> 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 <[email protected]>
Quoted 9 lines
---
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

Quoted 6 lines

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

Paul Barker

2016-11-12 12:51 UTC #4 lore raw

Quoted 40 lines · On Thu, 10 Nov 2016 12:57:02 +1100 Jonathan Liu <[email protected]> wrote:

Hi Paul,
Quoted 37 lines · Paul Barker
Quoted 10 lines · On Sat, 5 Nov 2016 12:50:07 +1100 Jonathan Liu <[email protected]> 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 <[email protected]>
Quoted 9 lines
---
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

Quoted 8 lines

Quoted 4 lines
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