Linuxbios.strip is 49152 bytes, and eepro100.elf is 22368. So that gives a total of 71520...larger than 65536. So one of them is too big. Any idea which?
-Steve
-----Original Message----- From: steven james To: Atherton, Stephen Cc: 'linuxbios@clustermatic.org' Sent: 4/11/03 9:25 AM Subject: Re: Still not having success with SM P4DPE
Greetings,
It looks like the fallback image is being built wrong.
This can be hacked together manually. linuxbios.strip should be the actual LinuxBIOS code. The objective is to assemble a 64K (exactly) block containing:
1. etherboot 2. null padding (can be generated with dd if=/dev/zero) 3. linuxbios.strip.
I just use calctool to figure out how much padding to use and cat eepro100.elf pad linuxbios.strip >fallback.bin
the 64K fallback.bin can then be appended to the primary image to get the full rom image.
That's a little ugly, but it should get the job done.
Just as a final verification, in linuxbios.map, ZKERNEL_START for the fallback image should be 0xffff0000. That is whjere it will look for the fallback etherboot. Also, it will ljmp to ZKERNEL_START-8 to transfer control to the primary image. I'm slowly trying to disentangle that on the boards I have. Unfortunatly, I don't have a P4DPE.
G'day, sjames
On Fri, 11 Apr 2003, Atherton, Stephen wrote:
Ron and James, thanks for clueing me in on the fallback image stuff.
I'm
still not quite doing something right though, it seems.
My config files are below. I based these on the samples in mainboard/supermicro/p4dpe. The fallback image is 81k and contains
the
etherboot payload...this doesn't seem right to me but I don't know
what else
to do. If I don't specify the etherboot payload, it tries to use
vmlinux
which is much, much bigger.
So I run the config script on both files, then go to the fallback/ and primary/ directories and run make, and I get a primary romimage of
458752
bytes and a fallback image of 81920 bytes. That doesn't seem right.
What
am I doing wrong? Oh and though I was doubtful, I did do a "cat primary/romimage fallback/romimage > finalimage" and burned the final
image.
Also, from the looks of the makeprocess my two image files are
basically the
same binary stuff but one has a lot of null padding. They both
contain the
eepro100 elf image and linuxbios.rom...
Anyone see what is wrong with this picture?
-Steve
fallback.config --------------------------------------------
target ./fallback mainboard supermicro/p4dpe option USE_FALLBACK_IMAGE=1 option ROM_SIZE=524288 option ROM_IMAGE_SIZE=49152 option SERIAL_CONSOLE=1 option TTYS0_BAUD=9600 option TTYS0_BASE=0x3f8 option TTYS0_LCS=0x3 option DEFAULT_CONSOLE_LOGLEVEL=9 option MAXIMUM_CONSOLE_LOGLEVEL=6 option USE_ELF_BOOT=1 option USE_GENERIC_ROM=1 payload ../eepro100.elf option CPU_CLOCK_MULTIPLIER=XEON_X8 option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON
primary.config --------------------------------------------------
target primary mainboard supermicro/p4dpe linux /usr/src/linux-2.4.18-14 commandline root=/dev/hda2 console=ttyS0,9600 single option USE_FALLBACK_IMAGE=0 option ROM_SIZE=524288 option ROM_IMAGE_SIZE=49152 option SERIAL_CONSOLE=1 option TTYS0_BAUD=9600 option TTYS0_BASE=0x3f8 option TTYS0_LCS=0x3 option DEFAULT_CONSOLE_LOGLEVEL=9 option MAXIMUM_CONSOLE_LOGLEVEL=8 option USE_ELF_BOOT=1 option BOOT_IDE=1 payload ../eepro100.elf option CPU_CLOCK_MULTIPLIER=XEON_X8 option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON
On Fri, 11 Apr 2003, Atherton, Stephen wrote:
Linuxbios.strip is 49152 bytes, and eepro100.elf is 22368. So that gives a total of 71520...larger than 65536. So one of them is too big. Any idea which?
use those files I just sent. You need to back up the linxubios size to 40K.
etherboot has grown just a tad.
ron
Greetings,
Possibly both :-) First, try: strip eepro100.elf objcopy -R .note -R .comment eepro100.elf eepro100.strip
That should shrink it a bit. If that isn't enough, you can probably squeeze a few more bytes out of linuxbios.strip by adjusting ROM_IMAGE_SIZE in the mainboard directory's Config file. Unfortunatly the build process currently faces a sort of chicken and egg problem. The resolution is to use that variable to pick a size. Too small and the build will fail, too large and you get null padding inside the image (which can't be cut out since that would screw up jmp offsets.
Between those two things, you should be able to get the two pieces to fit neatly into the boot block.
G'day, sjames
On Fri, 11 Apr 2003, Atherton, Stephen wrote:
Linuxbios.strip is 49152 bytes, and eepro100.elf is 22368. So that gives a total of 71520...larger than 65536. So one of them is too big. Any idea which?
-Steve
-----Original Message----- From: steven james To: Atherton, Stephen Cc: 'linuxbios@clustermatic.org' Sent: 4/11/03 9:25 AM Subject: Re: Still not having success with SM P4DPE
Greetings,
It looks like the fallback image is being built wrong.
This can be hacked together manually. linuxbios.strip should be the actual LinuxBIOS code. The objective is to assemble a 64K (exactly) block containing:
- etherboot
- null padding (can be generated with dd if=/dev/zero)
- linuxbios.strip.
I just use calctool to figure out how much padding to use and cat eepro100.elf pad linuxbios.strip >fallback.bin
the 64K fallback.bin can then be appended to the primary image to get the full rom image.
That's a little ugly, but it should get the job done.
Just as a final verification, in linuxbios.map, ZKERNEL_START for the fallback image should be 0xffff0000. That is whjere it will look for the fallback etherboot. Also, it will ljmp to ZKERNEL_START-8 to transfer control to the primary image. I'm slowly trying to disentangle that on the boards I have. Unfortunatly, I don't have a P4DPE.
G'day, sjames
On Fri, 11 Apr 2003, Atherton, Stephen wrote:
Ron and James, thanks for clueing me in on the fallback image stuff.
I'm
still not quite doing something right though, it seems.
My config files are below. I based these on the samples in mainboard/supermicro/p4dpe. The fallback image is 81k and contains
the
etherboot payload...this doesn't seem right to me but I don't know
what else
to do. If I don't specify the etherboot payload, it tries to use
vmlinux
which is much, much bigger.
So I run the config script on both files, then go to the fallback/ and primary/ directories and run make, and I get a primary romimage of
458752
bytes and a fallback image of 81920 bytes. That doesn't seem right.
What
am I doing wrong? Oh and though I was doubtful, I did do a "cat primary/romimage fallback/romimage > finalimage" and burned the final
image.
Also, from the looks of the makeprocess my two image files are
basically the
same binary stuff but one has a lot of null padding. They both
contain the
eepro100 elf image and linuxbios.rom...
Anyone see what is wrong with this picture?
-Steve
fallback.config --------------------------------------------
target ./fallback mainboard supermicro/p4dpe option USE_FALLBACK_IMAGE=1 option ROM_SIZE=524288 option ROM_IMAGE_SIZE=49152 option SERIAL_CONSOLE=1 option TTYS0_BAUD=9600 option TTYS0_BASE=0x3f8 option TTYS0_LCS=0x3 option DEFAULT_CONSOLE_LOGLEVEL=9 option MAXIMUM_CONSOLE_LOGLEVEL=6 option USE_ELF_BOOT=1 option USE_GENERIC_ROM=1 payload ../eepro100.elf option CPU_CLOCK_MULTIPLIER=XEON_X8 option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON
primary.config --------------------------------------------------
target primary mainboard supermicro/p4dpe linux /usr/src/linux-2.4.18-14 commandline root=/dev/hda2 console=ttyS0,9600 single option USE_FALLBACK_IMAGE=0 option ROM_SIZE=524288 option ROM_IMAGE_SIZE=49152 option SERIAL_CONSOLE=1 option TTYS0_BAUD=9600 option TTYS0_BASE=0x3f8 option TTYS0_LCS=0x3 option DEFAULT_CONSOLE_LOGLEVEL=9 option MAXIMUM_CONSOLE_LOGLEVEL=8 option USE_ELF_BOOT=1 option BOOT_IDE=1 payload ../eepro100.elf option CPU_CLOCK_MULTIPLIER=XEON_X8 option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON
steven james pyro@linuxlabs.com writes:
Greetings,
Possibly both :-) First, try: strip eepro100.elf objcopy -R .note -R .comment eepro100.elf eepro100.strip
Actually building eepro100.zelf should be more helpful. On that side of the fence. And at least with the 5.1.7+ I don't think the strip helps at all.
Eric
-
Atherton, Stephen -
ebiederman＠lnxi.com -
ron minnich -
steven james