serial port and console redirection

Discussion in 'UDOO X86' started by Snakebyte, Mar 19, 2018.

  1. Snakebyte

    Snakebyte Member

    Joined:
    Mar 19, 2018
    Messages:
    90
    Likes Received:
    9
    Hello,
    I am working with an unsupported bootloader and OS. With the on-board video, the bootloader works great (the OS is another story). I can use the serial port connection on UART1 as documented at

    https://www.udoo.org/docs-x86/Hardware_Reference/Pinout_Braswell.html

    with a USB-TTL connector to OS X with screen (115200 8 N 1). The Insyde splash screen and subsequent screen come up fast, with no delays (they display ahead of the video monitor). However, once the bootloader starts sending characters to the BIOS in teletype mode (int 0x10, ah = 0x0E, bx = 0x0001), the serial output slows to a crawl. The bootloader is configured for 9600 8 N 1 (ax = 0x00E3). I have not seen this discussed in the forums for x86.

    1) Is there an incompatibility with teletype mode?
    2) Is there a better way to write characters to the video screen than teletype mode?
    3) Can the udoo x86 support higher serial port modes? If so, what is the configuration code for ax?

    Thanks!
     
  2. waltervl

    waltervl UDOOer

    Joined:
    Dec 12, 2015
    Messages:
    2,266
    Likes Received:
    564
  3. Snakebyte

    Snakebyte Member

    Joined:
    Mar 19, 2018
    Messages:
    90
    Likes Received:
    9
    I appreciate the reminder to review the settings. I had previously tried setting the console speed to 9600, but this time I also changed to VT-100 as well. Neither worked - now I get gibberish for the splash screen. Also, I manually coded the DLAB on the serial port to set as 115200. Works great in VirtualBox, same incredibly slow behavior with Udoo x86. I also tried turning off console redirect, but then I didn't get anything. The bootloader serial port configuration code might be a problem, though.

    xor ax, ax
    mov ds, ax ! Vector and BIOS data segment
    mov bx, dx ! Line number
    shl bx, #1 ! Word offset
    mov bx, 0x0400(bx) ! I/O port for the given line

    It is addressing COM1 at 0x400, in the BIOS data area. Writing characters go to the same place as bx. I see that this may not be supported on UEFI machines like the Udoo, so I will hack around a bit and see about moving to 0x3F8.

    References for recoding the speed:
    http://pete.akeo.ie/2011/06/crafting-bios-from-scratch.html
    https://wiki.osdev.org/Serial_Ports

    manual serial port code:
    ! bump up to 115200
    lea dx, 3(bx) ! Line Control Register
    movb al, #0x80 ! Enable DLAB
    outb dx

    lea dx, 0(bx) ! LSB when DLAB = 1
    movb al, #0x01 ! LSB divisor = 1
    outb dx

    lea dx, 1(bx) ! MSB when DLAB = 1
    movb al, #0x00 ! MSB divisor = 0
    outb dx

    lea dx, 2(bx) ! IRQs and FIFO control Register
    movb al, #0xC7 ! Unset DLAB, set parity 8-N-1
    outb dx

    lea dx, 3(bx) ! Line Control Register
    movb al, #0x03 ! Unset DLAB, set parity 8-N-1
    outb dx

    lea dx, 4(bx) ! Modem Control Register
    movb al, #0x0B ! DTR, RTS, OUT2
    outb dx

    Most likely the code could be bummed by writing directly to the address (out 3(bx), al, e.g), but I just re-used some other code already in place that worked.

    Stock BIOS int code:

    mov ax, #0x00E3 ! 7 << 5 + 3
    int 0x14
     
    waltervl likes this.
  4. Snakebyte

    Snakebyte Member

    Joined:
    Mar 19, 2018
    Messages:
    90
    Likes Received:
    9
    I finally got the OS to boot yesterday. I found two issues. One is that console redirect needs to be off (I also turned off UART COM2, to make sure I was seeing COM1). The other is that I had to move some OS components into a different memory location from 0x100000 (the low end of the memory spaces returned by the BIOS). I ended up putting them at 10M, just under the 16M limit imposed by BIOS in real-mode. Seems like there might have been a collision of address space or something. This was a fluke find, because I had been experimenting with moving the load location and partitioning the physical memory. I still can't write to the serial port, but at least the OS boots.

    A couple items:

    1) I had said the bootloader was writing to 0x400 for COM1. This is incorrect. I studied the assembly code closer and realized that it was reading a value 0x400 from a vector address, which is zero for COM1. After reading more about BIOS (not my preferred firmware), I see that the bootloader is obtaining the COM1 address from the BIOS data area. The kernel does not. It assumes COM1 is at 0x3f8. This works perfectly fine in VirtualBox and should work on the Udoo x86 SBC, but does not.

    2) I say it should work on Udoo because of the Intel Braswell data sheet linked on the Udoo web page:

    https://www.udoo.org/docs-x86/Hardware_Reference/Pinout_Braswell.html
    http://www.intel.com/content/dam/ww.../pentium-celeron-n-series-datasheet-vol-1.pdf

    Page 142:

    16.4.3.1
    16.4.3.1.1 COM1
    Base I/O Address The base I/O address for the COM1 UART is fixed to 3F8h.

    What I did find in that same document is an oddity:
    16.4.3.2 Legacy Interrupt 16.4.3.2.1 COM1
    The legacy interrupt assigned to the COM1 UART is fixed to IRQ3.

    Just about everything I can find says COM1 is on IRQ4. I am not familiar enough with the x86 platform to know if this could impact serial out. On the serial port out, the splash screen and the screen that displays the boot device options come up well ahead of the video. Once control is passed to the bootloader, writing becomes painfully slow - maybe eight characters at a time every two to three seconds.

    Perhaps someone could confirm that this is a typo in the Intel data sheet, and that the Udoo x86 SBC does use IRQ4 for COM1.

    Thank you.
     
  5. Richard Frank-Huff

    Richard Frank-Huff New Member

    Joined:
    Jul 29, 2019
    Messages:
    2
    Likes Received:
    2
    Hoping that somebody has figured out the serial console situation with an Udoo x86, and that they can help me. I've got several of the x86 boards and, after far too much time, succeeded in serial console connections under two of three scenarios. (There are probably more scenarios, but I wanted to communicate that I can get the serial console working under two different scenarios -- neither of which is the scenario I'm seeking.)

    Let me begin with a bit of background:

    I've built a cluster of five Udoo x86 boards. [See: https://www.richardfrankhuff.com/2019/07/10/update-to-soc-cluster/] My intention from the beginning was to operate them headless and have an out-of-band connection to each via a serial terminal server. Through that terminal server, I could access the BIOS, install and OS via bootable USB or PXE, and -- with an OS installed -- view boot messages and access a shell. Since I have done this sort of thing many times before with different architectures, my assumption was that this would be a trivial. My assumption was wrong.

    First, the requirement for a 1.8V TTL UART had me stumped for the better part of a year. (My prior experience with TTL UARTs for serial console connection was 3.3V or 5V.) Once I saw a couple discussions calling out the 1.8V requirement, I was able to acquire and successfully connect it to CN15 (pins 16, 17, 18, 19). (See: photo 1). However, simply enabling console redirection in the BIOS gave me nothing. I've even updated to the 1.06 firmware, noting that it claims a fix related to console redirection. Again, I got nothing.

    Second, I configured GRUB on the existing CentOS 8 installation to enable a serial console while also removing the suppression of boot process messages.

    GRUB_TERMINAL_INPUT="serial console"
    GRUB_TERMINAL_OUTPUT="serial console"
    GRUB_CMDLINE_LINUX=
    [removed "rhgb quiet"; added "console=ttyS0,115200 console=tty0"]
    GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"

    After making the new GRUB config (i.e., "grub2-mkconfig -o /boot/grub2/grub.cfg") and rebooting, all of the boot process messages AND a console login would display on the serial console. However, it was not possible to access the BIOS or be presented with the GRUB boot loader menu -- which were both still only accessible via a connected HDMI display and USB keyboard. Let's call this "scenario one". (See: photo 2 and 3)

    Third, by testing a variety of settings in the BIOS, I stumbled upon the fact that if I enabled "PCI_HS_UART 0:30:3" under the console redirect submenu, I'd be presented with a console redirect ROM screen and be able to access the BIOS via the serial console but not progress to the boot loader menu on either the serial console or the HDMI display. In fact, the board just hung at a black screen with a single period and a flashing underline cursor when attempting to boot. It almost feels like the board cannot load GRUB when "PCI_HS_UART 0:30:3" is enabled, which doesn't really make any sense to me -- unless pushing the UART to PCI causes a conflict with the eMMC that's I'm using as a boot device. In any case, let's call this "scenario two". (See: photo 4 and 5)

    Has anyone succeeded in getting what I am calling "scenario three" to work? If so, what am I missing? Does the issue have something to do with the boot device being an eMMC on the PCI bus? Or, is it a legacy BIOS vs UEFI problem? Help!

    Photo 1 -

    IMG_2206.jpeg
    Photo 2 -
    Screen Shot 2020-01-21 at 4.12.18 PM.png
    Photo 3 -
    Screen Shot 2020-01-21 at 4.13.21 PM.jpg
    Photo 4 -
    Screen Shot 2020-01-21 at 4.53.23 PM.jpg
    Photo 5 -
    Screen Shot 2020-01-21 at 4.51.39 PM.jpg
     
    Zitt and ccs_hello like this.
  6. Zitt

    Zitt UDOOer

    Joined:
    Apr 22, 2017
    Messages:
    12
    Likes Received:
    8
    Thanks for posting this information. I don't yet have anything to offer from an advice perspective; but your "senerio two" option looks promising for what I need. With the current WorkingFromHome/Covid19 orders; I'm hoping I can use your pathfinding to enable bios / shell application development using my Udoo x86 and this console.

    I was able to find the 1.8V TTL device you appear to be using on Amazon.

    If I find anything useful out about your problem; I'll be sure to share.

    One thing I did appear to notice; is that you do not appear to have ground connected in your picture (between the UDOO and TTL serial device)... I assume this is something you corrected or you had them connected to the same power source.
     
  7. Richard Frank-Huff

    Richard Frank-Huff New Member

    Joined:
    Jul 29, 2019
    Messages:
    2
    Likes Received:
    2
    Thank you for jumping in on this. Definitely tried several combinations of connection for the TTL serial device. Not certain that I ever tried the pictured version with the ground at the same time. Usually, I only connect the ground and vcc when powering the connected device (e.g., a Raspberry Pi) from the USB TTL. However, I can see where I probably should connect the ground.
     
  8. Zitt

    Zitt UDOOer

    Joined:
    Apr 22, 2017
    Messages:
    12
    Likes Received:
    8
    Richard,
    I was able to get the serial console redirection working in UEFI which was my main goal to aid me in developing for my Day Job during this COVID-19 Working-From-Home situation.

    I was able to execute UEFI shell commands from the console when configured properly as a null modem configuration with Ground:
    CN15
    Pin8 -> UART_RXD -> B07WX2DSVB Pin TXD
    Pin6 -> UART_TXD -> B07WX2DSVB Pin RXD
    Pin4 -> UART_CTS# -> ?B07WX2DSVB Pin RTS?
    Pin2 -> UART_RTS# -> ?B07WX2DSVB Pin CTS?

    CN13
    Pin18 -> GND -> B07WX2DSVB Pin GND

    I haven't yet proven the RTS/CTS connections as my UEFI programming needs some debug.
    I was running teraterm on the "host" side and Udoo X86 was configured with 115200 baud, 8, n, 1 stop.

    I think your problem was after the bios hands off to the boot loader... which I'm not currently working on. If there is anything specific you would like me to try on my configuration; please let me know. I do have a linux ?Ubutu? distribution installed on the flash memory... I just haven't tried enabling any console access over the redirected port.
     

Share This Page