Booting the ELF kernel without ubldr on Raspberry Pi

[Sylvain Garrigues]

Hello Ian,

I’m using u-boot from the ports (sysutils/u-boot-rpi2). It doesn’t display anything about cache being enabled.

I was just comparing the time it takes to have the Linux kernel prints its first lines, and the time it takes for the FreeBSD kernel to print its own (the « Copyright » line) when used with u-boot+loader.
For the former, it’s under a second, for the latter it’s about 3-4 seconds (mainly spent when the loader loads the elf kernel).

So I was wondered how they made it and was led to believe the Linux kernel is compressed (and self-extracting), leading to less loading time from the SD card which apparently is the bottleneck.

So since the FreeBSD kernel has no « self-extracting » feature, and since ubldr doesn’t seem to support the extracting of a gzip kernel (well it seems to work with LOADER_GZIP_SUPPORT but I see no gain), I was trying to use the compression and extraction feature of u-boot with the use of recent mkimage with support for lzma compression. I thought I could boot directly a LZMA compressed kernel.bin with mkimage, without ubldr. But I forgot about the kernel expecting a variable with the DTB address, which is set up by ubldr, so I give up and will wait to see if someone is interested in implementing a self-extracting kernel in the future.

Best,
Sylvain    


> Le 24 déc. 2015 à 16:20, Ian Lepore <ian at freebsd.org> a écrit :
> 
> On Thu, 2015-12-24 at 11:51 +0100, Sylvain Garrigues wrote:
>> If I look at what gonzo did for VERSATILEPB, I think it can be done
>> easily by writing a tiny assembly code that does something like what
>> he did:
>> 
>> # set r0..r3 to zero
>>    /usr/bin/printf "\0\0\240\343" > ${WORKDIR}/first_commands
>>    /usr/bin/printf "\0\020\240\343" >> ${WORKDIR}/first_commands
>>    /usr/bin/printf "\0\040\240\343" >> ${WORKDIR}/first_commands
>>    /usr/bin/printf "\0\060\240\343" >> ${WORKDIR}/first_commands
>> 
>> # jump to kernel entry point
>>    /usr/bin/printf "\001\366\240\343" >> ${WORKDIR}/first_commands
>> 
>> # install kernel
>>    [ ! -d ${WORKDIR}/_.kernel.bin ] && mkdir ${WORKDIR}/_.kernel.bin
>>    board_default_installkernel ${WORKDIR}/_.kernel.bin
>> 
>>    dd of=$VERSATILEPB_FLASH bs=1M count=4 if=/dev/zero
>>    dd of=$VERSATILEPB_FLASH bs=1 conv=notrunc
>> if=${WORKDIR}/first_commands
>>    dd of=$VERSATILEPB_FLASH bs=64k oseek=15 conv=notrunc
>> if=${WORKDIR}/_.kernel.bin/boot/kernel/kernel.bin
>> 
>> The only problem for the Raspberry pi is that, if I am correct, the
>> DTB is modified by the firmware (bootcode.bin) so I can´t statically
>> compile the DTB in the kernel like for VERSATILEPB :( I would need to
>> mimic what loader does and create a kernel environment variable which
>> contains the address to the DTB.
>> 
>> This is a good exercice, but it doesn´t solve my project which is to:
>> 
>> 1/ have a self-extracting kernel or have a loader which uncompress
>> the kernel, so that it takes much less time to start (my benchmark is
>> raspbian or openelec). 
>> ==> I compiled ubldr with LOADER_GZIP_SUPPORT and compressed kernel
>> to kernel.gz, reducing the size by 2. The loader does manage to load,
>> uncompress and boot the kernel.gz, but the loading time is worse than
>> when uncompressed, so I´m stuck I don´t know what´s wrong?
>> 
>> 2/ have the bootloader / kernel display a nice splash screen while
>> the kernel boots
>> ==> for that I looked at u-boot splash screen but the quality of the
>> rendering is too poor (8-bit bitmap). I looked at the VT frame buffer
>> but the slash screen feature is also limited. So I might now look
>> into the misc/raspberrypi-userland port and understand how the
>> hello_jpeg sample code does that with the GPU, then I plan to port it
>> in the kernel initialization code, not sure it´s going to work) 
> 
> What version of u-boot are you using for this?  I don't understand the
> obsession with the time it takes to load the kernel unless something
> unusual is happening.  On my systems the time it takes to load a
> kernel, whether it's u-boot or ubldr doing the work, is pretty much
> exactly the time it takes to read the media the kernel is on.  On an
> sdcard that's usually a few seconds, on gigabit ethernet it tends to be
> far less than one second.  But all of that assumes that caching is
> enabled in u-boot, and it wasn't in some of the older ports.
> 
> When u-boot starts does it say anything about the caches being enabled
> or disabled?  Is the dcache command available?  If not, it's probably
> not enabled, and a newer u-boot may fix the problem.  I hope to be
> updating all our u-boot ports over the next month or so.
> 
> -- Ian