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
[1] http://support.amd.com/us/Embedded_TechDocs/45482.pdf
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
