Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:2009:oremanj:journal:week11 [2009/08/08 12:07]
rwcr
soc:2009:oremanj:journal:week11 [2009/08/08 12:15] (current)
rwcr
Line 134: Line 134:
  
 ==== Friday, 8 August ==== ==== Friday, 8 August ====
-I discovered that my test system'​s video card takes up 55k after it initializes,​ meaning my 90k gPXE ROM would cause an option ROM overflow. Seems my test system'​s BIOS doesn'​t handle this gracefully.+I discovered that my test system'​s video card takes up 55k after it initializes,​ meaning my 90k gPXE ROM would cause an option ROM overflow. Seems my test system'​s BIOS doesn'​t handle this gracefully. That's one mystery solved, though it doesn'​t make my e1000 any less bricked...
  
 On Michael'​s suggestion, I implemented a generic means for placing variables in base memory, in much the manner of ''​_''''​_data16''​ for pcbios builds (it actually uses ''​_''''​_data16''​ if it can). On EFI it places the variables in a special section that is relocated into a freshly allocated bit of base memory at init time. This is used by the FireWire debug code to place its portal structure low, where the debugging host can scan for it. It's a much nicer mechanism than the ''​umalloc_low()''​ of my original implementation. On Michael'​s suggestion, I implemented a generic means for placing variables in base memory, in much the manner of ''​_''''​_data16''​ for pcbios builds (it actually uses ''​_''''​_data16''​ if it can). On EFI it places the variables in a special section that is relocated into a freshly allocated bit of base memory at init time. This is used by the FireWire debug code to place its portal structure low, where the debugging host can scan for it. It's a much nicer mechanism than the ''​umalloc_low()''​ of my original implementation.
Line 188: Line 188:
 Meeting today, the majority of which was spent discussing an idea I had for loading large ROMs in crowded option ROM environments:​ have a small ROM stub that loads the rest of the ROM to an area not subject to the 128k option ROM limit. There are several ways of implementing this: Meeting today, the majority of which was spent discussing an idea I had for loading large ROMs in crowded option ROM environments:​ have a small ROM stub that loads the rest of the ROM to an area not subject to the 128k option ROM limit. There are several ways of implementing this:
   * My initial idea: program the PCI ROM BAR to map the full ROM to an area in high memory. This has some serious practical issues of the "where do you put it?" variety, because one would need to walk both the e820 memory map and the PCI bus to find an area not used by RAM or any other memory-mapped I/O device in the system. And there are some devices, such as the APICs, that don't show up in either.   * My initial idea: program the PCI ROM BAR to map the full ROM to an area in high memory. This has some serious practical issues of the "where do you put it?" variety, because one would need to walk both the e820 memory map and the PCI bus to find an area not used by RAM or any other memory-mapped I/O device in the system. And there are some devices, such as the APICs, that don't show up in either.
-    * On the other hand, it may be safe to do this by looking for a sufficiently ​large contiguous area in PCI memory BAR mappings, disabling ​those mappings ​while we access the ROM, and reenabling ​them later - bears trying, at least.+    * On the other hand, it may be safe to do this by looking for a sufficiently PCI memory BAR mapping (e.g. video card), disabling ​that mapping ​while we access the ROM, and reenabling ​it later - bears trying, at least.
   * Michael'​s idea: use the NVS subsystem to access the flash directly, scan for a gPXE image embedded within it, expose it via int13h, and boot it. The only practical issue here is the fact that most supported NICs don't have an NVS driver. The result may also be rather larger than accessing the PCI BARs, but tiny code that doesn'​t work is useless.   * Michael'​s idea: use the NVS subsystem to access the flash directly, scan for a gPXE image embedded within it, expose it via int13h, and boot it. The only practical issue here is the fact that most supported NICs don't have an NVS driver. The result may also be rather larger than accessing the PCI BARs, but tiny code that doesn'​t work is useless.
 This will be an interesting project to hack on over the next week. :-) This will be an interesting project to hack on over the next week. :-)

QR Code
QR Code soc:2009:oremanj:journal:week11 (generated for current page)