On 30.06.2010 16:36, Stefan Reinauer wrote:
> On 6/30/10 4:16 PM, Carl-Daniel Hailfinger wrote:
>
>>> 15kb lzma compressed is nothing.
>>>
>>>
>> 8 kB more or less in a recovery payload of a coreboot image are not
>> negligible IMHO.
>>
>> In normal OS environments people don't use compressed binaries, and
>> there a 2 MB size increase for flashrom (98% of it for dead code which
>> can't be optimized away by the compiler/linker) is definitely something
>> people will object to.
>>
>>
> Well...
>
> - once we have a recovery payload (which will have to load a 1MB rom
> image from _somewhere_ as we speak of size) and
>
If it is recovery over serial at 115200 bit/s (14 kByte/s), 2 MB more or
less make a difference. However, if that recovery loader also has
decompression support, that's different.
> - once we have people complaining
>
> we should definitely think about such optimizations. My bet is by then
> anything below 8mbit flash parts has died out. :)
>
I hope the same, but I'm not as optimistic as you are.
>> IMHO the {EOT} markers should be killed in libsuperiodetect, at least
>>
>>>> for the LDNs. Such an operation would have increased the size of the
>>>> patch and would have reduced readability as well. Due to that, I skipped
>>>> it, but I plan to do that in a later operation.
>>>>
>>>>
>>> What would you use instead? The array members all have different sizes
>>> as far as I can tell, so some kind of end marker will be needed.
>>>
>>>
>>>
>> The libsuperiodetect case doesn't care about LDNs at all. Having exactly
>> one LDN definition per Super I/O which is always EOT looks like dead
>> code to me, especially if nothing is looking at the LDN.
>>
>>
> Maybe using the tables from superiotool is not the best way to solve the
> problem you are trying to solve at all?
>
> What is that problem anyways? Since flashrom has mechanisms to figure
> out the board, and the super io is a hard component on the board, will
> you need anything more but the numeric ID of the chip?
>
Good point.
Many mainboards use Super I/O chips to translate flash buses, usually
LPC->SPI for newer boards and LPC->Parallel for older boards.
A few months ago, we had to handle every single board with such a
feature with a board enable, and the board enable table grew fast, even
for boards which didn't need any GPIO twiddling for write enables. Since
then, flashrom has evolved to autodetect ITE IT87* LPC->SPI translation,
and this allowed us to support a few dozen boards out of the box without
any board enables. flashrom has a few pending patches which add
autodetection for ITE and Winbond LPC->Parallel translation, and those
patches will allow us to kill a dozen board enables, and hundreds of
boards will start working automatically.
For automatic Super I/O probing to work well, I'd like to reuse some
proven code instead of rewriting the whole probing stuff from scratch.
Two possible sources of code exist for this:
- superiotool
- Linux kernel
Superiotool focuses on more recent (less than 12 years old) chips,
whereas the Linux kernel focuses on chips from the 90s. Both codebases
get some testing, and superiotool is regularly extended to support new
chips.
So flashrom needs the probing, and it also needs a function in each chip
definition which takes care of handling any translation functionality.
With that in mind, I picked the #ifdef solution because it would have
allowed me to simply run unifdef over the superiotool source code, then
import the generated files into the flashrom source without manual editing.
OTOH, I could write a Coccinelle semantic patch which eliminates the
need to touch any chip definitions in the superiotool source, and simply
run the semantic patch locally before copying over the patched files.
Printing the name (instead of a cryptic ID) of the detected Super I/O
chip is just for user friendliness.
>>>> {
>>>> uint8_t id, rev;
>>>> +#ifndef LIBSUPERIODETECT
>>>> uint16_t runtime_base;
>>>> +#endif /* ! LIBSUPERIODETECT */
>>>>
>>>>
>>>>
>>>>
>>> @@ -765,7 +803,9 @@
>>> Maybe this could be moved downwards to where it is used, to save an ifndef?
>>>
>>>
>>>
>> IIRC this would break on some compilers which don't allow variable
>> declarations in the middle of some code.
>>
>
> Ok, which ones of them are supported for compiling flashrom?
>
Well, it breaks if we specify -std=c90 or -ansi to gcc, and superiotool
has -ansi in the Makefile.
> The way superiotool defines functions also breaks K&R style.
>
I won't comment on coding style in superiotool because I haven't touched
it for quite some time, and coding style discussions usually lead to
frustration.
I hope my mail helped to clarify the goals I want to achieve.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
