[syslinux] [PATCH] git tree: libfat, chain, mtools/syslinux, menu.txt

[Gene Cumm]

On Sat, Aug 21, 2010 at 10:42, Michal Soltys <soltys at ziu.info> wrote:
> On 10-08-21 04:41, Gene Cumm wrote:
>>
>> On Fri, Aug 20, 2010 at 21:47, Michal Soltys<soltys at ziu.info>  wrote:
>>>
>>>  On 10-08-21 01:57, Gene Cumm wrote:
>>>>
>>>>  git://gnx.ath.cx/syslinux.git
>>>>
>>>>  On branch for_hpa, I've got several groups of changes (listed bottom
>>>> up)
>>>>  -chain.c32: the beginning of a DRMK loader; I still need to test this
>>>>  further and document/code what ones can possibly work
>>>>  -NEW: mtools/fixfat: Attempts to change the sectors attribute of the
>>>>  FAT to make it more "livable" (probably needs to move to utils, if
>>>>  included)
>>>>  -chain.c32: a little more progress on DRMK
>>>
>>>  Could you possibly point me to the versions of drmk you're testing with
>>> (I
>>>  think you mentioned about testing a few of them) ?
>>
>> best version.  cdd_1295.iso (v2.0) contains a hard drive image that
>> has been the most problematic to test for partition starts other than
>
> Thanks for info.
>
> I did 2 quick tests with this one (meaning - I pulled the hdd image and used
> it directly):
>
> 1) regular chainloading, with options:
>
> chain.c32 hd3 1 swap setdrv at 0x24 setgeo sethid write
>
> This as you probably guess, updates BPB values and writes them back to the
> disk. Handover in my version also populates the area with proper (as
> reported by bios) CHS geometry, both for GPT and DOS partitions (whenever it
> matter or not, it's being done now).

It writes to the disk?  That should only be done if you know things
are bad and should probably be done by another tool (setfatgeo.c32 or
setfatbpb.c32 might be a good tool to make), IMO.

> 2) kernel+sector combo:
>
> chain.c32 hd3 1 swap setdrv at 0x24 setgeo sethid write file=/dellbio.bin
> sseg=0x2000 fseg=0x70
>
> This line worked fine. Note that in case when both file and sector is loaded
> (and the latter is mmapped), my chain.c points ds:si and ds:bp to sector
> instead of handover area (which is ignored in such case).

Setting ds:si and ds:bp to this area: nice and convenient.

> Both options worked fine without 'swap' as well. Either way, I was greeted
> (on vbox vm) with dell gui (in which system test complained I wasn't dell,
> exit rebooted machine, memory test flashed some text quickly and didn't seem
> to do much).

So you're trying to load at least a part of DRMK from another file
system, if I'm interpreting things correctly?  I know that assuming
the BPB data is set correctly for a normal FAT file system, every
version DRMK I've tested boots perfectly from a FAT12 or FAT16 file
system with no assistance from chain (other than what a normal MBR
boot code will do and when I've tested this scenario; can't recall
which ones I've tested this way).

I've been trying to load dellbio.bin from the same FAT file system as
SYSLINUX and let dellbio.bin turn around and load dellrmk.bin and
command.com from that same file system.

I agree with both you and HPA.  I think that DRMK has enough options
it needs a convenience shortcut but also introducing these new
manipulations to the command line will offer benefit to other systems
that are quirky like DRMK (if they ever exist).

I haven't tried playing with the value on disk versus in memory very
carefully yet.  DRMK could use the hidden sectors as both a starting
point for where to look for the filesystem and as a signature to know
it's got the right one.  I had a lot of difficulty with diag 1295 when
all I did was move the file system without correcting the BPB.  Right
now, BOCHS is my friend for running the tests (Thank you again HPA!)
and I'm either going to use VMware Server or BOCHS to build the disk
images I want to test but probably BOCHS as I can play funny games on
the geometry (tried in VMware, didn't work out).

After I get some more testing done to make sure my theory of loading
DRMK and my code seem correct, I'd like to take a look at your code.

-- 
-Gene