Hi Scott. Thanks a lot for testing!
On 2011.07.12 02:38, Scott Duplichan wrote:
I tried the sample on ASRock E350M1 and it did not work. One reason is needed LPC clock initialization (http://permalink.gmane.org/gmane.linux.bios/67229).
OK.
I'm obviously a bit nervous about changing a clock frequency that defaults to 14 MHz to 48 MHz, even temporarily, if it is done on every boot, unless we first have insurance that devices connected there support 48 MHz. From looking at the SB800 datasheet, p232 [1], 2 clock lines are provided, so I'm not seeing much of a guarantee that a 48 MHz Super I/O chip is always connected to Clk1...
So I see two possibilities: 1. Add code to identify the motherboard to confirm that the device connected to Clk1/Clk2 supports 48 MHz before we increase the frequency (and decide which Clk should be used) 2. Let the device run at 14 MHz and try to support a 14 MHz mode of operation
#1 looks quite difficult to achieve while keeping a small footprint, so I'd rather go the #2 route, even if that results in the serial port being initialized at a lower nonstandard baudrate. The first thing we can do once we have panic-room access is set the clock to 48 MHz and continue with panic-room operations at 115200.
However, looking at the NCT6776F datasheet for instance, it appears that the SuperI/O is only meant to support 24 and 48 MHz clock frequencies, and I'm guessing the LPC timings from a chip strapped into thinking it runs at 48 while actually running at 14 will be messed up, so that may not be that great an idea...
Another problem is the one mentioned in the release notes about cases where the serial port pins default to gpio use and must be configured for serial port use. I believe this will be the situation with Nuvoton NCT6776F.
That's a good point. From what I can see, the NCT6776F doesn't actually seem to use a dual GPIO/UART, but other Super I/O might. Depending on how widespread these chips are, we might want to detect those. Right now, with UBRX is still in a PoC state, I'd rather avoid introducing special cases. At least, I don't believe is should be needed for testing the E350M1 as it uses a W83627HF.
I spent a few minutes debugging with AMD simnow but was unable to get it to work there. Maybe some additional port 80 codes that mark algorithm milestones would simplify debug.
I can do that, but you have to understand that, if we identify what looks like a PnP Super I/O, we test up to 32 possible LDs in sequence. If an LD is not identified as an UART, we just move on to the next one, so, unless you have a port 80 card with a buffer, I'd need to add a 1 second delay or something each time we fail to identify an LD as an UART, for the user to be notified, and the whole boot process would then take about half a minute (or more, if other PnP Super I/O candidates are identified at other bases).
I'll see what I can do, but if you know your Super I/O base as well as the LDN for the UART you want to use, you can modify the code to only test those, and report the error. Or you can just wait, as I'll update UBRX soon, to make is easier to test only a specific UART LDN and Super I/O base and add extra debug, to facilitate troubleshooting.
Regards,
/Pete