[syslinux] Syslinux drive confusion

[Gene Cumm]

On Sun, Apr 28, 2013 at 5:25 AM, Berth-Olof Bergman
<b-o.bergman at hotmail.se> wrote:
> I have the following problem with syslinux. With boards with same core chipset and bios, syslinux fails on some boards. The difference on boards are that the ones that succeed has standard PC components (KBC, PATA). The ones that failes have SATA only and no KBC.
>
> It does not matter if I boot from USB or Compact flash drive. I has been noted that the bootloader calls BIOS functions for a drive which are not the boot drive. The boot drive is always 0x80, but the syslinux bootloader do calls for a drive in the range 0x7f or something like that.

I'd guess that somehow the hand-off to Syslinux is confusing.

1) Are they partition like a typical HDD with legacy DOS partitioning?

2) What version of Syslinux?  Are you using the precompiled binaries
in the binary/source archive on kernel.org without any recompilation?
Any chance you could try 4.06, 5.01 or 5.10-pre2 (without any
compilation)?

3) What MBR?  Have you tried mbr/mbr.bin from Syslinux?

4) I presume you've tried a USB Flash Drive and/or Compact Flash in
both boards (with no changes to the media)?

5) It maybe worthwhile to write diag/mbr/handoff.bin to your MBR and
record the information (I've sometimes resorted to clear screenshots
from a cell phone camera for this initially).  If you're using some
other non-Syslinux MBR, you could also test its handoff by writing the
handoff.bin to the VBR per the instructions in diag/mbr/README
assuming the VBR is similar to the FAT* boot sector format (and not
FAT64).

> Anyway everything goes well up to it's time to load the menu. I now get almost a screen full of a text mode graphics character.

6) What menu?  It sounds like menu.c32 (but worth noting if it's
menu.c32, vesamenu.c32, gfxboot.c32 or something else).

> When running Ami BIOS it works, so this is clearly a BIOS dependency. The question is what. Our own 32-bit OS runs without problem. The BIOS follows the standards and the hardware are initialized properly.

I'd expect a 32b protected-mode system to work since most will
implement their own drivers and (mostly) ignore the Real Mode services
provided by the BIOS (once of course enough is loaded into memory for
use).

> I know Linux has made a mess of SATA (sd) and PATA (hd). The failing BIOS run SATA in legacy mode. Can this be a factor here?

I'd say the SATA legacy-mode code in the BIOS is the most likely
candidate to study for this undesired interaction.

7) It could be worth testing with mbr/mbr_c.bin (which will hand off
0x80 for the drive number if the CTRL key is held) or mbr/mbr_f.bin
(which always forces 0x80).

> B-O Bergman
> Zebor Technology

--
-Gene