On Sat, Jul 09, 2011 at 03:44:50PM -0500, Scott Duplichan wrote: > Kevin O'Connor wrote: > > ]Some serial ports have slightly different timing. These timing > ]variations result in less accurate boot time reporting. So, add a > ]calibration mechanism to the tool so that one can determine how much > ]time a specific machine's serial port uses. > > Hello Kevin, > > A while back I noticed both SeaBIOS and coreboot poll for TEMP (line status > register bit for transmitter empty) before transmitting a character. An > alternative is to poll THRE (transmitter holding register empty) instead. > > Polling TEMP forces the code to wait until the final stop bit time period is > complete before it can load the next character. It is understandable that on > some implementations this will cause one idle bit time to pass before > transmission of the next character starts. > > When THRE is polled, the code has a period of nearly 10 bit times where the > next character can be loaded such that it will transmit without any unneeded > idle time between characters.
Thanks Scott, in some of my recent tests I noticed that in the SeaBIOS code as well. I just sent a patch in a separate email. Unfortunately, I didn't see an improvement in the timing accuracy even after I made that change. Maybe I've missed something else. > Here is the result of a transmit test using both methods on ASRock E350M1. > The test works by timing a 5 second transmit: > > TX baud rate test, TEMP method (SeaBIOS and coreboot) > selected Measured Percent Error > 110 100 9 > 300 273 9 > 600 546 9 > 1200 1092 9 > 2400 2185 8 > 4800 4370 8 > 9600 8742 8 > 19200 17484 8 > 28800 26225 8 > 38400 34967 8 > 57600 52451 8 > 115200 104899 8 I'm seeing something very similar when running timing tests under Linux. I get ~93.9us per char instead of the 86.8us per character at 115200 baud - a difference of 8%. This was under Linux though. Oddly, under Linux, if I use bigger transmissions (eg, 10K) instead of just 4000 byte transmissions I get much better timings - as little as 88.1us. Maybe Linux is using the fifos when the transmission is large enough. > TX baud rate test, THRE method > selected Measured Percent Error > 110 110 0 > 300 300 0 > 600 600 0 > 1200 1201 0 > 2400 2403 0 > 4800 4807 0 > 9600 9615 0 > 19200 19232 0 > 28800 28848 0 > 38400 38464 0 > 57600 57697 0 > 115200 115394 0 > > I also noticed coreboot enables the uart fifos. This is not beneficial > because the simple polling logic used by coreboot and SeaBIOS cannot utilize > the transmit fifo. Could the fifos being enabled be the cause of the slow down even after the SeaBIOS serial polling fix? -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
