[LinuxBIOS] FILO problems with an NCD ThinStar terminal

Adam Nielsen a.nielsen at shikadi.net
Sat Sep 16 13:40:13 CEST 2006


Hi everyone,

I'm playing around with an old NCD ThinStar 300 terminal, and I'd like
to see if I can some custom code going on it so that I can do something
useful with it.

The terminal has an Intel CPU (sorry, can't recall which one it is at
the moment) but appears to be an i440BX chipset.  When switching the
unit on I can get into the boot monitor and then do a network boot, and
I've now figured out the exact header needed to get the unit to accept
boot images (they're in ELF format, but they need certain bytes set at
the start, and the image has to load at a certain address.)

I managed to boot an image I compiled in C (with an assembly loader
tacked on the front) and I was able to send a few bytes out over the
serial port.

I was about to embark on trying to install LinuxBIOS when I stumbled
across FILO.  I thought I'd try to run FILO directly from my loader
first as the LinuxBIOS configuration looked rather scary, and while I
was playing around with it (and much to my surprise) the terminal will
boot the FILO ELF loader directly!

Unfortunately there are a few issues with FILO, and it turned out that
when I enabled debugging mode I had to add my loader onto the start
anyway otherwise the terminal complained about CRC errors (one of the
flags in my loader tells the unit to skip the CRC check.)

Anyway, this worked, and I got to the point where FILO looks for a menu
file, but then it got stuck.  I tried using a menu.lst file so that I
could specify a serial terminal, but I had to embed the menu.lst file
into the ELF image (as I was hoping that the ELF loader would then load
menu.lst into RAM) and this appears to have worked, as FILO is now
telling me to "Press any key to continue" over the serial line. 
Unfortunately as soon as I do press a key it locks up.  It even locks up
if I press the Shift key on the unit's keyboard, making me wonder if
there's some problem with the IRQs pointing to the wrong address.

It may even be that I've just embedded the menu.lst file incorrectly -
how does everyone else embed theirs?  It worries me that half the
contents of the menu.lst file along with some garbage is dumped over the
serial port before the debug messages start appearing.  In fact, I just
realised that it's ignoring the baud rate I'd set in that file, so I
don't think it's being read at all.

Anyway, if anyone has any advice, I'm all ears!  See below for the debug
output.

Thanks,
Adam.

collect_sys_info: boot eax = 0x100000
collect_sys_info: boot ebx = 0x800
collect_sys_info: boot arg = 0x4254
collect_linuxbios_info: Searching for LinuxBIOS tables...
Can't get memory map from firmware. Using hardcoded default.
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 40 bytes (1 blocks), free: 16336 bytes (1 blocks)
collect_sys_info: 0000000000000000-00000000000a0000
collect_sys_info: 0000000000100000-0000000001000000
collect_sys_info: RAM 16 MB
relocate: Current location: 0x100040-0x1442c7
relocate: Relocating to 0xfbbd70-0xfffff7... ok
setup_timers: CPU 134 MHz
pci_init: Scanning PCI: found 7 devices
malloc_diag: alloc: 136 bytes (2 blocks), free: 16240 bytes (1 blocks)
pci_init: 00:00.0 8086:7100 0600 00
pci_init: 00:06.0 8086:1229 0200 00
pci_init: 00:07.0 8086:7110 0601 00
pci_init: 00:07.1 8086:7111 0101 80
pci_init: 00:07.2 8086:7112 0c03 00
pci_init: 00:07.3 8086:7113 0680 00
pci_init: 00:08.0 5333:8904 0300 00
menu: mem at 0x300000
malloc_diag: alloc: 160 bytes (3 blocks), free: 16216 bytes (1 blocks)
file_open: dev=mem at 0x300000, path=<NULL>
parse_device_name: offset=0x300000 length=0x0
devopen: after offset: start 6144, length 8382464
malloc_diag: alloc: 136 bytes (2 blocks), free: 16240 bytes (1 blocks)
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
...

(I had to change the RAM from 32MB down to 16MB as this is all the unit
has, and it locked up otherwise, as you might expect.)




More information about the coreboot mailing list