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

[Mark Pilant]

>> 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

This email message and any attachments are confidential and may contain information which is proprietary to Mintera Corporation. If you are not the intended recipient, please notify Mintera Corporation immediately -- by replying to this message or by sending an email to postmaster at mintera.com -- and destroy all copies of this message and any attachments. Thank you.