From owner-freebsd-arm@freebsd.org Thu Dec 24 15:20:19 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A552A4FE12 for ; Thu, 24 Dec 2015 15:20:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F881150A for ; Thu, 24 Dec 2015 15:20:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 24 Dec 2015 15:19:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tBOFKE8r005789; Thu, 24 Dec 2015 08:20:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1450970414.25138.238.camel@freebsd.org> Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Ian Lepore To: Sylvain Garrigues , Tim Kientzle Cc: freebsd-arm Date: Thu, 24 Dec 2015 08:20:14 -0700 In-Reply-To: <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> References: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 15:20:19 -0000 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