On Wed, 9 Apr 2008, Hannes Reinecke wrote: > >> Some BIOSes will crash if read at the wrong areas. So instead of > >> reading each word we should rather check for the ROM extension magic > >> or skip the entire 512 byte block if no ROM magic has been found. > >> If we have one we extract the size of the ROM area and skip the > >> entire ROM area if it's not an iBFT table. More efficient and less > >> error-prone. > >> > >> Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]> > > > > NACK. > > > > The iBFT does not have to be contained within a ROM area. I'm fairly > > sure that this change would break iSCSI-booting via either gPXE or via > > emBoot's products, since both will construct the iBFT in base memory > > (below 640kB). > > Hmm. We're start scanning an 512k. So the definition of ROM area is a > bit sloppy here. > > But the main point of this patch is that you _must_ _not_ scan the > entire area. If you do that you crash with buggy BIOSses and with Xen. > > And constructing an iBFT without a proper ROM expansion header is ... > odd.
No. The iBFT is unlikely to lie within the actual option ROM area (i.e. 0xd0000 upwards) since this area should be read-only at the time that the iSCSI boot ROM gets executed. (It will be writable during option ROM initialisation, if the BIOS supports DDIM, but not during system boot.) If you're scanning from 512k upwards, then looking for ROM headers is completely the wrong thing to do, since there's no reason why any data below 640kB should be formatted as an option ROM. > And as gPXE is open source you surely can add the proper ROM expansion > header there; shouldn't be too hard to convince emBoot, too. "Proper" ROM expansion header is not applicable here. gPXE ROMs have a proper ROM expansion header on the ROM image, but the iBFT is not (and cannot be) constructed within the ROM image. > Scanning the entire BIOS areas is a definite no-go. Then scan on paragraph boundaries from 512k to 640k, and look for option ROM headers only within the option ROM space after that. Note that Windows definitely scans the entire region from 512k to 1024k when performing an iSCSI boot, so anything that breaks if we do that will break when hosting Windows too. Michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
