Hi,

I'm having problems trying to wean myself off the very useful sam-ba.exe and TCL scripts. I'm using the at91sam9g45 dev board and I've got the bootloader, u-boot and linux running.

My first problem (or more likely mis-understanding) starts with the at91bootloader. I can write the bootloader to nand flash using sam-ba GUI->Nandflash tab->"Send Boot file" script, which writes the binary to nandflash at offset 0x0. The bootloader starts and loads u-boot and everything works fine. If i try to do the same thing within sam-ba GUI->Send File and use an offset address of 0x0 it successfully writes the flash (based on the logs) but the board doesn't boot (no print outs what-so-ever).

I've used this case as i think its similar to what i'm trying to do within linux, which is re-writing the first MTD partition with the exact same boot loader file (to be able to upgrade the boot without using sam-ba).

I've been reading through this forum and the only thing i could see that seems relevant is possibly I'm missing arm interupt vectors needed or some length parameter thats not actually present in the bootloader binary file itself, but is put in there by the sam-ba script "Send Boot file". This would explain why there are two methods for writing a file to flash, one for boot sectors and one for normal files.

Has anyone had any experience with writing the bootloader back the nandflash or could point me in the direction of documentation/resources that might help.

p.s. I've tried padding the bootloader and a number of other obvious things with no avail.

Thanks in advance.

Hey all,

Well i answered my own question. I programmed the boot partition using SAM-BA and the supplied nandflash_at91sam9g45ekes.bin and then did a readback using nand dump. It seems for some strange reason the Atmel SAM-BA program slightly changes the boot loader binary before writing it to the flash.

I've made the same change to my file using a hex editor and now i can write to flash and boot from it without any problems.

But if anyone has any insight into why this is the case I'd like to hear why.

I couldn't attach the file (won't allow .bin extensions) but the change was byte 18 goes from 0x30 to 0x00.

Although you mention byte 18, I think you face the followig issue:

See datasheet 11.4.2.1:

The sixth vector, at offset 0x14, contains the size of the image to download.

Thanks for the info. Are you referring to the AT91SAM9G45 preliminary datasheet? The section you referred to is then C15 Registers Access?