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 <mbrug...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
