Date: Sun, 20 Nov 2016 15:45:34 -0700 From: Warner Losh <imp@bsdimp.com> To: Lee D <embaudarm@gmail.com> Cc: girivs82@yahoo.com, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Low level boot loader for freebsd Message-ID: <CANCZdfqxq9aa4_DwRgf0HUM%2B8NFN49TiqtxqX4sbrxoXOSrunA@mail.gmail.com> In-Reply-To: <CANC_bnNCWOM9CKZrQAN7ODbREaF%2BwAum3jvCOwxrCEsLBEf=LQ@mail.gmail.com> References: <234108602.628399.1478324542467.ref@mail.yahoo.com> <234108602.628399.1478324542467@mail.yahoo.com> <CANC_bnNCWOM9CKZrQAN7ODbREaF%2BwAum3jvCOwxrCEsLBEf=LQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 20, 2016 at 12:08 PM, Lee D <embaudarm@gmail.com> wrote: > On Sat, Nov 5, 2016 at 1:42 AM, Shankar Giri via freebsd-arm < > freebsd-arm@freebsd.org> wrote: > >> Serious problems with blank emails, so I'm using my alternate email >> address. Hopefully this will go through.-----------------------------------Just >> an idea I'm throwing out. I decided to do a bit of baremetal coding on my >> Jetson-TK1 that got me thinking. Right now FreeBSD relies on uboot as the >> low level bootloader and ubldr uses the u-boot API to bootstrap on top of >> it. I'm thinking of extending the functionality of ubldr to remove the >> u-boot dependency and use our own baremetal lowlevel hookups (well, name >> might have to be changed since it won't be using u-boot >> anymore). Advantages:1. Low level bootstrapping code part of FreeBSD tree. >> Using the libstand library and the low level hookups, we'd get the low >> level bootloader compiled while building world+kernel.2. Sharing the same >> fdt. Since the low level bootloader uses the same dts/dtsi files as the >> kernel, there is no reason to have two of them. The same fdt can be shared >> between the bootloader and the kernel. Theoretically we could still do that >> now between u-boot and freebsd, but being maintained by different projects, >> the shared dts will have an unavoidable dichotomy.3. Seamless >> bootstrapping. Right now, the bootloader and kernel are completely separate >> entities, so once the kernel takes control, it ends up having to initialize >> a bunch of HW that the bootloader has already take care of. This makes >> sense now because there are no guarantees on what has and has not been >> initialized by u-boot and what could change in future. With the bootloader >> part of the freebsd base, we might actually be able to just do post-init >> work on the kernel and this could actually improve boot times (and in the >> embedded world, this counts for a lot)4. Use our default toolchain. Clang >> (binutils is unavoidable at this point till the llvm linker is mature). I >> already compiled my bare-metal code on Jetson-TK1 using Clang+binutils and >> it ran quite well, llvm has has gotten pretty mature at this point. I >> stopped using gcc for my arm compilation a long time ago, even for the >> freebsd kernel. Disadvantages:1. Embedded world is fragmented, too many >> machine/arch specific variations. Code maintainability could be a >> nightmare.2. Testing low level is difficult. You don't even have a uart >> console in bare-metal, so you'll have to rely on JTAG (sometimes really >> expensive lauterbachs) or poring through assembly. Plus we need to find >> people with embedded hardware willing to test them.3. Adoptability. I don't >> think people will warm up to a new bootloader soon, particularly those who >> have u-boot experience. Without contributors, this will die a slow >> agonizing death. What does the community think? Is this something that >> could actually help? If yes, I'm willing to start working on a >> proof-of-concept. My test vehicle would be the Jetson TK1. >> > > I think this is a great idea and I really wonder why the FreeBSD world > seems to be so enamored of u-boot. It is universally available. Lower-level boot loaders have been tried, and are kinda actually supported in places. However, as a project this represents a huge investment of time and effort for little return. > One reason that people choose FreeBSD over Linux for embedded work is > because it avoids the difficulties of the GPL. But of course, u-boot is > GPL. True, but the GPL is confined only to u-boot. > The nice thing about u-boot is that it is one program that can be > configured for many platforms. Correct. The project can leverage u-boot to work on a lot more platforms that we'd otherwise be able to support. > However, for the embedded world, I think a better approach to booting would > be to fully document the boot requirements of the kernel itself, so that we > can all write our own bootloaders for our own highly customized embedded > platforms. You are, of course, free to do this. Loading the kernel directly even mostly works, so long as you get the metadata structures that ubldr creates to be in place correctly. Alternatively, you can create a custom ubldr-like thing that talks to your boot loader if you want to allow loading of modules at boot time. > I have tried to boot freebsd myself from a standalone loader, skipping > u-boot and ubldr. I've only had partial success so far. This is something > that I am going to have to address in the coming months. Most likely, the meta-data is missing or corrupted that the kernel is expecting to find. > My intent would be to post my techniques for booting from bare metal > without ubldr as I figure it out. But it will be a few weeks at least > before I can work on it again. That would be cool. The early arm ports bypassed /boot/loader entirely, but people were upset that you couldn't set tuneables, nor could you load modules. For some applications, this is critical. For others, it's not needed. > Right now, my approach is: > > 1. Keep a copy of the FreeBSD kernel on my FAT32 boot partition, and load > that instead of the one on the UFS partition. > 2. Compile the FDT into the kernel. > 3. Configure the peripherals in my boot loader before starting FreeBSD. > The kernel seems to require that certain things be configured by u-boot. Depending on the platform, you may be seeing that we don't adequately implement pinmux, or that our dts doesn't completely describe the pins correctly. Also, on many boards, the primary boot loader and/or u-boot is expected to configure the DRAM memory controller completely. The kernel has no code to do that. Maybe the boot loader you are using is running out of SRAM and not configuring DRAM quite right, which means loading the kernel into DRAM and jumping to it isn't going to work. > Part of the idea here is avoid having to include UFS code in the boot > loader. It's quite small, I don't see why you'd want to. For the Atmel AT91RM9200, boot1 fits into about 6.5k and can load a kernel off of UFS SD card directly. It loads a compressed kernel and then decompresses it because that's faster than loading the uncompressed kernel. And requires that you have fewer partitions on your card, which simplifies deployment. > This approach is able to start booting the kernel but fails when it gets to > loading the SD-Card drivers. I think. It's been a while since I last > tried it. > > I hope you'll keep us apprised of your progress as well. I'd be interested as well. In general, FreeBSD/arm will continue to use u-boot, especially in the release engineering process. However, most of the folks working in that area are open to non-intrusive changes that facilitates other booting environments, so long as they are well maintained. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqxq9aa4_DwRgf0HUM%2B8NFN49TiqtxqX4sbrxoXOSrunA>