[coreboot] [RFC] Universal panic-room serial console, for x86 BIOS bootblock

Pete Batard pete at akeo.ie
Tue Jul 12 14:02:22 CEST 2011


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




More information about the coreboot mailing list