[U-Boot] And what about fitImages and ram disks?
I just created my initramfs and inserted it into my fit-image.its file. When I booted, I saw the following:
Trying 'ramdisk' ramdisk subimage Description: Bootstrap ramdisk Type: RAMDisk Image Compression: gzip compressed Data Start: 0x811ae9f0 Data Size: 2613908 Bytes = 2.5 MiB Architecture: MIPS OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: sha256 Hash value: 0faa7c3e4927b685cd5a050112ea6b90ad4dec4e4ea8627b4f589bfc60082eba Verifying Hash Integrity ... sha256+ OK Uncompressing Kernel Image ... OK Loading Ramdisk to 83ad9000, end 83d57294 ... OK Loading Ramdisk to 8385a000, end 83ad8294 ... OK [ 0.000000] Linux version 4.14.115-yocto-standard-custom (oe-user@oe-host) (gcc version 8.3.0 (GCC)) #1 Fri Jun 14 19:49:57 UTC 2019 [ 0.000000] Board has DDR2 [ 0.000000] Analog PMU set to hw control [ 0.000000] Digital PMU set to hw control [ 0.000000] SoC Type: MediaTek MT7688 ver:1 eco:2 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 00019655 (MIPS 24KEc) [ 0.000000] MIPS: machine is MediaTek LinkIt Smart 7688 [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 04000000 @ 00000000 (usable) [ 0.000000] Initrd not found or empty - disabling initrd
Does anybody have any hints as to why the Ramdisk would be relocated twice? Does anybody have any hints as to why the kernel didn't notice the ramdisk?
As you may notice, I am building these images with Yocto. The Yocto documentation advvices to bundle the initramfs with the kernel image, which I can do. But I am presented with two options here: bundle it with the kernel (which has been around since forwver), or bundle it in the FIT Image. I decided to assume that the Yocto documentation was a bit out of date and started by bundling it with my FIT image.
I will try doing what the documentation said to do next, but in the mean time, I thought I would ask what others have experienced with booting FIT Images with RAM disks. (For my particular application, I only ever need one configuration, with one kernel, one fdt, and one ramdisk, all of which could be bundled into the one kernel... so arguably, I don't need the flexibility of bundling it in the FIT image).
Thanks for any tips.
--wpd
Hi Patrick,
Am Fr., 14. Juni 2019 um 23:05 Uhr schrieb Patrick Doyle wpdster@gmail.com:
I just created my initramfs and inserted it into my fit-image.its file. When I booted, I saw the following:
Trying 'ramdisk' ramdisk subimage Description: Bootstrap ramdisk Type: RAMDisk Image Compression: gzip compressed Data Start: 0x811ae9f0 Data Size: 2613908 Bytes = 2.5 MiB Architecture: MIPS OS: Linux Load Address: 0x00000000 Entry Point: 0x00000000 Hash algo: sha256 Hash value: 0faa7c3e4927b685cd5a050112ea6b90ad4dec4e4ea8627b4f589bfc60082eba Verifying Hash Integrity ... sha256+ OK Uncompressing Kernel Image ... OK Loading Ramdisk to 83ad9000, end 83d57294 ... OK Loading Ramdisk to 8385a000, end 83ad8294 ... OK [ 0.000000] Linux version 4.14.115-yocto-standard-custom (oe-user@oe-host) (gcc version 8.3.0 (GCC)) #1 Fri Jun 14 19:49:57 UTC 2019 [ 0.000000] Board has DDR2 [ 0.000000] Analog PMU set to hw control [ 0.000000] Digital PMU set to hw control [ 0.000000] SoC Type: MediaTek MT7688 ver:1 eco:2 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 00019655 (MIPS 24KEc) [ 0.000000] MIPS: machine is MediaTek LinkIt Smart 7688 [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 04000000 @ 00000000 (usable) [ 0.000000] Initrd not found or empty - disabling initrd
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.
As you may notice, I am building these images with Yocto. The Yocto documentation advvices to bundle the initramfs with the kernel image, which I can do. But I am presented with two options here: bundle it with the kernel (which has been around since forwver), or bundle it in the FIT Image. I decided to assume that the Yocto documentation was a bit out of date and started by bundling it with my FIT image.
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.
I will try doing what the documentation said to do next, but in the mean time, I thought I would ask what others have experienced with booting FIT Images with RAM disks. (For my particular application, I only ever need one configuration, with one kernel, one fdt, and one ramdisk, all of which could be bundled into the one kernel... so arguably, I don't need the flexibility of bundling it in the FIT image).
Thanks for any tips.
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.
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
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
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,
On Mon, Jun 17, 2019 at 10:22 AM Daniel Schwierzeck daniel.schwierzeck@gmail.com wrote:
Am Mo., 17. Juni 2019 um 15:40 Uhr schrieb Patrick Doyle wpdster@gmail.com:
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:
I guess you overlooked my first comment? :D
The double relocation has been fixed after v2019.04 with e5151666364e64e6ca6e554e3d53f2a53fbc1800.
Oops, yes I did. I am sorry for the noise.
Could you also share how do you deploy your device-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 am working with a kernel that was massaged from an OpenWRT release into a Yocto build environment. The person who created the Yocto recipe for the kernel adapted the approach used in OpenWRT where, with the help of OpenWRT specific patches, the device tree is embedded within (not appended to) the kernel. I explored embedding the device tree in the FIT image and saw that I achieved better compression when it was embedded in the kernel, so I left his original code alone. Of course, adding an initramfs is totally blowing up the kernel size, but that will be my next problem :-)
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,
Oddly enough, while image size of primary concern to me, u-boot size is not that much of a concern. Right now, I am using slightly more than 50% of the size of the NOR flash for u-boot. So, I could put in a smaller NOR flash, if I worked at it, but the cost savings would be minimal. The rest of the system lives in NAND flash, which, although there is a lot more of it, there is a lot more to stuff in it, so I am trying to keep that as small as possible. Life is odd sometimes :-)
Thanks for the tips. I appreciate your help.
--wpd
participants (2)
-
Daniel Schwierzeck -
Patrick Doyle