I've managed to get all the way to jmp_to_elf_entry(), but I have run in to a snag in the assembly code which copies LinuxBIOS in to high memory and then attempts to continue execution up there.
At line 130 of arch/i386/boot/boot.c the code attempts to jump to the next instruction in its new home. (the jmp EAX). When tracing through it in bochs, however, the EAX just points to the next instruction (in low memory, where it was executing before).
The copy moves 0x12fab dwords (304kb?) from 0x04000 to 0x3fbb4154 (what on earth does this address represent?!)
I seem to pass all the ELF header checks so I don't think my problem is anywhere in the etherboot code... Can someone maybe explain what jmp_to_elf_entry() is doing here?
Regards, Andrew
On Tue, 2002-11-19 at 12:56, Andrew Kohlsmith wrote:
I've managed to get all the way to jmp_to_elf_entry(), but I have run in to a snag in the assembly code which copies LinuxBIOS in to high memory and then attempts to continue execution up there.
At line 130 of arch/i386/boot/boot.c the code attempts to jump to the next instruction in its new home. (the jmp EAX). When tracing through it in bochs, however, the EAX just points to the next instruction (in low memory, where it was executing before).
The copy moves 0x12fab dwords (304kb?) from 0x04000 to 0x3fbb4154 (what on earth does this address represent?!)
Can you send us the "objdump -p" of your ELF file ??
Ollie
The copy moves 0x12fab dwords (304kb?) from 0x04000 to 0x3fbb4154 (what on earth does this address represent?!)
Can you send us the "objdump -p" of your ELF file ??
$ objdump -p natsemi.elf
natsemi.elf: file format elf32-i386
Program Header: LOAD off 0x00000060 vaddr 0x00400000 paddr 0x00400000 align 2**5 filesz 0x00007209 memsz 0x0000b560 flags rwx
Just to make sure I didn't do anything wrong, I compiled eepro100.ebi as used in the smartcore-p5 config.etherboot. It doesn't look much different:
$ objdump -p eepro100.ebi
eepro100.ebi: file format elf32-i386
Program Header: LOAD off 0x00000060 vaddr 0x00400000 paddr 0x00400000 align 2**5 filesz 0x00006f49 memsz 0x00009ae0 flags rwx
For the record, I don't plan on using etherboot (the platform uses PCMCIA for network access) -- I will change BOOT_ROM=1 to BOOT_IDE=1 and boot from IDE (first by placing the kernel at a known offset, then hopefully by booting from GRUB/LILO if I can figure it out (does GRUB or LILO as an elf executable work at this time?). At this time, though, I can't even get a simple boot from ROM. :-(
Regards, Andrew
I've managed to get all the way to jmp_to_elf_entry(), but I have run in to a snag in the assembly code which copies LinuxBIOS in to high memory and then attempts to continue execution up there.
Just a reply to myself... I just discovered that bochs can give me the serial output without a serial port. Attached is what is coming out the serial console.
Regards, Andrew
Hello from Gregg C Levine Well done, Andrew. Can you send me a copy of your kernel, or at least make it available someplace, if it is too big to send via e-mail? Complete with instructions on how to attach it to the bochs simulator, please. And as usual, if you choose to send the things to me, off list as per the way the other item got to me. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Andrew Kohlsmith Sent: Tuesday, November 19, 2002 7:31 PM To: linuxbios@clustermatic.org Subject: Re: booting elf from ROM
I've managed to get all the way to jmp_to_elf_entry(), but I have
run in to
a snag in the assembly code which copies LinuxBIOS in to high memory
and
then attempts to continue execution up there.
Just a reply to myself... I just discovered that bochs can give me
the serial
output without a serial port. Attached is what is coming out the
serial
console.
Regards, Andrew
Well done, Andrew. Can you send me a copy of your kernel, or at least make it available someplace, if it is too big to send via e-mail? Complete with instructions on how to attach it to the bochs simulator, please. And as usual, if you choose to send the things to me, off list as per the way the other item got to me.
The kernel doesn't matter (I am not using one... yet).
Bochs was straightforward once I read the documentation a little more thoroughly. I have a 256k ROM image, with the first 64k being the etherboot ELF image, the next 128k empty, and the last 64k being the LinuxBIOS image. 256k down from 0xf0000 is 0xc0000, so I tell bochs that my video BIOS is a 0-byte file I call "nullrom" and the system BIOS is the romimage from LinuxBIOS, installed at 0xc0000.
(Since the video BIOS is at 0xc0000, I could have also put romimage where the video bios is asked for, and put nullrom at 0x00000.)
Start up two shells, one to run Bochs in, and one to receive the serial messages. On the latter, run tty to find out the device it's using. Tell Bochs that COM1 exists, and that its device is what was specified when you ran tty. Now run something like "sleep 1000000" on the sacrificial terminal.
Start up Bochs. On my particular system (since I have to override pci_set_method()'s analysis of my PCI access methods :-) I set a breakpoint on pci_set_method() and trace through until pci_check_direct returns. For me it returns with EAX=0 since neither direct method works in bochs. I override that with a set $eax=[address of pci_direct_conf1] and continue. There will be all kinds of text on the serial console.
And that's where I'm at. elfboot() finds my ELF image at 0xc0000, likes it, so elfload() loads it and tries to run it but gets nowhere. It copies something (the ELF image?) into high memory and tries to jump there to continue but EAX ends up in low memory anyway and we don't get to actually run the ELF image. :-(
Regards, Andrew