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@0x300000 malloc_diag: alloc: 160 bytes (3 blocks), free: 16216 bytes (1 blocks) file_open: dev=mem@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.)
Ok, promising update:
I disabled "GRUB" in the config file, hoping that would ignore the menu.lst, which it did, and it then gave me a boot prompt, and most amazing of all, it doesn't lock up when I type at it :-D
So, step two is figure out how to get it to boot something.
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.
I tried embedding a Linux kernel in the same manner as the menu.lst, but I got a warning that I was overwriting stack space in the ELF file, so that may explain the problem I was having before. However I now tried to get the kernel image to load at 0x400000, and readelf shows that everything is what I expect it to be, however FILO says it doesn't recognise the image at that offset (when I do it as ELF or a straight bzImage.)
So now I'm stuck again, but it looks like it's my method of embedding files into the ELF image that's the problem - can someone point me in the right direction here? Google's not being too helpful for me with this.
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-0x280ea7 relocate: Relocating to 0xe7f190-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 Press <Enter> for default boot, or <Esc> for boot prompt... timed out boot: mem@0x400000 malloc_diag: alloc: 160 bytes (3 blocks), free: 16216 bytes (1 blocks) malloc_diag: alloc: 184 bytes (4 blocks), free: 16192 bytes (1 blocks) file_open: dev=mem@0x400000, path=<NULL> parse_device_name: offset=0x400000 length=0x0 devopen: after offset: start 8192, length 8380416 malloc_diag: alloc: 160 bytes (3 blocks), free: 16216 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 184 bytes (4 blocks), free: 16192 bytes (1 blocks) file_open: dev=mem@0x400000, path=<NULL> devopen: already open malloc_diag: alloc: 160 bytes (3 blocks), free: 16216 bytes (1 blocks) load_linux_header: Not a Linux kernel image Unsupported image format malloc_diag: alloc: 136 bytes (2 blocks), free: 16240 bytes (1 blocks) boot: mem@0x400000,0x200000 malloc_diag: alloc: 168 bytes (3 blocks), free: 16208 bytes (1 blocks) malloc_diag: alloc: 200 bytes (4 blocks), free: 16176 bytes (1 blocks) file_open: dev=mem@0x400000,0x200000, path=<NULL> parse_device_name: offset=0x400000 length=0x200000 devopen: after offset: start 8192, length 8380416 devopen: after length: length 4096 malloc_diag: alloc: 168 bytes (3 blocks), free: 16208 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 200 bytes (4 blocks), free: 16176 bytes (1 blocks) file_open: dev=mem@0x400000,0x200000, path=<NULL> devopen: already open malloc_diag: alloc: 168 bytes (3 blocks), free: 16208 bytes (1 blocks) load_linux_header: Not a Linux kernel image Unsupported image format malloc_diag: alloc: 136 bytes (2 blocks), free: 16240 bytes (1 blocks) boot:
On Sat, Sep 16, 2006 at 10:03:14PM +1000, Adam Nielsen wrote:
I tried embedding a Linux kernel in the same manner as the menu.lst, but I got a warning that I was overwriting stack space
Try making the kernel into an elf and booting that directly, perhaps?
Use ftp://ftp.lnxi.com/pub/mkelfImage/
//Peter
Hi Peter,
Try making the kernel into an elf and booting that directly, perhaps?
That was the first thing I tried but it didn't work, although now I know about adding the proper signature/loader near the front of the ELF file I might try it again.
I actually got it to work late last night, it turns out I hadn't specified the section load address correctly in the linker script when I was embedding the kernel image into FILO - once I did that it detected the kernel and loaded it. Yay!
It was a pretty roundabout way of getting the kernel image into the FILO ELF file though:
http://sources.redhat.com/ml/ecos-discuss/2002-02/msg00422.html
(modified from ARM to i386, of course.) Is this the only way of embedding a binary file into an ELF image?
Thanks, Adam.
Hi,
On Sun, Sep 17, 2006 at 09:20:10AM +1000, Adam Nielsen wrote:
Try making the kernel into an elf and booting that directly, perhaps?
That was the first thing I tried but it didn't work, although now I know about adding the proper signature/loader near the front of the ELF file I might try it again.
Right, that was what I was getting at, sorry I wasn't more clear.
I actually got it to work late last night, it turns out I hadn't specified the section load address correctly in the linker script when I was embedding the kernel image into FILO - once I did that it detected the kernel and loaded it. Yay!
Goodie!
It was a pretty roundabout way of getting the kernel image into the FILO ELF file though:
http://sources.redhat.com/ml/ecos-discuss/2002-02/msg00422.html
(modified from ARM to i386, of course.) Is this the only way of embedding a binary file into an ELF image?
You mean besides mkelfImage? :)
//Peter
Is this the only way of embedding a binary file into an ELF image?
You mean besides mkelfImage? :)
Sorry, maybe I wasn't being so clear that time - I already have the ELF file (in this case filo.elf) and I want to add an arbitrary binary file into that existing ELF file (in this case the binary file is a kernel image, either the raw bzImage, or an ELF file created by mkelfImage - which would include all the ELF headers that mkelfImage generated.)
The idea being that I can create a section in filo.elf that says "load the binary image into memory at offset 0x400000", then I can tell FILO to boot from memory address 0x400000 - upon which it will report finding a kernel in ELF format (or in native Linux format) at that memory location and proceed to boot it.
From the looks of it, mkelfImage produces a new ELF file, it can't merge
into an existing ELF file.
Cheers, Adam.
On Sun, Sep 17, 2006 at 10:42:29AM +1000, Adam Nielsen wrote:
The idea being that I can create a section in filo.elf that says
Aye, my idea was that you could skip filo.elf and only send a mkelfImage:d kernel with a crafted header.
From the looks of it, mkelfImage produces a new ELF file, it can't merge into an existing ELF file.
Right - I assumed that FILO isn't a hard requirement and that loading the kernel is the ultimate goal.
//Peter
-
Adam Nielsen -
Peter Stuge