On Fri, 19 Jul 2013 19:24:36 +0400 Антон Кочков anton.kochkov@gmail.com wrote:
Just downloaded flashrom trunk and tried to read http://paste.flashrom.org/view.php?id=1695 - as you can see it fails
very interesting result (with r1701). Thanks for testing that. Can you please test r1700, and if that does not help r1697?
On Fri, 19 Jul 2013 19:17:44 +0200 Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
On Fri, 19 Jul 2013 19:24:36 +0400 Антон Кочков anton.kochkov@gmail.com wrote:
Just downloaded flashrom trunk and tried to read http://paste.flashrom.org/view.php?id=1695 - as you can see it fails
very interesting result (with r1701). Thanks for testing that. Can you please test r1700, and if that does not help r1697?
Carl-Daniel explained what happens on IRC:
"there is an old standard (never mentioned anywhere, but tradition for all 32bit capable chipsets since forever). the agreed-upon convention is that the ROM mapping window is exactly 16 MB big, and top-aligned to 4G. for LPC/FWH, there's also the convention that (from top of the window to bottom of the window) you have 4 MB flash space, 4 MB register space, 4 MB flash space, 4 MB register space. this also means the BIOS usually tells the OS that the top 16 MB are reserved, but stuff below the top 16 MB may be marked as unused or unusable. and there are some newer standards which place certain mmapped registers directly below the top 16 MB. so even on SPI chipsets, mapping more than 16 MB is simply impossible. and if it works, the SPI chip wouldn't be completely accessible; you only get the last 16 MB of a bigger flash chip."
The good news is that we do not face some weird problems with C types and that I am aware of yet another detail to fix for big flash chips. The bad news is that we can not even probe for those large chips on some chipsets and since we can not easily control this have to remove them for now. This shouldn't be a huge problem for anybody....
Thanks a lot for noticing this problem before we tagged 0.9.7 :)
-
Stefan Tauner