Attention is currently required from: Arthur Heymans, Jonathan Zhang, David Hendricks, Edward O'Callaghan, Angel Pons.

View Change

1 comment:

• File ich_descriptors.c:

  • Patch Set #3, Line 952: Ibex Peak is historically used as the default

    I wouldn't say "should" but it definitely could.

    Exactly, and that's why we're in this huge debate ;-) This ambiguity of intentions is exactly why we should match values (or ranges) to a specific chipset whenever possible, and document why the default value was chosen, especially if it's not the newest platform anymore.

    David, it's not about intentions at all. It's about what silicon
    vendors will provide (in the future) and what will match the
    situation best. Hence it will always be a "could", because it
    depends on decisions made outside of this project.

    
    >
    > Personally, as this branch seems complex enough already, I'd
    > first check if there is no easier way to distinguish server
    > descriptors from client ones.

    I actually did spend some time looking at this, and unfortunately there does not appear to be a reliable way. Intel does not version the IFD (AFAIK), and for the most part the layout is similar.

    The most obvious difference I saw is that server chips tend to have a large ISL value (more straps) compared to non-server chips.

    However, the SPI IP block seems common among client and server chips. We even call the chip enable function `enable_flash_pch100_or_c620()`.

    
    Also, please note that everything done about Emmitsburg so far
    (including what I wrote above) makes the assumption that it's
    right to return _LEWISBURG for it. I don't know if that is
    correct.

    Yes, LBG and EBG are very similar for flashrom's purposes just like Lynx Point and Wildcat Point. Read, write, and erase using layouts has been done a lot at this point.

    Well, see my other comment on the original patch. At least wrt. to
    the code in ichspi.c, EBG seems more closer to the newer client
    chips. I can't say if that is also the case descriptor-wise. But
    maybe, to correctly reflect the hardware situation, it might even
    be better to add a new enum value. I don't know if. But if you
    really care about maintainability as you just stated on the
    normalization patch, you should look into it, IMHO. Flashrom is
    much easier to maintain when the patch that adds support for a
    new platform actually matches the hardware.

To view, visit change 57635. To unsubscribe, or for help writing mail filters, visit settings.