I am working on a project using the AT91SAM9G20 running Linux. During the power up sequence I need to (within a 100ms or so) receive a message over the SPI bus, issue a response back and then boot Linux with arguments based on the SPI message received. I have tried to remove as much from U-Boot as possible but I can not get it to load fast enough so I was thinking of replacing it with my own code.

Since I need SPI support with a few possible request with their own specific responses I do not think this would fit in a modified at91bootstrap. I have written an application using the demo code (blinking LED's etc) and have tested the SPI communication using gdb and JLink so I have that part done. My issue now is to assemble this code so that at91bootstrap will be able to load it from NAND into SDRAM and execute it.

Reading the forums I've found very little information. I know I need to set the link address for my binary to 0x23F00000 but I am unsure of what initial startup code should be at this location. I see in the U-Boot source there is a cpu/arm926ejs/at91sam9/start.S and cpu/arm926ejs/at91sam9/lowlevel_init.S but I'm hoping that I won't need a ton of assembly linked in at the begining. If I do, no big deal just not sure what all is needed.

Has anyone loaded their own bare metal code using at91bootstrap? If so what did you do. That will probably get me most of the way through this issue.

>>Has anyone loaded their own bare metal code using at91bootstrap? If so what did you do. That will probably get me most of the way through this issue.

Yes, you have 16KB of space, arguably closer to 32KB if you use both SRAM blocks, and you keep the stack in check. You can do a lot of work in 16KB, you can certainly talk to SPI devices. Not sure how you'd pass parameters to uBoot, but I think loading the kernel would be just a matter of pulling the image from NAND, handling ECC, set up the parameter block, and jumping into the kernel image. I'm not convinced uBoot does anything magic, it just has a lot of features and functionality. You'd be hard pushed to boot linux directly on a 4 KB 9260, but a 16 KB 9G20, that's a whole other matter.

AT91 arbitrarily loads 256KB from NAND, or where ever, into the top of SDRAM at 0x23F00000, ie top 1 MB of 64 MB. This could frankly be anywhere within the SDRAM starting at 0x20000000 once you have initialized it, and limited by the SDRAM size, presumably up to 256 MB, but likely 32 or 64MB in most vanilla implementations.

Your dealing with an ARM9, so you can pretty much compile a classic bootable image, at this address, with vectors, copy the vector table into the base of SRAM, and map the SRAM to zero. This way the ARM9 can use interrupts with your code, as you can't rebase the vectors. If you've done much ARM7/9 development work this should be pretty straight forward.

If you don't need to handle interrupts/faults, you can just jump into linear ARM9 code(subroutines), straight out of AT91BootStrap, with little, or no, additional initialization code.

I plan on not using U-Boot, just loading the Kernel into RAM and jumping. I'm debating on if I'll use the DRM support for the SPI bus, I use it in the SPI Slave Kernel Module I wrote so I'm pretty familiar with that part. That would be the only reason I should need Interrupt Vectors.

I've started by reading the start.S and the first few sections of code that run at start up of U-Boot so I have an idea of everything that needs to be setup. I just found it a pain to remove code from U-Boot as so many peripherals are dependent on different libs that it feels simpler to just write my own bootloader. Most of my binary will be .rodata for all the predefined responses anyways.

I think my biggest issue will be getting everything to compile, setting the location of .text, including the correct static libs, etc. Its been a while since I wrote bare metal code, no longer have the luxury of an OS.

Suggest you look at AT91BootStrap as your model, not uBoot.

Review it's startup code (crt0_gnu.s), and how the base address of SRAM (0x200000) is specified in the makefile. You can set the stack top to 0x304000.

You will not need to set up the hardware, memory and clocks, AT91BootStrap will have done that already. uBoot and the kernel do not tweak the clocks or memory, they run in the environment built for them. The kernel sets up the MMU and page tables to virtualize the memory map.

Unless you have a huge amount of code, you should be able to integrate the code you need directly into AT91BootStrap, and stay within the 16KB window. Personally I don't find GNU/GCC to produce highly packed code, if space gets tight consider a different compiler.

> I plan on not using U-Boot, just loading the Kernel into RAM and jumping.

Hi there

Before you toss the U-Boot code, take a look at lib_arm/armlinux.c, or read the article "Booting ARM Linux" by Vincent Sanders. An obscure but crucial data structure that the boot program builds and passes to the ARM Linux kernel is ATAGS, which includes the machine type and memory information.

Regards