Starting Linux directly from AT91bootstrap3

Here is an update for our previous article on booting linux directly from AT91bootstrap. On newer ATMEL platforms, you will have to use AT91bootstrap 3. It now has a convenient way to be configured to boot directly to Linux.

You can check it out from github:

git clone git://github.com/linux4sam/at91bootstrap.git

That version of AT91bootstrap is using the same configuration mechanism as the Linux kernel. You will find default configurations, named in the form:<board_name><storage>_<boot_strategy>_defconfig

Let’s take for example the latest evaluation boards from ATMEL, the SAMA5D3x-EK. If you are booting from NAND flash:

make at91sama5d3xeknf_linux_dt_defconfig
make

You’ll end up with a file named at91sama5d3xek-nandflashboot-linux-dt-3.5.4.bin in the binaries/ folder. This is your first stage bootloader. It has the same storage layout as used in the u-boot strategy so you can flash it and it will work.

As a last note, I’ll had that less is not always faster. On our benchmarks, booting the SAMA5D31-EK using AT91bootstrap, then Barebox was faster than just using AT91bootstrap. The main reason is that barebox is actually enabling the caches and decompresses the kernel(see below, the kernel is also enaling the caches before decompressing itself) before booting.

8 thoughts on “Starting Linux directly from AT91bootstrap3”

I’m looking forward to read those benches on AT91bootstrap+barebox. (or even barebox+barebox !).
I agree that reading the NAND with Dcache enabled is faster, but the decompression should be the same, at least for uImages (the kernel is uncompressing itself, with D/Icache enabled (cf arch/arm/boot/compressed/), or I missed something…).

Indeed, you seem to be right, arch/arm/boot/compressed/head.S activates the caches before decompressing. So the speedup is probably due to having the caches while reading the NAND flash. I’m updating the post.

Regarding the benches, this is what I get when using barebox to load the kernel (measured with grabserial so not so precise):
– AT91bootstrap: 1.12s
– barebox 0.46s
– kernel: 1.49s
Total: 3.07s

I don’t really understand why the time used by the kernel is not the same in both cases. (1.49s vs 2.24s)
It’s the time between:
“Uncompressing Linux… done, booting the kernel.”
and
“Freeing unused kernel memory:”
right ?
Anyway, with barebox, you’ve got 1.58s to the start of the kernel, and with at91bootstrap only, 1.70s.
that’s 120ms less.
Not bad !
One question though, is at91bootstrat reading the exact kernel size (modulo one block) or more ?

I don’t think you can calculate the way you are doing because, as barebox is decompressing the kernel, you will never get Uncompressing Linux… done, booting the kernel. Instead, you havebooting Linux kernel with devicetree
[ 0.000000] Booting Linux on physical CPU 0x0

While I agree that you can’t really compute the time used by each component by using only grabserial, I really think that the speedup while using barebox is more than 120ms.

In the default configuration, at91bootstrap is reading 3MB of flash while the kernel I used is 1.7MB. You earn about 110ms by reading less blocks.

I’m Mathieu, I was present to the Captronic/LAAS seminar during december 2015 in Toulouse.
My company has to replace an obsolete ARM board and we choosed a sam 9G35 one.
I’m trying to boot from the sd card but I get a kernel panic while mount the root fs.
I found some tutorials at at91.com explaining 2 partitions must be created. First is fat typed, the 2nd is ext[2|4].

I got the latest mainline of AT91Bootstrap (3.8.5), U-Boot (2016.03), linux-2.6.39 and a buildroot fs.
I compiled each using at91sam9x5eksd_uboot_defconfig for the bootstrap and then renamed and stored on the fat partition
except the fs located on the ext partition as at91 advise.

When powering up the board, U-Boot stops on its command-line and I have to type in the command:
fatload mmc 0 22000000 zImage
for the kernel to be successfully loaded
I also added the bootargs command:
setenv bootargs ‘mem=128M console=ttyS0,115200 root=/dev/mmcblk0p2 rootdelay=2’
since the ext partition is mmcblk0p2

Did I missed something about the way to proceed for SD card boot on such a board ?
I wonder if what I try to do is possible on this board due to article at at91.com specifying:

For the Xplained boards, an alternative Buildroot configuration is
provided to boot from an SD card. Those configurations are labeled as
‘mmc’. In this case, after building Buildroot, follow the instructions
in the “Preparting the SD card” sction.

I also uploaded SAM-BA and tried to connect to board using DBGU serial port but SAM-BA do not recognize any valid chip id.
It seems connection between board and host is not done with such a cable, isn’t it?

Hi Mathieu
This is not the best place to get help, on something that’s quite unrelated to the blog post. I’d advice to try the at91 community resources instead.
Quick notes: the “macb0” error can be addressed by setting the “ethaddr” environment variable in U-Boot, but doesn’t look critical here.
Did you try “rootwait” instead of “rootdelay”? You delay of 2 seconds may not be enough.
Michael.

I am looking forward to verify the integrity of linux kernel from bootstrap. I tried to use the same process used for verifying a stand alone application, but it didn’t work. According to my understanding it should work.

Is there any way to verify the linux kernal image directly from bootstrap (skiping the uboot).