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

[Jerry Van Baren <gvb.uboot@gmail.com>]

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%^*-.