Re: grub-setup: error: Non-sector-aligned data is found in the core file

[UrJiZ]

On Nov 18, 2007 8:02 AM, Robert Millan <address@hidden> wrote:
> On Sun, Nov 11, 2007 at 02:47:21PM +0200, UrJiZ wrote:
> >
> > I just had the first success of loading grub from an Option ROM in
> > qemu. I modified ROMOS code mostly just removing the disk emulation
> > system and making it a simple core.img loader (the loading is a memory
> > copy + setting dl to what the user has defined +  jmp 0:8200h). I can
> > post this code if someone is interested.
>
> Might be useful for us, but in that case...
>
> > It is written in assembler,
> > x86 intel syntax, compiled using nasm
> If you want that code in GRUB, it needs to be converted to AT&T syntax.

 I'm not a real fan of gas and AT&T syntax. I'll propably make this my
project an external "add-on" which an user can download and extract to
his grub2 directory, atleast if no-one is willing to do the
conversion. (btw, can gas do "incbin"? ) ATM everything specific to
this project is (on my computer) in a folder called romboot.

> > and at the moment the rom
> > checksum fixing is done by the same dos tool(romchk.exe) as for romos,
>
> Is romchk.exe free software?

I don't know, but i rewrote it from scratch (only looking at it's
textual output) to prevent using dosbox (didn't look at any source).

> > Now i have both biosdisk and ata modules in the core, and the
> > dl-register-based rootdisk detection just uses fd if dl < 80h or hd if
> > dl > 80h. Having the possibility of selecting an ata drive via some
> > special value of dl would be great, i was thinking of F0h = ata0 ...
> > FFh = ata15 (although ata15 is not yet possible, but maybe possible in
> > future).
>
> I don't understand.  Isn't setting rootdisk in %dl a BIOS task?  Or you
> changed that?

Well, for an ISA Option ROM, bios doesn't provide any value for us
(because the rom isn't really a booted device, bios would continue
after the ROM executes RETF), the loader i wrote can choose this
arbitarily. As background, ISA Option ROM's were used for example in
SCSI controllers to provide "bios" disk services for scsi disks, etc.

> > Also, I'm not sure of this, but it seems that the ata driver blocks
> > out the hd*-devices and i understand this, but it also blocks
> > fd*-devices and this is something i don't really understand, I'd
> > really like to access both cdrom's and floppy disks.
>
> ata and biosdisk can't really coexist.  The block is just there to prevent
> undefined results.  You probably just want to only load biosdisk and discard
> the ata module for now.

Well, I prefer to dump the biosdisk module instead of ata. A native
floppy disk driver would be great.

> > And for the including of files in core.img, all i really need is a way
> > to include grub.cfg in there so that my ROM grub can display a menu
> > even without a root disk. I would be willing to attempt to work on
> > this, but i'd like to hear some suggestions/specification of how it
> > should be done (eq in what layer of grub, whether to have only
> > grub.cfg possible or to be able to have an entire filesystem (will
> > propably take more time for me), etc..).
>
> My idea is to allow grub-mkimage to include an image (at least one) with
> arbitrary content, which will later be dumped in memory.  Then make sure
> the runtime module loader won't attempt to treat it as a module, and find
> a way to locate it in memory.
>
> At that point, it's as simple as writing a disk/ driver that just maps
> accesses to that memory region.
>
> Then of course, the image would normally contain a filesystem, with anything
> grub might need (grub.cfg, unifont.pff, ...).

I played around and got a menu-only solution ready, but I'm not happy
about it (more a hack than a real solution). Modified init.c to map
dl=0x10 => (host) and made a fs driver called cfgfs (from hostfs.c)
that provides only static /boot/grub/grub.cfg. Added host disk driver
and cfgfs fs driver to the build and now i can get a menu.

What i'm worried about in your solution is that the overhead of any fs
image (several sectors) in core.img would make me drop many useful
modules. (64k of space) Of course, this would be very useful for any
other type of loading. (real diskette, netbooting (could carry kernel
and initrd over network withing core.img), etc...)


-- 
urjaman