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

Jerry Van Baren
2007-05-04T14:04:33Z

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