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

[Robert Millan]

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.

> 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?

> 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?

> 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.

> 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, ...).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)