|
From: <ebi...@ln...> - 2001-03-20 17:36:06
|
Jim Fredette <fre...@Za...> writes: > 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; Note many times you don't get all the way to a0000 because the extended bios data area tends to live there. > 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? Nope. You can't do that in ``real mode'' as that is 16 bit mode. To do this easily you just need to be in ``protected mode'', with virtual memory disabled. The normal mode of operation for ehterboot. You will want to check the memory size because you don't want to wire in a window at 256MB. Eric |
