>> What BRGs did you choose for tx and rx? > > BRG1 & BRG2
OK >> Get a scope on the UCC3 tx pin and try to output some chars. See if >> there is >> any digital activity on that pin at all. If you are looking at a >> terminal for >> output, there are too many things that could be wrong between that tx >> pin and >> your display (e.g. level translation issue, null modem issue, baud >> incompatibility, >> terminal program set for XON/XOFF or HW flow control and UART not set >> up compatibly). >> >> For now get the probe directly on the CPU's UCC3 Tx pin, output chars >> and see >> if there is any activity. > > We've done all this - nothing on the pins directly at the CPU. > > This is behaving very much like there is no clock to the device. > Is there something special that needs to be done to get the BRGs > to work? If I was doing this, at this point I would do some strategic printk debugging within ucc_uart.c. You said that you are using 2.6.33.3, so you already have all the fixes in ucc_slow.c that I had to backport to my older kernel. If you question the setup of the BRGs, go to your function that sets them up. I don't know about 2.6.33.3, but in the latest kernel it is qe_setbrg() in qe.c. At the very bottom there is an out_be32(). printk both the address, and the value that is being written to that address. You may need to cast the values to unsigned longs to printk them. I will look at your numbers if you send them to me. In my implemenation (which again was a backport, so this may not apply to you) the BRG writes were off by 4 bytes. But I think that this error was due to the backport -- a logic mismatch I needed to resolve during the port. Also in the current Linux kernel, there is a dependence on the correctness of the "brg-frequency" property from the dts. Look up above qe_setbrg() at the qe_get_brg_clk() function. Before the return (there are multiple return points) printk the brg_clk being returned. That must be correct for your hardware -- must be the actual brg freq. I assume that you are booting from U-Boot. I believe in modern implementations that U-Boot fills in the brg-frequency in the device tree at boot time. Let me know how it goes, Chuck Meade ch...@theptrgroup.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
