|
From: Jim F. <fre...@Za...> - 2001-03-20 17:21:59
|
hi ken, thanks for the reply; i read the documentation, and am sufficiently scared at this point to avoid making changes with regard to protected mode; however, i must come up with a solution; again, i've got this 73K worth of giganet card firmware payload that must be somehow attached to, and be made available to the etherboot image; i would appreciate your comments on my latest proposal to accomplish this: (using floppyload for development and testing) i) the executable portion of the .rom image for my ethernet card is 32K; however, i would append on an additional 73K of firmware, making the total size 105K; ii) i would modify floppyload.S to load this 105K image by upping the SYSSIZE parameter, and by disabling the 64K byte boundary crossing check, label "die:" in the code; iii) i would change the etherboot RELOCADDR to 78000h, leaving me with 164K of space up to a0000h; the firmware would reside immediately after the executable etherboot image, at 80000h; iv) etherboot executable code, which again, is 32K in size, ultimately exercises my driver's probe entry point, which can then read the firmware from 80000h and load it into the giganet card; to do this last step, i assume that the processor must be running in protected mode ... but i'm almost positive that its not; in that event, ie. in real-mode, is there a way that my probe routine can access this data that will certainly cross a 64K boundary? another question: the giganet card's 16K of registers and memory is accessible via pci memory space (as opposed to i/o space for all other cards supported by etherboot); i pencilled-in some changes to pci.c to identify the bar register for memory space access, and i am able to read and write to the card using a memory address of 10000000h; seems to me that the processor must be running in real mode if i am able to do this; yes? -thanks in advance, jim fredette >hi, >i have run hard against the 32K byte size limitation for an etherboot rom >image size while trying to add support for an ethernet card; the main >problem is that the particular ethernet chip on this card requires its 73K >worth of firmware to be downloaded from the driver; which means, that the Further discussion directed to etherboot-developers where it belongs. With the current approach, there is a limit of close to 64kB on the Etherboot code due to the way the real mode and protected mode code share a stack. Etherboot does not run totally in protected mode, it has to switch to real mode for some services, like console output, memory sizing, etc. These are in first32.S. You can read all about the way the stack is shared in the latest developer manual at etherboot.sourceforge.net/doc/html/devman.html To remove this limit you would have to make radical changes in the way real mode services are called from protected mode. loader.S is not the real problem (sorry bad pun), again read the developer manual, once it has done its job, it's not a concern. |
