Any reason your trying to do this the hard way?
If you download the latest code stack
you run STARTUP.NSH, the BIOS, ME BMC and FRUSDR code will all be updated with the system prompting you asking if you want to modify the FRU data fields. (if you selected "Update only the FRU" or "Update both the SDR and the FRU")
When the "Do you want to update the product info area of the FRU" prompt is displayed it will asked you if you want change the board PN and serial number
Any areas you say No to will not be modified.
If you do not want to update all the code for some reason the FUR24.nsh will just do the FRUSDR files.
The correct command is FS0:>frusdr -cfg master.cfg (which is what both these NSH files run)
(I suspect you may have tried a different command and perhap wiped your FRU data (Board SN, Part Number and Mfg. Date/Time blanked?) )
(This can be fixed also, but it a little more involved)
The only reason to modify the master.cfg file is if you want to make a change to a group of boards automatically.
The UR_BMC.fru file should never get modified since it is the template file.
You can look for the section near the end of the master.cfg
// FRU file or asset tag programming
This is the part of the scripts that sets the variables for updating and could be changed to write a group of the same part numbers or the same serial number to many boards(????)
Yes, there's a reason I want to modify the master.cfg file, but let's ignore that for the time being.
The key part of your comment is "Any areas you say No to will not be modified." Unfortunately, that's not the case. It doesn't ask you any questions about the Board area of the FRU (really, it shouldn't be changed), but if you run that script, it will wipe out the board serial number, part number and manufacturing date and time anyway. This is starting to look like a bug to me. It looks like it's updating it with the content of the UR_BMC.fru file, which obviously leaves those fields blank. Looking at the master.cfg script, it shouldn't touch those fields, yet it does.
There's another way to access the FRU without relying on UR_BMC.fru. This is also described in the master.cfg file (the part where you want to only modify the asset tag). This is the relevant portion of the script:
FRUNAME "SYSTEM"FRUADDRESS "IMBDEVICE" FF 20FRUAREA "PRODUCT"FRUFIELD "AT" "@STDIN:ASCII"
The difference is that it uses FRUNAME "SYSTEM" instead of FRUNAME "UR_BMC.fru".
Well, this part of the script doesn't work. You'll get an error if you select to only update the asset tag. Digging through PDF files for older motherboards on Intel's website, I found out that the line FRUADDRESS "IMBDEVICE" FF 20 should read FRUADDRESS "IMBDEVICE" 00 FF 20. The 00 is for the LUN address. Once I added that, things started working and I can update the fields I want without touching the rest (at least I believe so, I'm not done with this yet).
So there are several bugs here. Accessing the FRU as above is missing the LUN address. Referencing the UR_BMC.fru seems to overwrite the board serial #, part # and board mfg date and time, even though those fields are not asked to be refreshed in master.cfg.
If someone at Intel reads this, perhaps, you could look into it.
Just tried it with the current code stack and can not reproduce your issue.
Board areas are not updated or changed during normal update process
Product area and Chassis areas update correctly also.
Are you running the FUR_24.NSH program or are you manually using a command line?
If command line, what command are you typing?
You say " but if you run that script," which script are you running and how?
If you are running any commands or making edits that includes the the file name "UR_BMC.fru", you are telling the system to skip the master.cfg and overwrite with the template file which will wipe the Board part number, the board serial number and the manf. date.
I can provide you with a script to restore the manf date on your board, but would need the board serial number off the mother board tag to look up the manf date.
I would also be glad to assit with what ever modifications you are trying to do to the master.cfg.
FRU DATA.pdf 418.8 K
Ok, I'm not 100% sure the LUN address is needed anymore. What I'm finding is that the FRU isn't always accessible. It can be a bug, a hardware issue, I2C flakiness... So the script sometimes work, sometimes doesn't...
The wiping out of the motherboard serial number, part number and mfg date and time is still an issue though (when using the UR_BMC.fru) file.
I am using the latest Firmware Update Package and I use FUR24.nsh.
So I just tried it on another machine and this time, the board info didn't get wiped.
I can't explain it. The machine I used to test this kept wiping it every single time. I'm not sure what's going on with it.
Doc, you said above:
"If you are running any commands or making edits that includes the the file name "UR_BMC.fru", you are telling the system to skip the master.cfg and overwrite with the template file which will wipe the Board part number, the board serial number and the manf. date."
That's not so. And you showed that in your screenshots too. It doesn't say FRUFIELD "P#" or FRUFIELD "S#" after FRUAREA "BOARD" in master.cfg, so they shouldn't be wiped, even when using UR_BMC.fru, which master.cfg does use.
Anyway, my changes to master.cfg work fine assuming the FRU can be accessed just fine, which seems to be hit or miss on some motherboards. This is something we also see in linux using ipmitool. It doesn't always work, seemingly at random.
Thanks for looking into it. I'm gonna try on more motherboards to get a larger sample size.
I've had another board get its serial number, part number and mfg date/time wiped when trying to update the FRU.
The label on the motherboard is BZUB02506623 PBA E22554-750
Can you provide any help with recovering the missing data? Thanks in advance.
For the record, there are 2 ways to access the FRU from master.cfg.
Either FRUNAME "UR_BMC.SDR" followed by the FRUAREA and FRUFIELD tags.
Or FRUNAME "SYSTEM" followed by FRUADDRESS "IMBDEVICE" FF 20 followed by the FRUAREA and FRUFIELD tags.
The first method seems to always work, but it's the one that sometimes overwrites my board info. It also requires every FRUAREA tag to be defined in master.cfg, even though I'm only updating the Chassis area of the FRU (otherwise it exits with an error)
The second method does not always work. It does not require me to specify every FRUAREA tag (at least no error is generated).
I'm kind of at a loss as to why some things fail at random times without any pattern to the failures. It's quite possible we have other I2C devices present on the bus that are causing this instability (other than the motherboard). I have not been able to narrow it down to a specific root cause yet.
Has anyone seen unstable I2C behavior on the S5520UR motherboard?
I also have a quick question. When using syscfg to save/restore BIOS settings, it doesn't seem to take the "USB Boot Priority" setting into account (it's on the same screen as where the Boot Order gets set). Any idea?