From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 23 Jul 2015 22:17:29 -0600 Subject: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi In-Reply-To: References: <1436324032-17931-1-git-send-email-sjg@chromium.org> <55A0AAD3.2050302@wwwdotorg.org> <55A495AA.6080609@wwwdotorg.org> Message-ID: <55B1BC59.9040902@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/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.