Mike Banon writes:
> Before borrowing update_microcode.c for our family15tn, we need to
> somehow figure out if its even working for that "
> family_10h-family_15h ". If you go to the root directory with coreboot
> sources, and issue ' find . -type f -print0 | xargs -0 grep
> "cpu_microcode_bins"
Before borrowing update_microcode.c for our family15tn, we need to
somehow figure out if its even working for that "
family_10h-family_15h ". If you go to the root directory with coreboot
sources, and issue ' find . -type f -print0 | xargs -0 grep
"cpu_microcode_bins" ' command, you'll see that cpu
On Fri, August 17, 2018 11:00 pm, Mike Banon wrote:
> After some research I've discovered serious problems with
> "update_microcode" method:
That's unfortunate, but understandable. The AGESA code is convoluted.
Would it be possible for someone (myself included) to copy
update_microcode.c into the
On Wed, August 8, 2018 3:03 pm, Mike Banon wrote:
> It seems that now the microcode loading for AMD fam15h CPUs, including
> for A10-5750M fam15h Richland CPU found at coreboot-supported Lenovo G505S,
> is supposed to be done in two steps:
>
> 1) First of all it is initializing with this microcode
It seems that now the microcode loading for AMD fam15h CPUs, including
for A10-5750M fam15h Richland CPU found at coreboot-supported Lenovo
G505S, is supposed to be done in two steps:
1) First of all it is initializing with this microcode hardcoded as
the hex values - version 0600110F [2012-01-11]
5 matches
Mail list logo
