Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On Tuesday, August 04, 2015 at 02:07:41 AM, Simon Glass wrote: Hi Marek, Hi! On 3 August 2015 at 17:45, Marek Vasut ma...@denx.de wrote: On Wednesday, July 08, 2015 at 04:53:32 AM, 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) - Remove GPIO platform data (now uses device tree) - Remove serial platform data (now uses device tree) - Add 'ranges' support to simple-bus - Convert the DWC2 USB driver to support driver model - Convert the SMSC95XX USB Ethernet driver to support driver model - Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi With Ethernet active the device list looks something like this: U-Boot dm tree Class Probed Name root[ + ]root_driver simple_bus [ + ]|-- soc gpio[ ]| |-- gpio@7e20 serial [ + ]| |-- uart@7e201000 usb [ + ]| `-- usb@7e98 usb_hub [ + ]| `-- usb_hub usb_hub [ + ]| `-- usb_hub eth [ + ]| `-- smsc95xx_eth simple_bus [ ]`-- clocks Raspberry Pi 2 is not converted as I do not have one to test at present. Simon Glass (20): dm: net: Support usbethaddr environment variable dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined dm: usb: Add an errno.h header to usb_ether.c dm: usb: Prepare dwc2 driver for driver-model conversion dm: usb: Add driver-model support to dwc2 net: smsc95xx: Sort the include files net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE net: smsc95xx: Correct the error numbers net: smsc95xx: Prepare for conversion to driver model net: smsc95xx: Add driver-model support dm: serial: Update binding for PL01x serial UART dm: Support address translation for simple-bus arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info arm: rpi: Bring in kernel device tree files arm: rpi: Device tree modifications for U-Boot arm: rpi: Enable device tree control for Rasberry Pi arm: rpi: Drop the UART console platform data arm: rpi: Drop the GPIO platform data arm: rpi: Move to driver model for USB arm: rpi: Use driver model for Ethernet I could really use the DM part of this patchset on SoCFPGA, can you maybe drop the rpi part and repost it, so that part can be mainlined please ? Half of this series in in dm/master - please rebase on top of that. You asking people to rebased on top of dm/master has become quite common recently ;-) I hope to get a pull request out by Friday, Excellent, I'll wait until this stuff hits u-boot/master . Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On Wednesday, July 08, 2015 at 04:53:32 AM, 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) - Remove GPIO platform data (now uses device tree) - Remove serial platform data (now uses device tree) - Add 'ranges' support to simple-bus - Convert the DWC2 USB driver to support driver model - Convert the SMSC95XX USB Ethernet driver to support driver model - Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi With Ethernet active the device list looks something like this: U-Boot dm tree Class Probed Name root[ + ]root_driver simple_bus [ + ]|-- soc gpio[ ]| |-- gpio@7e20 serial [ + ]| |-- uart@7e201000 usb [ + ]| `-- usb@7e98 usb_hub [ + ]| `-- usb_hub usb_hub [ + ]| `-- usb_hub eth [ + ]| `-- smsc95xx_eth simple_bus [ ]`-- clocks Raspberry Pi 2 is not converted as I do not have one to test at present. Simon Glass (20): dm: net: Support usbethaddr environment variable dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined dm: usb: Add an errno.h header to usb_ether.c dm: usb: Prepare dwc2 driver for driver-model conversion dm: usb: Add driver-model support to dwc2 net: smsc95xx: Sort the include files net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE net: smsc95xx: Correct the error numbers net: smsc95xx: Prepare for conversion to driver model net: smsc95xx: Add driver-model support dm: serial: Update binding for PL01x serial UART dm: Support address translation for simple-bus arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info arm: rpi: Bring in kernel device tree files arm: rpi: Device tree modifications for U-Boot arm: rpi: Enable device tree control for Rasberry Pi arm: rpi: Drop the UART console platform data arm: rpi: Drop the GPIO platform data arm: rpi: Move to driver model for USB arm: rpi: Use driver model for Ethernet I could really use the DM part of this patchset on SoCFPGA, can you maybe drop the rpi part and repost it, so that part can be mainlined please ? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Hi Marek, On 3 August 2015 at 17:45, Marek Vasut ma...@denx.de wrote: On Wednesday, July 08, 2015 at 04:53:32 AM, 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) - Remove GPIO platform data (now uses device tree) - Remove serial platform data (now uses device tree) - Add 'ranges' support to simple-bus - Convert the DWC2 USB driver to support driver model - Convert the SMSC95XX USB Ethernet driver to support driver model - Enable CONFIG_DM_ETH and CONFIG_DM_USB on Raspberry Pi With Ethernet active the device list looks something like this: U-Boot dm tree Class Probed Name root[ + ]root_driver simple_bus [ + ]|-- soc gpio[ ]| |-- gpio@7e20 serial [ + ]| |-- uart@7e201000 usb [ + ]| `-- usb@7e98 usb_hub [ + ]| `-- usb_hub usb_hub [ + ]| `-- usb_hub eth [ + ]| `-- smsc95xx_eth simple_bus [ ]`-- clocks Raspberry Pi 2 is not converted as I do not have one to test at present. Simon Glass (20): dm: net: Support usbethaddr environment variable dm: usb: Allow USB Ethernet whenever CONFIG_DM_ETH is not defined dm: usb: Add an errno.h header to usb_ether.c dm: usb: Prepare dwc2 driver for driver-model conversion dm: usb: Add driver-model support to dwc2 net: smsc95xx: Sort the include files net: smsc95xx: Rename AX_RX_URB_SIZE to RX_URB_SIZE net: smsc95xx: Correct the error numbers net: smsc95xx: Prepare for conversion to driver model net: smsc95xx: Add driver-model support dm: serial: Update binding for PL01x serial UART dm: Support address translation for simple-bus arm: rpi: Define CONFIG_TFTP_TSIZE to show tftp size info arm: rpi: Bring in kernel device tree files arm: rpi: Device tree modifications for U-Boot arm: rpi: Enable device tree control for Rasberry Pi arm: rpi: Drop the UART console platform data arm: rpi: Drop the GPIO platform data arm: rpi: Move to driver model for USB arm: rpi: Use driver model for Ethernet I could really use the DM part of this patchset on SoCFPGA, can you maybe drop the rpi part and repost it, so that part can be mainlined please ? Half of this series in in dm/master - please rebase on top of that. I hope to get a pull request out by Friday, Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
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 swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On 07/28/2015 09:44 AM, Simon Glass wrote: On 28 July 2015 at 07:55, Tom Rini tr...@konsulko.com wrote: ... 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. There are two cases for probing: a) Standard buses that are probe-able in a standard way, like USB. It makes sense to probe these since the probing code is generic across a wide variety of systems and hence the code can be considered generic. b) Device-specific information sources (such as the RPi firmware etc.). Code for this isn't at all re-usable across systems. In the kernel, there's been some tendency to push for SW that runs before the kernel to probe these information sources and add the relevant information into the DT (or just include the information statically in DT source files), rather than including system-specific code in the kernel to do the probing. This keeps kernel code size down and avoids lots of non-generic code. Related, if the kernel knew it booted on nvidia,jetson-tk1, then that information is enough to tell the kernel the entire set of devices that are attached (aside from anything attached to the USB, PCIe, HDMI controllers). We could probe a board file from just the board name:-) DT schema/content is intended to be identical across all SW stacks so that it can be shared. There's a bit of friction here re: what a bootloader and OS kernel might want in DT vs. what they could/prefer-to probe themselves using device-specific code:-( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
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 swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
+Hans Hi, On 28 July 2015 at 07:55, Tom Rini tr...@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 swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
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 swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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). Right now, I think that's possible on the RPi. 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. ___
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
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 swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On 07/14/2015 09:44 AM, Simon Glass wrote: Hi Stephen, On 13 July 2015 at 22:52, Stephen Warren swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On 07/16/2015 08:10 AM, Pavel Machek wrote: On Mon 2015-07-13 22:52:58, Stephen Warren wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place? Indeed I would certainly rather not have U-Boot use a DT that contains invalid information. b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card. d) Build U-Boot + set of DTB images, then pick up the right one at the runtime? Perhaps that'd work. Neither of those options seem like a good idea to me. Stuff that can be autodetected does not belong to the device tree... I tend to agree, but then you need platform-specific code to do the auto-detection, and there's pushback on that since a large benefit of DT is to remove platform-specific code from SW and just represent the information in DT. Put another way, DT seems to end up being nothing (DT not used) or everything (even representing some auto-probed data). Not great, but. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Hi Stephen, On 16 July 2015 at 08:10, Pavel Machek pa...@denx.de wrote: On Mon 2015-07-13 22:52:58, Stephen Warren wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place? b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card. d) Build U-Boot + set of DTB images, then pick up the right one at the runtime? Neither of those options seem like a good idea to me. Stuff that can be autodetected does not belong to the device tree... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Stephen please can you update here? It seems to me that there is no requirement to add a lot of stuff to the device tree which we already have code to auto-detect. I'd like to pull in these changes but can hold off on the rpi parts until we figure this out. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On Mon 2015-07-13 22:52:58, Stephen Warren wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. Is that an option? I mean... if you can tolerate incorrect values for something, perhaps that something should not be in the dtb in the first place? b) Build a different U-Boot + DTB image for each board-rev, and put the correct one on the SD card. d) Build U-Boot + set of DTB images, then pick up the right one at the runtime? Neither of those options seem like a good idea to me. Stuff that can be autodetected does not belong to the device tree... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Hi Stephen, On 13 July 2015 at 22:52, Stephen Warren swar...@wwwdotorg.org wrote: On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
On 07/11/2015 08:04 AM, Simon Glass wrote: Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
Hi Stephen, On 10 July 2015 at 23:34, Stephen Warren swar...@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. absolutely must be done, please note that there are many more RPi models than there are currently DT files for in the upstream kernel. I keep meaning to add a complete set of DT files to the kernel, but haven't gotten around to it yet. Take a look at board/raspberrypi/rpi/rpi.c:models[] for a likely list of the different DTs we'd need. I've only added two - one for Raspberry Pi, and one for Raspberry Pi 2 (patches not sent yet, but at u-boot-dm/rpi-working) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/20] arm: rpi: Enable USB and Ethernet driver model Raspberry Pi
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 absolutely must be done, please note that there are many more RPi models than there are currently DT files for in the upstream kernel. I keep meaning to add a complete set of DT files to the kernel, but haven't gotten around to it yet. Take a look at board/raspberrypi/rpi/rpi.c:models[] for a likely list of the different DTs we'd need. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
