From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Tue, 28 Jul 2015 09:44: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: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de +Hans Hi, On 28 July 2015 at 07:55, 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 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