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 | 5 ++++- include/hw/core/cpu.h | 1 + include/hw/core/generic-loader.h | 1 + target/i386/cpu.c | 11 +++++++++++ 4 files changed, 17 insertions(+), 1 deletion(-) [1] http://web.archive.org/web/20201125131718/https://doc.coreboot.org/soc/amd/family17h.html -- 2.29.2
