From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Date: Fri, 31 Jul 2015 21:01:09 -0600 [thread overview]
Message-ID: <55BC3675.2000903@wwwdotorg.org> (raw)
In-Reply-To: <20150728135522.GB25532@bill-the-cat>
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.
next prev parent reply other threads:[~2015-08-01 3:01 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 2:53 [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 01/20] dm: net: Support usbethaddr environment variable Simon Glass
2015-07-08 4:04 ` Joe Hershberger
2015-07-08 20:31 ` Simon Glass
2015-07-08 20:43 ` Joe Hershberger
2015-07-08 21:07 ` Simon Glass
2015-07-20 13:56 ` Simon Glass
2015-07-20 18:10 ` Joe Hershberger
2015-07-21 21:25 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 02/20] dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 03/20] dm: usb: Add an errno.h header to usb_ether.c Simon Glass
2015-07-27 23:31 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 04/20] dm: usb: Prepare dwc2 driver for driver-model conversion Simon Glass
2015-07-27 23:31 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 05/20] dm: usb: Add driver-model support to dwc2 Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 06/20] net: smsc95xx: Sort the include files Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 07/20] net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 08/20] net: smsc95xx: Correct the error numbers Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 09/20] net: smsc95xx: Prepare for conversion to driver model Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 10/20] net: smsc95xx: Add driver-model support Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 11/20] dm: serial: Update binding for PL01x serial UART Simon Glass
2015-07-08 22:00 ` Vikas MANOCHA
[not found] ` <1436324032-17931-12-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2015-07-15 9:00 ` Linus Walleij
2015-07-15 9:00 ` [U-Boot] " Linus Walleij
[not found] ` <CACRpkdb=t21=qpqar5VXd4mtqTWrq6MvoX1OsVgmWpkyFqhj3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-15 9:38 ` Arnd Bergmann
2015-07-15 9:38 ` [U-Boot] " Arnd Bergmann
2015-07-15 10:08 ` Linus Walleij
2015-07-15 10:08 ` [U-Boot] " Linus Walleij
[not found] ` <CACRpkdakAVcBT8phhbFjE+mkfA0pTcHYiaL0dV4UNieH54fd+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-15 10:17 ` Arnd Bergmann
2015-07-15 10:17 ` [U-Boot] " Arnd Bergmann
2015-07-16 7:41 ` Geert Uytterhoeven
2015-07-16 7:41 ` [U-Boot] " Geert Uytterhoeven
2015-10-19 7:19 ` Linus Walleij
2015-10-19 7:19 ` [U-Boot] " Linus Walleij
2015-07-08 2:53 ` [U-Boot] [PATCH 12/20] dm: Support address translation for simple-bus Simon Glass
2015-07-27 23:32 ` Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 13/20] arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 14/20] arm: rpi: Bring in kernel device tree files Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 15/20] arm: rpi: Device tree modifications for U-Boot Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 16/20] arm: rpi: Enable device tree control for Rasberry Pi Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 17/20] arm: rpi: Drop the UART console platform data Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 18/20] arm: rpi: Drop the GPIO " Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 19/20] arm: rpi: Move to driver model for USB Simon Glass
2015-07-08 2:53 ` [U-Boot] [PATCH 20/20] arm: rpi: Use driver model for Ethernet Simon Glass
2015-07-11 5:34 ` [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi Stephen Warren
2015-07-11 14:04 ` Simon Glass
2015-07-14 4:52 ` Stephen Warren
2015-07-14 15:44 ` Simon Glass
2015-07-24 4:17 ` Stephen Warren
2015-07-24 13:44 ` Tom Rini
2015-07-28 3:10 ` Stephen Warren
2015-07-28 13:55 ` Tom Rini
2015-07-28 15:44 ` Simon Glass
2015-08-01 3:10 ` Stephen Warren
2015-08-01 3:01 ` Stephen Warren [this message]
2015-07-16 14:10 ` Pavel Machek
2015-07-20 14:25 ` Simon Glass
2015-07-24 4:20 ` Stephen Warren
2015-08-03 23:45 ` Marek Vasut
2015-08-04 0:07 ` Simon Glass
2015-08-04 0:37 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55BC3675.2000903@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.