MBR hack for serial console

John Baldwin jhb at freebsd.org
Thu Aug 27 14:16:44 UTC 2009


On Wednesday 26 August 2009 5:07:16 pm remodeler wrote:
> I am hoping for input on a patch I want to apply to the MBR of a FreeBSD
> 8-BETA3 AMD64 server. I need a serial console on this server. The ASUS
> motherboard (amibios) has PCI and PCI-e expansion slots, and a Moschip MCS9820
> UART (serial board) is installed at pci0:3:5:0. The amibios can be configured
> to do the plug-and-play enumeration, or this feature turned off, but there is
> no way to assign a particular i/o port to a PCI device in the BIOS, and I
> cannot get source for the BIOS to change this behavior. The serial board has a
> single Base Address Register at 10h in its pci configuration space. Whether
> the PCI bus is probed by the BIOS or FreeBSD, the UART BAR is assigned the
> i386 I/O port address of 0xe800. It must be COM1-COM4 (i.e. 0x3F8) to work in
> the boot sequence. I need access to the serial console before loader.

Hmm, is 60 bytes enough to read the current value of the BAR instead and use
that address?  Writing 0x3f8 will not work if the BAR has a length > 8, though
it sounds like that isn't the case.  Still, if the device is behind a PCI-PCI
bridge (which it probably is if it is on bus 3) you have the problem that 0x3f8
is probably not in the IO range decoded by the parent bridge.  Given that I
really think reading the current value and using that instead of 0x3f8 is
probably more reliable.

> I do not expect the hardware configuration to change so a hack is ok. My plan
> is to patch the MBR to override the serial card's BAR with 0x3F8. My reasoning
> is that the CPU is still in Real mode (allowing direct hardware access) until
> loader executes, and the serial console would work for the boot0 and boot2
> calls to the terminal. I have experimented with using pciconf to change the
> BAR from a command line; curiously the command:
> 
>  pciconf -w pci0:3:5:0 16 1016
> 
> loads 0x3F9 into the serial card's PCI configuration space instead of 0x3F8,
> and I don't understand why. I've worked up this patch and hope someone can
> tell me why this would or wouldn't work:

You would read back 0x3f9 because the lower 3 bits of a BAR are various flags.
bit 0 indicates if a BAR is for I/O (1) or memory (0) hence why you read back
0x3f8 | 0x1.

-- 
John Baldwin


More information about the freebsd-hackers mailing list