etherboot-developers Mailing List for Etherboot (Page 224)
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers — Discussion of developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(10) |
Sep
(3) |
Oct
(10) |
Nov
(47) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(41) |
Feb
(107) |
Mar
(76) |
Apr
(103) |
May
(66) |
Jun
(72) |
Jul
(27) |
Aug
(31) |
Sep
(33) |
Oct
(18) |
Nov
(33) |
Dec
(67) |
| 2002 |
Jan
(25) |
Feb
(62) |
Mar
(79) |
Apr
(74) |
May
(67) |
Jun
(104) |
Jul
(155) |
Aug
(234) |
Sep
(87) |
Oct
(93) |
Nov
(54) |
Dec
(114) |
| 2003 |
Jan
(146) |
Feb
(104) |
Mar
(117) |
Apr
(189) |
May
(96) |
Jun
(40) |
Jul
(133) |
Aug
(136) |
Sep
(113) |
Oct
(142) |
Nov
(99) |
Dec
(185) |
| 2004 |
Jan
(233) |
Feb
(151) |
Mar
(109) |
Apr
(96) |
May
(200) |
Jun
(175) |
Jul
(162) |
Aug
(118) |
Sep
(107) |
Oct
(77) |
Nov
(121) |
Dec
(114) |
| 2005 |
Jan
(201) |
Feb
(271) |
Mar
(113) |
Apr
(119) |
May
(69) |
Jun
(46) |
Jul
(21) |
Aug
(37) |
Sep
(13) |
Oct
(4) |
Nov
(19) |
Dec
(46) |
| 2006 |
Jan
(10) |
Feb
(18) |
Mar
(85) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(20) |
Aug
(9) |
Sep
(11) |
Oct
(4) |
Nov
(1) |
Dec
(40) |
| 2008 |
Jan
(19) |
Feb
(8) |
Mar
(37) |
Apr
(28) |
May
(38) |
Jun
(63) |
Jul
(31) |
Aug
(22) |
Sep
(37) |
Oct
(38) |
Nov
(49) |
Dec
(24) |
| 2009 |
Jan
(48) |
Feb
(51) |
Mar
(80) |
Apr
(55) |
May
(34) |
Jun
(57) |
Jul
(20) |
Aug
(83) |
Sep
(17) |
Oct
(81) |
Nov
(53) |
Dec
(40) |
| 2010 |
Jan
(55) |
Feb
(28) |
Mar
(36) |
Apr
(7) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ebi...@ln...> - 2002-12-05 13:10:49
|
ke...@us... (Ken Yap) writes: > >Are there any important things 5.1.4 that need to happen before I start > >merging this code? > > > >I hate to do it now, when 5.1.x is just really starting to stabalize > >but better now than later... > > I was going to have a go at fixing liloprefix but I'll just check in the > Makefile as I have it now, with the .lzdsk fix as well and then we'll > deal with whatever happens. I must not hold up progress. I'm still probably a couple of days out from actually doing anything, so we shouldn't need to rush to much. But we definitely should figure out the plan for integrating the code. Because once I start code will move around significantly. Eric |
|
From: <ke...@us...> - 2002-12-05 12:39:42
|
>Are there any important things 5.1.4 that need to happen before I start >merging this code? > >I hate to do it now, when 5.1.x is just really starting to stabalize >but better now than later... I was going to have a go at fixing liloprefix but I'll just check in the Makefile as I have it now, with the .lzdsk fix as well and then we'll deal with whatever happens. I must not hold up progress. |
|
From: <ebi...@ln...> - 2002-12-05 12:16:03
|
"deng zhiguo" <dz...@ho...> writes: > hello, etherboot-developers > > I have get a BootStrap program from a server(Novell RPL server), then I > jump to it,and this BootStrap program must use eax,ebx,ecx,edx,esi, so how I > write a function like xstart16 to do it? How I call the function _real_call ? So you want to modify etherboot to be able to work with Novell RPL images? Unless I am mistaken Novell RPL servers don't even do the standard DHCP && TFTP thing so there is not much of the normal etherboot you can use. What you are trying to do sounds so bizarre, and you seem to be approaching the entire situation so naively I am at a loss for words. Eric |
|
From: <ebi...@ln...> - 2002-12-05 12:09:53
|
I am busily cleaning up my code, and getting the last couple of things working. I finally have the nrv2b decompresser ported. It is not a terribly good match for the Itanium, weighing in at 720 bytes.... But that is still small enough to be quite useful. I now have a working Itanium image that is just 32912 bytes.... Uncompressed the same etherboot weighs in at: 69024 bytes. My gut impression is that I am seeing code doubling or tripling it's size compared to the size it would be on x86, too bad a general compressor can't shrink the code down tighter... The Hammer port will be so much nicer in this regard... Anyway after a little more cleanup I should be about ready to merge the Itanium port back into the main tree. Are there any important things 5.1.4 that need to happen before I start merging this code? I hate to do it now, when 5.1.x is just really starting to stabalize but better now than later... Eric |
|
From: <ke...@us...> - 2002-12-04 01:23:08
|
>Crash course directly using the .img file. >A) Just jump to the first byte of the .img. (Only a stack and return address >are expected) >B) $(START16) is a intermediate prefix that does the 16bit->32bit transition, > and is needed, when you have a 16bit prefix. >C) We might want to consolidate compressors and just use nrv2b (works for any > size image > and decompresses in 32bit mode). The old lzhuf compressor is still present > and all of > lzdisk etc still refer to it. >D) Except for lilo I think everything works. I just missed something there.. >. >E) The goal of having stackable prefixes like $(DISKLOADER) $(START16) .... > is primarily so that the same prefix can be use weather or not compression > is present > or not, simplify maintenance by decoupling those variables. >G) Yep I left a few rough edges in 5.1.x my apologies. >H) I was very careful in one or two cases (.rom and .dsk to be certain no rel >ocation would be > in effect, so drivers that were not yet updated would still work) Ok, lets standardise on nrv2b for 5.1.4, now's the time to do radical stuff before anyone complains :-). I'll give the various suffixes a workout and deprecate the lz compressor. |
|
From: <ebi...@ln...> - 2002-12-04 00:53:30
|
ke...@us... (Ken Yap) writes: > >There seems to be a change in the 5.1.3 Makefile. Previously in 5.0.x > >one could do: > > > >$ make bin32/mx98715.lzdsk > >cat bin/przloader.bin bin32/tulip.huf > bin32/mx98715.lzrom > >./makerom.pl -p 0x10d9,0x0531 -i'mx98715.lzrom 5.0.8 Etherboot (GPL)' > >bin32/mx98715.lzrom > >PCI header at 0x1c and PnP header at 0x34 > >cat bin/boot1a.bin bin32/mx98715.lzrom > bin32/mx98715.lzdsk.x > >dd if=bin32/mx98715.lzdsk.x of=bin32/mx98715.lzdsk bs=36k conv=sync 2> > >/dev/null > >rm -f bin32/mx98715.lzdsk.x > > > >But now in 5.1.3 you get: > > > >$ make bin32/mx98715.lzdsk > >make: *** No rule to make target `bin32/mx98715.lzdsk'. Stop. > > Ok, this was puzzling, but the reason is not that the .lzdsk rule has > gone away, but that it had not been updated to match the .dsk rule. > It seems that the rule to fix should look like: > > %.lzdsk: %.lzrom $(DISKLOADER) > cat $(DISKLOADER) $< > $@.x > dd if=$@.x of=$@ bs=36k conv=sync 2> /dev/null > $(RM) $@.x > > if it's to match .dsk. I assume that $(START16) is not needed any more. Yes. It is correct to remove $(START16) I accidentally added it in that case. The .rom image has $(START16) included earlier, and including it twice is just silly. It appeared non-trivial and low priority to remove the assumptions of the disk loader that it was loading a ROM image, which is why I made that mistake. That does mean disk images need to be below 32K or so though. > The whole area needs a good cleanup, but I don't know which prefix files > can jump directly into the .img. Eric, could we have a crash course on > how to jump into the new .img/.lzimgs so that I can have a go at fixing > the prefixes for 5.1.4? I assume $(DISKLOADER) works? Crash course directly using the .img file. A) Just jump to the first byte of the .img. (Only a stack and return address are expected) B) $(START16) is a intermediate prefix that does the 16bit->32bit transition, and is needed, when you have a 16bit prefix. C) We might want to consolidate compressors and just use nrv2b (works for any size image and decompresses in 32bit mode). The old lzhuf compressor is still present and all of lzdisk etc still refer to it. D) Except for lilo I think everything works. I just missed something there... E) The goal of having stackable prefixes like $(DISKLOADER) $(START16) .... is primarily so that the same prefix can be use weather or not compression is present or not, simplify maintenance by decoupling those variables. G) Yep I left a few rough edges in 5.1.x my apologies. H) I was very careful in one or two cases (.rom and .dsk to be certain no relocation would be in effect, so drivers that were not yet updated would still work) Eric |
|
From: <ke...@us...> - 2002-12-03 14:19:29
|
>There seems to be a change in the 5.1.3 Makefile. Previously in 5.0.x
>one could do:
>
>$ make bin32/mx98715.lzdsk
>cat bin/przloader.bin bin32/tulip.huf > bin32/mx98715.lzrom
>./makerom.pl -p 0x10d9,0x0531 -i'mx98715.lzrom 5.0.8 Etherboot (GPL)'
>bin32/mx98715.lzrom
>PCI header at 0x1c and PnP header at 0x34
>cat bin/boot1a.bin bin32/mx98715.lzrom > bin32/mx98715.lzdsk.x
>dd if=bin32/mx98715.lzdsk.x of=bin32/mx98715.lzdsk bs=36k conv=sync 2>
>/dev/null
>rm -f bin32/mx98715.lzdsk.x
>
>But now in 5.1.3 you get:
>
>$ make bin32/mx98715.lzdsk
>make: *** No rule to make target `bin32/mx98715.lzdsk'. Stop.
Ok, this was puzzling, but the reason is not that the .lzdsk rule has
gone away, but that it had not been updated to match the .dsk rule.
It seems that the rule to fix should look like:
%.lzdsk: %.lzrom $(DISKLOADER)
cat $(DISKLOADER) $< > $@.x
dd if=$@.x of=$@ bs=36k conv=sync 2> /dev/null
$(RM) $@.x
if it's to match .dsk. I assume that $(START16) is not needed any more.
The whole area needs a good cleanup, but I don't know which prefix files
can jump directly into the .img. Eric, could we have a crash course on
how to jump into the new .img/.lzimgs so that I can have a go at fixing
the prefixes for 5.1.4? I assume $(DISKLOADER) works?
|
|
From: Marty C. <md...@et...> - 2002-12-02 15:07:50
|
There seems to be a change in the 5.1.3 Makefile. Previously in 5.0.x one could do: $ make bin32/mx98715.lzdsk cat bin/przloader.bin bin32/tulip.huf > bin32/mx98715.lzrom ./makerom.pl -p 0x10d9,0x0531 -i'mx98715.lzrom 5.0.8 Etherboot (GPL)' bin32/mx98715.lzrom PCI header at 0x1c and PnP header at 0x34 cat bin/boot1a.bin bin32/mx98715.lzrom > bin32/mx98715.lzdsk.x dd if=bin32/mx98715.lzdsk.x of=bin32/mx98715.lzdsk bs=36k conv=sync 2> /dev/null rm -f bin32/mx98715.lzdsk.x But now in 5.1.3 you get: $ make bin32/mx98715.lzdsk make: *** No rule to make target `bin32/mx98715.lzdsk'. Stop. This still works: $ make bin32/tulip.lzdsk gcc -E -Wp,-Wall -DMOVEROM -DRELOC=0x94000 -DZLOADER -o bin/rzloader.s loader.S as -o bin/rzloader.tmp bin/rzloader.s objcopy -O binary bin/rzloader.tmp bin/rzloader.bin rm -f bin/rzloader.tmp cat bin/rzloader.bin bin32/tulip.huf > bin32/tulip.lzrom ./makerom.pl -i'tulip.lzrom 5.0.8 Etherboot (GPL)' bin32/tulip.lzrom cat bin/boot1a.bin bin32/tulip.lzrom > bin32/tulip.lzdsk.x dd if=bin32/tulip.lzdsk.x of=bin32/tulip.lzdsk bs=36k conv=sync 2> /dev/null rm -f bin32/tulip.lzdsk.x rm bin32/tulip.lzrom and, being a tulip driver, it would work for the card in question, but it would be nice if the old behavior still worked. It also introduces issues with the rom-o-matic.net code which expects to be able to "make $NIC.lsdsk" as well as "make $NIC/lzrom". So, is this a bug or an intentional change? Marty -- Try: http://rom-o-matic.net/ to make Etherboot images instantly. Name: Marty Connor US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA Voice: (617) 491-6935; Fax: (617) 491-7046 Email: md...@et... Web: http://www.etherboot.org/ |
|
From: harry1<ha...@az...> - 2002-11-30 03:42:08
|
<HTML> <head> <title>Lord of the Rings The Two Towers Cadbury Down Under Card Set</title> <meta NAME="description" content=""> <meta name="keywords" content=""> <link rel="stylesheet" href="/shop.css" type="text/css"> </head> <BODY> <table width="700" border="0" cellspacing="0" cellpadding="0" align="center"> <tr> <TD> <TABLE align='center' class='Description' cellpadding='4' cellspacing='4'> <TR> <TD> <center> <IMG src="http://www.dfnational.com/2towers/TwoTowersHeader.jpg" border='1' alt="The Journey Continues"> <font color="darkblue"> <h3> "Lord of the Rings" <br> "The Two Towers" Cadbury, Down Under Card Set </h3> </font> </center> </TD> </TR> <tr> <td> <CENTER> <FONT color='#454545'> <h2>Available NOW!</h2> 20 different, beautiful, full-color 2 1/2" x 3 1/2" high gloss premium cards. <BR> <br> <STRONG><FONT color="firebrick">This Rare Cadbury, Down Under set</FONT></STRONG> features storyline cards with all-new imagery from the thrilling second film in the Lord of the Rings Trilogy <STRONG>The Two Towers</STRONG> ! <br> <br> Follow <FONT color='#0000cd'><strong>Frodo, Sam, Gandolf the White, Aragorn, Legolas, Gimli, King Theoden, Lady Eowyn, Eomer, Faramir,</strong> and the rest of the fellowship as they battle the <STRONG>"Evil Wizard"</STRONG> <STRONG> Saruman, Grima Wormtounge, Orcs, Uruk-Hai, Wildmen of Dunlending</STRONG> in the race to destroy <STRONG><FONT color="#a63333">The Dark Lord Sauron</FONT></STRONG>'s Ring.</FONT> <BR> <BR> <STRONG>Special Bonus:</STRONG> Also receive a rare <STRONG>"Lord of the Rings"</STRONG> promo card! <br> A $5.00 value <FONT color="firebrick"><STRONG>Absolutely free</STRONG></FONT> with your order! </FONT><FONT color="#000000"> <h2><STRONG>One Ring to rule them all!</STRONG></h2> <a href="http://www.dfnational.com/2towers/contact.asp">Click here</a> </CENTER> </td> </tr> </TABLE> </TD> </tr> </table> <table border="0" align="center" width="700" ID="Table3"> <tr> <td> <hr> <FONT face="Term" color="lightslategray" size="2">You received this message because you are on a preffered list, reference 1129308638. If you received this message in error, and if you no longer wish to receive e-mails from us please click on the following link. </FONT><a href="http://www.dfnational.com/remove/remove.asp?e=e...@li..."> <FONT face="Term" color="lightslategray" size="2">Take me off your list</a>!</FONT><FONT face="Term" size="2"><FONT color="lightslategray"> <br> <BR> 1-(866) 667-5399 <br> NOUCE1<BR> 6822 22nd Avenue North <br> Saint Petersburg, FL, 33710-3918</FONT> </FONT> </td> </tr> </table> </BODY> </HTML> |
|
From: deng z. <dz...@ho...> - 2002-11-29 15:45:19
|
hello, etherboot-developers I have get a BootStrap program from a server(Novell RPL server), then I jump to it,and this BootStrap program must use eax,ebx,ecx,edx,esi, so how I write a function like xstart16 to do it? How I call the function _real_call ? Thanks ! _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/ |
CcDixMnAzL26CQkJIAkJCSAgCQkJCQkJCbvqvvfA2r/4us6/oSC1+7ijuOkgv8PH2LrOxc0gv8C0 wiAyMDEws+Kx7sH2IDMzMLi4sLMgwaS1tcDHIMDPwNoguK6woSDDosPitci02bDtIMfVtM+02S4g uMWz4iDG8rHVIDQyuLggwM/A2riusKEgu/2w3LOttNm0wiCwzcDOtaUguMWz4iC068fQwLsgwbm+ 98fYILnow+K1x7TCIL3FsdTAzrfCwMwgNTC4uLjtIMC7ILPRsO0gwNa+7iCw7bGzIMG5vvcgyMS/ oSCz67W/vcPA5b+hIMH4w+LHz7TCIMDOt8Kx7sH2IMb3x9TH0SC02bjpILPrtb+9w8DlwLogwP20 68D7wM4gIrD4sd7DyrD6IiC788XCwNS0z7TZLg0KDQoJCQkJwMy3r8fRILvzxcK/obytIMDavcXA zCC/+MfPtMIgwM/A2riuuKYgw6Ox4rb1IL2sv+7Az8DMIL7GtNW0z7TZLiDD6773wLsgv/jHz73D tMIgutC16bD6IMDOwOe4piDHyr/kt84gx8+9w7TCILHivvfAuyDAp8fRILjCw+PBpLq4ILytuvG9 uiDA4sTJwMy9uiC/oSC/wL3DuOkgv/jHz73DtMIgsbjAziCxuMH3IMGkuri4piC+8sC7ILz2IMDW vcC0z7TZLg0KDQoJCQkJwdi68bXIIMDOwOe/zSDAzsDnuKYgx8q/5LfOx8+0wiCx4r73wLsgv6yw 4b3DxNHB1rTCILD3IMDixMnAzL26IMH2sd0gudm3ziDAzLfCvK2/zSCxuMDOsaSw7bimILXut88g x8+9yr3Dv8AuCQkJICAgICAJCQkgIAkJCSAgIAkJCQm/wrbzwM4gw6S/6yC8rbrxvboNCgkJCQkJ ICDA4sTJwMy9ur/CtvPAzsOkv+u9w726xdvAuyDF68fYILq4tNkgyL/AssD7wM4gsbjAzi+xuMH3 yLC1v8C7IMH2v/jH1bTPtNkuDQoJCQkJCSAgwOLEycDMvbogs7u/obytIMO8sOjA+8DOIMDUu+fB 9r/4L8DMt8K8rcGivPYvwfa/+LD8uK4gte7AxyC8rbrxvbq4piDF68fYvK0guri02Q0KCQkJCQkg IMb4s9DAuiCxuMDOL7G4wffIsLW/wMcgseLIuLimIMGmsPjH2LXluLO0z7TZCQkJCQ0KDQogCQkJ CcGkurggRS1tYWlsIMGmsPggvK268b26DQoJCQkJCSAgyLi/+LTUsrK8rSC17rfPx8+9xSDDpL/r waS6uL/NIMDMt8K8rcDHILG4wM4vsbjB9yDBtrDHv6EguMK0wiDBpLq4uKYgudm3zrnZt84NCgkJ CQkJICBFLW1haWy3ziDBprD4x9ggteW4s7TPtNkJCQkJDQoNCgkJCQm4wsPjwaS6uCC8rbrxvboN CgkJCQkgICC4wsPjwaS6uLytuvG9urimIMXrx9ggwOLEycDMvbq/oSC17rfPtce0wiC48LXnIMOk v+uw+LDtv80gwMy3wrytwd8gte63z8fPvcUNCgkJCQkJICDDpL/rsPiw7b/NIMDMt8K8rcDHILG4 wM4vsbjB9yDBtrDHv6EguMK0wiDBpLq4tenAuyC6uLTZIL2xsNQgsMu79sfPvccgvPawoSDA1r3A tM+02S4JCQkJDQoNCgkJCQnBpLq4IL26xam3pg0KCQkJCQkgIMDixMnAzL26wMcgvPa4ucC6IMOk v+uw+LDtv80gwMy3wrytuKYguri02SC9sbDUILD8uK7H0iC89iDA1rW1t88gwaaw+MfPtMINCgkJ CQkJICC8rbrxvbrA1LTPtNkuILi+v6EgteW0wiDAzLfCvK2zqiDDpL/rsPiw7bimILTjv6Egtscg w6O+xiDH2Ljevccgx8q/5LChIL74vcC0z7TZLg0KCQkJCQkgIL26xam3prHitMnAuyDF68fYILi+ v6EgteW0wiDBpLq4tenAuyC9usWpt6bHz7DtILD8uK7H0iC89iDA1r3AtM+02S4JCQkJDQoNCgkJ CQkJICAgICAgIAkgZXRoZXJib290LWRldmVsb3BlcnMgtNQgu+fA/MfjtvS++MDMILjewM/AuyC6 uLO7tMLBoSC757D6teW4s7TPtNkuILHNx8/AxyDA/MDav+zG7SDBpLq4wMy/3L+hIL7utrDH0Q0K CQnBpLq4tbUgvvjAvcC7IL7Lt8G15biztM+02S4gwMwguN7Az8DHILz2vcXAuyC/+MShIL7KwLi9 w7jpILz2vcWwxbrOILimIMWsuK/Hz7y8v+QuCQkg |
|
From: <ke...@us...> - 2002-11-28 21:02:20
|
>I have a working port of etherboot to the Itanium. At least for the most >part. I still haven't yet gotten native etherboot drivers to work. But >that is mostly a matter of getting etherboot to relocate. Wow, this is exciting. Good stuff. Today the Itanium, tomorrow ... |
|
From: <ebi...@ln...> - 2002-11-28 13:26:19
|
I have a working port of etherboot to the Itanium. At least for the most part. I still haven't yet gotten native etherboot drivers to work. But that is mostly a matter of getting etherboot to relocate. I'm not going to think about this again until Monday, but then in the next couple of days I am going to be looking at merging my port back into the development branch... I have attacked a lot of 64bit cleanliness issues, and alignment issues in the core. As well as adding a directory structure to the etherboot tree, so the merge will be a little interesting. And yes, I have played with the parameters once again... Eric |
|
From: Georg B. <Geo...@po...> - 2002-11-24 18:16:12
|
Am Sonntag, 24. November 2002 07:14 schrieb Ken Yap: > I'm not sure what needs to be done to liloprefix.S to make it jump > directly to the .img file (Eric?) but you could try putting the rule for > .(lz)lilo back the way it was, inserting $(START16) as the second file. > Also you have to edit liloprefix.S to jump to offset 6 as it was in > 5.0.x. Thanks, the change to liloprefix.S was what I missed when I compared 5.0.x with 5.1.x. It works now with the changed liloprefix.S and %.lilo rule in the Makefile. Remains now the question what has to be done for the direct jump, but I'll leave this for somebody who knows x86 assembler better than me. Georg |
|
From: <ebi...@ln...> - 2002-11-24 14:50:10
|
ke...@us... (Ken Yap) writes: > >I think the reason is that in 5.0.x the .rom image was appended to > >liloprefix.bin, and in 5.1.3 the .img image is appended. The latter does > >not contain the signature, the former does. I tried both to disable the > >check and to generate the .lilo image from the .rom image instead the .img > >file, but in both cases the client hangs after starting the image. > > > >Does anybody know the reason for the .rom -> .img change or what has to be > >done to make the .lilo image work? > > I'm not sure what needs to be done to liloprefix.S to make it jump > directly to the .img file (Eric?) but you could try putting the rule for > .(lz)lilo back the way it was, inserting $(START16) as the second file. > Also you have to edit liloprefix.S to jump to offset 6 as it was in > 5.0.x. Roughly under 5.0.x etherboot had to be loaded at a specific address to run properly. So loading the .rom image was the only way to get it to work. Under 5.1.x etherboot now has the relocation code in it, so it now handles being loaded at an arbitrary address. So all that has to be done is to jump to the start of the .img file. I obviously forget to take out a couple of unnecessary checks. When I have a moment I will take a look. But it should be a fairly simple, operation to make it work. Eric |
|
From: <ke...@us...> - 2002-11-24 06:14:58
|
>I think the reason is that in 5.0.x the .rom image was appended to >liloprefix.bin, and in 5.1.3 the .img image is appended. The latter does >not contain the signature, the former does. I tried both to disable the >check and to generate the .lilo image from the .rom image instead the .img >file, but in both cases the client hangs after starting the image. > >Does anybody know the reason for the .rom -> .img change or what has to be >done to make the .lilo image work? I'm not sure what needs to be done to liloprefix.S to make it jump directly to the .img file (Eric?) but you could try putting the rule for .(lz)lilo back the way it was, inserting $(START16) as the second file. Also you have to edit liloprefix.S to jump to offset 6 as it was in 5.0.x. |
|
From: Georg B. <Geo...@po...> - 2002-11-23 20:39:55
|
Hi, I have problems to create .lilo images from the current cvs development version of etherboot. When started, the image complains: "No ROM signature" and then stops. This is because the code in liloprefix.S does not find the magic bytes 0xAA55 in the etherboot section. I think the reason is that in 5.0.x the .rom image was appended to liloprefix.bin, and in 5.1.3 the .img image is appended. The latter does not contain the signature, the former does. I tried both to disable the check and to generate the .lilo image from the .rom image instead the .img file, but in both cases the client hangs after starting the image. Does anybody know the reason for the .rom -> .img change or what has to be done to make the .lilo image work? Greetings, Georg |
|
From: <ke...@us...> - 2002-11-23 12:16:04
|
I have released Etherboot 5.0.8 at http://www.etherboot.org 5.0.8 is a maintenance release to package all the fixes that have accumulated since 5.0.7 was released. Enjoy! MD5 sums: 150e2b96961924e3c4e83c8de90d24fb etherboot-5.0.8.tar.bz2 70c9e68b5ea7b93e70cb5515b2fa41fd etherboot-5.0.8.tar.gz SHA1 sums: 4da7754133b2ea857a8769cdff84d9ef610d5f55 etherboot-5.0.8.tar.bz2 62bd673f2d145a6c88d9d52a7a2d5e312e79e35b etherboot-5.0.8.tar.gz |
|
From: Peter L. <P.L...@sy...> - 2002-11-22 16:10:15
|
Eric B said: > I don't even want to go into how bad I think in principle a syscall > layer in the firmware is, and it is definitely not something I would > design for. But at the same time I think there is value in being > compatible, especially if it the implementation is trivial and has no > real maintenance burden. I'm suggesting only that the syslinux behaviour (tftp a config file) is maintained at the highest level. As this simply uses dhcp and tftp, this should be exactly the kind of thing that the separate EB menu stuff does now, yes? > Give me a broader survey, but neither pxelinux nor the freebsd loader > use the UNDI layer. And UNDI is an optional part of PXE for the > Itanium. If an unmodified pxelinux would run under etherboot there > are plenty of people who would say that is PXE and not care about > the technical details. Sorry, too many acronyms beginning with 'U'. Yes, Eric, you are right; the question is which *interfaces* to export. I am embarrased to be guilty of the same mistake I described earlier, reading "UNDI" as the nic independence itself and forgetting that the "I" means "interface". Duh. People need the driver, not the driver API. One needs UNDI only if NOT using UDP; you observe that pxe clients only use the UDP PXE interface, and are suggesting just supporting UDP in the first instance. It would be interesting to know what NTLOADER and other things use. > > I don't want PXE support as such - I want open source firmware world > > domination, and supporting PXE is an important step on that road. > > Unbiased firmware which loads whatever environment is required to > > support the OS is the aim; LinuxBIOS and Adam Sulmicki's PC BIOS work > > can provide this for those who need an MS environments, and EB with PXE > > allows them to boot from the net. > > You want to take the torch on this one? It is on my wishlist, but > I really don't have time to pursue any of this right now. I think it's really interesting; at the moment, all I can really do is propagandise. I've been watching EB, LinuxBIOS and friends and also thinking about what vmware, User Mode Linux, bochs are doing for virtualisation. I like Ollie Lho's suggestion of "Omniboot" to described the mass of booting related stuff. This could really be something. |
|
From: <ebi...@ln...> - 2002-11-22 07:01:10
|
Peter Lister <P.L...@sy...> writes: > > I just took a look at syslinux and all it really uses is are the PXE > > UDP functions, that are currently implemented for freebsd support. > > Though I believe it uses the 16bit API entry points. > > There's actually no particular reason AFAICS that syslinux needs to use > pxe. It could be ported as an etherboot "menu module", to sit on top of > Etherboot's drivers so that people who want syslinux behaviour can have > a syslinux-in-firmware (which even has an IDE driver, dammit). I don't even want to go into how bad I think in principle a syscall layer in the firmware is, and it is definitely not something I would design for. But at the same time I think there is value in being compatible, especially if it the implementation is trivial and has no real maintenance burden. > > So with a little care I think etherboot could implement pxe without > > many changes. The task list would look like: > > > > The todo list would be: > > - Working 16bit PXE/32bit PXE glue code. > > - Working raw download driver. > > - [optional] PXE hacked DHCP. > > - [optional] PXE TFTP. > > - [optional] PXE UNDI compatibility. > > HPA has said that that the world needs a decent open source PXE > implementation, and I'm inclined to agree, though possibly not for the > same reasons. > > I'd have said that UNDI is the most essential bit - that is why people > *want* PXE, I perceive - nic independent booting. They tend to use "PXE" > as shorthand for "nic independent network boot". They are looking for > "network in the BIOS", not a lecture on the ways in which PXE is broken. Give me a broader survey, but neither pxelinux nor the freebsd loader use the UNDI layer. And UNDI is an optional part of PXE for the Itanium. If an unmodified pxelinux would run under etherboot there are plenty of people who would say that is PXE and not care about the technical details. > > Just in case someone is ambitious or has worries about shipping a > > machine to someone who really wants PXE support. > > I don't want PXE support as such - I want open source firmware world > domination, and supporting PXE is an important step on that road. > Unbiased firmware which loads whatever environment is required to > support the OS is the aim; LinuxBIOS and Adam Sulmicki's PC BIOS work > can provide this for those who need an MS environments, and EB with PXE > allows them to boot from the net. You want to take the torch on this one? It is on my wishlist, but I really don't have time to pursue any of this right now. Eric |
|
From: Peter L. <P.L...@sy...> - 2002-11-21 21:00:57
|
> I just took a look at syslinux and all it really uses is are the PXE > UDP functions, that are currently implemented for freebsd support. > Though I believe it uses the 16bit API entry points. There's actually no particular reason AFAICS that syslinux needs to use pxe. It could be ported as an etherboot "menu module", to sit on top of Etherboot's drivers so that people who want syslinux behaviour can have a syslinux-in-firmware (which even has an IDE driver, dammit). > So with a little care I think etherboot could implement pxe without > many changes. The task list would look like: > > The todo list would be: > - Working 16bit PXE/32bit PXE glue code. > - Working raw download driver. > - [optional] PXE hacked DHCP. > - [optional] PXE TFTP. > - [optional] PXE UNDI compatibility. HPA has said that that the world needs a decent open source PXE implementation, and I'm inclined to agree, though possibly not for the same reasons. I'd have said that UNDI is the most essential bit - that is why people *want* PXE, I perceive - nic independent booting. They tend to use "PXE" as shorthand for "nic independent network boot". They are looking for "network in the BIOS", not a lecture on the ways in which PXE is broken. > Just in case someone is ambitious or has worries about shipping a > machine to someone who really wants PXE support. I don't want PXE support as such - I want open source firmware world domination, and supporting PXE is an important step on that road. Unbiased firmware which loads whatever environment is required to support the OS is the aim; LinuxBIOS and Adam Sulmicki's PC BIOS work can provide this for those who need an MS environments, and EB with PXE allows them to boot from the net. The daft thing is that it should not be hard to provide even comitted MS users with far *better* firmware than they get from the likes of Award, and real choice about what sits on the mobo. And then, once open-source code actually has control, the prospects are *really* interesting. :) |
|
From: <ebi...@ln...> - 2002-11-21 09:51:39
|
ke...@us... (Ken Yap) writes: > >Roughly this is what I have proposed before for a standard except for > >using the C calling conventions. > > > >If there is a better proposal, or something more standard (say what > >the open firmware platforms are doing) I am still open to discussion. > >But if I don't hear anything this is what I will implement. > > Looks ok to me. Will it also work for environment variables? Linux > doesn't use them but other OSes might (think *BSD does). A bunch of > key/value pairs is all it needs. Basically I am passing a vector of ELF notes which have the form. n_name "string" (of the allocating authority "etherboot" for example) n_type number of whichever parameter we are passing. n_desc arbitrary binary data. So I suspect initially I will pass: #define EB_LOADER_INFO 1 #define EB_HEADER 2 #define EB_BOOTP_DATA_ADDR 3 n_name = "etherboot" n_type = EB_LOADER_INFO n_desc = &loadinfo (or perhaps the contents) n_name = "etherboot" n_type = EB_HEADER n_desc = address of the elf header. n_name = "etherboot" n_type = EB_BOOTP_DATA_ADDR n_desc = BOOP_DATA_ADDR Adding another parameter for to hold an environment, or to point at one should be fairly straight forward. I am going to aim at a couple of types like command line, bootloader, bootloader_version, to be universal. But for the most part the bootloader gets to pass what it wants, with no one interfering. Essentially this is an implementation of passing parameters by name instead of just by position. Eric |
|
From: <ke...@us...> - 2002-11-21 09:17:03
|
>Roughly this is what I have proposed before for a standard except for >using the C calling conventions. > >If there is a better proposal, or something more standard (say what >the open firmware platforms are doing) I am still open to discussion. >But if I don't hear anything this is what I will implement. Looks ok to me. Will it also work for environment variables? Linux doesn't use them but other OSes might (think *BSD does). A bunch of key/value pairs is all it needs. |
|
From: <AD...@la...> - 2002-11-21 06:48:59
|
Ojo6tvO6pyDA/LmuIMi4u+cgv8DHx726x8G288DaOjo6ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILHNx88o sc275ynAxyDAzLjewM8gIMHWvNK0wiDAzsXNs92788DHILDUvcPGx7Xuv6G8rSC89sH9x8+/tMC4 uOcsDQogwMy43sDPIMHWvNIgv9y/obTCIL7utrDH0SDBpLq4tbUgsKHB9rDtIMDWwfYgvsq9wLTP tNkuDQogursguN7Az8C6ILnfvcXA/L/rwNS0z7TZLiC09cDMu/MguN7Az8C7IL/4xKEgvsrAuL3D uOkgvsa3ocDHILz2IL3FILDFILrOuKYgIMWsuK8gx9jB1ry8v+QuIA0KIMHBwLogx8+35yC6uLO7 vLy/5C4NCiANCiBbvPYgvcUgsMUgus4oRG8gbm90IHNlbmQgbWUgIGFnYWluKV0NCiAgICAgICAg ICAgICAgICAgICAgICANCiAgICAgICAgICAgIA== |
|
From: <ebi...@ln...> - 2002-11-21 03:12:55
|
I just took a look at syslinux and all it really uses is are the PXE UDP functions, that are currently implemented for freebsd support. Though I believe it uses the 16bit API entry points. PXE under EFI is a little different. UNDI is optional and it loads EFI images, which only have a limited size due to implementation bugs. So with a little care I think etherboot could implement pxe without many changes. The task list would look like: The todo list would be: - Working 16bit PXE/32bit PXE glue code. - Working raw download driver. - [optional] PXE hacked DHCP. - [optional] PXE TFTP. - [optional] PXE UNDI compatibility. Just in case someone is ambitious or has worries about shipping a machine to someone who really wants PXE support. Eric |
53 messages has been excluded from this view by a project administrator.
