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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
