On 01.02.2010 17:12, Stefan Reinauer wrote:
On 2/1/10 5:41 AM, Carl-Daniel Hailfinger wrote:
Stefan: Could you please test this one on Mac OS X? In theory it should even allow us to kill the start=0x400 special case for Mac OS X.
Sorry I don't have a machine with OSX and coreboot table at my disposal right now, but on my macbookpro I get this:
flashrom v0.9.1-r888 Mapping low megabyte at 0x00000400, unaligned size 0xffc00. Mapping low megabyte, 0xffc00 bytes at unaligned 0x00000400. No coreboot table found. sh: dmidecode: command not found Found chipset "Intel ICH8M", enabling flash write... OK. This chipset supports the following protocols: FWH,SPI. Calibrating delay loop... OK. Found chip "SST SST25VF016B" (2048 KB, SPI) at physical address 0xffe00000. === This flash part has status UNTESTED for operations: ERASE Please email a report to flashrom@flashrom.org if any of the above operations work correctly for you with this flash part. Please include the flashrom output with the additional -V option for all operations you tested (-V, -rV, -wV, -EV), and mention which mainboard or programmer you tested. Thanks for your help! === No operations were specified.
However, I'd prefer a 1 line special case over adding 64 lines to the normal case for the reason ;-)
Thanks for testing.
The problem was that the mapping failed on some Linux machines because the kernel detected a mismatch between the PAT/MTRR (cached write-combining) and the requested mapping type (uncached) for the coreboot tables. That's why I introduced all the special code (a one-liner wouldn't have worked). The side effect of being able to use start=0x0 in the cbtables code under OS X is just a lucky coincidence.
For me, three things are important about this patch: 1. Does it fix the mapping on some Linux kernels/machines? 2. Does it still work on previously working Linux machines? 3. Does it still work on Mac OS X?
So far, at least requirement 2 seems to be fulfilled.
Regards, Carl-Daniel