I've modified, loaded, and executed a few applications to my board (AT91SAM9M10G45EK) using SAM-BA - mostly loads to DDRAM - and all of that works great.

Now I'm ready for the next step - loading the bootstrap to the board so that I can run one of these applications at startup. I've discovered that there are a few versions of the AT91Bootstrap program - one (v. 3.0) comes in the board's Software Evaluation Kit, another can be found in the board support pages (v. 1.16), and yet another version can be found in the "Academy" pages of the at91 community Web site. I've been trying to work with v. 3.0, the one packaged as "at91bootstrap-at91sam9m10-ek-gnu" in the Software Evaluation Kit.

I've been using GNU tools (specifically, YAGARTO's packaged GNU tools), and I had no problem compiling the bootstrap project for my EK. I used SAM-BA to load the "boot-at91sam9m10-ek-nandflash2ddram.bin" file to the NAND on my board (using the "SendBoot" option). Note that I did take into account my application's size, and input that into the AT91 project build accordingly. I loaded my application at address 0x20000 in NAND. I cycled the power on my board. And the last line ever printed to serial out was "Setting: MCK = 133MHz". After that, nothing happens...it's like the bootstrap just stops executing itself, and therefore everything else. I should definitely be seeing more output than this.

Could I have done something extremely wrong? I admit that I have a lot to learn here, so I wouldn't doubt I made some obvious error.

Does anyone have any "steps for success" I can follow in order to get my program executing at startup? And has anyone encountered the issue I mentioned above?

Thanks in advance...

I tried compiling the v. 3.0 Bootstrap so that I could test it out loading UBoot and Linux (see the Linux4Sam project at http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted). The bootstrap got hung on the same thing (last reported event was "Setting: MCK = 133MHz.").

I added a little more trace code to the bootstrap and found that the code goes as far as the CP15_EnableIcache() call, but just seems to freeze forever once CP15_ReadControl() is called.

This leads me to believe that I'm not compiling this correctly (some setting is not right), or that the v. 3.0 Bootstrap is flawed. Has anyone had success compiling and using the 3.0 Bootstrap?

Since I have successfully used the binaries for the AT91Bootstrap, UBoot, etc. provided on the Linux4Sam pages, I'm going to attempt compiling the source they provide for v. 1.16 of the AT91Bootstrap. If I have more questions, I'll post them here. If anyone has encountered any "gotchas," I would appreciate hearing about them.

Thanks again...

