Dear Dave,
Am Sonntag, den 15.12.2013, 09:27 -0700 schrieb Dave Frodin:
I'm still planning on reading the SPD values from a text file in the mainboard directory.
that is the same way, the Google boards are currently doing it [1], right? The SPD-hex-files in the board directory are listed in a Makefile. Can you use the same mechanism for AMD boards instead of your current library approach [5]?
This implementation was pushed with the Chromebook Butterfly without any discussion or announcement, so the Google folks might be able to tell us why they went this route.
I like Vladimir’s suggestion to put the SPD data into CBFS so it can easily be tuned [3]. No idea, what the downsides are.
Why have a config for this? It would make more sense to look for a file and if it's there use it, otherwise go for smbus. This way you patch is also useful for oveclockers and boot-time speedupers.
Do you also have the mainboard patch somewhere to look at, so the whole picture is clear how the current patch is used?
Thanks,
Paul
PS: It would be awesome if you could avoid TOP posting and use interleaved style [3].
[1] http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/sams... [2] http://review.coreboot.org/2359 [3] http://review.coreboot.org/#/c/4532/3/src/northbridge/amd/agesa/family14/dim... [4] http://en.opensuse.org/openSUSE:Mailing_list_netiquette [5] http://review.coreboot.org/4533
Paul,
It's pretty annoying to have to follow this discussion on two separate channels. Let's keep it @gerrit.
Dave,
What I'd like to see is the full changeset, from the current master, to the patch that adds the board. That's the only way to evaluate the usefulness, sanity, and functional aspect of the changes, especially since you are proposing a different way of doing something that is already done. Someone going through the patch chain might say "Oh, you can do this 100 times easier _this_ way".
To GERRIT! Alex
On Sun, Dec 15, 2013 at 3:52 PM, Paul Menzel paulepanter@users.sourceforge.net wrote:
This implementation was pushed with the Chromebook Butterfly without any discussion or announcement, so the Google folks might be able to tell us why they went this route.
Because the vendor required it. And, more vendors will require it in future, so it's nice to see this discussion.
ron