Hello,
I'm trying to boot Linux on qemu (0.8.2) with LinuxBIOSv2 (svn 2394) and FILO (0.5). I built filo.elf, ran buildtarget emulation/qemu-i386, changed Config.lb to use filo.elf as the payload, and built LinuxBIOS. I then copied the resulting qemu-bios.rom to bios.bin, and started qemu with the -L option to use this bios.bin, and -nographic to use the serial console.
When I try to boot a 2.6 bzImage kernel (using diskboot.img from Fedora), FILO gets as far as "Jumping to entry point..." and then hangs:
-----
qemu -L ~ -hda diskboot.img -m 256 -nographic -no-kqemu -d in_asm,exec
(qemu)
LinuxBIOS-1.1.8-FILO Mon Sep 4 10:07:27 PDT 2006 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8-FILO Mon Sep 4 11:01:19 PDT 2006 booting... Enumerating buses... Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [8086/1237] enabled PCI: 00:01.0 [8086/7000] enabled PCI: 00:01.1 [8086/7010] enabled PCI: 00:01.3 [8086/7113] enabled PCI: 00:02.0 [1013/00b8] enabled PCI: 00:03.0 [10ec/8029] enabled PCI: pci_scan_bus returning with max=00 done Allocating resources... Reading resources... Done reading resources. Setting resources... PCI: 00:01.1 20 <- [0x0000001400 - 0x000000140f] io PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] prefmem PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] mem PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] io Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 140 PCI: 00:01.0 subsystem <- 00/00 PCI: 00:01.0 cmd <- 147 PCI: 00:01.1 cmd <- 141 PCI: 00:01.3 cmd <- 140 PCI: 00:02.0 cmd <- 143 PCI: 00:03.0 cmd <- 141 done. Initializing devices... Root Device init PCI: 00:00.0 init PCI: 00:01.0 init PCI: 00:01.1 init PCI: 00:01.3 init PCI: 00:02.0 init PCI: 00:03.0 init Devices initialized Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 00000b74 checksum 841b
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
rom_stream: 0xfffe0000 - 0xfffeffff Found ELF candiate at offset 0 New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 (cleaned up) New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 (cleaned up) New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000236e0 filesz: 0x0000000000009748 Clearing Segment: addr: 0x0000000000109748 memsz: 0x0000000000019f98 Loading Segment: addr: 0x00000000001236e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 Jumping to boot code at 0x106924 FILO version 0.5 (eswierk@bianchi.arastra.com) Mon Sep 4 11:00:39 PDT 2006 collect_sys_info: boot eax = 0xe1fb007 collect_sys_info: boot ebx = 0x3ff77a0 collect_sys_info: boot arg = 0x3ff77a0 malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks) malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks) collect_elfboot_info: Bootloader: elfboot collect_elfboot_info: Version: 1.3 malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks) collect_linuxbios_info: Searching for LinuxBIOS tables... find_lb_table: Found canidate at: 00000530 find_lb_table: header checksum o.k. find_lb_table: table checksum o.k. find_lb_table: record count o.k. collect_linuxbios_info: Found LinuxBIOS table at: 00000530 malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks) convert_memmap: 0x00000000000000 0x00000000000bdc 16 convert_memmap: 0x00000000000bdc 0x0000000009f424 1 convert_memmap: 0x000000000c0000 0x00000000030000 1 convert_memmap: 0x000000000f0000 0x00000003f10000 1 convert_memmap: 0x000000000f0000 0x00000000000000 16 collect_sys_info: 0000000000000bdc-00000000000a0000 collect_sys_info: 00000000000c0000-00000000000f0000 collect_sys_info: 00000000000f0000-0000000004000000 collect_sys_info: RAM 64 MB relocate: Current location: 0x100000-0x123727 relocate: Relocating to 0x3fdc8d0-0x3fffff7... ok setup_timers: CPU 797 MHz pci_init: Scanning PCI: found 6 devices malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) pci_init: 00:00.0 8086:1237 0600 00 pci_init: 00:01.0 8086:7000 0601 00 pci_init: 00:01.1 8086:7010 0101 80 pci_init: 00:01.3 8086:7113 0680 00 pci_init: 00:02.0 1013:00b8 0300 00 pci_init: 00:03.0 10ec:8029 0200 00 Press <Enter> for default boot, or <Esc> for boot prompt... timed out boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) malloc_diag: alloc: 296 bytes (6 blocks), free: 16080 bytes (1 blocks) file_open: dev=hda1, path=/vmlinuz find_ide_controller: found PCI IDE controller 8086:7010 prog_if=0x80 find_ide_controller: primary channel: compatibility mode find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 ide_software_reset: Waiting for ide0 to become ready for reset... ok init_drive: Testing for hda init_drive: Probing for hda init_drive: LBA mode, sectors=16384 init_drive: LBA48 mode, sectors=16384 init_drive: Init device params... ok hda: LBA48 8192KB: QEMU HARDDISK devopen: Partition 1 start 3020518592 length 506638 Disk read error dev=1 drive=0 sector=3020518592 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518594 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518720 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518608 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518656 devread: read sector failed Unknown filesystem type malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) boot: hda:/vmlinuz console=ttyS0 malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) file_open: dev=hda, path=/vmlinuz Mounted fat malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) file_open: dev=hda, path=/vmlinuz devopen: already open malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) Found Linux version 2.6.15-1.2054_FC5 (bhcompile@hs20-bc1-2.build.redhat.com) #1 Tue Mar 14 15:48:03 EST 2006 (protocol 0x204) (loadflags 0x1) bzImage. init_linux_params: Setting up paramters at 0x90000 set_memory_size: 0000000000000bdc - 00000000000a0000 set_memory_size: 00000000000c0000 - 00000000000f0000 set_memory_size: 00000000000f0000 - 0000000004000000 set_memory_size: ramtop=0x4000000 set_memory_size: ext_mem_k=64512, alt_mem_k=64512 parse_command_line: original command line: "console=ttyS0" parse_command_line: kernel command line at 0x91000 parse_command_line: kernel command line (13 bytes): "console=ttyS0" load_linux_kernel: offset=0x2000 addr=0x100000 size=0x16d7f5 Loading kernel... ok start_linux: eip=0x100000 Jumping to entry point... -----
At this point, even qemu becomes unresponsive, so it's hard to figure out exactly what it's doing while running in a tight loop. The last entry in the qemu debug log file is the "Load new stack segment with new GDT" movl instruction in __switch_context:
----- 0x03fe3213: pop %ebx 0x03fe3214: sub $0x106943,%ebx 0x03fe321a: cli 0x03fe321b: mov %esp,%esi 0x03fe321d: sub %ebx,%esi 0x03fe321f: xchg %esi,0x109700(%ebx) 0x03fe3225: add %ebx,%esi 0x03fe3227: movzwl (%esi),%edx 0x03fe322a: mov 0x14(%esi),%eax 0x03fe322d: lgdtl 0x2(%esi) 0x03fe3231: mov %edx,%ss -----
I've also tried an older qemu (0.7.2), an older LinuxBIOS (svn 2302) and an older kernel (2.4.something from Fedora Core 1), all with the same result.
Any suggestions would be appreciated.
--Ed
your problem right now is with filo. Can you try an older one? OR, better yet: if you want to work with me and make linux your boot loader, a la OLPC, that would be better: no filo at all! (not that I don't like FILO, it's wonderful, but Linux as a boot-loader is wonderful-er).
let me know.
ron
On 9/4/06, ron minnich rminnich@gmail.com wrote:
your problem right now is with filo. Can you try an older one? OR, better yet: if you want to work with me and make linux your boot loader, a la OLPC, that would be better: no filo at all! (not that I don't like FILO, it's wonderful, but Linux as a boot-loader is wonderful-er).
Figures, the only part I didn't try downgrading is filo :-)
I would love to use Linux as my boot loader, but is it possible to cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM?
--Ed
On 9/4/06, Ed Swierk eswierk@arastra.com wrote:
I would love to use Linux as my boot loader, but is it possible to cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM?
Correction: we're using a 1 MByte EEPROM, which I notice is the same size specified for the OLPC.
I'll start digging into the instructions on wiki.laptop.org for building the OLPC LinuxBIOS. Any idea what configuration parameters I'd need to twiddle in emulation/qemu-i386/Config.lb to build the proper size image for qemu?
--Ed
I'll start digging into the instructions on wiki.laptop.org for building the OLPC LinuxBIOS. Any idea what configuration parameters I'd need to twiddle in emulation/qemu-i386/Config.lb to build the proper size image for qemu?
Change the ROM_SIZE to be 1024*1024 or 0x100000
On Mon, Sep 04, 2006 at 08:46:23PM -0500, Richard Smith wrote:
Change the ROM_SIZE to be 1024*1024 or 0x100000
Here's a patch which makes all "option ROM_SIZE" lines use x*y format which is a lot easier to read and modify, without having to use your brain or a calculator ;-)
Tested with abuild, no errors.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060906 17:41]:
On Mon, Sep 04, 2006 at 08:46:23PM -0500, Richard Smith wrote:
Change the ROM_SIZE to be 1024*1024 or 0x100000
Here's a patch which makes all "option ROM_SIZE" lines use x*y format which is a lot easier to read and modify, without having to use your brain or a calculator ;-)
Tested with abuild, no errors.
comments anyone?
Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [060906 17:41]:
On Mon, Sep 04, 2006 at 08:46:23PM -0500, Richard Smith wrote:
Change the ROM_SIZE to be 1024*1024 or 0x100000
Here's a patch which makes all "option ROM_SIZE" lines use x*y format which is a lot easier to read and modify, without having to use your brain or a calculator ;-)
Tested with abuild, no errors.
comments anyone?
works for me. I put that arithmetic stuff in the parser for this type of usage -- nice to see it used.
ron
Here's a patch which makes all "option ROM_SIZE" lines use x*y format which is a lot easier to read and modify, without having to use your brain or a calculator ;-)
Tested with abuild, no errors.
comments anyone?
Fine with me. As long as we don't go crazy and make the build system require it. It is easier to look at, understand and modify.
Consistency is good.
* Ed Swierk eswierk@arastra.com [060905 03:35]:
I'll start digging into the instructions on wiki.laptop.org for building the OLPC LinuxBIOS. Any idea what configuration parameters I'd need to twiddle in emulation/qemu-i386/Config.lb to build the proper size image for qemu?
Richard described how to do this.
Qemu can cope with different sizes of "flash". It can do 64k-512k for sure, but I am not sure about 1M. If it does not work, contact Fabrice Bellard or try to find the lines that read the rom. It should be a minor change.
Ed Swierk wrote:
On 9/4/06, ron minnich rminnich@gmail.com wrote:
your problem right now is with filo. Can you try an older one? OR, better yet: if you want to work with me and make linux your boot loader, a la OLPC, that would be better: no filo at all! (not that I don't like FILO, it's wonderful, but Linux as a boot-loader is wonderful-er).
Figures, the only part I didn't try downgrading is filo :-)
I would love to use Linux as my boot loader, but is it possible to cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM?
--Ed
no, but this is qemu ... can't you grow qemu emulated flash?
ron
On 9/5/06, Ronald G Minnich rminnich@lanl.gov wrote:
no, but this is qemu ... can't you grow qemu emulated flash?
Yes, but we plan to eventually run on actual hardware and would prefer to keep the qemu environment as close to the real thing as possible.
--Ed
Maybe this will help: http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id...
Roman
On 09/04/2006 13:22, Ed Swierk wrote:
Hello,
I'm trying to boot Linux on qemu (0.8.2) with LinuxBIOSv2 (svn 2394) and FILO (0.5). I built filo.elf, ran buildtarget emulation/qemu-i386, changed Config.lb to use filo.elf as the payload, and built LinuxBIOS. I then copied the resulting qemu-bios.rom to bios.bin, and started qemu with the -L option to use this bios.bin, and -nographic to use the serial console.
When I try to boot a 2.6 bzImage kernel (using diskboot.img from Fedora), FILO gets as far as "Jumping to entry point..." and then hangs:
qemu -L ~ -hda diskboot.img -m 256 -nographic -no-kqemu -d in_asm,exec
(qemu)
LinuxBIOS-1.1.8-FILO Mon Sep 4 10:07:27 PDT 2006 starting... Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8-FILO Mon Sep 4 11:01:19 PDT 2006 booting... Enumerating buses... Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [8086/1237] enabled PCI: 00:01.0 [8086/7000] enabled PCI: 00:01.1 [8086/7010] enabled PCI: 00:01.3 [8086/7113] enabled PCI: 00:02.0 [1013/00b8] enabled PCI: 00:03.0 [10ec/8029] enabled PCI: pci_scan_bus returning with max=00 done Allocating resources... Reading resources... Done reading resources. Setting resources... PCI: 00:01.1 20 <- [0x0000001400 - 0x000000140f] io PCI: 00:02.0 10 <- [0x00fc000000 - 0x00fdffffff] prefmem PCI: 00:02.0 14 <- [0x00fe000000 - 0x00fe000fff] mem PCI: 00:03.0 10 <- [0x0000001000 - 0x00000010ff] io Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 140 PCI: 00:01.0 subsystem <- 00/00 PCI: 00:01.0 cmd <- 147 PCI: 00:01.1 cmd <- 141 PCI: 00:01.3 cmd <- 140 PCI: 00:02.0 cmd <- 143 PCI: 00:03.0 cmd <- 141 done. Initializing devices... Root Device init PCI: 00:00.0 init PCI: 00:01.0 init PCI: 00:01.1 init PCI: 00:01.3 init PCI: 00:02.0 init PCI: 00:03.0 init Devices initialized Moving GDT to 0x500...ok Wrote linuxbios table at: 00000530 - 00000b74 checksum 841b
Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3
rom_stream: 0xfffe0000 - 0xfffeffff Found ELF candiate at offset 0 New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 (cleaned up) New segment addr 0x100000 size 0x236e0 offset 0xc0 filesize 0x9748 New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 (cleaned up) New segment addr 0x1236e0 size 0x48 offset 0x9820 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000236e0 filesz: 0x0000000000009748 Clearing Segment: addr: 0x0000000000109748 memsz: 0x0000000000019f98 Loading Segment: addr: 0x00000000001236e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 Jumping to boot code at 0x106924 FILO version 0.5 (eswierk@bianchi.arastra.com) Mon Sep 4 11:00:39 PDT 2006 collect_sys_info: boot eax = 0xe1fb007 collect_sys_info: boot ebx = 0x3ff77a0 collect_sys_info: boot arg = 0x3ff77a0 malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks) malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks) collect_elfboot_info: Bootloader: elfboot collect_elfboot_info: Version: 1.3 malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks) collect_linuxbios_info: Searching for LinuxBIOS tables... find_lb_table: Found canidate at: 00000530 find_lb_table: header checksum o.k. find_lb_table: table checksum o.k. find_lb_table: record count o.k. collect_linuxbios_info: Found LinuxBIOS table at: 00000530 malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks) convert_memmap: 0x00000000000000 0x00000000000bdc 16 convert_memmap: 0x00000000000bdc 0x0000000009f424 1 convert_memmap: 0x000000000c0000 0x00000000030000 1 convert_memmap: 0x000000000f0000 0x00000003f10000 1 convert_memmap: 0x000000000f0000 0x00000000000000 16 collect_sys_info: 0000000000000bdc-00000000000a0000 collect_sys_info: 00000000000c0000-00000000000f0000 collect_sys_info: 00000000000f0000-0000000004000000 collect_sys_info: RAM 64 MB relocate: Current location: 0x100000-0x123727 relocate: Relocating to 0x3fdc8d0-0x3fffff7... ok setup_timers: CPU 797 MHz pci_init: Scanning PCI: found 6 devices malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) pci_init: 00:00.0 8086:1237 0600 00 pci_init: 00:01.0 8086:7000 0601 00 pci_init: 00:01.1 8086:7010 0101 80 pci_init: 00:01.3 8086:7113 0680 00 pci_init: 00:02.0 1013:00b8 0300 00 pci_init: 00:03.0 10ec:8029 0200 00 Press <Enter> for default boot, or <Esc> for boot prompt... timed out boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200 malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) malloc_diag: alloc: 296 bytes (6 blocks), free: 16080 bytes (1 blocks) file_open: dev=hda1, path=/vmlinuz find_ide_controller: found PCI IDE controller 8086:7010 prog_if=0x80 find_ide_controller: primary channel: compatibility mode find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4 ide_software_reset: Waiting for ide0 to become ready for reset... ok init_drive: Testing for hda init_drive: Probing for hda init_drive: LBA mode, sectors=16384 init_drive: LBA48 mode, sectors=16384 init_drive: Init device params... ok hda: LBA48 8192KB: QEMU HARDDISK devopen: Partition 1 start 3020518592 length 506638 Disk read error dev=1 drive=0 sector=3020518592 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518594 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518720 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518608 devread: read sector failed Disk read error dev=1 drive=0 sector=3020518656 devread: read sector failed Unknown filesystem type malloc_diag: alloc: 280 bytes (5 blocks), free: 16096 bytes (1 blocks) malloc_diag: alloc: 208 bytes (4 blocks), free: 16168 bytes (1 blocks) boot: hda:/vmlinuz console=ttyS0 malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) file_open: dev=hda, path=/vmlinuz Mounted fat malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) elf_load: Not a bootable ELF image malloc_diag: alloc: 264 bytes (6 blocks), free: 16112 bytes (1 blocks) file_open: dev=hda, path=/vmlinuz devopen: already open malloc_diag: alloc: 248 bytes (5 blocks), free: 16128 bytes (1 blocks) Found Linux version 2.6.15-1.2054_FC5 (bhcompile@hs20-bc1-2.build.redhat.com) #1 Tue Mar 14 15:48:03 EST 2006 (protocol 0x204) (loadflags 0x1) bzImage. init_linux_params: Setting up paramters at 0x90000 set_memory_size: 0000000000000bdc - 00000000000a0000 set_memory_size: 00000000000c0000 - 00000000000f0000 set_memory_size: 00000000000f0000 - 0000000004000000 set_memory_size: ramtop=0x4000000 set_memory_size: ext_mem_k=64512, alt_mem_k=64512 parse_command_line: original command line: "console=ttyS0" parse_command_line: kernel command line at 0x91000 parse_command_line: kernel command line (13 bytes): "console=ttyS0" load_linux_kernel: offset=0x2000 addr=0x100000 size=0x16d7f5 Loading kernel... ok start_linux: eip=0x100000 Jumping to entry point...
At this point, even qemu becomes unresponsive, so it's hard to figure out exactly what it's doing while running in a tight loop. The last entry in the qemu debug log file is the "Load new stack segment with new GDT" movl instruction in __switch_context:
0x03fe3213: pop %ebx 0x03fe3214: sub $0x106943,%ebx 0x03fe321a: cli 0x03fe321b: mov %esp,%esi 0x03fe321d: sub %ebx,%esi 0x03fe321f: xchg %esi,0x109700(%ebx) 0x03fe3225: add %ebx,%esi 0x03fe3227: movzwl (%esi),%edx 0x03fe322a: mov 0x14(%esi),%eax 0x03fe322d: lgdtl 0x2(%esi) 0x03fe3231: mov %edx,%ss
I've also tried an older qemu (0.7.2), an older LinuxBIOS (svn 2302) and an older kernel (2.4.something from Fedora Core 1), all with the same result.
Any suggestions would be appreciated.
--Ed
* Roman Kononov kononov195-lbl@yahoo.com [060905 18:58]:
Maybe this will help: http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id...
Roman
Thanks a lot! Commited!
On 9/5/06, Stefan Reinauer stepan@coresystems.de wrote:
- Roman Kononov kononov195-lbl@yahoo.com [060905 18:58]:
Maybe this will help: http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id...
So is etherboot mantaining its own copy of FILO now?
* Richard Smith smithbone@gmail.com [060905 22:42]:
On 9/5/06, Stefan Reinauer stepan@coresystems.de wrote:
- Roman Kononov kononov195-lbl@yahoo.com [060905 18:58]:
Maybe this will help:
http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id...
So is etherboot mantaining its own copy of FILO now?
Since a while. Yinghai created the possibility to have both filo and etherboot as a payload as far as I can tell. He also added SATA and USB to Filo/Etherboot, which I backported to the "official Filo" that features a lot of other things that Filo/Etherboot does not do (grub menus for example)
Stefan
Since a while. Yinghai created the possibility to have both filo and etherboot as a payload as far as I can tell. He also added SATA and USB to Filo/Etherboot, which I backported to the "official Filo" that features a lot of other things that Filo/Etherboot does not do (grub menus for example)
Thanks. Just making sure I didn't lose track of where the official FILO was.
On 9/5/06, Roman Kononov kononov195-lbl@yahoo.com wrote:
Maybe this will help: http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id...
Bingo! Works like a charm. Thanks!
--Ed
* Ed Swierk eswierk@arastra.com [060904 20:22]:
hda: LBA48 8192KB: QEMU HARDDISK devopen: Partition 1 start 3020518592 length 506638 Disk read error dev=1 drive=0 sector=3020518592 devread: read sector failed
Nasty. The Filo IDE driver makes some assumptions about the IDE hw that QEMU does not fulfill.
I am not particularly familiar with that code, but I know the OpenBIOS IDE driver works on QEMU. It might be worth porting that fine driver written by the famous kernel hacker Jens Axboe.
-
Ed Swierk -
Richard Smith -
Roman Kononov -
ron minnich -
Ronald G Minnich -
Stefan Reinauer -
Uwe Hermann