Thread: Re: [Etherboot-developers] Windows 98 slow booting
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: <ke...@us...> - 2002-10-16 20:16:53
|
>This is tricky. We cannot reenable the a20 line on all paths out of >etherboot. Anything with a 32bit entry point expects the a20 line >to be already enabled. > >But probably for all code with a 16bit entry we need to do this, >along with the case when we return to the BIOS. Ken is this correct? >I wonder if this explains the DOS failures. Yes, that's right. For sure returning to the BIOS we should disable the A20 line. 16 bit entry should also not enable it. |
|
From: <ke...@us...> - 2002-10-16 20:23:14
|
>Yes, that's right. For sure returning to the BIOS we should disable the >A20 line. 16 bit entry should also not enable it. It's confusing to me at this hour of the morning whether it's enable or disable, but in any case I mean return the line to the state it was found at boot up. |
|
From: <ke...@us...> - 2002-10-16 20:57:18
|
>We call gateA20_unset() on some exit paths but not all. The proper >solution would probably be to have a static inline void eb_exit(int) that >calls gateA20_unset() (and maybe some other last-minute tidy-ups) before >doing an exit(). All existing calls to exit() should then be replaced >with calls to eb_exit(). However, I'm not sure that I completely >understand all the places where exit() is currently used in Etherboot, so >I'm not confident in doing this. For example, in main.c we have: > case 255: > exit(0); > state = -1; > break; >i.e. code following an exit(), which is puzzling me. > >Thoughts? From a glance at the code, that looks like the correct solution for 5.0. All the occurences of exit are in main, except for one in bootmenu.c which I'll do for completeness. Have you tried it and does it work? If so I'll make the changes later today. For 5.1, it's trickier, as Eric says as if Etherboot is running above 1 MB and you can't turn it off there and then. |
|
From: Michael B. <mb...@fe...> - 2002-10-16 21:45:27
|
On Thu, 17 Oct 2002, Ken Yap wrote: > >We call gateA20_unset() on some exit paths but not all. The proper > >solution would probably be to have a static inline void eb_exit(int) that > >calls gateA20_unset() (and maybe some other last-minute tidy-ups) before > >doing an exit(). All existing calls to exit() should then be replaced > >with calls to eb_exit(). However, I'm not sure that I completely > >understand all the places where exit() is currently used in Etherboot, so > >I'm not confident in doing this. For example, in main.c we have: > > case 255: > > exit(0); > > state = -1; > > break; > >i.e. code following an exit(), which is puzzling me. > >Thoughts? > From a glance at the code, that looks like the correct solution for 5.0. > All the occurences of exit are in main, except for one in bootmenu.c > which I'll do for completeness. Have you tried it and does it work? If > so I'll make the changes later today. I tried temporarily adding gateA20_unset to one exit path and it worked (in the sense that Windows then booted normally). I haven't made any changes to the code - be my guest. I should have this test machine available for another few days if anyone wants to come up with a solution for 5.1, but it'll have to go back to its owner at some point. I don't have any other machines that exhibit this problem. Michael Brown http://www.fensystems.co.uk |
|
From: <ebi...@ln...> - 2002-10-16 23:32:33
|
ke...@us... (Ken Yap) writes: > >We call gateA20_unset() on some exit paths but not all. The proper > >solution would probably be to have a static inline void eb_exit(int) that > >calls gateA20_unset() (and maybe some other last-minute tidy-ups) before > >doing an exit(). All existing calls to exit() should then be replaced > >with calls to eb_exit(). However, I'm not sure that I completely > >understand all the places where exit() is currently used in Etherboot, so > >I'm not confident in doing this. For example, in main.c we have: > > case 255: > > exit(0); > > state = -1; > > break; > >i.e. code following an exit(), which is puzzling me. > > > >Thoughts? > > >From a glance at the code, that looks like the correct solution for 5.0. > All the occurences of exit are in main, except for one in bootmenu.c > which I'll do for completeness. Have you tried it and does it work? If > so I'll make the changes later today. > > For 5.1, it's trickier, as Eric says as if Etherboot is running above 1 > MB and you can't turn it off there and then. It isn't a lot trickier, as there is always code that runs below 1MB to jump to the entry point. So we just need to include the code in stub that jumps to the 16bit entry point. That is a little trickier because that one piece can no longer be in C. :( Eric |
|
From: Michael B. <mb...@fe...> - 2002-10-17 07:46:06
|
On 16 Oct 2002, Eric W. Biederman wrote: > > For 5.1, it's trickier, as Eric says as if Etherboot is running above 1 > > MB and you can't turn it off there and then. > It isn't a lot trickier, as there is always code that runs below 1MB > to jump to the entry point. So we just need to include the > code in stub that jumps to the 16bit entry point. That is a little > trickier because that one piece can no longer be in C. :( It's not just the 16-bit entry point that needs it - it's also needed whenever Etherboot returns to the BIOS, or boots from disk. Michael Brown http://www.fensystems.co.uk |
|
From: <ebi...@ln...> - 2002-10-17 07:58:48
|
Michael Brown <mb...@fe...> writes: > On 16 Oct 2002, Eric W. Biederman wrote: > > > For 5.1, it's trickier, as Eric says as if Etherboot is running above 1 > > > MB and you can't turn it off there and then. > > It isn't a lot trickier, as there is always code that runs below 1MB > > to jump to the entry point. So we just need to include the > > code in stub that jumps to the 16bit entry point. That is a little > > trickier because that one piece can no longer be in C. :( > > It's not just the 16-bit entry point that needs it - it's also needed > whenever Etherboot returns to the BIOS, or boots from disk. Right. In particular for 5.1 exit16, and xstart16 need to have the code to disable the A20 line. Given the complexity of that code figuring out how to share code between those two cases is desireable. 5.1 is cleaner in what actually needs to be modified, than 5.0. It is just more of a pain because you cannot do it in C. Eric |
|
From: Eric W B. <ebi...@ln...> - 2002-10-18 22:51:44
|
ebi...@ln... (Eric W. Biederman) writes: > Michael Brown <mb...@fe...> writes: > > > On 16 Oct 2002, Eric W. Biederman wrote: > > > > For 5.1, it's trickier, as Eric says as if Etherboot is running above 1 > > > > MB and you can't turn it off there and then. > > > It isn't a lot trickier, as there is always code that runs below 1MB > > > to jump to the entry point. So we just need to include the > > > code in stub that jumps to the 16bit entry point. That is a little > > > trickier because that one piece can no longer be in C. :( > > > > It's not just the 16-bit entry point that needs it - it's also needed > > whenever Etherboot returns to the BIOS, or boots from disk. > > Right. In particular for 5.1 > exit16, and xstart16 need to have the code to disable the A20 line. > Given the complexity of that code figuring out how to share code > between those two cases is desireable. > > 5.1 is cleaner in what actually needs to be modified, than 5.0. It > is just more of a pain because you cannot do it in C. I haven't gotten to this yet. I'm busy trying to get some changes into 2.5.x before the feature freeze. But I did run across a weird system where you cannot disable the a20 line. So we need to be careful how this gets implemented... Eric |
