Am Mo., 17. Juni 2019 um 15:40 Uhr schrieb Patrick Doyle wpdster@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@gmail.com wrote:
Am Fr., 14. Juni 2019 um 23:05 Uhr schrieb Patrick Doyle wpdster@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,