Low level boot loader for freebsd
girivs82 at yahoo.com
girivs82 at yahoo.com
Sat Nov 5 05:45:48 UTC 2016
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.
More information about the freebsd-arm
mailing list