On pe, 2015-05-08 at 09:02 +0000, Wolfgang Kamp - datakamp wrote:
Hello Kyösti, hello Wim,
with AGESA source there is a file buildOpts.c in the mainboard directory. In this file you can overwrite seed values and they will be passed to AGESA build. With binary Pi this file is absent. How is it possible to pass values to binary PI? My AMD support comes from Aschheim-Dornach, Germany.
Regards, Wolfgang
Wolfgang,
with the PI source you are in a better position to develop than any of us in the community contributors. I hope you would push your AMD FAEs to get the API fixed, if you indeed are currently unable to make FT3b work with on-board memory, with the pre-built binaryPI files AMD AES pushes to coreboot 3rdparty / blobs. If you do not do that, You will need to rebase your local changes and rebuild PI part of your firmware image part every time AMD updates their MullinsPI package.
I am complaining about the current state of things here as well:
http://review.coreboot.org/#/c/9386/
Just beware that what I consider as the official documentation, taken from AMD AES website about PI and coreboot, still states the following in FAQ.462:
"Note that the customer MAY NOT ship product with the nonscrubbed PI, as no such rights are provided in the NDA or otherwise. The customer must convert to the IP-scrubbed PI for production."
I have tried to have AMD AES to fix/revisit/confirm this statement for 6 months now, since it has not been updated after all the binaryPI invention our partners in crime came up with. I have contacted AMD AES both directly and via their EMEA FAE, but they have pretty much zero response rate nowadays towards coreboot community.
Kind Regards, Kyösti Mälkki
Hello Kyosti,
I do agree with you that it is much easier and straight forward to change memory parameters when you are using the source agesa but it is definitely possible to do this for the binary agesa as well. You can provide the binary AGESA with external tables during run-time.
I do agree with your other points though.
Best Regards,
Wim Vervoorn
Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands
T : +31-(0)73-594 46 64 E : wvervoorn@eltan.com W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Kyösti Mälkki Sent: Wednesday, May 13, 2015 7:49 AM To: coreboot@coreboot.org Cc: Wolfgang Kamp - datakamp Subject: Re: [coreboot] AGESA PI for Olivehill+
On pe, 2015-05-08 at 09:02 +0000, Wolfgang Kamp - datakamp wrote:
Hello Kyösti, hello Wim,
with AGESA source there is a file buildOpts.c in the mainboard directory. In this file you can overwrite seed values and they will be passed to AGESA build. With binary Pi this file is absent. How is it possible to pass values to binary PI? My AMD support comes from Aschheim-Dornach, Germany.
Regards, Wolfgang
Wolfgang,
with the PI source you are in a better position to develop than any of us in the community contributors. I hope you would push your AMD FAEs to get the API fixed, if you indeed are currently unable to make FT3b work with on-board memory, with the pre-built binaryPI files AMD AES pushes to coreboot 3rdparty / blobs. If you do not do that, You will need to rebase your local changes and rebuild PI part of your firmware image part every time AMD updates their MullinsPI package.
I am complaining about the current state of things here as well:
http://review.coreboot.org/#/c/9386/
Just beware that what I consider as the official documentation, taken from AMD AES website about PI and coreboot, still states the following in FAQ.462:
"Note that the customer MAY NOT ship product with the nonscrubbed PI, as no such rights are provided in the NDA or otherwise. The customer must convert to the IP-scrubbed PI for production."
I have tried to have AMD AES to fix/revisit/confirm this statement for 6 months now, since it has not been updated after all the binaryPI invention our partners in crime came up with. I have contacted AMD AES both directly and via their EMEA FAE, but they have pretty much zero response rate nowadays towards coreboot community.
Kind Regards, Kyösti Mälkki
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On ke, 2015-05-13 at 10:18 +0200, Wim Vervoorn wrote:
Hello Kyosti,
I do agree with you that it is much easier and straight forward to change memory parameters when you are using the source agesa but it is definitely possible to do this for the binary agesa as well. You can provide the binary AGESA with external tables during run-time.
Thanks Wim!
I can see how the relevant table that used to be in buildOPts.c is now implemented for DB-FT3b-LC board in agesawrapper.c.
So Wolfgang, you can pay for the development, which IMHO should not be more than 2 hours of engineering time, given the infrastructure is already there in binaryPI. Or request a free copy of the GPL'd DB-FT3b-LC coreboot OSP package from Sage (se-eng.com) to see for yourself where the table has to seat.
Or you can wait until DB-FT3b-LC board support appears upstreamed at coreboot.org. I have this board here on my desk so it might not take that long.
Regards, Kyösti
As Wim pointed out, it is possible, but not exactly clear as there was a big effort to clean up the buildopts and agesa wrappers. We have a slightly different implementation at Sage, but we are working up something that will work with the coreboot.org code. Here is what you need to know.
The gizmosphere/gizmo2 is an example of how a board with soldered down memory has the spd added to the rom image, but there are some differences with the AGESA binary PI implementation.
* Add a .spd.hex file to the mainboard folder.. Everything useful pretty much is defined in the first 30 bytes. Leave the CRC checksum bytes at locations 126/127 as zeroes so that the CRC will get calculated runtime. * Update the mainboard Makefile.inc to include the .spd.hex * Update the mainboard Kconfig to select SPD_CACHE * Update the mainboard BiosCallOuts.c file for the function to retrieve the SPD data from {AGESA_READ_SPD, agesa_ReadSpd } to {AGESA_READ_SPD, agesa_ReadSpd_from_cbfs } * Update devicetree.cb file for turn off the SMBUS, dev 14.0. Remove the lines for the chip drivers and remove the [register "spdAddrLookup" = "...], since the SPD data is coming from CBFS. * Add PSO_ENTRY ROMDATA PlatformMemoryConfiguration[] with all settings into a a file under the mainboard and then add it to agesawrapper_amdinitpost() : PostParams->MemConfig.PlatformMemoryConfiguration = PlatformMemoryConfiguration;.
Since agesawrapper.c was moved to the chipset directory we need to check for the table in the mainboard, but don't currently have a mechanism. We have some thoughts on how to do it, but it isn't prepared yet.
Regards, Marc
On Wed, May 13, 2015 at 3:28 AM Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On ke, 2015-05-13 at 10:18 +0200, Wim Vervoorn wrote:
Hello Kyosti,
I do agree with you that it is much easier and straight forward to
change memory parameters when you are using the source agesa but it is definitely possible to do this for the binary agesa as well. You can provide the binary AGESA with external tables during run-time.
Thanks Wim!
I can see how the relevant table that used to be in buildOPts.c is now implemented for DB-FT3b-LC board in agesawrapper.c.
So Wolfgang, you can pay for the development, which IMHO should not be more than 2 hours of engineering time, given the infrastructure is already there in binaryPI. Or request a free copy of the GPL'd DB-FT3b-LC coreboot OSP package from Sage (se-eng.com) to see for yourself where the table has to seat.
Or you can wait until DB-FT3b-LC board support appears upstreamed at coreboot.org. I have this board here on my desk so it might not take that long.
Regards, Kyösti
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hello Kyösti,
thank you for your help. I have got the DB-FT3b-LC coreboot OSP package and I can see how things work in agesawrapper.c. My starting point is Olivehill+ and I moved the agesawrapper.c to mainboard directory. Because now the agesawrapper is board specific I think it belongs there as it is in family 14H. And memory down in star topology now works fine in our board. Next problem is how to configure the GFX ports to get DVI and eDP.
Regards, Wolfgang
-----Ursprüngliche Nachricht----- Von: coreboot [mailto:coreboot-bounces@coreboot.org] Im Auftrag von Kyösti Mälkki Gesendet: Mittwoch, 13. Mai 2015 11:27 An: Wim Vervoorn Cc: Wolfgang Kamp - datakamp; coreboot@coreboot.org Betreff: Re: [coreboot] AGESA PI for Olivehill+
On ke, 2015-05-13 at 10:18 +0200, Wim Vervoorn wrote:
Hello Kyosti,
I do agree with you that it is much easier and straight forward to change memory parameters when you are using the source agesa but it is definitely possible to do this for the binary agesa as well. You can provide the binary AGESA with external tables during run-time.
Thanks Wim!
I can see how the relevant table that used to be in buildOPts.c is now implemented for DB-FT3b-LC board in agesawrapper.c.
So Wolfgang, you can pay for the development, which IMHO should not be more than 2 hours of engineering time, given the infrastructure is already there in binaryPI. Or request a free copy of the GPL'd DB-FT3b-LC coreboot OSP package from Sage (se-eng.com) to see for yourself where the table has to seat.
Or you can wait until DB-FT3b-LC board support appears upstreamed at coreboot.org. I have this board here on my desk so it might not take that long.
Regards, Kyösti
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Kyösti Mälkki -
Marc Jones -
Wim Vervoorn -
Wolfgang Kamp - datakamp