Am Mo., 17. Juni 2019 um 15:40 Uhr schrieb Patrick Doyle <wpds...@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.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
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
