On 10/2/18 10:16 PM, ron minnich wrote:
we are at long last removing bounce buffers from selfboot. https://review.coreboot.org/c/coreboot/+/28647
This greatly simplifies the code and there are almost no platforms left that need them. Here are the ones that seem to:
src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig
Out of curiosity why this hits some but not all FSP1.0 platforms I checked the git history. I couldn't find an explanation why fsp_rangeley and fsp_sandybridge were skipped in 7904e72. Maybe they were just over- looked?
For these boards, I made the following change: "For these five boards we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0x3d00000 (64 MiB - 2 MiB) which will put the non-relocatable x86
nb. that's -3MiB
ramstage out of the way of any reasonable payload until we can get rid of it for good."
Not sure about this, but a wild guess: If you build a libpayload payload with a huge heap (part of .bss, IIRC), you might easily reach this area. Not that I would care (don't own any of the affected platforms), but if this is the case, it might be a problem for other people.
Nico
oops, sorry, I'll fix that 2 to 3 :-)
I think if somebody is building libpayloads with 64 MiB - 3 MiB bss that's a crazy day :-)
On Tue, Oct 2, 2018 at 3:03 PM Nico Huber nico.h@gmx.de wrote:
On 10/2/18 10:16 PM, ron minnich wrote:
we are at long last removing bounce buffers from selfboot. https://review.coreboot.org/c/coreboot/+/28647
This greatly simplifies the code and there are almost no platforms left that need them. Here are the ones that seem to:
src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/lx/Kconfig src/northbridge/via/vx900/Kconfig src/soc/intel/fsp_baytrail/Kconfig src/soc/intel/fsp_broadwell_de/Kconfig
Out of curiosity why this hits some but not all FSP1.0 platforms I checked the git history. I couldn't find an explanation why fsp_rangeley and fsp_sandybridge were skipped in 7904e72. Maybe they were just over- looked?
For these boards, I made the following change: "For these five boards we change CONFIG_RAMBASE from 0x100000 (the value needed in 1999 for the 32-bit Linux kernel, the original ramstage) to 0x3d00000 (64 MiB - 2 MiB) which will put the non-relocatable x86
nb. that's -3MiB
ramstage out of the way of any reasonable payload until we can get rid of it for good."
Not sure about this, but a wild guess: If you build a libpayload payload with a huge heap (part of .bss, IIRC), you might easily reach this area. Not that I would care (don't own any of the affected platforms), but if this is the case, it might be a problem for other people.
Nico
-
Nico Huber -
ron minnich