Well that's a strange one. Thanks for doing the comparison for me and
sharing the result and fix!
// Dean Glazeski
On Mon, May 3, 2010 at 12:01 PM, Gary Carlson <gcarl...@carlson-minot.com>wrote:
> 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" <dngl...@gmail.com> wrote:
>
> > On Mon, May 3, 2010 at 6:36 AM, Peter Korsgaard <jac...@sunsite.dk>
> wrote:
> >>>>>>> "Gary" == Gary Carlson <gcarl...@carlson-minot.com> 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
> >> Openocd-development@lists.berlios.de
> >> 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
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
