Stefan Reinauer stepan@openbios.org writes:
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 don't recall exactly but look at the code in lbflash does. I believe there is a pointer to where the vendor and part are.
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.
The problem is that over time hardware people get inventive. So I'm not certain that is possible.
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.
Agreed. But having code that works everywhere is useful.
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.
Agreed.
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?
Yes. There is a directory with all of that.
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.
Right now as long as the image is small enough it fits in 4Mbit it will happily flash in either a 4Mbit or an 8Mbit part.
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.
Yes and no. Having a directory with all of the pieces is useful, and is a lot more maintainable from a forward/backwards compatibility point of view. If we combine them I would rather do it as a cpio or a tar or an rpm. Something where the structure is apparent but you have to try to work at it to get multiple files.
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 am conflicted on that one. If you are talking users and not developers it is usually easier to ensure that people have the right mtd drivers loaded. Last I looked the mtd code had a much better structure than flash_and_burn, allowing for much more code reuse and a lot more eyes looking at the problems. flash_and_burn on the other hand seems a great tool for developers, who know what should be happening but it doesn't seem to have as many checks to make certain that you aren't doing something stupid.
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?
Groan. It looks like someone forget to place the source rpm on the public ftp site. 2.1 is pretty much a maintenance release with the exception of a couple of very minor bug fixes nothing really has changed. So for getting a feel of the structure and the files we are currently using 2.0 should be reasonable starting point.
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.
Sure I don't have a problem with putting a checksum, crc or a hash in a data segment somewhere. It will likely take an extra linker pass to do that but that shouldn't be a problem. Ideally that would be one of the triggers for deciding if we go to fallback or normal mode.
Hmm. In looking at things I just noticed that the decompressor doesn't have anything like that, which really is a bug. That I unfortunately didn't catch when I found that code.
Eric