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

[Stephen Warren]

On 07/16/2015 08:10 AM, Pavel Machek wrote:
> On Mon 2015-07-13 22:52:58, Stephen Warren 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.
> 
> Is that an option? I mean... if you can tolerate incorrect values for
> something, perhaps that something should not be in the dtb in the
> first place?

Indeed I would certainly rather not have U-Boot use a DT that contains
invalid information.

>> b) Build a different U-Boot + DTB image for each board-rev, and put the
>> correct one on the SD card.
> 
> d) Build U-Boot + set of DTB images, then pick up the right one at the
> runtime?

Perhaps that'd work.

>> Neither of those options seem like a good idea to me.
> 
> Stuff that can be autodetected does not belong to the device tree...

I tend to agree, but then you need platform-specific code to do the
auto-detection, and there's pushback on that since a large benefit of DT
is to remove platform-specific code from SW and just represent the
information in DT. Put another way, DT seems to end up being "nothing"
(DT not used) or "everything" (even representing some auto-probed data).
Not great, but.