From mboxrd@z Thu Jan 1 00:00:00 1970 From: JP Date: Tue, 27 May 2008 09:47:52 -0500 Subject: [U-Boot-Users] PXA270 board startup: printf does not work In-Reply-To: <482B013D.6020206@att.net> References: <482AEDD9.7080500@att.net> <482AF811.6000400@ge.com> <482B013D.6020206@att.net> Message-ID: <483C1F18.7050903@att.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de JP wrote: > Jerry Van Baren wrote: >> Your talk about having a corrupted local char buffer confused me. If it >> were not for that detail, I would have been positive that you have a >> problem with handling your UART's Tx busy flag. >> >> Your symptoms are typical of not waiting for the UART to complete >> transmitting a character before stuffing the next one in once the UART >> FIFO is full. The result is that, if the string has fewer than /n/ >> characters (/n/ being the depth of the UART's Tx FIFO, possibly a few >> more), it works OK. If the string is longer than /n/, it gets corrupted >> by your s/w overwriting characters in the UART. Depending on the UART >> implementation, this could include the one currently being shifted out, >> resulting in garbage characters. > > A very long (already initialized) string prints correctly with puts, so > I suspect the FIFO implementation is OK. We're using the FFUART. >> What in your processor is 32 bytes long? UART FIFO? Cache line? Hmmmm, >> could you be having cache consistency problems? Cache problems would be >> consistent with garbage in memory. >> >> BIG WARNING NOTE: Writing memory with a debugger is typically very >> benign (s.l.o.w.) compared to writing with the processor. Writing >> single memory locations with the processor is typically benign compared >> to a cache line burst read/write. SDRAM (including DDR/DDR2) >> initialization problems typically do *not* show up until cache is >> enabled because it is the burst read/write that violates the "S" in >> SDRAM (you end up out of sync "synchronous"). >> FAQ: > > Thanks for those ideas. We haven't found many examples to compare our > configuration to, but we did have trouble initially getting the SDRAM > startup sequence working. Your description and the wiki entry describe > what could be happening. > > JP This turned out to be a hardware problem: the DQM 0/1 lines that select 8 bits of a 32 bit location were reversed.