On 08.02.2008 17:21, Chris Kilgour wrote:
Carl-Daniel Hailfinger wrote:
Please be aware this is all completely untested; there could be plenty of typos and plain-old mistakes inside. The binaries produced should be considered unstable and experimental. Use them at your own risk!
I will try to take a look ASAP. The optimal case would be that the original and modified sources compile to an identical binary or at least a binary with perfectly explainable differences.
The VSA sources are a mix of assembly and C code. The binaries will be quite different because (naturally) gcc will produce different machine code than Microsoft C from the 16-bit era, and all the assembly-coded functions are now using GNU __attribute__((fastcall)) rather than "MS pascal" calling convention. Also, the final link output will have the various bits and pieces in different locations. So a straight binary diff will exhibit mostly differences.
Understood.
That said, I took the time of locating and disassembling the assembly functions from OLPC VSA blob and comparing against the output of the assembly functions from my build (by far the biggest risk because of all the manual modifications I made), and the differences were all explainable in light of the above. For the C code I felt it was way too hard to even attempt such an approach.
Thanks for investing the time to verify the differences.
Within the tarball there is a file modification_notes.txt that highlights what I have done. I'm hoping to foster some discussion on a testing approach that lays somewhere between manual inspection and slapping the open-tools blob into a coreboot ROM and crossing our fingers...
I fear that for most of us the only way to test is to burn the generated VSA into a ROM and start the machine. However, I have to admit I didn't read the modification notes you supplied. I will read it.
Regards, Carl-Daniel