From owner-freebsd-arm@freebsd.org Thu Dec 24 15:40: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 92270A50744 for ; Thu, 24 Dec 2015 15:40:19 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3098010E7; Thu, 24 Dec 2015 15:40:19 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id l126so185340225wml.0; Thu, 24 Dec 2015 07:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tLYxRmnd9VXg+efs0pVJKUVQekfMRYminzCoTGphhsQ=; b=rl/C9kg3lqV2ZRGCa3Uu3UPOEiJAb1qm0vZKbtKqAqVe77wqBfShdbALyfDsYstznc U1yMwXpeukVEwIRbF/6CNfAsxOGwPho6307hPcO0Ak/dm052tlfISMyNGqY9IE9Edmk8 NhDS+ciGHhToZoW/M/mxnlVN8xgWvcDmhNR9tVbfsZgAODiBGlLb0CSSSp0s7boaiIeU yw+ayceagG4AARglGQOYvaR+T52rbqwXa95G46qN6/W8AbW8cIsNEoFh2Dke9/LQkrpB 7iQscuJ5d9Je3mWECFSggWtdprDPG1FLxS4mD6iFuiiJfdh70a4fVD9tHzmostpTbpoS n1ig== X-Received: by 10.194.243.227 with SMTP id xb3mr42718782wjc.96.1450971616528; Thu, 24 Dec 2015 07:40:16 -0800 (PST) Received: from [192.168.0.5] (lns-bzn-50f-81-56-235-196.adsl.proxad.net. [81.56.235.196]) by smtp.gmail.com with ESMTPSA id x125sm32687873wmg.1.2015.12.24.07.40.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Dec 2015 07:40:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Booting the ELF kernel without ubldr on Raspberry Pi From: Sylvain Garrigues In-Reply-To: <1450970414.25138.238.camel@freebsd.org> Date: Thu, 24 Dec 2015 16:40:13 +0100 Cc: Tim Kientzle , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <32849B9F-C7B8-4A86-B8F1-043F62D2E64C@kientzle.com> <8F62699C-126D-492D-8B7E-8C250ED5BC07@gmail.com> <1450970414.25138.238.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3112) 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:40:19 -0000 Hello Ian, I=E2=80=99m using u-boot from the ports (sysutils/u-boot-rpi2). It = doesn=E2=80=99t 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 =C2=AB Copyright =C2=BB line) when used with u-boot+loader. For the former, it=E2=80=99s under a second, for the latter it=E2=80=99s = 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 =C2=AB self-extracting =C2=BB = feature, and since ubldr doesn=E2=80=99t 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 =20 > Le 24 d=C3=A9c. 2015 =C3=A0 16:20, Ian Lepore a = =C3=A9crit : >=20 > 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: >>=20 >> # 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 >>=20 >> # jump to kernel entry point >> /usr/bin/printf "\001\366\240\343" >> ${WORKDIR}/first_commands >>=20 >> # install kernel >> [ ! -d ${WORKDIR}/_.kernel.bin ] && mkdir ${WORKDIR}/_.kernel.bin >> board_default_installkernel ${WORKDIR}/_.kernel.bin >>=20 >> dd of=3D$VERSATILEPB_FLASH bs=3D1M count=3D4 if=3D/dev/zero >> dd of=3D$VERSATILEPB_FLASH bs=3D1 conv=3Dnotrunc >> if=3D${WORKDIR}/first_commands >> dd of=3D$VERSATILEPB_FLASH bs=3D64k oseek=3D15 conv=3Dnotrunc >> if=3D${WORKDIR}/_.kernel.bin/boot/kernel/kernel.bin >>=20 >> 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=C2=B4t = 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. >>=20 >> This is a good exercice, but it doesn=C2=B4t solve my project which = is to: >>=20 >> 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).=20 >> =3D=3D> 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=C2=B4m stuck I don=C2=B4t know what=C2=B4s = wrong? >>=20 >> 2/ have the bootloader / kernel display a nice splash screen while >> the kernel boots >> =3D=3D> 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=C2=B4s going to work)=20= >=20 > 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. >=20 > 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. >=20 > -- Ian