|
From: Ken Y. <ke...@nl...> - 2001-03-20 22:46:04
|
|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; Probably doable, might be a squeeze into 512 bytes. BTW, floppyload.S is obsolete and has been replaced by boot1a.s. |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; The problem with this is Etherboot is going to relocate itself (using loader.S) to 0x94000. The space from 0x90000-9xA0000 has to be kept free. Therefore you should locate your firmware at 0x90000 - 73k at most. Better still I suggest loading the firmware, then Etherboot, at 0x90000 - 105k, then let Etherboot do its thing as normal. Your firmware will be below Etherboot. |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 Why do you think it's not in protected mode? |way that my probe routine can access this data that will certainly cross a |64K boundary? BTW it has always been possible to access more than 64kB in real mode, you just have to diddle with the segment registers to achieve this, which is why segmented architecture is such a pain. |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? Not necessarily, it could be running in protected mode with physical memory mapped 1:1. Virtual memory mapping is something over and above protected mode. Etherboot's protected mode simply gives access to the CPU of all of memory as a flat space. The advantage of PM is of course that one has a 32 bit processor. |
