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.schwierz...@gmail.com> wrote:
> Am Fr., 14. Juni 2019 um 23:05 Uhr schrieb Patrick Doyle <wpds...@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
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 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.
--wpd
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
