A lot of AMD CPUs boot the bootstrap processor using a new mechanism.
According to https://doc.coreboot.org/soc/amd/family17h.html [1] that means
that the flash header specifies a destination and size in RAM (!), and the
bootstrap processor will start using a CS segment descriptor set up in such
a way that from the CPU's point of view, 0xf000:0xffff is the last byte of
the loaded blob (i.e. of the BIOS).
See <https://doc.coreboot.org/soc/amd/family17h.html>, which says:
>Picasso Reset Vector and First Instructions
[example]
>Flash BIOS Directory Table
>destination = 0x9b00000
>size = 0x300000
>... then the BIOS image is placed at the topmost position the region
>0x9b00000-0x9dfffff and
>reset_vector = 0x9dffff0
>CS_shdw_base = 0x9df0000
>CS:IP = 0xf000:0xfff0
The patch below allows the user to set up CS_shdw_base.
In order to test, try
qemu-system-x86_64 \
-m 1G \
-device loader,file=BIOS.fd,csbaseaddr=0x9df0000,addr=$0x9b00000,cpu-num=0,force-raw=on \
-device loader,addr=0xfff0,cpu-num=0 \
-bios BIOS.fd
The "-bios BIOS.fd" at the end is optional--but customary.
This has been used successfully for more than a year in BIOS development.
Danny Milosavljevic (1):
i386: Add support for AMD new-style boot mechanism.
hw/core/generic-loader.c | 6 +++++-
include/hw/core/cpu.h | 1 +
include/hw/core/generic-loader.h | 1 +
target/i386/cpu.c | 11 +++++++++++
4 files changed, 18 insertions(+), 1 deletion(-)
[1] http://web.archive.org/web/20201125131718/https://doc.coreboot.org/soc/amd/family17h.html
--
2.29.2