[U-Boot] And what about fitImages and ram disks?

[Daniel Schwierzeck]

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_CMDLINE_LEGACY=y
> # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
> CONFIG_MIPS_BOOT_FDT=y

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,
>                 &images->lmb);
>  }
>
> 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
e5151666364e64e6ca6e554e3d53f2a53fbc1800.

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
6943cc9732202b9c65990cff9f74cea6b8173e09
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_CMDLINE_LEGACY=y
# CONFIG_MIPS_BOOT_ENV_LEGACY is not set
CONFIG_MIPS_BOOT_FDT=y

then you could use FIT with single images and TFTP boot during development
for shorter cycles times. But for permanent deployment you could still
switch to
an approach with built-in initramfs and DTB to reduce the size of the
kernel image.
Actually MIPS U-Boot can boot all possible combinations of legacy or FIT images
with bundled or separate initramfs or DTB images,

-- 
- Daniel