Hi Simon,
I wonder what would be involved in adjusting config_distro_bootcmd to support FIT?
Well, it goes against the very idea of config_distro_bootcmd, which is to provide a single standard mechanism that doesn't rely on any bootloader-specific file formats etc. That mechanism is a raw zImage, a raw initrd, and a plain text extlinux.cfg file to specify things like file paths/names, command-line, etc.
The boot.scr support there is legacy, and not something that should be built upon going forward. So, that's not an argument for adding support for a third mechanism!
Do we need to adjust the mechanism? The only difference I see is that FIT brings the files together.
Speaking as one of the ARM maintainers that's not what we want. We want to be able to use the standard kernel, initrd and then a DT so we can boot a single image across any device that the kernel supports.
In Fedora at the moment we can boot around a 100 odd devices off a single kernel by specifying the DT separately. I've not looked at FIT closely but I don't believe it provides us that.
Would it make it simpler or harder? To me, we should be moving to using FIT with U-Boot as it is much more flexible and better designed from the ground up to provide the required features.
I disagree that FIT is a good idea, but that's a separate topic.
Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a bzImage.
Do you mean FIT normally contains an originally uncompressed kernel (i.e. an Image file in ARM land at least), but then compresses it itself as part of FIT image generation? A bzImage is also a "compressed kernel".
That's right, that's what I mean.
So it seems like we need an additional decompression address.
I suppose we could always use malloc() instead... But perhaps a FIT load address makes sense. But then we don't really need a kernel load address do we? Shouldn't that be specified in the FIT itself?
A FIT load address does sound like it makes sense.
If U-Boot copies the kernel image out of the FIT image to somewhere else, the FIT image shouldn't specify the address to copy it to. This varies per SoC, so if this address is hard-coded into FIT, it means the FIT image can't be used on different SoCs (or perhaps even different boards, depending on how differing RAM sizes work on various HW). This is why with config_distro_bootcmd, all the addresses come from the U-Boot environment, not hard-coded into a file on the disk. That way, the files are all generic and can be used on various different systems that require different addresses. It possibly makes sense for kernel_addr_r to be the destination of that copy?
The above it what Fedora does, this is why we assisted in the implementation of config_distro_bootcmd so we could have a single kernel for all devices.
Doesn't the kernel know where the kernel needs to be loaded / copied as part of the bzImage stuff? From what I see at present this is hard-coded into the code in the kernel. So we need to put this correct address in the FIT, is that right? Are you thinking we should allow FIT to take an environment variable as a load address?
If so, I feel it would make a lot of sense for the kernel to package up the FIT to avoid these issues.
Is there an overview of a FIT image somewhere, does it only contain a single DT or does it package up a single one for the device? Currently in Fedora we're shipping 283 DTs for a single 4.0.3 multiplatform kernel. For the images we ship we can for example just plug a generic image into a Jetson TK1 board and have it boot without any device specific configuration.
Peter