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,0xff79x: 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