[U-Boot] And what about fitImages and ram disks?
daniel.schwierzeck at gmail.com
Mon Jun 17 14:22:25 UTC 2019
Am Mo., 17. Juni 2019 um 15:40 Uhr schrieb Patrick Doyle <wpdster at gmail.com>:
> Hello Daniel,
> First of all, thank you for the reply.
> Second of all, my apologies for all of the typos in my email. I
> _really_ shouldn't allow myself to compose emails at 5pm on a Friday
> afternoon as I am getting ready to leave for the weekend :-)
> On Mon, Jun 17, 2019 at 7:27 AM Daniel Schwierzeck
> <daniel.schwierzeck at gmail.com> wrote:
> > Am Fr., 14. Juni 2019 um 23:05 Uhr schrieb Patrick Doyle <wpdster at gmail.com>:
> > > Does anybody have any hints as to why the Ramdisk would be relocated twice?
> > This have been fixed with e5151666364e64e6ca6e554e3d53f2a53fbc1800.
> > > Does anybody have any hints as to why the kernel didn't notice the ramdisk?
> > Could you share your U-Boot version and board config, particulary the
> > CONFIG_MIPS_BOOT_* options.
> > For boot with DT hand-over you'll need
> > 6943cc9732202b9c65990cff9f74cea6b8173e09 with mainline Linux.
> I am building u-boot v2019.04-rc4.
> The only CONFIG_MIPS_BOOT options I see in my .config are:
> # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
This looks okay.
> Thanks for the tip on the patch. I'll apply that and see how/if that
> helps. Looking at it, I see that it does the following:
> @@ -247,6 +247,8 @@ int arch_fixup_fdt(void *blob)
> static int boot_setup_fdt(bootm_headers_t *images)
> + images->initrd_start = virt_to_phys((void *)images->initrd_start);
> + images->initrd_end = virt_to_phys((void *)images->initrd_end);
> return image_setup_libfdt(images, images->ft_addr, images->ft_len,
> That might explain why my kernel didn't find the ramdisk (although I
> am now wondering if one of the OpenWRT patches that were applied to
> the kernel, which defer parsing the device tree until much later in
> the process might also contribute to my problem). But I don't think
> this would explain why u-boot relocated the ramdisk twice at boot. Is
> that typical?
I guess you overlooked my first comment? :D
The double relocation has been fixed after v2019.04 with
Could you also share how do you deploy your devie-tree blob? Do you put
it in the FIT image and use DTB hand-over to Linux or do you use the
built-in or appended DTB approach? Patch
is only relevant for the DTB hand-over case where the initramfs adress and size
will be embedded in the DTB. Otherwise the address and size is passed
via kernel command line. This should work without problems.
> > I strongly recommend a FIT image with separate Linux, initramfs and DT
> > images and to use DT hand-over by U-Boot (CONFIG_MIPS_BOOT_FDT) when
> > booting from traditional flash media. Then you have the full
> > flexibility with making initramfs optional or to support multiple DT
> > blobs. If you want to boot from a file system (e.g. FAT32 on MMC) you
> > could checkout CONFIG_DISTRO and don't use U-Boot's mkimage at all.
> For my particular (extremely memory constrained) application, I expect
> to only ever need to support a single ramdisk and device tree with my
> kernel. (Or, equivalently, if I need multiple versions of ramdisks or
> device trees to support different hardware configurations, it would be
> more efficient for me to create targeted builds for those hardware
> configurations). I am not sure what the flexibility of FIT buys me,
> and, so far in informal testing, I get better compression by bundling
> everything together. But, as I get to decide what goes into the FIT
> image, I am left with complete flexibility of deciding whether or not
> to bundle everything in the kernel, or separately in the FIT image,
> and thus have the luxury of changing my mind at a later date :-)
> > Another advantage of FIT is the massively decreased build times during
> > development. You can simply update initramfs or DTB's of a kernel
> > image within (mili-)seconds because you don't need to invoke Linux
> > Kbuild to re-link vmlinux and to run some compression algo afterwards.
> > But I'm not sure how relevant this is inside the Yocto build
> > environment.
> Yeah, I'm working on ways to improve cycle time, but, relative to the
> overall time to develop, compile, and deploy the application layer
> (both in development time, and in compile time), the kernel, device
> tree, and ramdisk are only a small percentage of the time involved.
> But I like your thinking here.
> Thanks again for the tips.
If U-Boot size is not such an issue, you could keep this configuration:
# CONFIG_MIPS_BOOT_ENV_LEGACY is not set
then you could use FIT with single images and TFTP boot during development
for shorter cycles times. But for permanent deployment you could still
an approach with built-in initramfs and DTB to reduce the size of the
Actually MIPS U-Boot can boot all possible combinations of legacy or FIT images
with bundled or separate initramfs or DTB images,
More information about the U-Boot