I have a custom board based on AT91SAM9261-EK but added a S29GL256P 16-bit NOR flash as datasheet suggested. I am having issue booting into it. The hex file compiled for SDRAM works, so I know the code is ok. Compiled a flash version but it does not run. I verified the flash content is correct.

Thanks for your help in advance.

The code to boot an ARM9 isn't quite like the code that loads/runs in SDRAM. You need to double check the vectors and the initialization code. Try booting and stepping through the code with your JTAG debugger. Without a clear idea of where it is failing, you're lost. You could try writing a very small amount of code, basically enough to configure and demonstrate UART function, directly off the reset vector. Do it in assembler.

Want to confirm the NOR FLASH is decoding/executing properly? Copy the ROMBoot code into your flash memory and see if that boots up normally.

Try building a version of AT91BootStrap made to function at the FLASH address, not the SRAM one.

Thanks for the help.

When I tried to step into the flash code, I always get "cannot find bounds of current function" on the first assembly instruction. Don't know what is wrong there.

Sounds like a gdb issue. Is it fatal? If you can't tell it to ignore that fact it doesn't have any details on the code being debugged you'll need to poke around with the gcc/gdb documentation.

The Segger J-Link (SAM-ICE) does provide rudimentary stepping operation. This would probably suffice to step far enough to get the USART up, blink LED's or provide some other signs-of-life type indication.

As a model, AT91Bootstrap is probably the place to start from. It's the kind of thing you can stick in SRAM, and then migrate to FLASH.

As you haven't posted any code or hex data it's rather hard to assess your situation any further.

Thanks...I think I'll go back to the boot strap you mentioned...:-(

With BMS=0 is supposed to access the device as a 16-bit wide ROM on EBI NCS0 (SMC defaults). The timing should be fairly slow, but you can fix that as the boot proceeds.

Other members of the ATMEL ARM7/9 series part use this for external ROM/FLASH, or internally bonded flash die, so I doubt there is an errata.

The S29GL looks to be a good candidate, scanning the data sheet. BYTE# needs to be high, D0-D15, and A1-A24 (9261) to A0-A23 (S29GL256)

The NOR connection is correct and I can read write the NOR w/o any issue. I pull the BMS low to boot from the NOR, however, no sign of life... Somehow Macraigor USB2Sprite JTAG does not work when BMS is low and my JLink is broken...:-(

Just want to make sure the AT91SAM9261 is reset as little endian, isn't it?

Yes, and you'd expect to see the words

0x000D
0xEA00
0x0005
0xEA00

Or something very similar.

Bytes 0x0D,0x00,0x00,0xEA,0x05,0x00,0x00,0xEA,...

If not 0xEA's then 0xE5's

You could paste the hex file, and I could tell you if it appears to be viable.

Thanks for your help on this.

I looked into the AT91bootstrap code you mentioned. I have a question regarding the relocation of the code to SRAM in the beginning.

_relocate_to_sram:
mov r1, #0
ldr r3, =_stext
ldr r4, =_edata
1:
cmp r3, r4
ldrcc r2, [r1], #4
strcc r2, [r3], #4
bcc 1b
ldr pc, =_setup_clocks
_setup_clocks:

How come the last line of "ldr pc, =_setup_clocks" will point the PC to SRAM, which is in 0x30xxxx? In other words, the "_setup_clocks" is determined in compile time, so even after the loop of ldr/str copying the code to SRAM, the "_setup_clocks" should still be pointing to the instruction in flash, not in SRAM. Did I misunderstand something here?

Thanks.

The only example from AT91 Bootstrap that builds directly for NOR is the AT91CAP9. The examples do however illustrate ARM9 boot code, and AT91 hardware setup and staging. There are many ways to do it

It's using the fact that while the code is compiled to fit in SRAM (0x100000 for the CAP9), the NOR ROM image appears at address zero at boot (r1 = 0 for source copy). The constant value, for _setup_clocks, is loaded from a literal pool, that is accessed by a pc relative addressing mode. The code up to _setup_clocks is agnostic to it's location.

With a ROM on a 9261 it manifests in two locations zero and 0x10000000, you'd want to jump to the image in the upper address before REMAP is used to park the SRAM at zero. You'd want RAM at zero so the vector table can be modified.

The reason to run from SRAM is that it is single cycle and agnostic to the clock configuration and external bus settings. This permits both to be set up with appropriate settings (ie clocks wrt to external memory access speeds and geometry) before jumping back to ROM code if desired.

Mostly I would anticipate a fairly compact boot loader, enough to get SRAM and SDRAM set up, and application copied across. SRAM being the most desirable spot for application and stacks due to it's speed.

Thanks for the reply.

I acutally monitored the PC value before and after the "ldr pc, =_setup_clocks". It changes from 0x0000xxxx to 0x0030xxxx. But forgive my slow brain, I still don't quite understand why that is, since the "_setup_clocks" is set to 0x0000xxxx in compile time. So, how can it be changed to 0x0030xxxx after the copying is done?

I suspect you'll find the linker is generating a binary for 0x300000. Check where r3 is pointing.

are you used IAR compiler? you can check you configuer file for your project.

I'd anticipate most people are using GNU gcc/make to build AT91BootStrap, as it's designed to work out of the box that way. Using Keil does generate tighter code.