|Trev||ppc440ep_serial.device Issues||20110220 22:41|
|From another thread:
The serial port works fine under u-boot, but I get either nothing or garbage under OS4. 9600, 8N1, XON/XOFF. What's the status of ppc440ep_serial.device? If there are still issues, what's the recommended solution for remote serial output?
E.g. `COPY foo.txt "SER:/9600/8N1"' sends garbage out the serial port.
|tonyw||Re: ppc440ep_serial.device Issues||20110221 12:41 #2298|
I've just spent several hours playing with the serial port on my Sam 440ep and I can't see anything wrong with it. I've tried Update 1 and Update 2's drivers and they seem to work the same way.
[This is probably telling you something you already know, but bear with me, there just might be something you've forgotten. Someone else might learn something, too.]
The values in Prefs/Serial are default settings that only apply if you use the basic device name "SER:" with no qualifiers. You can override those default settings with qualifiers such as "SER:/9600" which forces the speed to 9600 baud, regardless of what the serial.prefs say.
Most applications (terminal emulators, etc) will program the serial port when they run.
The system debug output and the output from U-Boot use the "baudrate" setting from the NVRAM (type "nvgetvar" to see the current setting). Ouput from debug channels or IExec->DebugPrintF() always uses that value, regardless of what the "SER:" preferences are set to.
In your case, garbage characters sound like a speed mismatch between the ends of the cable (or, less likely, a character width mismatch).
There are no outstanding bug reports for the ppc440ep serial device.
|xenic||Re: ppc440ep_serial.device Issues||20110222 03:43 #2347|
Are you setting the receiving device to 9600. If it works in UBoot then I would assume that the receiving device is set the same as the UBoot default which is 115200 on my SAM Flex.
|Trev||Re: ppc440ep_serial.device Issues||20110222 04:16 #2348|
I have u-boot set to 9600:
Unfortunately, the problem doesn't appear to be something obvious like inconsistencies between host and terminal settings.
|Trev||Re: ppc440ep_serial.device Issues||20110222 05:02 #2350|
I have a Sam440ep-flex 733 MHz, which has a processor local bus clock of 146 MHz. Perhaps ppc440ep_serial.device doesn't know how to set up UART regs for that clock speed. It might be assuming a specific clock or incorrectly detecting the current clock.
Confirmed, in part. `COPY foo SER:' changes the UART divisor from 0x0035 (48) = 9600 bps to 0x0024 (36) = ~14133 bps. So, ppc440ep_serial.device doesn't know or is misinterpreting the PLB clock. (My back of the envelope calculations aren't correct for 146 MHz, so I'm a bit confused here, too.) Who maintains ppc440ep_serial.device? m3x?
Edit: Actually, I think they're doing similar calculations, except ppc440ep_serial.device isn't taking into account PLB clock ratios, so it sets up a divisor for PLB instead of PLB*2. Not taking into account the OPB divisor? Or something like that. I'm not an expert here, but the math works.
|Trev||Re: ppc440ep_serial.device Issues||20110222 21:00 #2369|
It looks like ppc440ep_serial.device is basing its calculations (or tables) on a PLB clock of 100 MHz, not 147 MHz (146,666,666 Hz). I sent a message to Max Tretene over at Amigaworld. I can't find his email address. And as I write this, I realize that it's probably in the u-boot sources, and indeed it is.
|Trev||Re: ppc440ep_serial.device Issues||20110222 22:10 #2371|
Per Max, there is indeed a bug in ppc440ep_serial.device V52.1. It bases its calculations on the assumption that u-boot initialized the UART for 115,200 bps, i.e. baudrate=115200. This was fixed in ppc440ep_serial.device V53.1, which is only available with AmigaOS 4.1 for Sam460ex. (That would put it somewhere between AmigaOS 4.1 Update 2 and a theoretical AmigaOS 4.1 Update 3. A coinciding update from Hyperion for other platforms would have been a nice gesture.) Everything is working fine now. (Edit: If a little birdie with a copy of the Sam460ex CD sent me a copy of the new ppc440ep_serial.device, I wouldn't complain.)