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

[Simon Glass]

+Hans

Hi,

On 28 July 2015 at 07:55, Tom Rini <trini at konsulko.com> 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 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).

I really like the idea of keeping the DT minimal rather than
slavishing adding a whole lot of detail for every board. If things can
be probed then I think it is acceptable to probe them to avoid an
explosion of DTs. We can do run-time fix ups even if they are
currently not very efficient. The 'fdt' command can modify the running
FDT I think, but it currently breaks everything since by then we have
devices and have recorded the DT offsets. We could add a DT library to
fix this, but for now fix-ups need to be done before relocation.

Re overlays, yes we could do that and probably should. But again we'll
need a DT library that turns the DT into a tree.

Hans mentioned he was thinking about this.

But getting back to this series, I feel that for now we can get a long
way with just two device trees: rpi1 and rpi2.

Regards,
Simon