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

[Stephen Warren <swarren@wwwdotorg.org>]

On 07/28/2015 07:55 AM, Tom Rini wrote:
> 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@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@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).

I'm still not convinced of the utility of DT /if/ we can't completely
get rid of C code alongside it. Representing part of the system in DT
and part in C seems to me to be the absolute worst case. If we need C
for part of the system config, we should just use it for all of it.