* Eric W. Biederman ebiederman@lnxi.com [051112 22:27]:
void show_id(unsigned char *bios, int size) { unsigned char *manuf, *id; id=bios+size-0x1d; while (*id==0) id--; while (*id) id--; manuf=id-1; id++; while (*manuf && *manuf!=0xff) manuf--; manuf++; printf("MANUFACTURER: %s\n", manuf); printf("MAINBOARD ID: %s\n", id); }We have on most boards id.lds That places that information at a magic location. Unfortunately that conflicts with nvidia chipset requirements. And I think in the general case and fixed location will be a problem.
The above will fail on nvidia. Agreed.
The next problem is that the id is relative to the end of the image. So the start position changes a) dependent on the chipset b) dependent on the length of the motherboard manufacturer and id.
NVIDIA:
SECTIONS { . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end - __id_start); .id (.): { *(.id) } }
Others (src/arch/i386/lib/id.lds) SECTIONS { . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start); .id (.): { *(.id) } }
the arima hdama image looks like this: 00000000fffdffd8 R __id_start 00000000fffdffd8 r vendor 00000000fffdffde r part 00000000fffdfff0 R __id_end
only the last 16 bytes don't belong to the ID.
funny enough, linuxbios.rom contains this:
007ffd0: ffff ffff ffff ffff 4152 494d 4100 4844 ........ARIMA.HD 007ffe0: 414d 4100 2800 0000 2200 0000 0000 0200 AMA.(..."....... 007fff0: e9b5 49ff ff00 0000 e903 4aff ff00 0000 ..I.......J.....
So where does the 2800 0000 2200 0000 0000 0200 come from?
Does the linker put some crap in there after the ID?
This makes it really hard to do a decent identification, even if we know where the ID should/could be.
I would also suggest that on a given cpu architecture (ie. x86 or ppc) the ID string should either be at a fixed address, one that suits all chipsets. Or It should be identifyable in flash using a signature, similar to the LinuxBIOS table in memory.
My basic concern is that I don't think we can do this inline across variations in architecture.
If such a in-rom table differs in position or details between x86 and ppc, this won't be too nasty.
Although I don't have a problem exporting such information from the linuxbios table which should work universally but it won't work for the first we flash something.
I agree. Putting this in the LinuxBIOS table would be fine to probe the running system. I rather plan for the case where there has never been a time with a non-linuxbios image in flash.
Please checkout our latest version of lbflash ftp://ftp.lnxi.com/pub/linuxbios/utilities/lbflash/
We have a working map. The code works well enough that we can deal with multiple flash chips and other weird cases automatically.
I've looked at this. Do you deliver this map as an extra file with an image? Having this in the image would help comparing the map of an file image to that of the rom image for example. I.e. you have two versions of a board out there, one with 8MBit flash and one with 4 MBit flash. Someone has a 512kByte flash file. Is this the normal image of case 1 or a complete image of case 2 etc pp.
I'd rather give them a cat rommap linuxbios.rom > linuxbios.flashimage than 2 different files to cope with because I bet someone will mix this up some time. It's just not solid.
The ideal case is if we could start converging flash_and_burn and lbflash. At least with respect to user interface.
I've looked at lbflash earlier today. It seems to be using mtd for all it's actions while flash_and_burn uses /dev/mem and some extra magic. Then there's my old and obsolete /dev/bios. I want to drop that one at least and rather have an improved solution in userspace.
MTD is overly complex for what we are doing. and flash_and_burn has been working really reliably for me.
I also saw you have a newer lbflash version available as a binary than as source. Unfortunately there's no changelog in the binary rpm. Is it worth waiting for that source release?
The case that isn't currently covered is a checksum and that is only because it keeps slipping my mind. We do perform a full byte for byte comparison against the source file though. Which is good to ensure you have flashed successfully but it doesn't detect if your romimage got damaged in transport.
In safety critical environments a system is required to deny service if it can't proof it's own integrity during runtime. Lots of systems even probe flash and memory continuedly during runtime to find bit tilts within a really short manifestation time.
Stefan.