[coreboot] Testing modernizing patches on ASUS KGPE-D16. (was Re: Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?)

Arthur Heymans arthur at aheymans.xyz
Mon Dec 17 16:31:42 CET 2018


Felix Held <felix-coreboot at felixheld.de> writes:

> Hi!
>
>
>> Things should settle down some after Christmas, so I'll see what I can
>> do to pull the old D16 dev platform back out at that time and start
>> testing / merging patches.  Are there any others that I should also help
>> take a look at?
>
> Arthur pushed a new version of your patch #19820 and since it does what your
> original patch does, I'd say that it should be safe for merging to have that
> problem fixed in the upcoming release. Of course unless someone else tests the
> patch and finds a (very unlikely) regression before tomorrow. There are two more
> patches from that series, but I haven't reviewed them, since they add features
> and don't just fix problems.
>
> I'm not sure if Arthur has some other patches that are relevant to the KGPE-D16;
> IIRC he also looked into some improvements on the AMD side.
>

https://review.coreboot.org/c/coreboot/+/30063 implement relocatable
ramstage on AMDFAM10. Would be interesting to see whether it works on
amdfam15 hardware and if S3 resume still works fine.

https://review.coreboot.org/c/coreboot/+/30064/4 Implements postcar
stage on amdfam10 and drops the backup of RAMBASE..RAMTOP region.
It would allow to drop a whole lot of legacy code used for S3 resume, so
also definitely worth testing.

Both patches worked on a gigabyte m57-sli4 board with a amdfam10 CPU, so
I expect that booting till the OS still works fine. S3 resume might be a
little different. (review for board port is:
https://review.coreboot.org/c/coreboot/+/27618)

Something thing that would seem nice and would make CAR setup more
unified with how we do things on Intel hardware is to use variable
MTRR's for CAR instead of the fixed ones. A difficulty is that the
location needs to be carefully chosen as it needs to be below the
TOP_MEM MTRR, while also not hindering the raminit (I suppose)...

Another thing I'm working on, is to use C_ENVIRONMENT_BOOTBLOCK on all
x86 platforms (dropping use of romcc). Bringing that feature to amdfam10
won't be practical on my gigabyte m57sli board due to it using LPC flash
(I expect tons of reflashes/testing cycles ;). If someone is willing to
donate a supported board (not really interested in doing a board port
due to the deplorable state of AMD code in general) featuring amdfam10
hardware, preferably with DDR3 (implements S3 resume) and a SPI boot
medium, that would be fun.

It does not look this has anything to do with the original thread title
so sorry for hijacking it a little...

> Regards
>
> Felix

Kind regards

-- 
==============
Arthur Heymans



More information about the coreboot mailing list