dmp vortex86ex in libreboot

small embedded system (SoC), i586 CPU made by a company called DMP. Seems like there are no blobs except a small firmware for a keyboard controller (PS/2), could use usb keyboard instead if the ps/2 'blob' is an issue.

(Back to homepage)

Last updated 00:22 UTC+0100 on November 23rd, 2014

#libreboot on November 15th, 2014

<pehjota> After the conversation yesterday about KolibriOS, I stumbled upon some hardware that community seems to like: the Vortex86 series of i586-compatible SoCs and the DMP EBOX nettops that use those SoCs.  coreboot supports one computer by DMP (src/mainboard/dmp/vortex86ex/) which appears to be the EBOX-3100 (the only EBOX nettop AFAICT without VGA).  Three years ago someone ported coreboot to the
<pehjota> EBOX-3300MX but apparently never upstreamed that work.  These Vortex86 SoCs look pretty good, freedom-wise: I think there's no microcode at all, the VGA cores don't seem to need option ROMs, and there are no blobs for things like ME/MRC/AGESA.  They have relatively low CPU clock rates (most at 600 or 933 MHz), so they aren't great for compiling or gaming.  But they're sold as nettops, thin clients,
<pehjota> and embedded systems, and the prices ($95–$269 from the US distributor) aren't bad.
<pehjota> DMP EBOX computers: http://www.compactpc.com.tw/en/index.html.  EBOX-3300MX coreboot port: https://github.com/XVilka/coreboot (last six commits).  Basic (and incomplete) information on the Vortex86 SoCs: http://www.vortex86.com/.  Some technical overviews and resources: http://www.dmp.com.tw/tech/.  DMP's BusyBox/Linux distribution (with a Linux config file but apparently no source code):
<pehjota> http://www.dmp.com.tw/tech/os-xlinux/.

#libreboot on November 16th, 2014

