Check for valid MBR before adding drive as "bootable"

[Steve Goodrich]

Back in July I was working on a problem that involved determining if a drive was bootable (see emails from circa 13 July 2012, "Bootorder Failover (Patch)").  I now have a few extra cycles and I'd like to try to do this the right way.  What I'm trying to do is add the "drive_is_bootable()" call to the various boot_add_xxx methods, similar to the following in boot.c:

void
boot_add_hd(struct drive_s *drive_g, const char *desc, int prio)
{
    if (!CONFIG_CHECK_BOOTABLE || drive_is_bootable(drive_g))    // <<<<< new code
        bootentry_add(IPL_TYPE_HARDDISK, defPrio(prio, DefaultHDPrio)
                  , (u32)drive_g, desc);
}

The drive_is_bootable() function would read the MBR from the drive, check a few things to ensure that the drive is bootable, and return 0 (fail) or non-zero (success).  Per the email thread referenced above, I've got my own copy of process_op() from which I've removed the ASSERT16().  Unfortunately, there are ASSERT16()'s deeper in the call tree -- specifically in the code used by process_floppy_op(), process_ata_op(), and process_cdemu_op().

I think the proper approach would be to put the processor in 16-bit mode and use the original process_op() function (returning to 32-bit mode afterward), but I'm not sure how to do that here.  Can anyone offer some guidance here?

Thanks,
    -- Steve G.

[Steve Goodrich]

<BUMP>

Does anyone have recommendations on how to do this (or any other way to check the MBR before adding a drive to the bootable device list)?

Thanks,
     -- Steve G.

----- Original Message -----
From: "Steve Goodrich" 
To: "seabios" 
Sent: Wednesday, October 24, 2012 6:50:59 AM
Subject: [SeaBIOS] Check for valid MBR before adding drive as "bootable"

Back in July I was working on a problem that involved determining if a drive was bootable (see emails from circa 13 July 2012, "Bootorder Failover (Patch)").  I now have a few extra cycles and I'd like to try to do this the right way.  What I'm trying to do is add the "drive_is_bootable()" call to the various boot_add_xxx methods, similar to the following in boot.c:

void
boot_add_hd(struct drive_s *drive_g, const char *desc, int prio)
{
    if (!CONFIG_CHECK_BOOTABLE || drive_is_bootable(drive_g))    // <<<<< new code
        bootentry_add(IPL_TYPE_HARDDISK, defPrio(prio, DefaultHDPrio)
                  , (u32)drive_g, desc);
}

The drive_is_bootable() function would read the MBR from the drive, check a few things to ensure that the drive is bootable, and return 0 (fail) or non-zero (success).  Per the email thread referenced above, I've got my own copy of process_op() from which I've removed the ASSERT16().  Unfortunately, there are ASSERT16()'s deeper in the call tree -- specifically in the code used by process_floppy_op(), process_ata_op(), and process_cdemu_op().

I think the proper approach would be to put the processor in 16-bit mode and use the original process_op() function (returning to 32-bit mode afterward), but I'm not sure how to do that here.  Can anyone offer some guidance here?

Thanks,
    -- Steve G.

_______________________________________________
SeaBIOS mailing list
[e-mail]
http://www.seabios.org/mailman/listinfo/seabios

[Kevin O'Connor]

On Wed, Oct 24, 2012 at 06:50:59AM -0600, Steve Goodrich wrote:
> Back in July I was working on a problem that involved determining if
> a drive was bootable (see emails from circa 13 July 2012, "Bootorder
> Failover (Patch)").  I now have a few extra cycles and I'd like to
> try to do this the right way.  What I'm trying to do is add the
> "drive_is_bootable()" call to the various boot_add_xxx methods,
> similar to the following in boot.c:
>
> void
> boot_add_hd(struct drive_s *drive_g, const char *desc, int prio)
> {
>     if (!CONFIG_CHECK_BOOTABLE || drive_is_bootable(drive_g))    // <<<<< new code
>         bootentry_add(IPL_TYPE_HARDDISK, defPrio(prio, DefaultHDPrio)
>                   , (u32)drive_g, desc);
> }
>
> The drive_is_bootable() function would read the MBR from the drive,
> check a few things to ensure that the drive is bootable, and return
> 0 (fail) or non-zero (success).

I think that is the right approach.
> Per the email thread referenced
> above, I've got my own copy of process_op() from which I've removed
> the ASSERT16().  Unfortunately, there are ASSERT16()'s deeper in the
> call tree -- specifically in the code used by process_floppy_op(),
> process_ata_op(), and process_cdemu_op().
>
> I think the proper approach would be to put the processor in 16-bit
> mode and use the original process_op() function (returning to 32-bit
> mode afterward), but I'm not sure how to do that here.  Can anyone
> offer some guidance here?

We really don't want to run anything in 16bit mode that doesn't
absolutely have to run there, so I wouldn't trampoline into 16bit to
do this.

That is unfortunate with process_op.  Maybe introduce a
process_read_op32() in block.c and have it just handle CMD_READ and
only call the drivers you care about?

-Kevin