i get an error when using: BOOTUTILW64E.EXE for flashing iPXE into an Intel® Gigabit-Ethernet-Controller 82574L EXPI9301CT 8086:10d3
with a winbond 25x40 CLING SPI Flash Chip 4M-bit/512K-byte (524,288)

did a git clone today and without modification "make bin/808610d3.rom"

I do recall vaguely the message on the mailing-list you refer to above, but the details have eluded me. Hopefully the information above combined with all the information in that ML thread above should help. I do recall some hex-editing of the header was required to make it work properly.

i have looked up this tip>
The kernel itself has protections enabled to make it more difficult to become compromised.

0-address protection

Since the kernel and userspace share virtual memory addresses, the "NULL" memory space needs to be protected so that userspace mmap'd memory cannot start at address 0, stopping "NULL dereference" kernel attacks. This is possible with 2.6.22 kernels, and was implemented with the "mmap_min_addr" sysctl setting. Since Ubuntu 9.04, the mmap_min_addr setting is built into the kernel. (64k for x86, 32k for ARM.)

I went searching in my #ipxe IRC logs, and found this line from mouse in 2014:

Quote:20140519-075533Z #ipxe: <mouse> BTW, do you have spec / tool to create FLB file from Option ROM to flash it via bootutil? current bootutil doesn't accept option rom as is. I've made a workaround by saveimage, cut the FLB header and glue it with iPXE option rom.

and again reiterated by mcb30 a while later

Quote:20140821-000836Z #ipxe: <mcb30> a) use an older version of bootutil
20140821-000848Z #ipxe: <mcb30> b) use flashrom (if it supports your NIC) instead of bootutil
20140821-000912Z #ipxe: <mcb30> c) try mouse's hint that "bootutil required FLB format only. Raw Option ROM is not accepted. To workaround just saveimage, cut the header and prepend it to the iPXE Option ROM. Then everything started to flash and work"

So maybe you should try option C and see how that works out for you. I'm not sure what the format of the FLB header is, but you'll have to compare the raw option rom with the .flb file generated by saveimage, and then you'll hopefully figure out which byte index the raw option rom image starts and the FLB header ends.

Best of luck! Please document how you did it here if you actually figure it out.

but how to encapsulate the rom in the container is far from my knowledge (yet)
more information on FLB format:

Code:

IBABUILD EXAMPLES:
------------------
IBABuild is generally used in three different scenarios:

- To create an image file or files to be programmed into flash, either as
part of the NIC manufacturing process, or as part of the BIOS programming
process for LOMs.
- To create and program an image directly into a NIC.
- To program an arbitrary image file into a NIC.

While it is possible (and perhaps even probable) that IBABuild will be used
in other ways, these three scenarios capture the vast majority of IBABuild
uses.

A few examples of each scenario are given in this section. These examples
are not intended to be comprehensive and will not cover every possible
combination of IBABuild parameters. They are simply intended to illustrate
how the various parameters are used.

To create an image file containing SETUP, UNDI, and BC for use in a NIC based
on the 82540EM Ethernet controller:

IBABUILD -OF=NIC -IMAGE=SETUP,UNDI,BC -DEVID=100E

The output of this command is the file name BA????L2.NIC, where ???? is the
Intel Boot Agent version number for Gigabit adapters.

To create a minimum-size split ROM implementation for a LOM implementation of
the 82551QM Fast Ethernet controller:

IBABUILD -OF=LOM -IMAGE=BC
IBABUILD -OF=LOM -IMAGE=UNDI -DEVID=1229

These commands will create two files: BA????BC.LOM and Ba????X2.LOM,
where ???? is the Intel Boot Agent version number for Fast Ethernet adapters.

To program an UNDI/SETUP/BC image into all NICs in the system:

IBABUILD -ALL -IMAGE=UNDI,BC,SETUP

To program the file FOO.FLB into a NIC:

IBABUILD -NIC=1 -UPDATE=FOO.FLB

APPLICATION NOTE:
-----------------

The FLB file format allows up to 16 supported device IDs to be included in
the FLB file header structure. In order to support more than 16 device IDs,
Windows PROSet allows FLB images to be concatenated together. This is
accomplished by using IBABuild to generate two FLB images with support for
up to 16 devices each, and then concatenating the FLBs together using the
"copy" command as follows:

- UNDI may be put in a LOM image without BC. (This is the other half of a
split image.)

- Unless it is completely alone in a .LOM (split) image, BC must always be
accompanied by UNDI.

- If the image is .NIC, .FLB, or .HEX, and UNDI is present, BC must be present.

IMAGE FILE NAMING CONVENTIONS:
------------------------------

In order to be able to easily identify various versions of the boot agent for
different adapters, the flash image file name contains information about its
contents. The file name has the following format:

BAxyzztn.eee

where: x is the major version number of the agent in decimal
y is the minor version number of the agent in decimal
zz is the build number of the agent in decimal
t is the type of image
n is the adapter family the image supports
eee is the type of image file

Good research you've done there. Using dd you should be able to easily rip the FLB header out of the backup.flb file. Then you just take note of the size of the ipxe rom and use cat to glue the two files together (cat header.flb 80861503.rom >80861503.flb). Then you finally open that FLB file open in a hex editor and change those bytes you need to change (size and version). Once you've done this manually and verified that it actually works then we can look into automating this.

Why do you need to change the version number? None of the documentation you've pasted explains why you need to do that.

(2015-07-14 20:09)robinsmidsrod Wrote: Why do you need to change the version number? None of the documentation you've pasted explains why you need to do that.

