From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Fri, 04 May 2007 10:04:33 -0400 Subject: [U-Boot-Users] Wind River SBC8560 saga continues In-Reply-To: <315FA8E37E6E844C9B2EF35715F600720A3CEA@bache.mintera.net> References: <315FA8E37E6E844C9B2EF35715F600720A3CBB@bache.mintera.net> <2acbd3e40705031026s2f240a39x6677bf28b66d45b@mail.gmail.com> <315FA8E37E6E844C9B2EF35715F600720A3CC9@bache.mintera.net> <463A8BB6.2040502@gmail.com> <315FA8E37E6E844C9B2EF35715F600720A3CEA@bache.mintera.net> Message-ID: <463B3D71.5020600@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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