[U-Boot] pull request: raspberry pi updates
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
--- The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
---------------------------------------------------------------- - fix complation error for CONFIG_USB - update RPi3 DTBs to v5.1-rc6 state - add defconfig for RPi3 B+ - Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
---------------------------------------------------------------- Berkus Decker (1): ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER
Heinrich Schuchardt (2): fdt: update bcm283x device tree sources to Linux 5.1-rc6 state ARM: defconfig: add Raspberry Pi 3 Model B+
akaher (1): Fix compilation error if CONFIG_USB is disabled
arch/arm/dts/Makefile | 13 +- arch/arm/dts/bcm2835-rpi-a-plus.dts | 15 ++- arch/arm/dts/bcm2835-rpi-a.dts | 9 +- arch/arm/dts/bcm2835-rpi-b-plus.dts | 15 ++- arch/arm/dts/bcm2835-rpi-b-rev2.dts | 11 +- arch/arm/dts/bcm2835-rpi-b.dts | 9 +- arch/arm/dts/bcm2835-rpi-cm1-io1.dts | 88 ++++++++++++++ arch/arm/dts/bcm2835-rpi-cm1.dtsi | 34 ++++++ arch/arm/dts/bcm2835-rpi-zero-w.dts | 123 +++++++++++++++++-- arch/arm/dts/bcm2835-rpi-zero.dts | 105 ++++++++++++++++ arch/arm/dts/bcm2835-rpi.dtsi | 22 ++-- arch/arm/dts/bcm2835.dtsi | 7 +- arch/arm/dts/bcm2836-rpi-2-b.dts | 81 ++++++++++++- arch/arm/dts/bcm2836-rpi.dtsi | 6 + arch/arm/dts/bcm2836.dtsi | 25 ++-- arch/arm/dts/bcm2837-rpi-3-a-plus.dts | 175 +++++++++++++++++++++++++++ arch/arm/dts/bcm2837-rpi-3-b-plus.dts | 178 ++++++++++++++++++++++++++++ arch/arm/dts/bcm2837-rpi-3-b.dts | 128 +++++++++++++++++++- arch/arm/dts/bcm2837-rpi-cm3-io3.dts | 87 ++++++++++++++ arch/arm/dts/bcm2837-rpi-cm3.dtsi | 52 ++++++++ arch/arm/dts/bcm2837.dtsi | 20 ++-- arch/arm/dts/bcm283x-rpi-lan7515.dtsi | 41 +++++++ arch/arm/dts/bcm283x-rpi-smsc9512.dtsi | 1 + arch/arm/dts/bcm283x-rpi-usb-otg.dtsi | 11 ++ arch/arm/dts/bcm283x.dtsi | 57 +++++++-- arch/arm/mach-bcm283x/include/mach/mbox.h | 2 +- configs/rpi_3_b_plus_defconfig | 43 +++++++ include/configs/rpi.h | 36 +++++- include/dt-bindings/clock/bcm2835-aux.h | 10 +- include/dt-bindings/clock/bcm2835.h | 10 +- include/dt-bindings/net/microchip-lan78xx.h | 21 ++++ include/dt-bindings/pinctrl/bcm2835.h | 8 +- include/dt-bindings/soc/bcm2835-pm.h | 28 +++++ 33 files changed, 1365 insertions(+), 106 deletions(-) create mode 100644 arch/arm/dts/bcm2835-rpi-cm1-io1.dts create mode 100644 arch/arm/dts/bcm2835-rpi-cm1.dtsi create mode 100644 arch/arm/dts/bcm2835-rpi-zero.dts create mode 100644 arch/arm/dts/bcm2836-rpi.dtsi create mode 100644 arch/arm/dts/bcm2837-rpi-3-a-plus.dts create mode 100644 arch/arm/dts/bcm2837-rpi-3-b-plus.dts create mode 100644 arch/arm/dts/bcm2837-rpi-cm3-io3.dts create mode 100644 arch/arm/dts/bcm2837-rpi-cm3.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi-lan7515.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi-usb-otg.dtsi create mode 100644 configs/rpi_3_b_plus_defconfig create mode 100644 include/dt-bindings/net/microchip-lan78xx.h create mode 100644 include/dt-bindings/soc/bcm2835-pm.h
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote:
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
- Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
Berkus Decker (1): ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER
Heinrich Schuchardt (2): fdt: update bcm283x device tree sources to Linux 5.1-rc6 state ARM: defconfig: add Raspberry Pi 3 Model B+
akaher (1): Fix compilation error if CONFIG_USB is disabled
arch/arm/dts/Makefile | 13 +- arch/arm/dts/bcm2835-rpi-a-plus.dts | 15 ++- arch/arm/dts/bcm2835-rpi-a.dts | 9 +- arch/arm/dts/bcm2835-rpi-b-plus.dts | 15 ++- arch/arm/dts/bcm2835-rpi-b-rev2.dts | 11 +- arch/arm/dts/bcm2835-rpi-b.dts | 9 +- arch/arm/dts/bcm2835-rpi-cm1-io1.dts | 88 ++++++++++++++ arch/arm/dts/bcm2835-rpi-cm1.dtsi | 34 ++++++ arch/arm/dts/bcm2835-rpi-zero-w.dts | 123 +++++++++++++++++-- arch/arm/dts/bcm2835-rpi-zero.dts | 105 ++++++++++++++++ arch/arm/dts/bcm2835-rpi.dtsi | 22 ++-- arch/arm/dts/bcm2835.dtsi | 7 +- arch/arm/dts/bcm2836-rpi-2-b.dts | 81 ++++++++++++- arch/arm/dts/bcm2836-rpi.dtsi | 6 + arch/arm/dts/bcm2836.dtsi | 25 ++-- arch/arm/dts/bcm2837-rpi-3-a-plus.dts | 175 +++++++++++++++++++++++++++ arch/arm/dts/bcm2837-rpi-3-b-plus.dts | 178 ++++++++++++++++++++++++++++ arch/arm/dts/bcm2837-rpi-3-b.dts | 128 +++++++++++++++++++- arch/arm/dts/bcm2837-rpi-cm3-io3.dts | 87 ++++++++++++++ arch/arm/dts/bcm2837-rpi-cm3.dtsi | 52 ++++++++ arch/arm/dts/bcm2837.dtsi | 20 ++-- arch/arm/dts/bcm283x-rpi-lan7515.dtsi | 41 +++++++ arch/arm/dts/bcm283x-rpi-smsc9512.dtsi | 1 + arch/arm/dts/bcm283x-rpi-usb-otg.dtsi | 11 ++ arch/arm/dts/bcm283x.dtsi | 57 +++++++-- arch/arm/mach-bcm283x/include/mach/mbox.h | 2 +- configs/rpi_3_b_plus_defconfig | 43 +++++++ include/configs/rpi.h | 36 +++++- include/dt-bindings/clock/bcm2835-aux.h | 10 +- include/dt-bindings/clock/bcm2835.h | 10 +- include/dt-bindings/net/microchip-lan78xx.h | 21 ++++ include/dt-bindings/pinctrl/bcm2835.h | 8 +- include/dt-bindings/soc/bcm2835-pm.h | 28 +++++ 33 files changed, 1365 insertions(+), 106 deletions(-) create mode 100644 arch/arm/dts/bcm2835-rpi-cm1-io1.dts create mode 100644 arch/arm/dts/bcm2835-rpi-cm1.dtsi create mode 100644 arch/arm/dts/bcm2835-rpi-zero.dts create mode 100644 arch/arm/dts/bcm2836-rpi.dtsi create mode 100644 arch/arm/dts/bcm2837-rpi-3-a-plus.dts create mode 100644 arch/arm/dts/bcm2837-rpi-3-b-plus.dts create mode 100644 arch/arm/dts/bcm2837-rpi-cm3-io3.dts create mode 100644 arch/arm/dts/bcm2837-rpi-cm3.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi-lan7515.dtsi create mode 100644 arch/arm/dts/bcm283x-rpi-usb-otg.dtsi create mode 100644 configs/rpi_3_b_plus_defconfig create mode 100644 include/dt-bindings/net/microchip-lan78xx.h create mode 100644 include/dt-bindings/soc/bcm2835-pm.h _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote:
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
- Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
Berkus Decker (1): ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER
For the record: https://patchwork.ozlabs.org/patch/1024140/
Heinrich Schuchardt (2): fdt: update bcm283x device tree sources to Linux 5.1-rc6 state ARM: defconfig: add Raspberry Pi 3 Model B+
https://patchwork.ozlabs.org/patch/1092162/ https://patchwork.ozlabs.org/patch/1092161/
akaher (1): Fix compilation error if CONFIG_USB is disabled
I don't see this one in patchwork for some reason but it started out at https://lists.denx.de/pipermail/u-boot/2019-April/363693.html
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote:
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
Best regards
Heinrich
- Fix BCM2835_MBOX_TAG_TEST_PIXEL_ORDER define
Berkus Decker (1): ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER
For the record: https://patchwork.ozlabs.org/patch/1024140/
Heinrich Schuchardt (2): fdt: update bcm283x device tree sources to Linux 5.1-rc6 state ARM: defconfig: add Raspberry Pi 3 Model B+
https://patchwork.ozlabs.org/patch/1092162/ https://patchwork.ozlabs.org/patch/1092161/
akaher (1): Fix compilation error if CONFIG_USB is disabled
I don't see this one in patchwork for some reason but it started out at https://lists.denx.de/pipermail/u-boot/2019-April/363693.html
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote:
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote:
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Regards
Heinrich
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote:
Hi Tom,
Please have a look on the following patches.
Regards, Matthias
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
are available in the Git repository at:
https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:
ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 +0200)
- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
Hi Matthias,
Have these been out on the list for general review? I don't remember seeing them.
On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: > >Hi Tom, > >Please have a look on the following patches. > >Regards, >Matthias > >--- >The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: > > Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) > >are available in the Git repository at: > > https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 > >for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: > > ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >+0200) > >---------------------------------------------------------------- >- fix complation error for CONFIG_USB >- update RPi3 DTBs to v5.1-rc6 state >- add defconfig for RPi3 B+
Why do we need a separate config when it's detected and works perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote: >Hi Matthias, > >Have these been out on the list for general review? I don't remember >seeing them. > >On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: >> >>Hi Tom, >> >>Please have a look on the following patches. >> >>Regards, >>Matthias >> >>--- >>The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: >> >> Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) >> >>are available in the Git repository at: >> >> https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 >> >>for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: >> >> ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >>+0200) >> >>---------------------------------------------------------------- >>- fix complation error for CONFIG_USB >>- update RPi3 DTBs to v5.1-rc6 state >>- add defconfig for RPi3 B+ > >Why do we need a separate config when it's detected and works >perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
The firmware includes device trees
https://github.com/raspberrypi/firmware/tree/master/boot
At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to better use it:
https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-usin... https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9...
From 121d9d775c6af6ba5d1c3f198f478404a9196f84 Mon Sep 17 00:00:00 2001
From: Alexander Graf agraf@suse.de Date: Wed, 21 Feb 2018 17:41:13 +0100 Subject: [PATCH] rpi: Use firmware provided device tree
Currently the firmware generates a device tree for us that we could just use to adjust ourselves. We then on boot throw that away and use our own built-in device tree to configure device access.
This is bad for a multitude of reasons. For starters, it breaks overlay support in config.txt, confusing users. Much worse however is that we are stuck with individual U-Boot builds per board. The firmware can easily give us the right DT depending on the target board and revision though.
So let's use the firmware provided device tree instead. That way U-Boot as well as payloads loaded by it can automatically adapt to variants of RPi hardware.
Signed-off-by: Alexander Graf agraf@suse.de Signed-off-by: Guillaume Gardet guillaume.gardet@free.fr --- configs/rpi_0_w_defconfig | 2 +- configs/rpi_2_defconfig | 2 +- configs/rpi_3_32b_defconfig | 2 +- configs/rpi_3_defconfig | 2 +- configs/rpi_defconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index 1ab35f1b253..d26010efac1 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 53aa554cc74..2b6bbf1b4b4 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2836-rpi-2-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig index c33ea58438a..c3fe878aa36 100644 --- a/configs/rpi_3_32b_defconfig +++ b/configs/rpi_3_32b_defconfig @@ -15,7 +15,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig index 98573bb89a4..6895228bdb5 100644 --- a/configs/rpi_3_defconfig +++ b/configs/rpi_3_defconfig @@ -15,7 +15,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index bd15c98697b..477a1bf789f 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
On 6/25/19 5:51 AM, Jonathan Gray wrote:
On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote: > On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote: >> Hi Matthias, >> >> Have these been out on the list for general review? I don't remember >> seeing them. >> >> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: >>> >>> Hi Tom, >>> >>> Please have a look on the following patches. >>> >>> Regards, >>> Matthias >>> >>> --- >>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: >>> >>> Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) >>> >>> are available in the Git repository at: >>> >>> https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 >>> >>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: >>> >>> ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >>> +0200) >>> >>> ---------------------------------------------------------------- >>> - fix complation error for CONFIG_USB >>> - update RPi3 DTBs to v5.1-rc6 state >>> - add defconfig for RPi3 B+ >> >> Why do we need a separate config when it's detected and works >> perfectly well with the standard rpi_3 and rpi_3_32b configs? > > Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
The firmware includes device trees
https://github.com/raspberrypi/firmware/tree/master/boot
At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to better use it:
https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-usin... https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9...
From 121d9d775c6af6ba5d1c3f198f478404a9196f84 Mon Sep 17 00:00:00 2001
From: Alexander Graf agraf@suse.de Date: Wed, 21 Feb 2018 17:41:13 +0100 Subject: [PATCH] rpi: Use firmware provided device tree
Currently the firmware generates a device tree for us that we could just use to adjust ourselves. We then on boot throw that away and use our own built-in device tree to configure device access.
This is bad for a multitude of reasons. For starters, it breaks overlay support in config.txt, confusing users. Much worse however is that we are stuck with individual U-Boot builds per board. The firmware can easily give us the right DT depending on the target board and revision though.
So let's use the firmware provided device tree instead. That way U-Boot as well as payloads loaded by it can automatically adapt to variants of RPi hardware.
Signed-off-by: Alexander Graf agraf@suse.de Signed-off-by: Guillaume Gardet guillaume.gardet@free.fr
This patch never made it into mainline U-Boot but it is still applicable.
So what is your suggestion? Drop all RPI device trees and apply this patch? (CCing Alex)
Why does the patch not remove CONFIG_DEFAULT_DEVICE_TREE? Why does the patch not reduce the number of config files to 2: one for 32bit and one for 64bit if everything else is given by the board provided DTB?
Regards
Heinrich
configs/rpi_0_w_defconfig | 2 +- configs/rpi_2_defconfig | 2 +- configs/rpi_3_32b_defconfig | 2 +- configs/rpi_3_defconfig | 2 +- configs/rpi_defconfig | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index 1ab35f1b253..d26010efac1 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index 53aa554cc74..2b6bbf1b4b4 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2836-rpi-2-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig index c33ea58438a..c3fe878aa36 100644 --- a/configs/rpi_3_32b_defconfig +++ b/configs/rpi_3_32b_defconfig @@ -15,7 +15,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig index 98573bb89a4..6895228bdb5 100644 --- a/configs/rpi_3_defconfig +++ b/configs/rpi_3_defconfig @@ -15,7 +15,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index bd15c98697b..477a1bf789f 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y CONFIG_CMD_MMC=y CONFIG_CMD_USB=y CONFIG_CMD_FS_UUID=y -CONFIG_OF_EMBED=y +CONFIG_OF_BOARD=y CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-b" CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
On 24/06/2019 20:11, Tom Rini wrote:
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote: > Hi Matthias, > > Have these been out on the list for general review? I don't remember > seeing them. > > On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: >> >> Hi Tom, >> >> Please have a look on the following patches. >> >> Regards, >> Matthias >> >> --- >> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: >> >> Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) >> >> are available in the Git repository at: >> >> https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 >> >> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: >> >> ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >> +0200) >> >> ---------------------------------------------------------------- >> - fix complation error for CONFIG_USB >> - update RPi3 DTBs to v5.1-rc6 state >> - add defconfig for RPi3 B+ > > Why do we need a separate config when it's detected and works > perfectly well with the standard rpi_3 and rpi_3_32b configs?
Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
Tom, sorry for my late answer. I was looking into this. I'll put it on top of my list for today. I think you are right, but I want to first understand 100% the implications of CONFIG_OF_EMBED.
Regards, Matthias
On 25/06/2019 09:58, Matthias Brugger wrote:
On 24/06/2019 20:11, Tom Rini wrote:
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 9:56 PM, Tom Rini wrote: > On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote: >> Hi Matthias, >> >> Have these been out on the list for general review? I don't remember >> seeing them. >> >> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: >>> >>> Hi Tom, >>> >>> Please have a look on the following patches. >>> >>> Regards, >>> Matthias >>> >>> --- >>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: >>> >>> Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) >>> >>> are available in the Git repository at: >>> >>> https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 >>> >>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: >>> >>> ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >>> +0200) >>> >>> ---------------------------------------------------------------- >>> - fix complation error for CONFIG_USB >>> - update RPi3 DTBs to v5.1-rc6 state >>> - add defconfig for RPi3 B+ >> >> Why do we need a separate config when it's detected and works >> perfectly well with the standard rpi_3 and rpi_3_32b configs? > > Good question. It came from Heinrich, so Heinrich?
If we call the bootefi command without a OS supplied device tree the U-Boot device tree is passed to the operating system.
So we need a device tree which is a complete description of the respective system.
On the Linaro boot-architecture list there has been a lengthy discussion with Linaro people thinking that it is the responsibility of the hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
Tom, sorry for my late answer. I was looking into this. I'll put it on top of my list for today. I think you are right, but I want to first understand 100% the implications of CONFIG_OF_EMBED.
Ok here is my take on that. RPi config uses OF_EMBEDED, MISC_INIT_R and DISTRO_DEFAULTS.
Environment variable fdtfile is set to the model->fdtile in board_init, which gets passed in depending on the RPi we are running on. In misc_init_r the fdt_addr points to the build-in DTB (set_fdt_addr) and fdtfile variable is set. IN initr_env fdtcontroladdr is set to the build-in DTB as well.
I'm not sure what distro boot does with that, as I find it really hard to deduce what it is doing from the header file. If anybody can tell how to easily decrypt that, that would be helpfull.
Regards, Matthias
On 26/06/2019 13:09, Matthias Brugger wrote:
On 25/06/2019 09:58, Matthias Brugger wrote:
On 24/06/2019 20:11, Tom Rini wrote:
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote: > On 6/12/19 9:56 PM, Tom Rini wrote: >> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote: >>> Hi Matthias, >>> >>> Have these been out on the list for general review? I don't remember >>> seeing them. >>> >>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: >>>> >>>> Hi Tom, >>>> >>>> Please have a look on the following patches. >>>> >>>> Regards, >>>> Matthias >>>> >>>> --- >>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: >>>> >>>> Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) >>>> >>>> are available in the Git repository at: >>>> >>>> https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 >>>> >>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: >>>> >>>> ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >>>> +0200) >>>> >>>> ---------------------------------------------------------------- >>>> - fix complation error for CONFIG_USB >>>> - update RPi3 DTBs to v5.1-rc6 state >>>> - add defconfig for RPi3 B+ >>> >>> Why do we need a separate config when it's detected and works >>> perfectly well with the standard rpi_3 and rpi_3_32b configs? >> >> Good question. It came from Heinrich, so Heinrich? > > If we call the bootefi command without a OS supplied device tree the > U-Boot device tree is passed to the operating system. > > So we need a device tree which is a complete description of the > respective system. > > On the Linaro boot-architecture list there has been a lengthy discussion > with Linaro people thinking that it is the responsibility of the > hardware and firmware to provide the correct device tree and not of the OS.
OK, but on Pi aren't we passed, and pass along, the dtb from the previous stage?
Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
Tom, sorry for my late answer. I was looking into this. I'll put it on top of my list for today. I think you are right, but I want to first understand 100% the implications of CONFIG_OF_EMBED.
Ok here is my take on that. RPi config uses OF_EMBEDED, MISC_INIT_R and DISTRO_DEFAULTS.
Environment variable fdtfile is set to the model->fdtile in board_init, which gets passed in depending on the RPi we are running on. In misc_init_r the fdt_addr points to the build-in DTB (set_fdt_addr) and fdtfile variable is set. IN initr_env fdtcontroladdr is set to the build-in DTB as well.
I'm not sure what distro boot does with that, as I find it really hard to deduce what it is doing from the header file. If anybody can tell how to easily decrypt that, that would be helpfull.
So after looking more into this (holiday in between, sorry): distro boot tries to load a device tree from the boot medium, if this fails it uses the embedded device tree blob.
Tom, I suppose you refered to the fact that you can get a device tree from the FW that starts u-boot. This is not enabled in the defconfig. So from my point of view it makes sense to create a new config which uses the DTS for the board. You can't be sure that your setup has the dtb in the right folder, which is used by distro boot before falling back to the embedded DTB.
Regards, Matthias
On Fri, Jul 05, 2019 at 01:27:24PM +0200, Matthias Brugger wrote:
On 26/06/2019 13:09, Matthias Brugger wrote:
On 25/06/2019 09:58, Matthias Brugger wrote:
On 24/06/2019 20:11, Tom Rini wrote:
On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
On 6/12/19 10:08 PM, Tom Rini wrote: > On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote: >> On 6/12/19 9:56 PM, Tom Rini wrote: >>> On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote: >>>> Hi Matthias, >>>> >>>> Have these been out on the list for general review? I don't remember >>>> seeing them. >>>> >>>> On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger mbrugger@suse.com wrote: >>>>> >>>>> Hi Tom, >>>>> >>>>> Please have a look on the following patches. >>>>> >>>>> Regards, >>>>> Matthias >>>>> >>>>> --- >>>>> The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218: >>>>> >>>>> Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400) >>>>> >>>>> are available in the Git repository at: >>>>> >>>>> https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07 >>>>> >>>>> for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6: >>>>> >>>>> ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 12:23:46 >>>>> +0200) >>>>> >>>>> ---------------------------------------------------------------- >>>>> - fix complation error for CONFIG_USB >>>>> - update RPi3 DTBs to v5.1-rc6 state >>>>> - add defconfig for RPi3 B+ >>>> >>>> Why do we need a separate config when it's detected and works >>>> perfectly well with the standard rpi_3 and rpi_3_32b configs? >>> >>> Good question. It came from Heinrich, so Heinrich? >> >> If we call the bootefi command without a OS supplied device tree the >> U-Boot device tree is passed to the operating system. >> >> So we need a device tree which is a complete description of the >> respective system. >> >> On the Linaro boot-architecture list there has been a lengthy discussion >> with Linaro people thinking that it is the responsibility of the >> hardware and firmware to provide the correct device tree and not of the OS. > > OK, but on Pi aren't we passed, and pass along, the dtb from the > previous stage? > Currently `bootefi` uses as default what it finds in $fdt_control_addr and provides this to GRUB, Linux, or any other payload.
Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass in a device tree, that U-Boot then uses?
I haven't taken this as I haven't gotten an answer to this part. I could have sworn that the proprietary loader passed along the device tree that's passed by us to the next stage.
Tom, sorry for my late answer. I was looking into this. I'll put it on top of my list for today. I think you are right, but I want to first understand 100% the implications of CONFIG_OF_EMBED.
Ok here is my take on that. RPi config uses OF_EMBEDED, MISC_INIT_R and DISTRO_DEFAULTS.
Environment variable fdtfile is set to the model->fdtile in board_init, which gets passed in depending on the RPi we are running on. In misc_init_r the fdt_addr points to the build-in DTB (set_fdt_addr) and fdtfile variable is set. IN initr_env fdtcontroladdr is set to the build-in DTB as well.
I'm not sure what distro boot does with that, as I find it really hard to deduce what it is doing from the header file. If anybody can tell how to easily decrypt that, that would be helpfull.
So after looking more into this (holiday in between, sorry): distro boot tries to load a device tree from the boot medium, if this fails it uses the embedded device tree blob.
Tom, I suppose you refered to the fact that you can get a device tree from the FW that starts u-boot. This is not enabled in the defconfig. So from my point of view it makes sense to create a new config which uses the DTS for the board. You can't be sure that your setup has the dtb in the right folder, which is used by distro boot before falling back to the embedded DTB.
Thanks for digging more. The first thing is, shouldn't we be taking in the patch (not right now of course, release is days away) that enables taking the dtb we're passed since that enables the normally documented Pi-way of doing overlays? And the second thing is, with the release scheduled for Monday, should I still be looking at this PR as-is or do you want to re-spin with only important bugfixes? Thanks!
participants (6)
-
Heinrich Schuchardt -
Jonathan Gray -
Matthias Brugger -
Matthias Brugger -
Peter Robinson -
Tom Rini