The simple way to do this (reload the ebda_seg from the bda) on every access is going to lead to terrible code generation. It may be simpler to implement the Post Memory Manager (PMM) interface - in theory, an option rom shouldn't relocate the ebda if it can allocate memory via PMM. Another possibility would be to assign a segment to the current ebda location (eg, fs/gs) at every entry to the C code.
yes perhaps, because when PPM manager fails to provide memory, the option rom will do the EBDA stuff anyway.
Hrmm. I'm not sure what the following part of your patch does:
The option rom has either BEV OR BCV not both. BEV is for network card, just a entrypoint. BCV will patch the int13 and add new device there.
@@ -341,13 +343,29 @@ callrom(rom, OPTION_ROM_INITVECTOR, 0); continue; }
// PnP rom.
if (pnp->bev)
// Can boot system - add to IPL list.
add_ipl(rom, pnp);
else if (pnp->bcv)
// Has BCV - run it now.
callrom(rom, pnp->bcv, 0);
- /* rebuild the PNP block, init migh have change that */
- pnp = get_pnp_rom(rom);
- /* for further details check BIOS Boot Specification */
- while (pnp) {
dprintf(1, "$PnP at %p\n",pnp);
if ((pnp->bev) && (!pnp->bcv))
add_ipl(rom, pnp, IPL_TYPE_BEV);
if ((!pnp->bev) && (pnp->bcv)) {
dprintf(1, "Running BCV %x\n",pnp->bcv);
callrom(rom, pnp->bcv, 0);
add_ipl(rom, pnp, pnp->type_lo);
the type_lo is not the boot type, Its a PCI type it seems so it then should be HDD (this can fix the floppy item which is wrong)
}
if (pnp->nextoffset)
there can be more BEV/BCVs in the chain.
pnp = (struct pnp_data *) (((u8 *) pnp) + pnp->nextoffset);
else
pnp = NULL;
- }
- }
}
Rudolf