Ronald G Minnich <[EMAIL PROTECTED]> writes: > LOAD 0x001000 0x00080000 0x00080000 0x02868 0x06b20 RWE 0x1000 > LOAD 0x004000 0x00091000 0x00091000 0x00028 0x00028 RWE 0x1000 > LOAD 0x005000 0x00100000 0x00100000 0x8b197 0x8b197 RW 0x1000 > LOAD 0x090249 0x00082249 0x00082249 0x1c6165 0x1c6165 RW > 0x1000 > > > Note that 82249 segment ... 90249 size. > > 00 .note > 01 .note .text .rodata .rodata.str1.1 .rodata.str1.32 .data .bss > 02 .nokill > 03 .kernel > 04 .rodata.str1.1 .rodata.str1.32 .data .bss .nokill .kernel > .ramdisk > > > > some piece of code somwhere is really anxious to merge the ramdisk and > other segments! even though .kernel is segment 3 it also ends up in > segment 4. grind teeth.
That sounds insanely buggy. With out the headers I'm not certain if I am reading your data right. > Eric, do you think 'ld' is fixable? we seem to have trouble with it rev > after rev after rev ... This current output is really busted. I like the > idea of using it but ... this gets old :-) Agreed... You might try: mkelf-x86-linux in elfboottools-2.0.tgz. Which does pretty much the same thing as mkelfImage except it creates the output file by hand so it is a little smaller, and doesn't suffer from ld problems. The code is beta, but it may be worth messing with. Ultimately I'm pretty certain I just want to patch the kernel, and have a utility that attaches ramdisks as needed, see kparam for my initial prototype. ld might be fixable, but I really don't want to mess with it. Eric
