Thread: Re: [Etherboot-developers] 5.1.5 Menu & Console problems
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <ke...@us...> - 2003-01-16 11:56:55
|
>On my system, etherboot 5.1.5 loads from floppy (rtl8139.zdsk), then loads >an NFL tagged image. When a selection is made from NFL, an attempt is made >to load the selected file (I see the TFTP request at server), and etherboot >puts out a single DOT, then pauses for a period of time, then spews a large >number of dots, followed by a reboot. Ah well the good news is that the 8139 driver is confirmed working at least. Your problems sound similar to mine in that 5.1.5 cannot boot from a menu choice. |
|
From: <ke...@us...> - 2003-01-16 16:57:49
|
>It looks like I mangled the logic to reinitialize things after calling >cleanup. > >So I suspect after we returned to either boot returned neither: >dev->probe(PROBE_AWAKE) was being called, nor was console_init(); > >I have just checked in the fix and hopefully it does the correct thing now. Ok that works better now, it can successfully load an image after returning from a menu. Now the next problem: Real mode images (DOS, ROM) jump off and reset the machine. May have something to do with the not-yet implemented A20 line restore when leaving Etherboot to run a RM image. Protected mode image (Linux) gets to run the third stage, prints out the location of the ramdisk and then fails to start the kernel. Again maybe something to do with A20. |
|
From: <ebi...@ln...> - 2003-01-16 17:07:57
|
ke...@us... (Ken Yap) writes: > >It looks like I mangled the logic to reinitialize things after calling > >cleanup. > > > >So I suspect after we returned to either boot returned neither: > >dev->probe(PROBE_AWAKE) was being called, nor was console_init(); > > > >I have just checked in the fix and hopefully it does the correct thing now. > > Ok that works better now, it can successfully load an image after > returning from a menu. Now the next problem: Is this problem independent of menus? > Real mode images (DOS, ROM) jump off and reset the machine. May have > something to do with the not-yet implemented A20 line restore when > leaving Etherboot to run a RM image. > > Protected mode image (Linux) gets to run the third stage, prints out the > location of the ramdisk and then fails to start the kernel. Again maybe > something to do with A20. The Linux code should not have a20 problems. It has been a little while since I tested mkelf but it was working at the time I made the patch to generate the checksums. And note some machines have a20 set permanently on. So while we may confuse some machine's BIOS's by not restoring a20 that should be all we confuse. Eric |
|
From: <ke...@us...> - 2003-01-16 17:16:46
|
>> Ok that works better now, it can successfully load an image after >> returning from a menu. Now the next problem: > >Is this problem independent of menus? I haven't tested it without a menu actually, now that you mention it but it shouldn't matter if the image is successfully loaded no? >The Linux code should not have a20 problems. It has been a little >while since I tested mkelf but it was working at the time I made the >patch to generate the checksums. > >And note some machines have a20 set permanently on. So while we may >confuse some machine's BIOS's by not restoring a20 that should be all >we confuse. I think you're right there. BTW the Linux image was generated by a recent mkelf so should have checksumming. |
|
From: <ebi...@ln...> - 2003-01-16 19:17:48
|
ke...@us... (Ken Yap) writes: > >> Ok that works better now, it can successfully load an image after > >> returning from a menu. Now the next problem: > > > >Is this problem independent of menus? > > I haven't tested it without a menu actually, now that you mention it but > it shouldn't matter if the image is successfully loaded no? > > >The Linux code should not have a20 problems. It has been a little > >while since I tested mkelf but it was working at the time I made the > >patch to generate the checksums. > > > >And note some machines have a20 set permanently on. So while we may > >confuse some machine's BIOS's by not restoring a20 that should be all > >we confuse. > > I think you're right there. BTW the Linux image was generated by a > recent mkelf so should have checksumming. Interesting. It definitely needs some tracking down. An interesting data point with respect to booting linux would be to try mkelfImage ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-2.0.tar.gz It does fewer bios calls, than the standard linux kernel, or none at all when running under LinuxBIOS, and in general the images it makes tend to work in more difficult situations. With the checksum in place that should at least confirm the data was in memory correctly at one point. Hopefully I can reproduce this and give some amount of comment. Eric |
|
From: <ebi...@ln...> - 2003-01-16 16:21:59
|
ke...@us... (Ken Yap) writes: > >On my system, etherboot 5.1.5 loads from floppy (rtl8139.zdsk), then loads > >an NFL tagged image. When a selection is made from NFL, an attempt is made > >to load the selected file (I see the TFTP request at server), and etherboot > >puts out a single DOT, then pauses for a period of time, then spews a large > >number of dots, followed by a reboot. > > Ah well the good news is that the 8139 driver is confirmed working at > least. Your problems sound similar to mine in that 5.1.5 cannot boot > from a menu choice. It looks like I mangled the logic to reinitialize things after calling cleanup. So I suspect after we returned to either boot returned neither: dev->probe(PROBE_AWAKE) was being called, nor was console_init(); I have just checked in the fix and hopefully it does the correct thing now. Eric |
