Date: Fri, 25 Mar 2016 19:14:58 +0100 From: Sylvain Garrigues <sylgar@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: ticso@cicely.de, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support Message-ID: <2A98ACB7-2815-4169-951A-0123C71D9987@gmail.com> In-Reply-To: <CANCZdfpB3EX7YS-4qi_mgRx23y62Gpki8EVP0Mjp=Z9u5O911w@mail.gmail.com> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> <CANCZdfrhm5NSCXehkDc%2BDa4cxYhbU_NnEopR__e_a0CgajEL3A@mail.gmail.com> <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> <CANCZdfpB3EX7YS-4qi_mgRx23y62Gpki8EVP0Mjp=Z9u5O911w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
u-boot> fatload mmc 0 0x100000 kernel.bin takes around the same time than ubldr (actually slightly less, let=E2=80=99= s say 4s - but that=E2=80=99s still so slow...) Happy to help or test anything to get FreeBSD=E2=80=99s kernel first = line appear on the screen near =C2=AB instantaneously =C2=BB (~ 1s) like = our NetBSD or Linux friends. Sylvain > Le 25 mars 2016 =C3=A0 19:01, Warner Losh <imp@bsdimp.com> a =C3=A9crit = : >=20 >=20 >=20 > On Fri, Mar 25, 2016 at 11:55 AM, Sylvain Garrigues <sylgar@gmail.com = <mailto:sylgar@gmail.com>> wrote: > Thank you.=20 >=20 > I wanted to boot the kernel directly so as to: > 1/ remove the dependency on a 3rd party loader > 2/ reduce boot time and make it comparable with NetBSD and Linux = (which don=E2=80=99t use u-boot) >=20 > NetBSD and Linux on the Pi boot so much faster than our FreeBSD image: = less than 1 second after power-up, the first kernel copyright line = appears on my LCD. For the FreeBSD images, the longest part is ubldr = loading the kernel. It takes around 4/5 seconds (with the same SD card). >=20 > I used recent u-boot versions (the current u-boot-rpi2 port is getting = old and is not in sync with the u-boot-rpi port recently updated), tried = with dcache enabled, but the boot process still takes several seconds, = most of the time being spent in ubldr loading the kernel. >=20 > I have no idea how we could improve the booting time? I wanted to = experiment with booting the kernel directly as the first ARM program on = my Pi, but as you explained I need some init code. I managed to compile = Andrew=E2=80=99s one = (https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c = <https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c>) but I don=E2=80=99t know how to use it. Andrew, if you read = this ;-) >=20 > I wonder if the loader could be more efficient at loading off the SD = card. The SD cards can do 10-20MB/s easily, and the ARM kernel is around = 5MB last time I checked. 5 seconds is 1MB/s, which is much slower than = we know the hardware can do. I don't know if that's because the callback = mechanism in u-boot.bin is so slow (that's what ubldr uses to load the = kernel), or there's something inherently slow about our loader. Some = analysis here might be quite useful. I'm guessing that we're not getting = all the benefits from streaming read mode because we're doing I/Os that = are tiny for some reason. But I haven't looked to make sure. >=20 > What's the speed when booting directly from u-boot.bin? >=20 > Warner >=20 >=20 >=20 > =20 >> Le 25 mars 2016 =C3=A0 06:48, Warner Losh <imp@bsdimp.com = <mailto:imp@bsdimp.com>> a =C3=A9crit : >>=20 >>=20 >>=20 >> On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter = <ticso@cicely7.cicely.de <mailto:ticso@cicely7.cicely.de>> wrote: >> On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: >> > Hello, >> > >> > I have written a small (ugly) patch to be able to boot a kernel = directly without the ubldr loader while still using an external DTB = (Linux-style booting may pass the DTB location pointer in the r2 = register). >> > The patch is here: = https://reviews.freebsd.org/differential/diff/14577/ = <https://reviews.freebsd.org/differential/diff/14577/>; >> > >> > I tested my patch successfully with the QEMU emulator with the -dtb = option available in recent versions, using a VERSATILEPB kernel without = FDT_STATIC. >> > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash = -cpu arm1176 -dtb versatilepb.dtb >> > FYI, once the kernel is built, here is the script to build the = versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 = registers): https://reviews.freebsd.org/P92 = <https://reviews.freebsd.org/P92>; <https://reviews.freebsd.org/P92 = <https://reviews.freebsd.org/P92>>; >> > >> > I also tested successfully my patch on my Raspberry Pi 2 using = U-BOOT and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI = option): >> > u-boot> fatload mmc 0 0x200000 kernel.bin >> > u-boot> go 0x200000 >> > >> > That works. >> > >> > So now I thought I could even bypass u-boot and launch kernel.bin = directly from the Pi firmware??? But it doesn???t work, I don???t = understand why, and that is why I am writing here. >> > Here is the config.txt which I thought would work: >> > >> > kernel=3Dkernel.bin (instead of u-boot.bin) >> > kernel_address=3D0x200000 (line added because a FreeBSD kernel = needs to be loaded on a 1MB or 2MB boundary) >> > device_tree=3Drpi2.dtb >> > device_tree_address=3D0x100 >> > disable_commandline_tags=3D1 >> > >> > What am I missing? Is it even possible to boot kernel.bin directly = on the Pi (with my patch)? I found this static minimalist loader from = Andrew here: = https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b3= 9acd710c = <https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c><https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d= 849d997b1b39acd710c = <https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c>> - does it mean such a loader is necessary before the kernel? >> > >> > Thanks, >> > Sylvain >> > >> > PS: I know the =C2=AB official and supported =C2=BB way of booting = FreeBSD on the Pi is the u-boot + ubldr combination. I just would like = to finish this experiment and understand why kernel.bin cannot be booted = directly. >>=20 >> I don't know if it is part of ubldr, or if there is any additional = code, >> which runs before ubldr, but the Pis won't boot with the ARM CPU. >> Somewhere in the boot path is GPU bootcode, which then enables the = ARM >> CPU. >> You also need low level HW init, such as setting up the clocks and = RAM, >> which is not done in the Kernel. >>=20 >> What you are missing it the hardware init code that's in u-boot.bin. = This code sets up >> the board after the on-board GPU loads it into the ARM's address = space. That code >> sets up the ARM side of the world and hands off the code to ubldr = which finds the dtb >> and does the normal /boot/loader things as well (loading modules, = setting tunables >> and the like) then hands off to the kernel. You can eliminate ubldr = without a huge >> amount of effort, as you've found. However, eliminating u-boot.bin is = going to be >> a lot more work/ >>=20 >> tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite = a bit different >> than between the initial bootstrap and u-boot.bin. So you can't just = drop in kernel.bin >> and have it work without replicating that interface. >>=20 >> Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A98ACB7-2815-4169-951A-0123C71D9987>