Re: mini PCIe serial card (StarTech 2p1s) support

[Philip Tricca]

Thanks for the quick response Andrei,

On 08/04/2015 11:06 AM, Andrei Borzenkov wrote:
> В Mon, 03 Aug 2015 21:55:36 -0700
> Philip Tricca <address@hidden> пишет:
> 
>> Hello grub-help,
>>
>> I've spent the better part of a day trying to get grub to dump output to
>> a serial device with no luck. From the little experience I do have with
>> Grub I've never had a problem configuring a serial device so long as
>> it's "standard serial hardware" like a 8250/16550 UART on the one of the
>> 4 standard I/O ports: 0x3f8, 0x2f8, 0x3e8, 0x2e8. I am however having
>> trouble getting my add-on PCIe serial hardware (Startek 2s1p) to work.
>> Likely this is related to the serial ports on this card using I/O ports
>> on 0xe030 and 0xe020.
>>
>> I've tested this device with Linux successfully with the kernel
>> reporting the following in dmesg:
>>
>> 0000:02:00.0: ttyS1 at I/O 0xe030 (irq = 16, base_baud = 115200) is a
>> ST16650V2
>>
>> and using the device as expected: I get a kernel log and login from
>> ttyS1. AFAIK the 16650v2 UART is backward compatible with the 8250. The
>> difference being the 16650v2 has a 32 byte FIFO.
>>
>> In the Grub shell I'm able to see the card with lspci:
>> 02:00.0 9710:9912 [0700] Communication controller [PI 02]
>>         IO space 0 at 0xe030
>>         32-bit memory space 1 at 0x00000000f7c05000 [non-prefetchable]
>>         32-bit memory space 5 at 0x00000000f7c04000 [non-prefetchable]
>> 02:00.1 9710:9912 [0700] Communication controller [PI 02]
>>         IO space 0 at 0xe020
>>         32-bit memory space 1 at 0x00000000f7c03000 [non-prefetchable]
>>         32-bit memory space 5 at 0x00000000f7c02000 [non-prefetchable]
>>
>> I spent some time poking around in the Grub serial code and I ran aross
>> the include/grub/i386/coreboot/serial.h header (I'm on x84_64 / UEFI)
>> where the 4 standard serial I/O ports are defined
>> (GRUB_MACHINE_SERIAL_PORTS). I experimented with adding the I/O port for
>> my add-on card to this array in an attmpt to get Grub to probe it but
>> had no luck. Adding the I/O port 0xe030 to the end of the array, as well
>> as replacing one of the existing 4 entries wasn't successful:
>>
>> diff --git a/include/grub/i386/coreboot/serial.h
>> b/include/grub/i386/coreboot/serial.h
>> index b6819d5..ce79ba0 100644
>> --- a/include/grub/i386/coreboot/serial.h
>> +++ b/include/grub/i386/coreboot/serial.h
>> @@ -19,6 +19,6 @@
>> #ifndef GRUB_MACHINE_SERIAL_HEADER
>> #define GRUB_MACHINE_SERIAL_HEADER     1
>>
>> -#define GRUB_MACHINE_SERIAL_PORTS { 0x3f8, 0x2f8, 0x3e8, 0x2e8 }
>> +#define GRUB_MACHINE_SERIAL_PORTS { 0xe030, 0x2f8, 0x3e8, 0x2e8 }
>>
>> #endif
>>
>> Additional inforation: I'm building Grub from source for the 'x86_64'
>> target and the 'efi' platform.
> 
> On EFI serial driver is completely different and does not use direct
> port access at all; it relies on EFI firmware driver exporting
> SERIAL_IO_PROTOCOL. You can use lsefi grub command to list handles; if it
> does not show SERIAL_IO, we cannot do anything. If it does it could
> mean bug in grub and needs investigation.

My point of confusion here was that the efi serial.h file simply
includes the serial.h from the i386/coreboot directory. Since this is
where the port addresses are defined I figured grub must fall back to
port I/O if possible. Bad assumption I suppose.

lsefi on my system doesn't return the GUID for a SERIAL_IO_PROTOCOL. It
looks like lsefi would transform this into the string 'serial' in its
output but that's also not listed. So I guess my platform firmware
doesn't support any serial hardware :(

Quick workaround was to use a USB to serial adapter compatible with the
pl2303 driver. This works flawlessly.

Thanks for the data,

Philip

>>                                I'm also linking all of the modules built
>> into the bootx64.efi image. For testing I'm just copying bootx64.efi to
>> a GPT/FAT32 USB drive and booting directly from the UEFI shell.
>>
>> Anyone out there willing to share their experience in the Grub serial
>> code, specifically with regard to configuring UARTs with weird I/O ports?
>>
>> Thanks in advance,
>> Philip
>>
>> _______________________________________________
>> Help-grub mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/help-grub
>