<fchmmr> pehjota, I added info about those vortex86 machines to libreboot.org/release.html and to git. 
<fchmmr> By the way, xvilka (the person behind those commits on that github page) is in #coreboot at the moment. 
<pehjota> Cool.  I can't discuss it right now either (busy and have to go idle soon), but I'm interested in his work and possibly seeing at least EBOX-3350MX (a nice cheap one with VGA) supported as well.
<pehjota> The EBOX systems are cheap (once you add the cost of a power supply and enclosure to a BBB, it isn't much cheaper than an EBOX is) and most have VGA.  Some have dual Ethernet and miniPCI.

<mtjm> what is in dmp_kbd_fw_part1.inc in coreboot sources?
<fchmmr> mtjm, coreboot/src/cpu/dmp/vortex86ex/dmp_kbd_fw_part1.inc is part of the "DEBLOB" file in libreboot. 
<fchmmr> I'll check it's contents in a coreboot clone. 
<fchmmr> it's referenced (included) by src/cpu/dmp/vortex86ex/biosdata.{inc,lds}
<fchmmr> src/cpu/dmp/vortex86ex/biosdata.inc: #include "src/cpu/dmp/vortex86ex/dmp_kbd_fw_part1.inc"
<fchmmr> src/cpu/dmp/vortex86ex/Makefile.inc:chipset_bootblock_inc += $(src)/cpu/dmp/vortex86ex/biosdata.inc
<mtjm> are there other blobs for that platform?
<mtjm> for checking if it's code or data, see code that uses it (hardware only here?) and relevant documentation; if a disassembler produces reasonable code for an appropriate ISA, then it's most probably code, otherwise it's unknown
<mtjm> (or is it e.g. a keymap?)
<fchmmr> As far as I can tell, src/cpu/dmp/vortex86ex/dmp_kbd_fw_part1.inc is the only blob
<fchmmr> xvilka will know more, I'm sure
I then asked for more info in #coreboot and emailed Andrew Wu (original maintainer for that board) asking the same question

#coreboot on November 16th, 2014

<fchmmr> xvilka, what is src/cpu/dmp/vortex86ex/dmp_kbd_fw_part1.inc for? What kind of data is it?
<fchmmr> Is there a document that describes this data?
<idwer> fchmmr: you haven't looked at biosdata.inc/.lds then
<ruik> fchmmr: i think it is firmware for keyboard controller havent check
<fchmmr> idwer, i looked at biosdata.inc, not lds. checking now. 
<fchmmr> ruik, keyboard as in ps/2 keyboard?
<ruik> fchmmr: yes
<ruik> fchmmr: could be 8051
<ruik> 0x2 can be LJMP

back to #libreboot on November 16th, 2014

<fchmmr> mtjm, just a hunch from #coreboot discussion: I think it might just be for PS/2 keyboards, not sure. 
<fchmmr> If that is the case though, you could basically just ignore it (not use it) and use a usb keyboard, I imagine.  

<pehjota> fchmmr: The EBOX-3100 (only Vortex86EX computer by DMP: <http://www.compactpc.com.tw/en/product/EBOX-3100/ebox-3100_1.html>.
<fchmmr> coreboot menuconfig just says DMP -> Vortex86EX
<pehjota> Yeah, it doesn't say which computer that is, but I'm guessing it's the EBOX-3100.
<fchmmr> maybe there are more that also work. 
<fchmmr> I found a few "86duino" boards for isntance. 
<fchmmr> http://www.bttr-software.de/forum/mix_entry.php?id=13074
<fchmmr> http://www.86duino.com/?page_id=85/installation-troubleshooting-1/recompiling-coreboot-seabios-need-config-files
<pehjota> Yeah, there's 86duino which supposedly comes with coreboot installed.  There were some old configs posted to a forum but the links are dead.  Other than that I can't find source code.  And it's not in upstream coreboot.
Surely someone had a git repository somewhere? Was it public (and is it still online)?
So we need to check all the usual places (github, gitorious, search google/ddg, etc).

<pehjota> Yeah, that thread; the links are dead.
<fchmmr> tried the wayback machine?
<fchmmr> https://archive.org/web/
<pehjota> Oh right, that's a Vortex86EX.  Maybe that's the one supported by coreboot.  DMP sells that one too.
<fchmmr> a lot of the actual commits in coreboot seem to come from DMP themselves. 

<pehjota> I didn't, but the Wayback Machine usually doesn't archive .zip files or other things that aren't Web documents.
<fchmmr> sometimes it does. 

<pehjota> Yeah, there's a developer at DMP who contributes this code to coreboot.
<pehjota> And who is apparently active with KolibriOS too.
<fchmmr> Andrew Wu
<pehjota> Yup.

<fchmmr> does trisquel 7 run on i586-only hardware?
<fchmmr> i thought it was i686
<fchmmr> I asked in #trisquel
<pehjota> Not sure.
<pehjota> Rereading the message in 8522f99 ("Add support for DMP Vortex86EX PCI mainboard.") and looking at <http://www.86duino.com/index.php?p=68>, I think that might be the board.
<fchmmr> maybe it runs on all vortex86ex soc's
<pehjota> The code in src/cpu/ should, but src/mainboard/ is specific to individual boards.
<fchmmr> I meant that maybe the same rom will work on multiple boards. 
Or maybe all those *many* menuconfig options means that it could...

<pehjota> Although src/mainboard/dmp/vortex86ex/Kconfig appears to support configuration for different Vortex86EX-based boards, which is interesting.
<pehjota> With defaults for 86Duino ZERO.
<fchmmr> yes. lots of config options in menuconfig. 
<fchmmr> the default microcode options when selecting that board is "do not include microcode", which is promising. 
<pehjota> Yeah, as I said I don't think there's any microcode on Vortex86.  I think the ISA is implemented directly in hardware.
<fchmmr> Where does it say 86Duino in that Kconfigfile?
<pehjota> It doesn't; I'm just guessing based on some of the default values.
<fchmmr>  select BOARD_ROM_KB_256
<fchmmr> in Kconfig
<fchmmr> probably couldn't fit GRUB in there, then. Would hvae to use SeaBIOS. 
<pehjota> And as I said, the initial commit message suggests it could have been originally for the 86Duino ZERO.
<fchmmr> But if there's no vbios, or if it's a full (and free) vbios implementation, then seabios would be ok. 
<pehjota> Yeah, it uses SeaBIOS.
<pehjota> Yup.
<fchmmr> personally I'd prefer to use GRUB, but seabios is also fine. 
<fchmmr> GRUB wouldn't fit in such a small space
<fchmmr> unless you build it with basically no modules
<pehjota> It's basic VGA hardware with no option ROM AFAICT.  No GPU or anything to initialize.  The Linux driver is just a framebuffer one.
<fchmmr> this all sounds very promising. 
<fchmmr> That file for keyboard can apparently be ignored if it's a freedom issue
<pehjota> So just a framebuffer that gets sent out on VGA.
<fchmmr> (can use usb keyboard)
<pehjota> Yeah.
<fchmmr> <pehjota> So just a framebuffer that gets sent out on VGA.
<fchmmr> <pehjota> The Linux driver is just a framebuffer one.
<pehjota> There's no GPU driver enabled in DMP's Linux config, only a couple video framebuffer drivers.
<fchmmr> I'll ask on the mailing list (coreboot one) who has vortex86 hardware to test on
<pehjota> The Linux config file is in the "source" .zip files here: <http://www.dmp.com.tw/tech/os-xlinux/>.
<pehjota> (Old version of Linux.)
<fchmmr> Source for Vortex86DX/MX: xlinux-5.7-src-dx.zip (4.74 MB)
<fchmmr> Source for Vortex86SX: xlinux-5.7-src-sx.zip (4.77 MB) 
<fchmmr> isn't it vortex86ex that we're looking at?
<pehjota> fchmmr: Yeah, the SoC supported in mainline coreboot is the EX, for which there are apparently no "sources" on that page.  I wouldn't use these systems for routers though; there are cheaper Atheros MIPS boards with dual Ethernet ports and built-in wireless chipsets, which should be able to run U-Boot.
<pehjota> Good call on asking Andrew Wu.  I was planning to just ask DMP in general about coreboot support for the EBOX systems.
<pehjota> Personally I'm not all that interested in the EX-based systems like 86Duino.  They don't have VGA, which would be necessary at least for the use cases I currently have in mind.  I think the MX ones are more interesting from a practical perspective (they should be just as potentially free and xvilka ported coreboot to one of them).  DX2 ones are also nice, but more expensive.

DMP sells the 86Duino directly, and distributors sell the EBOX-3100 (as well as the other EBOX computers).

Firmware for keyboard

In coreboot, see src/cpu/dmp/vortex86ex/dmp_kbd_fw_part1.inc. It is believed to be firmware for a PS/2 keyboard controller, though it's actual purpose is yet to be confirmed. You could probably exclude this (libreboot already does, in the DEBLOB script) and plug in a USB keyboard.

A copy of dmp_kbd_fw_part1.inc: dmp_kbd_fw_part1.inc.txt.

The hex arrays were copied and formated in a PHP file. This outputs the array in intel hex format. See results at array.php (for src, clone the libreboot site using the info from the home page). The output was then saved as dis.inc and dis.inc.hex.

According to ruik in #coreboot IRC channel, this is either 8051 or 8052 assembly code. I installed 2 disassemblers: dis51 (8051 disassembly) and d52 (8052 disassembly).
$ dis51 < dis.inc > dmp_kbd_fw_part1.inc.disassembled.dis51.txt
And for 8052 disassembly:
$ d52 -dh dis.inc.hex
$ mv dis.inc.d52 dmp_kbd_fw_part1.inc.disassembled.d52.txt

Disassembly results here:
8051 (dis51) disassembly: dmp_kbd_fw_part1.inc.disassembled.dis51.txt - lots of data (non-instruction) sections, might be unknown instructions from 8052?
8052 (d52) disassembly: dmp_kbd_fw_part1.inc.disassembled.d52.txt - it's 8051 code. See below.

The original dmp_kbd_fw_part1.inc in coreboot also has a GPL licence attached, so it's possible that DMP might give the source code for this. Otherwise, if all else fails, we have the disassembled code to try to reverse engineer.

Todo's from mtjm:

Andrew Wu replied to my email. The keyboard controller firmware is non-free; no source code available. The GPL license on it is bogus. So libreboot will simply not include PS/2 keyboard support for this machine, unless it can be reverse engineered based on the above. (not needed. just use USB)

Andrew also said that the firmware is 8051 code, not 8052. The firmware implements a standard PC/AT 8042 keyboard controller (handling PS/2 KB_CLK, KB_DATA signals, etc) There are datasheets for this!!.

Andrew also said that he doesn't know about specific hardware as he is in sotfware, so he forwarded me to sales, they/he will let me know what vortex86ex systems are actually available for coreboot.

The 8051 PS/2 keyboard controller firmware not only controls PS/2 keyboard/mouse, but also handles some system functions, like system reset, A20 line enable, etc, via I/O port 60h/64h.

(Because standard PC/AT 8042 keyboard controller does so).

In short, if software reads or writes I/O port 60h/64h in vortex86ex, then you need the 8051 firmware, otherwise these I/O ports won’t work correctly.

I think most OSes, like DOS or Windows, will access port 60h/64h on startup, so removing the firmware code may cause many compatibility problems. 
Instead I propose that I take some minimal time to re-disassemble it
trough the usual free software tools like gdb, binutils(readelf, and
objdump), or radare2.

^ other approaches.

If GNU/Linux will work, then it's ok.