>
> If you paid $15K for an ARM926EJ-S board, it sounds like you got screwed --
> but because I now feel bad for you, I'm totally willing to sell you another
> for half price :)


I'd give it to you for 1/4 the price and throw in a set of steak knives!
The ARM is just the servant that fans with palm branches and hands out
grapes to the picoArray which is like 300 DSP's.


> > I was reading & writing to a blank sector just to test out my configs and
> > I noticed that when I did any fill command (b,h,w) to flash, when I read
> > back I didn't get the same results.
> >
> > Here is what a flash fillb 0x20000000 0xaa 128 looks like:
> > 0x20030000: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaa
> ffffaaaa
> > 0x20030020: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa
> ffffaaaa
> > ffffaaaa
> > 0x20030040: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa
> ffffaaaa
> > ffffaaaa
> > 0x20030060: ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa ffffaaaa
> ffffaaaa
> > ffffaaaa
>
> Looks like you have the chip select configured wrong.  Without knowing
> anything else about your processor, it seems as though the access width is
> configured incorrectly based on what you show here.
>
> > But that wasn't the bad news ... when I rebooted ... no u-boot.
> > Displaying memory where uboot "was" showed that half the words of the
> > address where it lived were filled with 0xffff so something went crazy
> and
> > hosed my flash in areas I wasn't even messing with.
>
> That could also be explained by having a bad config for your peripheral
> bus.
>

Yea, I think the memory map documentation I first read was wrong.  Looking
at the data sheet for the flash part ... it is a 8 or 16 bit device and it
is strapped for 16 bit so my  cfi setup should be flash bank cfi  0x20000000
0x08000000 2 4 0 (I think).  I'll try that tomorrow.

I think I remember seeing a message not too long ago that said there was a
problem with the chip width being different than the bus width ... need to
go back through the messages.

Later,

Brian
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to