<br>Hi.<br><br><div class="gmail_quote">On 8 February 2013 16:44, Stefan Tauner <span dir="ltr"><<a href="mailto:stefan.tauner@student.tuwien.ac.at" target="_blank">stefan.tauner@student.tuwien.ac.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 8 Feb 2013 11:08:21 +0100<br>
Mark Marshall <<a href="mailto:markmarshall14@gmail.com">markmarshall14@gmail.com</a>> wrote:<br>
<br>
Hi Mark,<br>
<br>
> The other problems are:<br>
> - That most of flashrom seems to be limited to 2^24 address bits.<br>
>   (this is relatively easy to fix)<br>
<br>
We will see about that :) We are of course aware that this is needed<br>
quite soon. Do you want to help us with this (mostly testing, but if<br>
you like you can also try to create the needed patch)?<br></blockquote><div><br>I've got some patches that work here, but one of them involves just<br>commenting out the code in spi.c::spi_chip_read!  I don't really understand <br>
what it thinks it's checking for (which isn't strictly true, it seems to be to do <br>with accessing the flash through a memory window, which happens for a<br>motherboard BIOS.)<br><br>I'll neaten them up and post them next week.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> - That flashrom thinks a page is always 256 byes (I think I've found<br>
>   most cases of this, but I'm not sure.  What's the granularity flag<br>
>   for?<br>
<br>
The flag is there to fix exactly this :)<br>
See also <a href="http://patchwork.coreboot.org/patch/3757/" target="_blank">http://patchwork.coreboot.org/patch/3757/</a><br>
Not many chips need this and so we never moved into this direction...<br>
do you really need it?<br></blockquote><div><br>I don't know if I need it.  I guess not actually, as my page size is 512, <br>and it should all work with the code for 256?  It might be faster as 512, but I<br>don't care about that small difference.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> I've also found that flashrom doesn't always do what I expect, and I'm not<br>
> sure if this is<br>
> by design or not.  for instance, if I want to erase my entire flash chip,<br>
> it ends up calling<br>
> the sector erase on each sector, not by doing a chip-erase?  Are these<br>
> types of things<br>
> written down anywhere?<br>
<br>
We try to erase the smallest possible blocks first (in order of the<br>
eraser array of the chip definition(s) in flashchips.c. This potentially<br>
allows to skip writing of block as explained above. It is of course<br>
rather useless for the -E/--erase operation, but the code is shared and<br>
no one complained yet IIRC (or sent a patch). Most of these details are<br>
not documented I think, but some are (in the manpage). Patches for the<br>
manpage are welcomed. Everyone is invited to edit the wiki too :)<br></blockquote><div><br>I was wondering about creating a more detailed structure of both the contents of <br>the ROM and the (set of) files that the user was trying to program.  Then we <br>
could read back from the flash only for the bits that we needed. Any thoughts?<br><br>Thanks for your help, and I'll try to post more next week.<br><br>Regards,<br><br>Mark M?<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888">--<br>
Kind regards/Mit freundlichen Grüßen, Stefan Tauner<br>
</font></span></blockquote></div><br>