[U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi

[Tom Rini]

On Thu, Jul 23, 2015 at 10:17:29PM -0600, Stephen Warren wrote:
> On 07/14/2015 09:44 AM, Simon Glass wrote:
> > Hi Stephen,
> > 
> > On 13 July 2015 at 22:52, Stephen Warren <swarren at wwwdotorg.org> wrote:
> >> On 07/11/2015 08:04 AM, Simon Glass wrote:
> >>> Hi Stephen,
> >>>
> >>> On 10 July 2015 at 23:34, Stephen Warren <swarren at wwwdotorg.org> wrote:
> >>>> On 07/07/2015 08:53 PM, Simon Glass wrote:
> >>>>> Raspberry Pi uses a DWC2 USB controller and a SMSC USB Ethernet adaptor.
> >>>>> Neither of these currently support driver model.
> >>>>>
> >>>>> This series does the following:
> >>>>> - Move Raspberry Pi to use device tree control (u-boot-dtb.bin instead of
> >>>>>      u-boot.bin)
> >>>>
> >>>> I'd strongly prefer not to do this. For one thing, it means we'd need
> >>>> different U-Boot builds for each of the different RPi models, and we
> >>>> currently don't need that (or perhaps we require users to create their
> >>>> own u-boot-dtb.bin by choosing the right DTB to append). If it
> >>>
> >>> Why does device tree change how things work now? The get_board_rev()
> >>> function currently deals with this. It doesn't look like rpi_board_rev
> >>> is used anywhere else.
> >>
> >> Without a DT, the code is free to make all the board-rev-specific
> >> decisions at run-time without external influence.
> >>
> >> With a DT, we either have to:
> >>
> >> a) Pick the DT for one particular board and use that everywhere, even if
> >> it's incorrect for the actual board in use.
> >>
> >> b) Build a different U-Boot + DTB image for each board-rev, and put the
> >> correct one on the SD card.
> >>
> >> Neither of those options seem like a good idea to me.
> > 
> > How about:
> > 
> > c) Leave the code as is, and not add a whole lot more device tree files.
> > 
> > After all the kernel only has files for rpi and rpi_2. Why should we
> > add one for each variant? If you don't want to do it, why do it?
> 
> For the kernel I do expect to add a DT file for each variant. That makes
> sense since we expect a single kernel binary to run unmodified on all
> HW, parameterize the HW setup via the DTB, and have an infrastructure to
> pass the different DTs to the kernel easily.
> 
> For U-Boot, I'd like to continue to have a single-binary that runs on
> all RPis (well, one for RPi 1, another for RPi 2). That's a very nice
> usage model for users. That's not possible if U-Boot pulls everything
> from DT and we have a different DT for each system (which only makes
> sense so that we don't lie in the DT, or fail to represent the
> differences between the models) since a single DT is embedded into the
> U-Boot binary; there's no infra-structure to passing 1 of n DTBs to U-Boot.

So my question is, for what U-Boot needs, can we have 1 DT for RPi 1
(that's not lying about what the HW can do) and 1 DT for RPi 2?  This is
the kind of question I'm frankly strugling with right now on converting
more of the TI boards to be DT based as well.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150724/88572444/attachment.sig>