Hi!
When looking at the examples and forum archives I get the impression that L4Linux users tend to work with ramdisks. However, in general I understand that in the Linux world ramdisks are considered mostly obsolete. Initramfs is the preferred solution
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Do...
I replaced my disk image with a cpio archive suitable for initramfs and everything still works fine. Linux can dynamically recognize whether it is cpio or not. I understand my filesystem can grow dynamically until Linx runs out of memory. I dropped the ramdisk_size parameter from the kernel command line. Are there any drawbacks or pitfalls I am missing?
The next step is compression. Both ramdisks and cpio archives can be compressed, again Linux can dynamically recognize that and uncompress before usage. (I have only tested cpio.gz so far, but I understand also disk images work and both faster lzo and more aggressive bzip2 and xz are supported.)
However, when I tried to used my cpio.gz archive, the effect was zero. Someone had magically uncompressed my archive before making the U-Boot image. I tracked it down to the script src/l4/pkg/bootstrap/server/src/build.pl.
system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); $file = "$modname.ugz" if !$?;
It unpacks everything that is gzip compressed. Maybe that is necessary for object or executable files, I see some assembly manipulation a couple of lines further down, which I have not analyzed. However, for disk images or initramfs archives I cannot see the point.
So I made the following hack
diff --git a/src/l4/pkg/bootstrap/server/src/build.pl b/src/l4/pkg/bootstrap/server/src/build.pl index 22382d6..a31743e 100755 --- a/src/l4/pkg/bootstrap/server/src/build.pl +++ b/src/l4/pkg/bootstrap/server/src/build.pl @@ -75,8 +75,13 @@ sub build_obj($$$) printf STDERR "Merging image %s to %s [%dkB]\n", $file, $modname, ((-s $file) + 1023) / 1024; # make sure that the file isn't already compressed - system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); - $file = "$modname.ugz" if !$?; + if ($file =~ m/ramdisk-arm.rd$/) { + system("false"); + } else { + system("$prog_gzip -dc $file > $modname.ugz 2> /dev/null"); + } + $file = "$modname.ugz" if !$? ; + print "using ", $file ; system("$prog_objcopy -S $file $modname.obj 2> /dev/null") if $strip && !$no_strip; system("$prog_cp $file $modname.obj")
This worked as expected, my disk image remained compressed and Linux could uncompress it a boot time. Of course it is a hack, because the file name should not be hard-coded there. Same question as before, am I missing anything here?
Also build.pl would fail to do the uncompression if a module is compressed with lzo, bzip2 or xz.
Yes, I have found the variable BOOTSTRAP_UIMAGE_COMPRESSION. It worked fine during image creation, but during boot U-Boot failed with
Verifying Checksum ... OK Uncompressing Kernel Image ... Error: inflate() returned -5 GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover resetting ...
I assume this could be fixed by modiyfing the memory map. However, because my kernel is very small compared to the user space image and Linux has this nice dynamic support for various compression schemes I think I prefer an uncompressed U-Boot image containing a compressed user space image.
Regards,
Uwe Geuder Nomovok Ltd. Tampere, Finland uwe.gxuder@nomovok.com (bot test: humans correct 1 obvious spelling error)