* Eric W. Biederman ebiederman@lnxi.com [051113 09:33]:
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?
Looking at crt0.s it is not crap but really useful: The linker places pointers to the string so we actually don't have to walk backward. I could not find this in the code, but I consider it can be used:
int show_id(unsigned char *bios, int size) { unsigned char *manuf, *id; unsigned int *walk;
walk=(unsigned int *)(bios+size-0x10); walk--; printf("image size=%d\n", *walk); walk--; id=bios+size-*walk; walk--; manuf=bios+size-*walk; printf("MANUFACTURER: %s\n", manuf); printf("MAINBOARD ID: %s\n", id); return 0; }
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.
Though, matching a file image with what is in a certain system is absolutely necessary if we want to establish LinuxBIOS as a usable product for end customers.
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.
There will always be small differences, such where the image is located and where the entry point is loaded. As long as there's a good mechanism making it easy to get this information in one way we're fine. The LinuxBIOS table is slightly different on ppc and x86 already today.
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.
So you could flash a fallback only image over a fallback+normal image without lbflash ever complaining.
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.
Probably true.
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 would agree if mtd did the autoprobing and flash_and_burn didnt. But finding the right pair of mtd drivers can be annoying. The modular concept is nice, no doubt. But for an end user I don't really see an advantage.
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.
Ah, I assumed that you would only provide the source for older releases, same for the cmos tool. Which would be perfectly understandable. So I will have a closer look at lbflash. How do you produce the rom tables?
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.
Hey, it's really small. In a safety critical application we might not even want to go to fallback mode but rather print an error message over serial and go to nirvana in case of a wrong checksum. Just wondering where the best place for such a checksum check would be anyways. I would not want to cope with this in ramless code I guess.
Stefan