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

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

[Patrick Doyle]

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 at 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

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

[Daniel Schwierzeck]

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 at 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.

-- 
- Daniel

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

[Patrick Doyle]

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

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

[Daniel Schwierzeck]

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,

-- 
- Daniel

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

[Patrick Doyle]

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