Dean/Peter,
Well I have some good news on this problem. I finally discovered on Friday
what the issue was. Atmel¹s technical support confirmed my suspicions this
morning. On the bright side, it turns out this is not directly an OpenOCD
issue. :)
Atmel¹s internal BootROM masked programmed at the factory utilizes the ARM
exception vector six to determine the image size of the first stage
bootstrapper. If you look at the linker script and startup file they
provide for the AT91 bootstrapper utility you will notice the crt0_gnu.S has
the following define for vector 6:
.word _edata /* Size of the image for SAM-BA */
Where _edata is defined by the linker script elf32-littlearm.lds:
/* collect all initialized .data sections */
.data : AT ( ADDR (.text) + SIZEOF (.text) ) {
_sdata = .;
*(.vectors)
*(.data)
_edata = .;
}
The problem with this is that the linker script will assign the absolute
address of the last location rather then the size which should be calculated
by subtracting the starting address from this value. If the linker script
is changed to:
/* collect all initialized .data sections */
.data : AT ( ADDR (.text) + SIZEOF (.text) ) {
_sdata = .;
*(.vectors)
*(.data)
_edata = (. - ADDR (.text));
}
Then everything works swell. The image can be downloaded to the first block
with OpenOCD and it will actually boot.
So naturally this leads to the next question. Why does this work at all?
Well...Atmel confirmed that their native ISP tool is modifying the vector
behind the scenes prior to committing the image to flash. Although I
downloaded the image programmed by their tool and eventually spotted the
difference, I was so initially focused on the reset vector being right that
I missed this subtle difference between what the compiler/linker was
generating and what their tool actually had programmed further down the
image.
When I surrendered and actually performed a byte-by-byte comparison of the
files out of despair rather the just looking at the reset vector, I finally
made progress towards the solution.
So while this is not a direct problem with OpenOCD, I wanted to expound on
it so other fellow OpenOCD developer/users don't flail around for days like
I did. Atmel indicated that they will likely modify their application note
to point this subtlety out also.
Thanks to everyone for their help and advice!
Gary
On 5/3/10 7:10 AM, "Dean Glazeski" <[email protected]> wrote:
> On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard <[email protected]> wrote:
>>>>>>> "Gary" == Gary Carlson <[email protected]> writes:
>>
>> Gary> I wanted to see if anyone has any experience trying to upload the
>> Gary> AT91Bootstrap code into NAND flash for any of the AT91SAM9XXX parts
>> (i.e.
>> Gary> AT91SAM9260, AT91SAM9G20, etc.) using OpenOCD?
>>
>> Gary> I have tried erasing and programming the first block of the NAND
>> Gary> flash in every command combination possible with the image I
>> Gary> have. The programming cycle is successful, the verify command is
>> Gary> successful, but the internal first stage boot ROM concludes that
>> Gary> it isn't a valid image and goes limp (or brain dead depending on
>> Gary> how you want to look at it). The Atmel startup diagnostics from
>> Gary> the internal boot code is naturally zero, so it is left to wild
>> Gary> imagination what the problem is.
>>
>> I haven't used it, but my guess is that the boot ROM expects a different
>> OOB / EEC layout than what openocd writes.
>>
>> --
>> Bye, Peter Korsgaard
>> _______________________________________________
>> Openocd-development mailing list
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>
> This is interesting. I'm the one that actually wrote the original AT91SAM9
> NAND flash piece. To be honest, I haven't been able to test the "bootability"
> of the flash stuff that gets written. I thought that if I could write and
> then read the same data, then everything should be okay. Something I'm
> thinking I should have done is try to write with SAM-BA and then verified what
> was written with the OpenOCD driver. I have plans of playing with this more
> once I get out of classes for the year. Right now, I'm sort of swamped in
> projects.
>
> // Dean Glazeski
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
