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

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Mark Pilant wrote:
>>> 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.
> 
> The code is stock U-Boot 1.2.0.  In serial_init() from the module
> .../cpu/mpc85xx/serial_scc.c, the code reads:
> 
>     volatile immap_t *im = (immap_t *)CFG_IMMR;
>     ...
>     volatile ccsr_cpm_cp_t *cp = &(im->im_cpm.im_cpm_cp);
> 
>     ...
> 
>     while (cp->cpcr & CPM_CR_FLG)  /* wait if cp is busy */
> 
> It is this second "while" that is "hanging".  The generated code for
> the while is:
> 
>     lis     R9,0xff79
> x:  lwz     R0,0x19c0(R9)
>     andis.  R11,r0,0x1
>     bne     x
> 
> R9 correctly contains the CPM base, and the offset 0x19c0 is correct
> for the CPCR.  So it would appear the code should be picking up the
> contents of location 0xff7919c0.  Here is where the fun begins.  The
> value retrieved by the code (into R0) is 0x00810000 but the value
> retrieved by the visionCLICK dm command is 00800000.  (This is also
> the value displayed by the CPCR field of the "COMM" register list.
> 
> I have verified the TLBs, and they correctly have cache inhibit set,
> so I can't see why this "wrong" value is being retrieved.
> 
> BTW, this same board works fine running V6.3 of VxWorks; which I also
> compiled and flashed.
> 
> - Mark

Ok, the good news is that eliminates one of the failure modes.  We 
eliminate enough of them and the real one will be obvious. ;-)  That was 
somewhat of a long shot, so it isn't too surprising that it wasn't the 
fault.

I'm not familiar with the 85xx processors, I presume they have BAT 
registers like most 8xxx family.  Is it possible the memory is mapped 
via a BAT and _that_ is set up wrong (cached and/or doesn't have the "G" 
bit set)?  BATs override the TLBs.

Does the TLB have the "G" (Guarded) bit set?  That prevents out-of-order 
loading (probably not an issue, but something to check).

How about hitting it with da big hammer: put a sync;isync pair in the 
loop.  If that makes it better, remove the isync (should not be 
necessary).  If that still works, try using a eieio instead of the sync 
(I'm not sure if eieio is useful for the 85xx, on the 603e core, it is a 
NOP).

Good luck,
gvb