Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Nov 2016 14:08:52 -0500
From:      Lee D <embaudarm@gmail.com>
To:        girivs82@yahoo.com
Cc:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: Low level boot loader for freebsd
Message-ID:  <CANC_bnNCWOM9CKZrQAN7ODbREaF%2BwAum3jvCOwxrCEsLBEf=LQ@mail.gmail.com>
In-Reply-To: <234108602.628399.1478324542467@mail.yahoo.com>
References:  <234108602.628399.1478324542467.ref@mail.yahoo.com> <234108602.628399.1478324542467@mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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.

The nice thing about u-boot is that it is one program that can be
configured for many platforms.

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.

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.

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.

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.

Part of the idea here is avoid having to include UFS code in the boot
loader.

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.

PS I am working on Xilinx Zynq.

Lee



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANC_bnNCWOM9CKZrQAN7ODbREaF%2BwAum3jvCOwxrCEsLBEf=LQ>