Self-contained ramdisk as GRUB module

[mystran]

I'm sure there's some really obvious solution, but I haven't seen the light yet, so maybe someone else has. Problem is as follows:

Link a module, that contains a ramdisk driver (that's not a problem) and a set of files, in such a way that the driver can access the files.

Best I've come up with is something like: make an archive out of the required files, pipe it into a script that turns it into (say) assembler source with the bytes converted into one long hexadecimal array and pipes that to gas. Then it's just an array in an object file, and can be linked easily.

The archive part is fine, but is there easier way to get it linked as raw data with a label before and after it (or length, either will do), without the ugly binary->hexdecimal conversion? I could write an object file manually, I know, but is there a tool that already does that?

Or have I just missed something?
I want to run the tool in Linux, and I preferably want the object be ELF.

On Windows there's the whole resource mess for this thing, but nobody seems to use anything like that in ELF land. And there's that XPM format that seems like a warning sign to me...

[mystran]

Success. I figured it out. The following does it for input file called 'hello-test':

Code: Select all

$ objcopy -Ibinary -Bi386 -Oelf32-i386 hello-test hello-test.o
$ objdump -x hello-test.o 

hello-test.o:     file format elf32-i386
hello-test.o
architecture: i386, flags 0x00000010:
HAS_SYMS
start address 0x00000000

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000012  00000000  00000000  00000034  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
00000000 l    d  .data  00000000 
00000000 g       .data  00000000 _binary_hello_test_start
00000012 g       .data  00000000 _binary_hello_test_end
00000012 g       *ABS*  00000000 _binary_hello_test_size

Actually objcopy documentation specifically says this can be used to do things like embed pictures into binaries. And the irony is that only reason I stumbled on the whole objcopy was because I was browsing info-index trying to figure out whether there's info page for Gas.

Maybe that should be mentioned in OSFAQ, as I might not be the only one that could use it.

[paulbarker]

GAS has '.incbin file, skip, count' where file is obviously the file to include, skip is the number of bytes into the file to start at and count is the number of bytes to include.

NASM has 'incbin file, skip, count'. The only difference from GAS is the lack of a dot.

[Brendan]

Hi,

NASM has 'incbin file, skip, count'. The only difference from GAS is the lack of a dot.

That is exactly how I've been generating boot images for years, except that I use macros in NASM to generate "directory information" for each file (type, size, access flags, etc).

I also put directories in there too, so that once the OS has booted (and someone formats a hard drive partition) it can flush everything in the RAMdisk (or VFS cache in my case) to the hard drive. Then all you need to do is install a bootloader and OS installation is done...

Anyway, if you're curious see: http://bcos.hopto.org/latest/image/doc/index.html

Follow the links to see the macros I'm using (and don't pay any attention to the copyright notice - if you think the macros I'm using might be useful then grab 'em).


Cheers,

Brendan

[mystran]

Bah, objcopy is better, because it gives me useable information directly invokable from a Makefile, without having to know the filesize.

But yeah, I thought it must be possible with assembler directly too, that's why I was looking for that GAS info page.

Now I only need the absolute minimum of archiving (too lazy to have checked ar-format yet).

[mystran]

Oh well I just write my own archiving code. At least it's portable (by me) then.

[paulbarker]

The skip and count parts of both GAS & NASM's incbin are optional. I would prefer objcopy myself though.