[U-Boot-Users] Problems using UART1 instead of UART0

[Bob Grimes]

Hi TsiChung,

First, thanks!  And second, sorry about the last ramble; it was late,
and after nearly 16 hours at it, I needed a break!  Third, I'm on
vacation for a week starting tomorrow, and on another project today,
so things will have to wait a bit.  But I do owe you an explanation of
where things sit.  This is a bit long, and not time-critical, so feel
free to set it aside for when you need a bit of comic relief!

After emailing last, I tried a few experiments, and in thinking about
the results this morning on the train, I am almost entirely certain
the problem is somewhere in my hack to attempt to run out of RAM.
What threw me on a long detour was an apparent flaky serial port.
Late yesterday I realized that swap I mentioned in my first post, and
what had appeared to be working software and flaky hardware actually
was non-working software and working, though deceptive, hardware.
What I had thought was the board responding to keyboard input via the
serial port was in fact, a reflection of the received data on uart 0
being transmitted out the unused uart 1.  Specifically, my theory is
that because the uart 1 transmit pin was not being set as an output,
and thus were left presumably floating, the received data arriving at
the shared transceiver chip was strong enough to influence the input
to the transceiver to case phantom transmission on the idle port -
hence, the board, and more specifically, the software, seemed to be
working.  Hence also the timing seemed right!

When I changed to the correct port, nothing happened, and attempting
to break out of GDB caused it to report several errors, all to the
effect that the CPU had run away.  So ultimately I thought there was
an issue with uart 1 programming.  Investigation of the code, which
isn't always easy with all the configuration, macros, include and
source files in vastly different areas of the tree (e.g. ./board,
./cpu, ./drivers, ./lib_m68k) made it terribly difficult to convince
myself the software was okay or not.

Finally, I tried more carefully to debug what I thought was the
working uart 0 version, and I finally noticed that breaking out from
gdb wasn't working there either.  Thinking about it this morning, I've
realized that that version never was working to begin with!  What I
really understand now is that the problem lies in changing the clock
near the beginning of startup, where uboot assumes it is running from
flash - sdram gets corrupted, bam!

The real problem is either (or both) my erroneous assumption that
CFFlasher would work to program my flash, or that the flash is bad.
Because we have a different flash part, unless CFFlasher is using CFI,
the first assumption is wrong - is that correct?  Also, I got an
algorithm for programming the flash with the P&E Micro tools, but that
didn't work.  So I figured I would use uboot, running out of RAM.

So I'm a bit stuck.  My plan is to try a new algorithm with the P&E
Micro tools; if that works, great!  If not, I'm going to hack uboot to
skip the clock change, adjust the baud rate calculation, and possibly
skip the relocation; this last step is not necessary, IIRC.  Once I
get the hacked uboot-ram running from sdram, I'll use it to program
the real uboot.  Again, there _is_ a reason to run uboot from ram
only!

Thanks for all your help, and sorry if I've been too much of a pain -
no excuse save a panic rush to get something positive done before a
much needed, if not necessarily deserved, vacation!

Take care,
-Bob

On 8/24/07, Liew Tsi Chung-r5aahp <Tsi-chung.Liew at freescale.com> wrote:
> Bob,
>
>         I'll get back on Monday to assist you.
>
> Regards,
> TsiChung
>
> -----Original Message-----
> From: Bob Grimes [mailto:rsg.uboot at gmail.com]
> Sent: Thursday, August 23, 2007 10:05 PM
> To: Liew Tsi Chung-r5aahp
> Subject: Re: Problems using UART1 instead of UART0
>
> On 8/23/07, Liew Tsi Chung-r5aahp <Tsi-chung.Liew at freescale.com> wrote:
> > Bob,
> >
> > To try the extra uart on M5329EVB, connect pin 78 uart1 rx and pin 77
> uart1 tx, or pin 73 uart2 tx and pin 74 uar2 rx at J38. The signal is
> only TTL, you will need a transceiver to have it working.
>
> I'll have to look into that, but I've been focusing on the customer's
> board...  ;-)
>
> >
> > As for your custom board, you might need to check your RCON
> configuration. It could have the RCON set at default value or other than
> value specified in M5329EVB.h. Try to use oscope to check on the pin 24
> of BDM header first to find out the CPU clock speed. Then use that freq
> to calculate your bus clock. The uart baud rate is based on the bus
> clock. If the bus freq increase or descrease ~4Mhz, it will affect the
> baudrate output.
>
> Okay, now I am really confused.
>
>   1. The RCON signal is not being used - it is pulled high with a 10k
> resister to 3.3 V.
>   2. RCON register reads 0x0001, which indicates "normal" operation -
> right?
>   3. When uboot is configured for uart0 and I run it, I get bit widths
> about 8.5 us, which is close to 115,200 as expected.  Not exactly, but I
> think there's significant measurement error.  Anyway, this isn't the
> problem.
>   4. When running, I see a nice, solid 2 MHz on pin 24 of BDM header.
>   5. Oddly, FB_CLOCK is 1.333 MHz when running, pretty solid though.
> When I power up the board without the BDM, this is solid 60 MHz, as
> advertised.
>
> So, don't know about much of this.  Are these signals normal?
>
> I don't know...  I'm not sure if the processor is running or not,
> though.  At this point, I think it's software and/or hardware.  ;-) My
> current thinking is that there my attempt to run uboot only within ram
> is not working right, actually.  Unfortunately, while I have BDM
> working, I can't program the Flash.  I once got an old version
> (1.1.6?) working from RAM, but abandoned that for your 1.2 port, but
> that was on the m5329evb, so I could program that board's flash using
> CFFlasher, then debug using BDM.  Now, what can I do?  By the way, this
> is why one might want to run uboot from ram - to program the flash in
> the first place!!!
>
> There doesn't seem to be any way to use CFFlasher with my board, even
> though it is very similar to the m5329evb - probably because we're using
> an 8 MB Atmel NOR flash chip..
>
> Okay, I'm rambling, and best check out...
>
> -Disgruntled Bob
> >
> > Regards,
> > TsiChung
> >
> > -----Original Message-----
> > From: Bob Grimes [mailto:rsg.uboot at gmail.com]
> > Sent: Thursday, August 23, 2007 7:21 PM
> > To: Das U-Boot Mailing List; Liew Tsi Chung-r5aahp
> > Subject: Problems using UART1 instead of UART0
> >
> > Hi,
> >
> > I finally got our custom board, and unfortunately, the hardware guy
> > seemed to have missed the message, and he's assigned the second
> > mcf5329 uart to the console!  Argh!
> >
> > So I've tried changing CFG_UART_PORT from (0) to (1), but nothing
> seems to happen.  I've traced into some of the code, and have confirmed
> that the associated pins have been properly assigned to UART1.  I'm
> having trouble determining anything more than that; specifically, I've
> yet to find the serial init code, as it seems to hang when setting the
> cpu clock speed.  Probably not too surprising I can't debug through that
> code, but it doesn't seem to make it through.
> >
> > Tsi Chung, have you tried this?
> >
> > Back to the debugger, and code inspecting...
> >
> > Thanks,
> > -Bob
> >
>