Hello Everyone,
As a result of incoming 4.7 release many boards are going to be deprecated. We would like to support alix platforms which are based on Geode LX and yet not EARLY_CBMEM_INIT enabled. We have all hardware at hand and would gladly bring these platforms up to current standards.
We saw that Kyösti Mälkki did a lot of good work for other AMD platforms and even offered to help with implementing EARLY_CBMEM_INIT on Geode. Unfortunately the thread died: https://www.mail-archive.com/coreboot@coreboot.org/msg50205.html
Could You give us any tips where and how to start?
AFAIK it is about calculating the top of RAM and recovering the cbmem on S3 resume (am I wrong?). I have already tried to implement it, but when trying to get timestamps with cbmem, it complains that it could not find timestamp table (did not even get error with cpufreq missing as this module occurs to be a problem on Geode).
Has anybody maybe done some work yet?
Best Regards, --- Michał Żygowski https://3mdeb.com | @3mdeb_com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi Kyösti, if you can support us and provide some guidance about correct way of approaching below issue we would appreciate that.
On 12/14/2017 04:56 PM, Michal Zygowski wrote:
Hello Everyone,
As a result of incoming 4.7 release many boards are going to be deprecated. We would like to support alix platforms which are based on Geode LX and yet not EARLY_CBMEM_INIT enabled. We have all hardware at hand and would gladly bring these platforms up to current standards.
We saw that Kyösti Mälkki did a lot of good work for other AMD platforms and even offered to help with implementing EARLY_CBMEM_INIT on Geode. Unfortunately the thread died: https://www.mail-archive.com/coreboot@coreboot.org/msg50205.html
Could You give us any tips where and how to start?
AFAIK it is about calculating the top of RAM and recovering the cbmem on S3 resume (am I wrong?). I have already tried to implement it, but when trying to get timestamps with cbmem, it complains that it could not find timestamp table (did not even get error with cpufreq missing as this module occurs to be a problem on Geode).
Has anybody maybe done some work yet?
Best Regards, --- Michał Żygowski https://3mdeb.com | @3mdeb_com
Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com
Hi Piotr
I never worked with Geode LX codebase, my impression is that EARLY_CBMEM_INIT may not be worth the trouble.
Visit comments in cpu/amd/geode_lx/msrinit.c: "set up about 500Mb of memory", "doesn't really matter", "WARNING", "probably incorrectly set here". That's enough to tell me you may be looking at some amount of refactoring to have this feature sorted out.
First, you should be looking at MSR_GLIU0_SYSMEM and MSR_GLIU1_SYSMEM to have cbmem_top() implemented for romstage. In its current state, amd/lx/northbridgeinit.c : GLPCIInit() sets up these and other relevant registers of memory map only late in ramstage. At the minimum you will need to move that setting at the end of romstage with the actual amount of installed DRAM on the system. I don't have Geode datasheets at hand and I have no clue how many other MSRs are required for correct DRAM routing.
Second, you need functional CAR migration to get any benefits of EARLY_CBMEM_INIT, logs and timestamps from romstage get lost unless you have exactly correct sequence for CAR teardown implemented. Given that you don't have to worry about ACPI S3 support you have some room for mistakes or taking shortcuts there. In general, LX cache management code seems to be all over the place, or at least it is very different from any Intel (native, MRC) or AMD (AGESA/binaryPI) implementations I have reviewed in the past years.
If you decide to try hack something together, just push it out for review with WIP or NOTFORMERGE. Make some logs available and I should be able to explain why/where it fails without digging into the datasheets myself. You need to be able to address all of DRAM at the end of romstage and that is not currently happening, AFAICS.
Kyösti