[U-Boot-Users] Wind River SBC8560 saga continues

Jerry Van Baren
2007-05-04T01:26:14Z

Mark Pilant wrote:
> Hi Andy.
>
>>> Finally, I notice there is one area of memory, defined at 0x70000000,
>>> which has a TLB but does not appear to have any real memory to back
>>> it up. (This address is associated with the CFG_INIT_RAM_ADDR
>>> defined symbol.)
>> This is just the initial area to store stuff before RAM is actually
>> set up. It has to be somewhere with nothing behind it so it will just
>> stay in the cache. Most 85xx systems use 0xe4010000. However, once
>> RAM is set up, this address loses its meaning
>
> OK. That sounds reasonable, although I haven't run across this before.
>
>>> I am hoping someone might be able to point out if I am missing
>>> something (subtle or obvious :-).
>>>
>>> I had thought this might be the source of the CPM SCC problem I
>>> am having, but so far it does not seem to be the case.
>> I don't recall seeing the email about your problem. Could you
>> redescribe it?
>
> Simply put, I'm trying to get U-Boot 1.2.0 compiled and running on
> a Wind River SBC8560 board we have. From what I saw of the '8560
> support in general and the SBC8560 in particular, I thought it would
> be relatively simple.
>
> After setting up the ELDK on a Fedora Core 6 system I have, I was able
> to make a couple of changes to sbc8560.h (mostly to use SCC1 for the
> console) and build an image.
>
> Loading the image into flash (using WR visionCLICK) everything goes
> along fine until the code attempts to initialize the CPM SCC Tx & Tx.
> After writing the appropriate value to the proper location, the code
> hangs waiting for the command to complete.
>
> In reality, what appears to be happening is the code is reading one
> value (0x00810000) from the CPM CPCR (0xff7919c0) and if I dump that
> location using visionCLICK I see a different value (0x00800000). The
> difference being the code sees the busy FLG and dumping the location
> has it clear; indicating it is no longer busy.
>
> This feels a lot like a caching issue, but from everything I can see,
> the TLB is set up with the cache inhibited, so everything should be
> read/written through to memory.

Another possibility is that the register is missing the "volatile"
qualifier and thus the compiler is not re-reading the register every
time around the loop. If this is a possiblility, disassemble the
routine and see what the compiler actually produced.

> I have been trying for about the past two weeks to sort this out and
> get U-Boot up. I'm not worried about the Linux kernel right now :-)
>
> - Mark

Good luck,
gvb

Due to idiotic lawyer wanabes, in one second this email will self-destr%^*-.