Re: Appended DTB files for multi-machine kernels
Hi Arnd, On Fri, Jul 5, 2013 at 6:34 AM, Arnd Bergmann a...@arndb.de wrote: On Thursday 04 July 2013, Mark Brown wrote: On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote: Unless I missed some recent discussion, this case is not easy to handle. Yes, I know that these kind of things should be handled by a next-generation bootloader, but in our case, we want to avoid a loader update of already shipped hardware by all means. There was some discussion about appending multiple DTBs recently. I can't actually recall anything about it though so that's not an entirely helpful thing... Yes, it keeps coming up, I think by now everybody agreed it's a good idea to extend the ATAGS compat mode, but so far nobody has implemented it. Magnus Damm was very interested in this feature last year and was planning to work on it, but I don't know how far he got. Correct, I was and still am a bit interested in it. I did however never get around to write any code. My apologies if that stalled anyone. With mach-shmobile we're now getting to a point where most of our boards are using DT_MACHINE and appended DTB instead of the MACHINE and mach-type. Because of that I feel that the moment has sort of passed for me. Regardless of this nearly all our boot loaders pass mach-type so it would be nice to match on that instead of the appended DTB. Thanks, / magnus ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
On 07/04/2013 10:56 AM, Daniel Mack wrote: ... The built-in support for attaching a DTB to the zImage does not suffice here, because we have one image for all models, and also, we couldn't do a 'per-board-revision' selection that way either. ... As a solution, I'm thinking of a small framework that could for example work as follows. a) A small mechanism allows storing multiple DTB binary files inside the kernel binary at compile time... ... c) Allow users to open-code the DTB lookup depending on whatever kind of runtime information (be it the board_revision or anything else). The problem with (c) is that in general it probably requires a lot of infra-structure to be working to implement it. On Tegra, the board revision is in an EEPROM attached to an I2C bus. You'd need to have parsed DT and started instantiating devices already before you could access the ID EEPROM to know which board revision you're running on. That's a bit of a chicked-and-egg problem. Even with a much simpler scheme such as board ID encoded into GPIOs, you'll still likely run into similar problems; pinmux and GPIO controller drivers are needed just to read the GPIOs, which then requires DT to instantiate those drivers. So, the suggestion of Nicolas's that you mentioned does solve that rather neatly. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote: Unless I missed some recent discussion, this case is not easy to handle. Yes, I know that these kind of things should be handled by a next-generation bootloader, but in our case, we want to avoid a loader update of already shipped hardware by all means. There was some discussion about appending multiple DTBs recently. I can't actually recall anything about it though so that's not an entirely helpful thing... As a solution, I'm thinking of a small framework that could for example work as follows. a) A small mechanism allows storing multiple DTB binary files inside the kernel binary at compile time, and a simple function can extract them again by name at runtime (something like what the firmware framework does, but I don't know if that one can be used at such an early stage in the boot process). Another way of skinning this would be for either the kernel to contain a set of machine ID to compatible string mappings or for the device trees for the boards to have an additional properties giving the machine IDs that the boards match. The kernel could then look for multiple DTBs appended to the image and try to pick one based on ATAGs. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
On Thu, 4 Jul 2013, Daniel Mack wrote: Hi, I'm facing a problem with a transition from legacy board-file driven ARM machines to DTB, and I'm under the impression that a solution for it could be of broader interest. In short, devices that have been deployed in quantities come in three hardware variants, which all boot with a unique machine-id. We ship kernel images that have board support for all three machine types, and do minor fixups to platform data of some drivers at runtime, depending on the board revision number (passed in via ATAGs). The built-in support for attaching a DTB to the zImage does not suffice here, because we have one image for all models, and also, we couldn't do a 'per-board-revision' selection that way either. Unless I missed some recent discussion, this case is not easy to handle. Yes, I know that these kind of things should be handled by a next-generation bootloader, but in our case, we want to avoid a loader update of already shipped hardware by all means. As a solution, I'm thinking of a small framework that could for example work as follows. a) A small mechanism allows storing multiple DTB binary files inside the kernel binary at compile time, and a simple function can extract them again by name at runtime (something like what the firmware framework does, but I don't know if that one can be used at such an early stage in the boot process). b) A DT_MACHINE_START-like macro takes both the machine ID and the name of a DTB file that is compiled in. When matched, generic functions would load the given file, populate the device tree and then conduct a generic DT boot for the specified platform. c) Allow users to open-code the DTB lookup depending on whatever kind of runtime information (be it the board_revision or anything else). Of course, everything has to be an opt-in that stubs itself out at zero costs if not needed. I'm open to opinion and sugesstions :) What you describe above more or less fits the definition of what I called the impedance matcher. However it doesn't need to be part of the kernel at all. But you should make it into a separate binary. Please have a look at the bottom of this post for a more comprehensive description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929 Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
Hi Nicolas, On 04.07.2013 19:28, Nicolas Pitre wrote: On Thu, 4 Jul 2013, Daniel Mack wrote: I'm open to opinion and sugesstions :) What you describe above more or less fits the definition of what I called the impedance matcher. However it doesn't need to be part of the kernel at all. But you should make it into a separate binary. Please have a look at the bottom of this post for a more comprehensive description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929 Thanks for the link. Interesting read indeed. The only thing I'm pondering about is that we already have generic loader code in Linux and a build system that supports a wide range of platforms. I don't know whether it's worth opening that can of worms again and re-implement all details about load addresses, compiler flags, device-tree parsing code yet once again. At least in terms of LOCs, we would certainly be better off doing it inside the kernel. But I generally second your opinion about pushing vendors to do it right, so I might give that approach a shot soon; there is no code yet anywhere I take it? Thanks, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
On Thu, 4 Jul 2013, Daniel Mack wrote: Hi Nicolas, On 04.07.2013 19:28, Nicolas Pitre wrote: On Thu, 4 Jul 2013, Daniel Mack wrote: I'm open to opinion and sugesstions :) What you describe above more or less fits the definition of what I called the impedance matcher. However it doesn't need to be part of the kernel at all. But you should make it into a separate binary. Please have a look at the bottom of this post for a more comprehensive description: http://article.gmane.org/gmane.linux.ports.arm.kernel/242929 Thanks for the link. Interesting read indeed. The only thing I'm pondering about is that we already have generic loader code in Linux and a build system that supports a wide range of platforms. I don't know whether it's worth opening that can of worms again and re-implement all details about load addresses, compiler flags, device-tree parsing code yet once again. At least in terms of LOCs, we would certainly be better off doing it inside the kernel. That is still code with relatively low value that has to be carried and maintained. And if you do it for your own device outside of the kernel then you can literally hack it the way you want quickly and forget about it once it works. Since this is useful for legacy setups only, you do not have to care about maintaining it in the future. But I generally second your opinion about pushing vendors to do it right, so I might give that approach a shot soon; there is no code yet anywhere I take it? Not that I'm aware of, besides parts of libfdt and atags_to_fdt.c from the kernel tree that can be lifted and modified according to your needs. I don't imagine you'd need much more than that anyway. Nicolas ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
On Thursday 04 July 2013, Mark Brown wrote: On Thu, Jul 04, 2013 at 06:56:24PM +0200, Daniel Mack wrote: Unless I missed some recent discussion, this case is not easy to handle. Yes, I know that these kind of things should be handled by a next-generation bootloader, but in our case, we want to avoid a loader update of already shipped hardware by all means. There was some discussion about appending multiple DTBs recently. I can't actually recall anything about it though so that's not an entirely helpful thing... Yes, it keeps coming up, I think by now everybody agreed it's a good idea to extend the ATAGS compat mode, but so far nobody has implemented it. Magnus Damm was very interested in this feature last year and was planning to work on it, but I don't know how far he got. As a solution, I'm thinking of a small framework that could for example work as follows. a) A small mechanism allows storing multiple DTB binary files inside the kernel binary at compile time, and a simple function can extract them again by name at runtime (something like what the firmware framework does, but I don't know if that one can be used at such an early stage in the boot process). Another way of skinning this would be for either the kernel to contain a set of machine ID to compatible string mappings or for the device trees for the boards to have an additional properties giving the machine IDs that the boards match. The kernel could then look for multiple DTBs appended to the image and try to pick one based on ATAGs. IIRC there is actually an unused field in the dtb header that could be used to match a board ID. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Appended DTB files for multi-machine kernels
Hi Arnd, On 04.07.2013 23:34, Arnd Bergmann wrote: On Thursday 04 July 2013, Mark Brown wrote: Another way of skinning this would be for either the kernel to contain a set of machine ID to compatible string mappings or for the device trees for the boards to have an additional properties giving the machine IDs that the boards match. The kernel could then look for multiple DTBs appended to the image and try to pick one based on ATAGs. IIRC there is actually an unused field in the dtb header that could be used to match a board ID. While that would help many users, it doesn't cover our case where different board revisions require different DTBs to be loaded, depending on the supplied ATAG. I think I'll go for Nicolas Pitre's suggestion as first step. He's right that's it's a hack anyway, and we're just dealing with legacy systems here, and hence it might not even be worth caring too much about a proper solution. Thanks for all the answers, Daniel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