Okay, I switched to using the v. 1.16 project, and after a slight modification (see this link: http://www.at91.com/forum/viewtopic.php/t,20624/), got it compiling and linking. I tested it out with the other binaries in the Linux4Sam package, and all works fine...my compiled bootstrap seems to load uboot without a problem, and uboot loads Linux, etc.

Now I am trying to modify v. 1.16 of the bootstrap to execute a simple program. The bootstrap seems to work okay...it makes it all the way to the end of main (where it returns "JUMP_ADDR"), and then nothing happens. I loaded the bootstrap using SAM-BA and the "SendBoot" command. Then I loaded my simple program at location 0x20000 in NAND, as this is what the "IMG_ADDRESS" is currently defined as in the bootstrap.

The program seems to get copied over by the bootstrap okay...it resides in the "JUMP_ADDR" location of memory after I restart the board. But why doesn't it execute? What am I doing wrong? I think I'm missing something very obvious. Can someone help me out?

May be it does execute, but crashes.

You could disassemble the code with something like objdump and do some basic analysis and code walking to see if it appears runable code.

You could dump the code out before jumping to it, to confirm that it is really loading what you expect.

You could do a checksum or CRC to sanity check it's the same code you built on the host.

You could use a hardware debugger and step into the code and understand how/where it fails.

You could output some additional checkpoints to the debug serial port.

Look at the code you are trying to run. If you start playing with the clocks, this can cause problems with SDRAM that's already up, or peripherals setup using the original basis. If you use interrupts, you need to be sure what memory is mapped at zero, and the vectors have been copied there.

Well, everything seems to be working, but I don't have any real reason as to why. Two things I did differently since my last post: for my board header file (at91sam9ma10g45ek) in the AT91 Bootstrap, I left the IMG_SIZE as its default value (0x40000). I was/am somewhat unclear as to whether the IMG_SIZE describes the Bootstrap image size, or the size of the image the bootstrap is supposed to be jumping into. I also changed the JUMP_ADDR to 0x70000000 (it was 0x73F00000). All of the sample projects I have been building specifiy 0x70000000 as their start location, so I figured I would specify this as the start address. I have loaded the bootstrap with SAM-BA (SendBoot command) a few different times, loaded various sample projects at address 0x20000, and everything I have tried thus far works. Maybe it was the IMG_SIZE that messed me up before...I had a lower size specified, but then again, I thought SAM-BA overwrote the size in the exception vectors, so figured it wasn't a huge deal at the moment, anyway. Maybe it actually is a big deal.

Something interesting that is happening now though, is that I am seeing some type of corruption in my debug output. Example:
I loaded the bootstrap to the board with SAM-BA - no corruption.
I loaded a sample program for my board (part of the EK download) titled "basic-pwm-project-at91sam9m10-ek-gnu". For some reason, all of the Makefiles provided with the sample kit are specified for use with another board, so I don't trust the .bin files, either. I recompiled the project for my specific board, then loaded it to address 0x20000 using SAM-BA. I disconnected, then reconnected power to the board. I attached a screenshot of what I see in my serial console. The first three lines read okay (I inserted these into the bootstrap for my own reference). The third line is the last printout from my bootstrap code. It should say "About to return from main()...". It seems to be overlapping with the actual sample program output, which is the following (in code):

So something weird is going on there.

The 0x20000 address is the second (128K) block within the NAND part, and is not in the ARM's address space.

The 0x40000 length is the two NAND blocks (256K) to accommodate uBoot. You can make this bigger, or smaller, if required to accommodate your own code. I'd stick to a multiple of 128KB. The Linux kernel is typically stored at 0x200000, and even if you don't uses that, you have some headroom. The point of keeping it short/small is to limit the amount of time it takes to load/boot to a minimum.

AT91BootStrap goes into the NAND at zero, the first 128K block, the amount loaded on AT91SAM9xxx devices depends on the size of the primary SRAM, the size is encoded in the vector so RomBOOT can sanity check it.

Your code running in SDRAM doesn't need this, unless you add some sanity checking into your AT91BootStrap code.

Are you changing any clocks, or baud rates as you enter your code, either in main(), or prior to that in startup.s or whatever? If you change baud rates, or reprogram them, make sure the serial port has sent all pending data first.

The code was typically high loaded, ie at 63MB (assuming a minimum 64MB seen on most AT91SAM9xxx parts), so that it can load the linux kernel and have it decompress at the front of SDRAM/DDR, and do the virtualization cleanly. Remember uBoot and AT91BootStrap all disappear in oblivion once you jump out of them.

If you are strapping directly into your final application, putting it at the base of the SDRAM/DDR makes a lot of sense. You should consider pointing your stack into the fast SRAM on-chip.

The applications I have been testing boot capabilities with are those provided in the Atmel Software Evaluation Kit ("at91sam9m10-ek-softpack-1.9", found at http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4735). All of these applications use the startup code found in the at91 library ("board_cstartup.S", "board_lowlevel.c", etc.). "board_lowlevel.c" initializes the main oscillator, PLLA, and also performs a switch to "fast clock," among other things. I haven't made any modifications to these files...I made the assumption that they should work "as is" since they are part of at91lib. For the sample project that produced the corrupt output I posted about before, the only calls in main() preceding the debug output are:

Everything that happens before those calls should be part of the at91lib board startup code (aside from the bootstrap, of course).

It's possible that the at91lib code is responsible for mangling things at startup...I have noted corrupt serial output when using one of the fatfs projects ("basic-fatfs-sdcard-project-at91sam9m10-ek-gnu") provided in the software EK. This project was sending out garbage when it was just programmed from SAM-BA and run in DDRAM (with the "go" command in the SAM-BA tcl shell). I would like to know if this is a fact, though, or just a plausible theory.

I am currently using the AT91 Bootstrap to jump directly into the Atmel application sample I have programmed onto the board. Once I know this works correctly, my plan is to test booting into a more complicated application that I have produced. At some point, U-Boot may come into the picture...but I am trying to understand one piece of the boot process at a time, so I'd like to ensure the AT91 Bootstrap is working reliably for me, first. I'd also like to try all of this out in Dataflash and make sure that works okay, too.

I would avoid doing the TRACE_CONFIGURE, it meddles with the GPIO pins, and resets the DBGU and changes the baud rate. The port and the GPIOs it uses have already been successfully initialized.

Without carefully waiting for the USART to finish sending the last character you are likely to knock the receiver out of sync.

I suspect the value for MCK is correct, as it probably doesn't reprogram that when you get back from main().

If you want to leave the GPIO and TRACE initialization in there, add in a small spin-loop delay of at least one or two character times.

Removing the TRACE_CONFIGURE line does the trick. I'm assuming this line is unecessary because the AT91 Bootstrap code already does the same thing...and that interrupting whatever it is doing could cause (temporary) garbage output?

I did attempt the alternate route of leaving TRACE_CONFIGURE in and adding a delay loop, but it didn't really have the effect I was hoping...still lots of garbage.

Regardless, thank you! I am slowly making progress towards the bigger picture.

This may be worthy of another thread...I will keep working on it before I resort to that, though.

Now testing everything that I have done so far, I am trying to make things work in dataflash (SPI Flash). It sort of works...my compiled dataflash bootstrap can be loaded in place of the Linux4Sam dataflash bootstrap...everything starts up and Linux boots correctly. Just loading the bootstrap by itself (using SAM-BA), or with a sample application to jump into...well, nothing happens. Whenever I restart the board (by disconnecting power), my bootstrap code is erased from address 0x0 (something I did not observe happening when NAND was the target). So I know this is capable of working, but I am not sure why it is currently failing...it doesn't act like the bootstrap starts up at all when I try booting into a sample application.

You can pretty much disregard my last post. I figured out what I did wrong...I'll explain myself in case someone else ends up in this same predicament.

All of the time I was working with NAND booting, I had CFG_DEBUG defined in the AT91 Bootstrap. Because this was defined, a call akin to TRACE_CONFIGURE from the sample applications was being executed in the bootstrap code. This is why I was seeing random garbage text previously...I understand that part. Apparently, though, I forgot to define CFG_DEBUG in the Dataflash compilation of the bootstrap code. And I already had the TRACE_CONFIGURE call commented out in the sample application (that I planned to "boot into" from the bootstrap) due to the previous garbage text. This is not a good combination - with both items not implemented, nothing appeared to be happening at all. When I enabled one or the other (not both), I got the output I had been expecting.

I am again following up on my earlier posts - maybe it will help someone else on a future forum search. When I first began this thread, I mentioned that there were several different bootstrap versions out there. The first one I began compiling was the one that was included in the EK for my board (the actual project title is "at91bootstrap-at91sam9m10-ek-gnu"). I was able to compile this bootstrap without a problem, but for reasons unknown to me, the code for CP15_EnableIcache() was failing - the bootstrap would get this far and then seemed to completely stop executing in this function call.

After seeing the CP15 code in the other various bootstraps, I decided to try my own patch to fix the code that was failing for me. My solution was very simple:

I commented out all of the existing code within the CP15_EnableIcache() function. I replaced it with this code:

I added the following functions to the cp15.c file:

Finally, I added the following define to the cp15.h file:

This seems to be what all of the other bootstrap projects do, so I'm not sure why the EK is different. All of the EK calls are to the at91lib files, so maybe they were just there for demonstration purposes. Whatever the reason, it isn't very reassuring that they don't seem to work, since they are part of the at91lib...

My disclaimer: I tested this out quickly, and it seems to work so far. I haven't tried removing or doing anything else with the other myriad CP15 function calls and assembly code. The whole reason I returned to this bootstrap is because it supposedly has SD card support, and v. 1.16 of the AT91 Bootstrap does not. I have no idea if this code is better than or newer than that of the 3.0+ versions of the AT91 Bootstrap...I guess time will tell.