i don't know if it is necessary. just copied from the thread i found.
i will try this tomorrow. lets see if we can get it to work.
after just adding the header without modification the tool accepts the file but raises cpu to 100% and hangs
i really need to learn offsets

[SOLVED]
save rom in container and raw rom from card:
BOOTUTILW64E.EXE -nic=1 -SAVEIMAGE -FILE=backup.FLB
BOOTUTILW64E.EXE -nic=1 -SAVEIMAGE -FILE=backup.NIC
note down size of backup.nic
extract header:
dd if=BACKUP.FLB bs=1 count=378 of=header.flb
make bin/808610d3.mrom (You have to use Mrom format)
utils/./padimg.pl --blksize=(size of backup.nic) --byte=0x00 808610d3.mrom
cat header.flb 808610d3.mrom > 808610d3.flb
BOOTUTILW64E.EXE -nic=1 -RESTOREIMAGE -FILE=808610d3.flb
sample file can be downloaded from http://www.behead.de/808610d3.flb
sample header: http://www.behead.de/header.flb
i used this method because i was not able to correctly modify the header so i padded the file to be the exact same size as the original image and just added the header.
in theory this should work without the size limitation of the original file.

Good testing! At least this gives us the option of making an iPXE ROM that is the same size as the Intel ROM. What was the size of backup.nic in bytes? I guess the next step is to actually figure out how to add a ROM with arbitrary size (within padding and max restrictions).

(2015-07-17 22:05)robinsmidsrod Wrote: Good testing! At least this gives us the option of making an iPXE ROM that is the same size as the Intel ROM. What was the size of backup.nic in bytes? I guess the next step is to actually figure out how to add a ROM with arbitrary size (within padding and max restrictions).

it was not possible for me to do the same with a little embed script (fits of course still into the size of backup.nic). the application hangs again. do you know how embed scripts are handled internally?

Well, 69632 = 65536 + 4096, so 68KB. That's an odd size for a ROM, but at least it is aligned on a 4K boundary, which I'm guessing is the requirement. Using util/padimg.pl with a blocksize of 4096 should give you a viable ROM, I'm guessing. But if you end up with something larger, then you'll still need to modify the size value in the header.

I just stumbled upon this thread while trying to flash my 82574L, and I thought I'd report my findings for anyone else that makes their way here.

Unfortunately, when I was trying to use the directions that jrsmile posted, BOOTUTILW64E.EXE just ended up hanging. In retrospect, this was probably because the new image was larger than the old one and I didn't bother to change the size in the .flb header. In any case, instead of investigating the .flb problems, I tried to troubleshoot why flashrom wasn't working correctly (I was getting the same error that jrsmile mentioned on Mint).

It turns out that if your kernel is configured with CONFIG_STRICT_DEVMEM=y, flashrom won't work. So I ended up re-compiling my kernel with it disabled, and flashrom lit up. I had to use a pretty recent build of flashrom to get support for the 82574L, by the way.

From there, I read the ROM contents (total of 512K) and looked around for PXE code using "cat backup.bin | xxd | less". I found that the PXE code started at offset 0x2000, so I dumped the contents of 808610d3.mrom at that point (which overwrote all of the original PXE code) using some "dd" shenanigans. After I wrote it back to the card with flashrom, everything lit up!

iPXE briefly shows up during BIOS initialization (where IBA used to initialize), and I have an iPXE entry in my BIOS boot menu, which works as expected.

I know it has been a while but any update on automating this. It appears the new versions of bootutil don't accept .rom images and creating the .flb with the header + mrom seems very error prone.

I just tried doing this on my system and ran into 2 problems.

1) backing up the nic's .flb and .nic files was "unsupported" according to bootutil
2) After creating the .flb file and attempting to flash the rom bootutil just hangs. I'm not sure if it's working or broken yet.

Would be great if the wiki could be updated and hopefully a make target for .flb files for intel nics.

(2016-12-30 08:42)jgarr Wrote: I know it has been a while but any update on automating this. It appears the new versions of bootutil don't accept .rom images and creating the .flb with the header + mrom seems very error prone.

I just tried doing this on my system and ran into 2 problems.

1) backing up the nic's .flb and .nic files was "unsupported" according to bootutil
2) After creating the .flb file and attempting to flash the rom bootutil just hangs. I'm not sure if it's working or broken yet.

Would be great if the wiki could be updated and hopefully a make target for .flb files for intel nics.

I know that it has been awhile since this topic has been looked at, but as it is the first result when you search for some of these errors, I thought I would share my experiences.

I also was getting the same errors and jgarr and found that the dos utility in FreeDOS was unable to do anything with the NICs in one of my machines. I was unable to saveimage the ROM (Unsupported) nor was I able to flash the ROM. However if you boot into the EFI shell and then use the x64-EFI version of bootutil from the current preboot.exe from INTEL, everything works as expected.

Hey.
I know that this topic is very, very old, but I think I should share my experience.
Background: my network card, based on the NIC 82574L, built into the Intel D2500NN motherboard, died for an unknown reason after changing OS from Windows to Linux Ubuntu Desktop.
The BIOS did not show the mac address of the network card and Windows Device Manager showed "error code 10".

I came to the conclusion that the memory was somehow damaged by the EEB. Fortunately, I had another exactly the same motherboard,
so I was able to dump the EEBOOM memory image from the working motherboard and flash it into a non-working one.
Since I spent a large amount of my free time on this, I want to help people who will follow my path.
I'll attach the utility for flashing Intel NIC's and the EEPROM image for 82574L.
I have replaced the MAC address with zeros (Its the first three bytes of EEPROM image). You can put there your own, or flash EEPROM without affecting yours with special command on EEUPDATE tool.
Wish you good luck.