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