Thread: Re: [Etherboot-developers] Tagged Test Image
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <ke...@us...> - 2003-03-19 05:03:03
|
>Does anyone have a working tagged test image for the 5.1 development >release? By working I mean on that will do something after it is >transferred. I don=92t seem to be able to get past the transfer done >stage. I have been able to boot Linux images directly and via a menu on 5.1.6 I think. I don't anything was broken since then except for the .dsk and .fd0 thing. Booting ROM images IIRC worked through a menu, I should try it directly. But it'll have to wait a couple of days before I get a chance to sort out what's the story. |
|
From: <ke...@us...> - 2003-03-25 12:50:47
|
>Now that I finally have an eprom burner and some chips I am able to test >out booting from an eprom. My 3c509 works fine in 5.0, but stops after >the done message in 5.1 (same as the floppy). I am assuming it is a >tagging issue. Ok I got around to doing some tests on 5.1.7 and 5.0.x. 5.0.x is in ROM, and 5.1.7 was loaded from floppy. The test images (ELF and NBI) were made with mknbi-1.4.0 but mknbi-1.2.12 gave the same results. Linux (tomsrtbt) FreeDOS image 5.0.x ok ok 5.1.7 no RELOCATE ok ok 5.1.7 RELOCATE fail(1) fail(2) (1) Printed out first32 banner and location of ramdisk, then froze. (2) Rebooted. So it looks like the problem occurs in the transition to 16-bit mode. The 3c509 is a programmed I/O NIC so it wouldn't be a virt to phys problem and anyway any loading corruption would have shown up immediately after launch in case (1), one would expect. Eric, is there anything extra I should be doing in the mknbi trampolines to ensure the transition happens properly? Should Etherboot be doing something more to prepare for the jump to 16-bit? I seem to remember the 3c509 used to work in an earlier version of 5.1. |
|
From: <ke...@us...> - 2003-03-26 01:36:23
|
Ok, bad news. I've confirmed the results below with an eepro100, so the problem is not the 3c509 driver. In both last night's test and today's a Pentium was used. > Linux (tomsrtbt) FreeDOS image ROM image >5.1.7 no RELOCATE ok ok ok >5.1.7 RELOCATE fail(1) fail(3) fail(3) > >(1) Printed out first32 banner and location of ramdisk, then froze. >(2) Rebooted. (3) Froze. (1) could be an error in the trampoline that mknbi uses, but with FreeDOS and the ROM image it should be just straight jumps into 16-bit code; Etherboot is supposed to just call xstart16. Which makes me suspect that the 16-bit registers are messed up in RELOCATE mode. Or maybe it's something to do with A20 routines? Any theories, Eric? I should test this later with older 5.1 releases to try to see if this ever worked with RELOCATE or it was my imagination. |
|
From: <ke...@us...> - 2003-03-26 02:59:39
|
>(1) could be an error in the trampoline that mknbi uses, but with >FreeDOS and the ROM image it should be just straight jumps into 16-bit >code; Etherboot is supposed to just call xstart16. Which makes me >suspect that the 16-bit registers are messed up in RELOCATE mode. Or >maybe it's something to do with A20 routines? Any theories, Eric? Eric, at lines 133 onward in tagged_loader.c there is: gateA20_unset(); xstart16(tctx.img.execaddr, tctx.img.u.location, virt_to_phys(BOOTP_DATA_ADDR)); But if A20 is unset, the relocated Etherboot may be unmapped (depending on whether it's in an odd or even megabyte), and then there's no way to execute xstart16. Am I wrong? Wasn't this discussed last year? Perhaps what's needed is an xstart16 that does the A20 unset as well (in 16-bit mode). I'm going to comment out the gateA20_unset and see what happens. |
|
From: <ke...@us...> - 2003-03-26 03:06:52
|
>I'm going to comment out the gateA20_unset and see what happens. Bingo, DOS and ROM images now load and run. |
|
From: <ebi...@ln...> - 2003-03-26 07:50:58
|
ke...@us... (Ken Yap) writes: > >I'm going to comment out the gateA20_unset and see what happens. > > Bingo, DOS and ROM images now load and run. O.k. Then we need to get a20 handling fixed in 5.1.x That is one area 5.0 is definitely doing better. Enabling a20 we can leave in the C code. But the code should: - Test to see if a20 is already enabled. - Test to see if we can use the bios to enable a20 - Test to see if we can directly enable a20 KBC. And we should record how a20 was enabled so when we are in 16bit mode we can restore a20 to the state we can in with. I think there is something else missing from the 5.0.x a20 handling as well. But it should not be hard to move that down to 16bit mode. I believe some things do get grumpy if we don't disable a20 handling when we do the hand off in 16bit mode so. But moving the disable to xstart16 looks like the right place to do it given the consequence if we are above 1MB. We probably did not see this earlier as -DRELOCATE was not the default. Eric |
|
From: Timothy L. <tl...@ro...> - 2003-03-27 02:34:39
|
> >I'm going to comment out the gateA20_unset and see what happens. > > Bingo, DOS and ROM images now load and run. I am not sure what happened, but the latest cvs update I did reboots almost immediately on my 486. I will try some debugging tomorrow. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.465 / Virus Database: 263 - Release Date: 3/25/2003 |
|
From: <ke...@us...> - 2003-03-26 09:24:02
|
>O.k. Then we need to get a20 handling fixed in 5.1.x >That is one area 5.0 is definitely doing better. The Linux images not running appears to be my bug in the trampoline (invalid assumption about which 64kB segment it's running in). I'll work on that. It also looked like a bunch of stuff in misc.c should be migrated to arch/i386/firmware. |
|
From: <ebi...@ln...> - 2003-03-26 20:42:06
|
ke...@us... (Ken Yap) writes: > >O.k. Then we need to get a20 handling fixed in 5.1.x > >That is one area 5.0 is definitely doing better. > > The Linux images not running appears to be my bug in the trampoline > (invalid assumption about which 64kB segment it's running in). I'll work > on that. > > It also looked like a bunch of stuff in misc.c should be migrated to > arch/i386/firmware. Yep. The are all conditional upon -DPCBIOS so they are not a problem. But moving the could would certainly be a clean thing to do. Eric |
