[U-Boot] pull request: raspberry pi updates

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190705/c8eafdc4/attachment.sig>