[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrei Borzenkov
Subject: Re: mini PCIe serial card (StarTech 2p1s) support
Date: Tue, 4 Aug 2015 21:06:21 +0300

В 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 @@
> -#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.

>                                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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]