From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 31 Jul 2015 21:01:09 -0600 Subject: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi In-Reply-To: <20150728135522.GB25532@bill-the-cat> References: <1436324032-17931-1-git-send-email-sjg@chromium.org> <55A0AAD3.2050302@wwwdotorg.org> <55A495AA.6080609@wwwdotorg.org> <55B1BC59.9040902@wwwdotorg.org> <20150724134440.GK25532@bill-the-cat> <55B6F2A8.8010007@wwwdotorg.org> <20150728135522.GB25532@bill-the-cat> Message-ID: <55BC3675.2000903@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>> wrote: >>>>>> On 07/11/2015 08:04 AM, Simon Glass wrote: >>>>>>> Hi Stephen, >>>>>>> >>>>>>> On 10 July 2015 at 23:34, Stephen Warren >>>>>>> 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.