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!
Its not my cup of tea but did you check the settings of console redirection in UEFI? Page 48 of the PDF manual: http://download.udoo.org/files/UDOO_X86/Doc/UDOO_X86_MANUAL.pdf
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
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.
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 - Photo 2 - Photo 3 - Photo 4 - Photo 5 -
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.
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.
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.
