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

  • board_name can be: at91sam9260ek, at91sam9261ek, at91sam9263ek, at91sam9g10ek, at91sam9g20ek, at91sam9m10g45ek, at91sam9n12ek, at91sam9rlek, at91sam9x5ek, at91sam9xeek or at91sama5d3xek
  • storage can be:
    • df for DataFlash
    • nf for NAND flash
    • sd for SD card
  • our main interest will be in boot_strategy which can be:
    • uboot: start u-boot or any other bootloader
    • linux: boot Linux directly, passing a kernel command line
    • linux_dt: boot Linux directly, using a Device Tree
    • android: boot Linux directly, in an Android configuration

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.

Alexandre Belloni

Author: Alexandre Belloni

Alexandre is Bootlin's co-owner and COO. Alexandre joined as a kernel and embedded Linux engineer in 2013, and became co-owner and COO in 2021. More details...

8 thoughts on “Starting Linux directly from AT91bootstrap3”

  1. 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…).

    Reply

    1. 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

      Without barebox:
      – AT91bootstrap: 1.70s
      – kernel: 2.24s
      Total: 3.94s

      Reply

      1. 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 ?

        Reply

        1. 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 have
          booting 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.

          Reply

  2. Hi Alexandre,

    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

    after saving env, I type the bootz command and get following results:

    U-Boot> bootz
    Kernel image @ 0x22000000 [ 0x000000 – 0x24195c ]

    Starting kernel …

    Uncompressing Linux… done, booting the kernel.
    Linux version 2.6.39+ (root@Ntb-ocl-ubuntu) (gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) ) #1 Mon May 30 10:46:32 CEST 2016
    CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
    CPU: VIVT data cache, VIVT instruction cache
    Machine: Atmel AT91SAM9X5-EK
    Memory policy: ECC disabled, Data cache writeback
    Clocks: CPU 400 MHz, master 133 MHz, main 12.000 MHz
    …

    It seems to me the kernel I compiled Mon May 30 is successfully loaded but after HW initalization I get the following message:

    Waiting 2sec before mounting root device…
    VFS: Cannot open root device “mmcblk0p2” or unknown-block(0,0)
    Please append a correct “root=” boot option; here are the available partitions:
    Kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
    [] (unwind_backtrace+0x0/0xe0) from [] (panic+0x50/0x178)
    [] (panic+0x50/0x178) from [] (mount_block_root+0x230/0x280)
    [] (mount_block_root+0x230/0x280) from [] (prepare_namespace+0x160/0x1b4)
    [] (prepare_namespace+0x160/0x1b4) from [] (kernel_init+0x100/0x134)
    [] (kernel_init+0x100/0x134) from [] (kernel_thread_exit+0x0/0x8)

    I tried ext2 and ext4 fs type but panic remains.

    I’m also surprised by the bootstrap startup messages:

    RomBOOT

    AT91Bootstrap 3.8.5-00008-g5029707 (vendredi 27 mai 2016, 16:59:43 (UTC+0200))

    1-Wire: Loading 1-Wire information …
    1-Wire: ROM Searching … Done, 0 1-Wire chips found

    WARNING: 1-Wire: No 1-Wire chip found

    1-Wire: Using default information

    1-Wire: Board sn: 0x4010425 revision: 0x8421

    SD/MMC: Image: Read file u-boot.bin to 653262848
    SD: Card Capacity: High or Extended
    SD: Specification Version 3.0X
    SD/MMC: Done to load image

    U-Boot 2016.03-linux4sam_5.3 (May 27 2016 – 17:22:40 +0200)

    CPU: AT91SAM9G35
    Crystal frequency: 12 MHz
    CPU clock : 400 MHz
    Master clock : 133.333 MHz
    DRAM: 128 MiB
    WARNING: Caches not enabled
    NAND: 128 MiB
    MMC: mci: 0
    reading uboot.env
    In: serial
    Out: serial
    Err: serial
    Net: macb0
    Error: macb0 address not set.

    Please, see the last error line about macb0

    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?

    Thanks for help,

    Regards,

    Mathieu Cier

    Reply

    1. 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.

      Reply

  3. Hi Michael,

    Thanks for answers.
    Indeed I tried a rootdelay of 3 seconds and since partitions on mmc device are detected.

    Mathieu

    Reply

  4. Hello Alexandre,

    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).

    Thanks in advance.

    Reply

Leave a Reply