Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Dec 2015 08:20:14 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        Sylvain Garrigues <sylgar@gmail.com>, Tim Kientzle <tim@kientzle.com>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Booting the ELF kernel without ubldr on Raspberry Pi
Message-ID:  <1450970414.25138.238.camel@freebsd.org>
In-Reply-To: <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com>
References:  <C6819C94-DF61-447F-AC61-FD3E061A6F76@gmail.com> <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1450970414.25138.238.camel>