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

[Tom Rini]

On Mon, Jul 27, 2015 at 09:10:32PM -0600, Stephen Warren wrote:
> On 07/24/2015 07:44 AM, Tom Rini wrote:
> > 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.
> 
> This would be possible iff all the HW that U-Boot interacts with is
> identical on all relevant systems and we simply leave out all the
> other details that U-Boot doesn't care about (or any differences that
> exist can be probed via standard protocols such as USB).

Exactly.

> Right now, I think that's possible on the RPi.

That's good..

> However, this limits U-Boot's ability to support all HW. If we wanted
> U-Boot to fully support all features of the HW, this limited DT
> wouldn't be sufficient. Examples of potential issues are:
>
> a) On RPis that contain the USB hub + Ethernet chip, there's a GPIO
> that feeds into that chip's enable pin. Right now, U-Boot relies on
> either the HW default being sufficient to turn that pin on, or perhaps
> the binary FW that runs before U-Boot does this. However, U-Boot
> really should set the GPIO itself so that it doesn't rely on HW state
> set up before it runs. It should also do this only on systems with the
> USB+LAN chip; we don't have the full schematics for all RPi boards so
> there's no guarantee the same GPIO doesn't do something else on some
> boards, especially in the future.
> 
> b) I2S (digital audio) output is present on some boards. Someone might
> want U-Boot to play a startup sound, or make a warning beep under
> certain error conditions. It's not /that/ likely, but similar features
> have been implemented on other boards. The availability of I2S outputs
> varies from model to model.
> 
> c) If we want to expose the GPIOs on the expansion header, the set of
> GPIOs that it's useful to expose varies between boards.
> 
> We could probably think of other issues too.
> 
> To handle all of these, we'd either have to have separate DTs for the
> different cases, or represent the differences in code. Having multiple
> DTs has the issues I mentioned previously. By the time we represent
> part of the HW structure in code, it's far simpler to just represent
> it all in that one place. C structs are (currently at least) better
> than DT for representing this information anyway; the C compiler does
> a lot more error-checking when initializing structs than dtc can do
> for example, and code-sharing between boards is easier.

Maybe examples like these are why we will need (and want) to keep
platform data as a possibility in our DM work.  There's value in keeping
the DT that we use as minimal as possible (so that it can work as
broadly as possible) and then do run-time fixups.  The other option here
might be something like device tree overlays or at least exposing the
running DT (... more readily, I bet you could kludge it today) so that
the existing cli infrasturcture can modify it).

-- 
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/20150728/0bda93e8/attachment.sig>