Hi all,
I would like to extend to TPM PCR register the differents parts of coreboot once loaded. Is it correct to use the pointers from memlayout.h? For instance to extent the romstage to PCR1 I do something like:
extern char _romstage, _eromstage; tlcl_measure(1, &_romstage, &_eromstage - &_romstage);
Is it correct to do the same bootblock, ramstage, verstage, etc? My goal is to extend all the coreboot.
Thanks! Jorge
Hi,
If you have a board with TPM just simply go with vboot + measured boot. It will automatically extend the loaded parts of coreboot before execution.
Regards, Michał
On 12.11.2019 11:10, Jorge Fernandez Monteagudo wrote:
Hi all,
I would like to extend to TPM PCR register the differents parts of coreboot once loaded. Is it correct to use the pointers from memlayout.h? For instance to extent the romstage to PCR1 I do something like:
extern char _romstage, _eromstage; tlcl_measure(1, &_romstage, &_eromstage - &_romstage);
Is it correct to do the same bootblock, ramstage, verstage, etc? My goal is to extend all the coreboot.
Thanks! Jorge _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Michal,
If you have a board with TPM just simply go with vboot + measured boot. It will automatically extend the loaded parts of coreboot before execution.
Which configs are needed?
CONFIG_VBOOT CONFIG_VBOOT_MEASURED_BOOT
Anything else?
Thanks!
Typically these are the options that one has to select in menuconfig. But in order to have them work as expected you need few other things. As a reference please heave a look at: https://review.coreboot.org/c/coreboot/+/35998
You need to reserve some CMOS memory for vboot context, set default vboot configuration in Kconfig of your platform and prepare a flashmap layout file (*.fmd) - its the simplest case. Additionally you should have at least one RW slot by selecting CONFIG_VBOOT_SLOTS_RW_A.
If this is already done for your boards, then:
CONFIG_VBOOT CONFIG_VBOOT_MEASURED_BOOT CONFIG_VBOOT_SLOTS_RW_A
selected from menuconfig should be sufficient.
Regards, Michał
On 12.11.2019 11:38, Jorge Fernandez Monteagudo wrote:
Hi Michal,
If you have a board with TPM just simply go with vboot + measured boot. It will automatically extend the loaded parts of coreboot before execution.
Which configs are needed?
CONFIG_VBOOT CONFIG_VBOOT_MEASURED_BOOT
Anything else?
Thanks! _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Typically these are the options that one has to select in menuconfig. But in order to have them work as expected you need few other things. As a reference please heave a look at: https://review.coreboot.org/c/coreboot/+/35998
You need to reserve some CMOS memory for vboot context, set default vboot configuration in Kconfig of your platform and prepare a flashmap layout file (*.fmd) - its the simplest case. Additionally you should have at least one RW slot by selecting CONFIG_VBOOT_SLOTS_RW_A.
If this is already done for your boards, then: CONFIG_VBOOT CONFIG_VBOOT_MEASURED_BOOT CONFIG_VBOOT_SLOTS_RW_A
selected from menuconfig should be sufficient.
Wow, it seems a little more complicated than get some pointers and extend them :) Well, thanks for the info! I'll give it a try!
Regards, Jorge
Hi Michal!
You need to reserve some CMOS memory for vboot context, set default vboot configuration in Kconfig of your platform and prepare a flashmap layout file (*.fmd) - its the simplest case. Additionally you should have at least one RW slot by selecting CONFIG_VBOOT_SLOTS_RW_A.
Could you please advise how to implement the flashmap layout file to reserve space for the RW partition? When coreboot rom is compile without VBOOT I get the next info:
Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 32260 none fallback/ramstage 0x7f00 stage 64238 none cmos_layout.bin 0x17a40 cmos_layout 1516 none fallback/dsdt.aml 0x18080 raw 6656 none (empty) 0x19b00 null 25240 none apu/amdfw 0x1fdc0 raw 560128 none pci1002,9874.rom 0xa8a00 optionrom 64512 none fallback/payload 0xb8680 simple elf 2627296 none (empty) 0x339dc0 null 2908120 none AGESA 0x5ffdc0 raw 690436 none (empty) 0x6a8740 null 1405592 none bootblock 0x7ffa00 bootblock 944 none
and the default fmd map:
# layout for firmware residing at top of 4GB address space # +-------------+ <-- 4GB - ROM_SIZE / start of flash # | unspecified | # +-------------+ <-- 4GB - BIOS_SIZE # | FMAP | # +-------------+ <-- 4GB - BIOS_SIZE + FMAP_SIZE # | CBFS | # +-------------+ <-- 4GB / end of flash
FLASH@4286578688 0x800000 { BIOS@0 8388608 { FMAP@0 0x200 COREBOOT(CBFS)@512 8388096 } }
Thanks! Jorge
Hi Jorge,
I see you have AMD platform, so things may look differently than in the linked patch. The example FMD file that could work for you (1 RW partition only):
FLASH@0xff800000 0x800000 { RW_UNUSED@0x0 0x20000 AMDFW(PRESERVE)@0x20000 0x90000 SI_BIOS@0xb0000 0x750000 { RW_SECTION_A 0x200000 { VBLOCK_A 0x10000 FW_MAIN_A(CBFS) RW_FWID_A 0x40 } CONSOLE 0x10000 SMMSTORE(PRESERVE) 0x40000 RW_VPD(PRESERVE) 0x4000 WP_RO { FMAP@0x0 0x800 RO_FRID 0x40 RO_FRID_PAD 0x7c0 RO_VPD(PRESERVE) 0x4000 GBB 0x1e000 COREBOOT(CBFS) } } }
Important to select AMDFW_OUTSIDE_CBFS when using this flashmap layout. Save the content to the board.fmd file and fill the file path in the menuconfig: General -> fmap description file in fmd format
You may want to choose different sizes of partitions etc. This is just an example.
Regards, Michał
On 13.11.2019 12:35, Jorge Fernandez Monteagudo wrote:
Hi Michal!
You need to reserve some CMOS memory for vboot context, set default vboot configuration in Kconfig of your platform and prepare a flashmap layout file (*.fmd) - its the simplest case. Additionally you should have at least one RW slot by selecting CONFIG_VBOOT_SLOTS_RW_A.
Could you please advise how to implement the flashmap layout file to reserve space for the RW partition? When coreboot rom is compile without VBOOT I get the next info:
Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 32260 none fallback/ramstage 0x7f00 stage 64238 none cmos_layout.bin 0x17a40 cmos_layout 1516 none fallback/dsdt.aml 0x18080 raw 6656 none (empty) 0x19b00 null 25240 none apu/amdfw 0x1fdc0 raw 560128 none pci1002,9874.rom 0xa8a00 optionrom 64512 none fallback/payload 0xb8680 simple elf 2627296 none (empty) 0x339dc0 null 2908120 none AGESA 0x5ffdc0 raw 690436 none (empty) 0x6a8740 null 1405592 none bootblock 0x7ffa00 bootblock 944 none
and the default fmd map:
# layout for firmware residing at top of 4GB address space # +-------------+ <-- 4GB - ROM_SIZE / start of flash # | unspecified | # +-------------+ <-- 4GB - BIOS_SIZE # | FMAP | # +-------------+ <-- 4GB - BIOS_SIZE + FMAP_SIZE # | CBFS | # +-------------+ <-- 4GB / end of flash
FLASH@4286578688 0x800000 { BIOS@0 8388608 { FMAP@0 0x200 COREBOOT(CBFS)@512 8388096 } }
Thanks! Jorge _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Michal!
Thanks for the info!
Yes, I'm using the amd/bettong mainboard. I've changed the Kconfig adding
config VBOOT select VBOOT_STARTS_IN_ROMSTAGE select VBOOT_NO_BOARD_SUPPORT select VBOOT_MEASURED_BOOT select AMDFW_OUTSIDE_CBFS
config VBOOT_SLOTS_RW_A default y
config FMDFILE string default "src/mainboard/$(CONFIG_MAINBOARD_DIR)/vboot-rwa.fmd" if VBOOT
Now, I get an error processing the CBFS. As you said, I suppose I need to modify the sizes to adapt it to my requirements. Where can I found info about the fmap files? This, and the cmos layout files are unknown areas to me, and I don't know where to begin to modify it.
The error I get is:
Created CBFS (capacity = 5083096 bytes) Created CBFS (capacity = 2031512 bytes) CBFS AGESA CBFS fallback/romstage CBFS fallback/ramstage CBFS cmos_layout.bin CBFS pci1002,9874.rom CBFS fallback/dsdt.aml CBFS fallback/payload CBFS AGESA E: Could not add [3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin, 690436 bytes (674 KB)@0x540000]; too big? E: Failed to add '3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin' into ROM image. E: Failed while operating on 'FW_MAIN_A' region! E: The image will be left unmodified.
Regards, Jorge
Most likely you will need also this:
select VBOOT_VBNV_CMOS select VBOOT_NO_BOARD_SUPPORT select GBB_FLAG_DISABLE_LID_SHUTDOWN select GBB_FLAG_DISABLE_PD_SOFTWARE_SYNC select GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC select GBB_FLAG_DISABLE_FWMP select RTC select VBOOT_STARTS_IN_ROMSTAGE
Under config VBOOT. And define the CMOS offset for vboot in Kconfig as in the patch linked earlier. AGESA binary typically have to reside under certain offset in the binary, so you have to pass the AGESA name to be added to RO partition only in menuconfig of vboot, since it should probably reside there.
On 13.11.2019 14:37, Jorge Fernandez Monteagudo wrote:
Hi Michal!
Thanks for the info!
Yes, I'm using the amd/bettong mainboard. I've changed the Kconfig adding
config VBOOT select VBOOT_STARTS_IN_ROMSTAGE select VBOOT_NO_BOARD_SUPPORT select VBOOT_MEASURED_BOOT select AMDFW_OUTSIDE_CBFS
config VBOOT_SLOTS_RW_A default y
config FMDFILE string default "src/mainboard/$(CONFIG_MAINBOARD_DIR)/vboot-rwa.fmd" if VBOOT
Now, I get an error processing the CBFS. As you said, I suppose I need to modify the sizes to adapt it to my requirements. Where can I found info about the fmap files? This, and the cmos layout files are unknown areas to me, and I don't know where to begin to modify it.
The error I get is:
Created CBFS (capacity = 5083096 bytes) Created CBFS (capacity = 2031512 bytes) CBFS AGESA CBFS fallback/romstage CBFS fallback/ramstage CBFS cmos_layout.bin CBFS pci1002,9874.rom CBFS fallback/dsdt.aml CBFS fallback/payload CBFS AGESA E: Could not add [3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin, 690436 bytes (674 KB)@0x540000]; too big? E: Failed to add '3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin' into ROM image. E: Failed while operating on 'FW_MAIN_A' region! E: The image will be left unmodified.
Regards, Jorge _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Michal!
Under config VBOOT. And define the CMOS offset for vboot in Kconfig as in the patch linked earlier. AGESA binary typically have to reside under certain offset in the binary, so you have to pass the AGESA name to be added to RO partition only in menuconfig of vboot, since it should probably reside there.
Maybe do you refer to the AMD firmware instead of AGESA? I've seen in src/soc/amd/stoneyridge/Makefile.inc when the AMDFW_OUTSIDE_CBFS the amdfw.rom is the firmware to copy in a fixed position inside ROM. In src/soc/amd/stoneyridge/Kconfig you can see that they define RO_REGION_ONLY with the default 'apu/amdfw'
Anyway, I've tried changing the flash size to 16MB to see the component's distribution. I've modified your file a little:
FLASH@0xff800000 0x1000000 { RW_UNUSED@0x0 0x20000 AMDFW(PRESERVE)@0x20000 0x90000 SI_BIOS@0xb0000 0xF50000 { RW_SECTION_A 0x500000 { VBLOCK_A 0x10000 FW_MAIN_A(CBFS) RW_FWID_A 0x40 } CONSOLE 0x10000 SMMSTORE(PRESERVE) 0x40000 RW_VPD(PRESERVE) 0x4000 WP_RO { FMAP@0x0 0x800 RO_FRID 0x40 RO_FRID_PAD 0x7c0 RO_VPD(PRESERVE) 0x4000 GBB 0x1e000 COREBOOT(CBFS) } } }
Now, the CBFS is created ok:
Created CBFS (capacity = 10325976 bytes) Created CBFS (capacity = 5177240 bytes) CBFS AGESA CBFS fallback/romstage CBFS fallback/ramstage CBFS cmos_layout.bin CBFS pci1002,9874.rom CBFS fallback/dsdt.aml CBFS fallback/payload CBFS AGESA CBFS fallback/ramstage CBFS pci1002,9874.rom CBFS fallback/dsdt.aml CBFS fallback/payload DD Adding AMD Firmware CBFS coreboot.rom CBFSLAYOUT coreboot.rom
This image contains the following sections that can be manipulated with this tool:
'RW_UNUSED' (size 131072, offset 0) 'AMDFW' (preserve, size 589824, offset 131072) 'VBLOCK_A' (size 65536, offset 720896) 'FW_MAIN_A' (CBFS, size 5177280, offset 786432) 'RW_FWID_A' (size 64, offset 5963712) 'CONSOLE' (size 65536, offset 5963776) 'SMMSTORE' (preserve, size 262144, offset 6029312) 'RW_VPD' (preserve, size 16384, offset 6291456) 'RO_FRID' (size 64, offset 6309888) 'RO_FRID_PAD' (size 1984, offset 6309952) 'RO_VPD' (preserve, size 16384, offset 6311936) 'GBB' (size 122880, offset 6328320) 'COREBOOT' (CBFS, size 10326016, offset 6451200)
It is possible to perform either the write action or the CBFS add/remove actions on every section listed above. To see the image's read-only sections as well, rerun with the -w option. CBFSPRINT coreboot.rom
FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 65316 none fallback/ramstage 0x10040 stage 68406 none cmos_layout.bin 0x20bc0 cmos_layout 1548 none pci1002,9874.rom 0x21240 optionrom 64512 none fallback/dsdt.aml 0x30ec0 raw 6656 none fallback/payload 0x32940 simple elf 2627360 none (empty) 0x2b40c0 null 5394136 none AGESA 0x7d8fc0 raw 690436 none (empty) 0x881940 null 1405592 none bootblock 0x9d8c00 bootblock 944 none FMAP REGION: FW_MAIN_A Name Offset Type Size Comp fallback/ramstage 0x0 stage 68406 none pci1002,9874.rom 0x10b80 optionrom 64512 none fallback/dsdt.aml 0x20800 raw 6656 none fallback/payload 0x22280 simple elf 2627360 none (empty) 0x2a3a00 null 312664 none AGESA 0x2eff80 raw 690436 none (empty) 0x398900 null 1406616 none
Here you can see the line with the copy of the firmware:
DD Adding AMD Firmware
The code is in 'southbridge/amd/pi/hudson/Makefile.inc' and they do:
dd if=$(obj)/amdfw.rom \ of=$(obj)/coreboot.pre conv=notrunc bs=1 seek=131072 >/dev/null 2>&1
to copy 'amdfw.rom' to the AMDFW(PRESERVE) in the flashmap.
I think in a 8MB flash there is no room to the CBFS and a copy in the RW_SECTION_A. Is it possible to enable VBOOT and don't have a RW_SECTION_A? I'm not interested in recover the firmware...
Thanks Jorge
On 14.11.2019 08:48, Jorge Fernandez Monteagudo wrote:
Hi Michal!
Under config VBOOT. And define the CMOS offset for vboot in Kconfig as in the patch linked earlier. AGESA binary typically have to reside under certain offset in the binary, so you have to pass the AGESA name to be added to RO partition only in menuconfig of vboot, since it should probably reside there.
Maybe do you refer to the AMD firmware instead of AGESA? I've seen in src/soc/amd/stoneyridge/Makefile.inc when the AMDFW_OUTSIDE_CBFS the amdfw.rom is the firmware to copy in a fixed position inside ROM. In src/soc/amd/stoneyridge/Kconfig you can see that they define RO_REGION_ONLY with the default 'apu/amdfw'
No, AMDFW which comprises PSP firmware and other components lies at offset 0x20000 from the beginning of the flash (typically). AGESA is a silicon initialization code which lies on different offsets (usually 0xFFE00000) and has to be in the RO region, because this is the range of addresses it fits to (its nearly the bottom of the flash). Putting AGESA in RW_A is impossible, because RW_A is not in the range of addresses where AGESA should be placed, thus the previous error.
Anyway, I've tried changing the flash size to 16MB to see the component's distribution. I've modified your file a little:
FLASH@0xff800000 0x1000000 { RW_UNUSED@0x0 0x20000 AMDFW(PRESERVE)@0x20000 0x90000 SI_BIOS@0xb0000 0xF50000 { RW_SECTION_A 0x500000 { VBLOCK_A 0x10000 FW_MAIN_A(CBFS) RW_FWID_A 0x40 } CONSOLE 0x10000 SMMSTORE(PRESERVE) 0x40000 RW_VPD(PRESERVE) 0x4000 WP_RO { FMAP@0x0 0x800 RO_FRID 0x40 RO_FRID_PAD 0x7c0 RO_VPD(PRESERVE) 0x4000 GBB 0x1e000 COREBOOT(CBFS) } } }
If You do not have 16MB flash you won't be able to flash it with flashrom. Secondly the base address of 0xff80000 should change in such situation.
Now, the CBFS is created ok:
Created CBFS (capacity = 10325976 bytes) Created CBFS (capacity = 5177240 bytes) CBFS AGESA CBFS fallback/romstage CBFS fallback/ramstage CBFS cmos_layout.bin CBFS pci1002,9874.rom CBFS fallback/dsdt.aml CBFS fallback/payload CBFS AGESA CBFS fallback/ramstage CBFS pci1002,9874.rom CBFS fallback/dsdt.aml CBFS fallback/payload DD Adding AMD Firmware CBFS coreboot.rom CBFSLAYOUT coreboot.rom
This image contains the following sections that can be manipulated with this tool:
'RW_UNUSED' (size 131072, offset 0) 'AMDFW' (preserve, size 589824, offset 131072) 'VBLOCK_A' (size 65536, offset 720896) 'FW_MAIN_A' (CBFS, size 5177280, offset 786432) 'RW_FWID_A' (size 64, offset 5963712) 'CONSOLE' (size 65536, offset 5963776) 'SMMSTORE' (preserve, size 262144, offset 6029312) 'RW_VPD' (preserve, size 16384, offset 6291456) 'RO_FRID' (size 64, offset 6309888) 'RO_FRID_PAD' (size 1984, offset 6309952) 'RO_VPD' (preserve, size 16384, offset 6311936) 'GBB' (size 122880, offset 6328320) 'COREBOOT' (CBFS, size 10326016, offset 6451200)
It doesn't mean it will work...
It is possible to perform either the write action or the CBFS add/remove actions on every section listed above. To see the image's read-only sections as well, rerun with the -w option. CBFSPRINT coreboot.rom
FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 65316 none fallback/ramstage 0x10040 stage 68406 none cmos_layout.bin 0x20bc0 cmos_layout 1548 none pci1002,9874.rom 0x21240 optionrom 64512 none fallback/dsdt.aml 0x30ec0 raw 6656 none fallback/payload 0x32940 simple elf 2627360 none (empty) 0x2b40c0 null 5394136 none AGESA 0x7d8fc0 raw 690436 none (empty) 0x881940 null 1405592 none bootblock 0x9d8c00 bootblock 944 none FMAP REGION: FW_MAIN_A Name Offset Type Size Comp fallback/ramstage 0x0 stage 68406 none pci1002,9874.rom 0x10b80 optionrom 64512 none fallback/dsdt.aml 0x20800 raw 6656 none fallback/payload 0x22280 simple elf 2627360 none (empty) 0x2a3a00 null 312664 none AGESA 0x2eff80 raw 690436 none (empty) 0x398900 null 1406616 none
Yes, you can add or remove components freely with cbfstool.
Here you can see the line with the copy of the firmware:
DD Adding AMD FirmwareThe code is in 'southbridge/amd/pi/hudson/Makefile.inc' and they do:
dd if=$(obj)/amdfw.rom \ of=$(obj)/coreboot.pre conv=notrunc bs=1 seek=131072 >/dev/null 2>&1
to copy 'amdfw.rom' to the AMDFW(PRESERVE) in the flashmap.
I think in a 8MB flash there is no room to the CBFS and a copy in the RW_SECTION_A. Is it possible to enable VBOOT and don't have a RW_SECTION_A? I'm not interested in recover the firmware...
Not exactly. This code puts AMDFW always at offset of 0x20000 from the beginning of flash. It has nothing to do with CBFS if AMDFW_OUTSIDE_CBFS is selected.
You need at least 1 RW slot, otherwise: https://review.coreboot.org/c/coreboot/+/34977 you will end in a boot loop.
Regards, Michał
Thanks Jorge _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Michal,
No, AMDFW which comprises PSP firmware and other components lies at offset 0x20000 from the beginning of the flash (typically). AGESA is a silicon initialization code which lies on different offsets (usually 0xFFE00000) and has to be in the RO region, because this is the range of addresses it fits to (its nearly the bottom of the flash). Putting AGESA in RW_A is impossible, because RW_A is not in the range of addresses where AGESA should be placed, thus the previous error. ... Not exactly. This code puts AMDFW always at offset of 0x20000 from the beginning of flash. It has nothing to do with CBFS if AMDFW_OUTSIDE_CBFS is selected.
Yes, you're right!! With AMDFW_OUTSIDE_CBFS the AMDFW file is dd to the fixed positionand I have to play with the AGESA blob. Then I've tried to set RO_REGION_ONLY to 'AGESA.bin' or '3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin' but the build process insist putting the file in RO and RW partition. I don't know why?
But I have a progress. I've been able to create a coreboot.rom with your fmap file and using cbfstool to manually craft the final rom. Now, only the payload has no room in the FW_MAIN_A.
build/util/cbfstool/cbfstool build/coreboot.rom print -r COREBOOT,FW_MAIN_A FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 65316 none fallback/ramstage 0x10040 stage 68424 none cmos_layout.bin 0x20bc0 cmos_layout 1548 none pci1002,9874.rom 0x21240 optionrom 64512 none fallback/dsdt.aml 0x30ec0 raw 6656 none fallback/payload 0x32940 simple elf 2627360 none (empty) 0x2b40c0 null 151256 none AGESA 0x2d8fc0 raw 690436 none (empty) 0x381940 null 1405592 none bootblock 0x4d8c00 bootblock 944 none FMAP REGION: FW_MAIN_A Name Offset Type Size Comp fallback/ramstage 0x0 stage 68424 none pci1002,9874.rom 0x10b80 optionrom 64512 none fallback/dsdt.aml 0x20800 raw 6656 none
Now I'm able to boot and I see the VBOOT traces...
I've found in 'https://doc.coreboot.org/security/vboot/index.html' the next configuration: VBOOT_ENABLE_CBFS_FALLBACK I think it could be an interesting option to fallback to the RO payload if I can't make room for him, but nothing in the code for this configuration! Anyone knows something?
Regard, Jorge vboot - Verified Boot Support — coreboot 4.10-1302-g3e9061e27c documentationhttps://doc.coreboot.org/security/vboot/index.html Signing the coreboot Image¶. The following command script is an example of how to sign the coreboot image file. This script is used on the Intel Galileo board and creates the GBB area and inserts it into the coreboot image. It also updates the VBLOCK areas with the firmware signing key and the signature for the FW_MAIN firmware. More details are available in 3rdparty/vboot/README. doc.coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I haven't provided the RW CBFS size, so it may be automatically determining its size based on components size. Setting fixed size may lead to the presence of some empty space.
And the RO_REGION_ONLY should be 'AGESA' not 'AGESA.bin', since we pass CBFS names there, not filenames of binaries on the root file system.
On 14.11.2019 13:07, Jorge Fernandez Monteagudo wrote:
Hi Michal,
No, AMDFW which comprises PSP firmware and other components lies at offset 0x20000 from the beginning of the flash (typically). AGESA is a silicon initialization code which lies on different offsets (usually 0xFFE00000) and has to be in the RO region, because this is the range of addresses it fits to (its nearly the bottom of the flash). Putting AGESA in RW_A is impossible, because RW_A is not in the range of addresses where AGESA should be placed, thus the previous error. ... Not exactly. This code puts AMDFW always at offset of 0x20000 from the beginning of flash. It has nothing to do with CBFS if AMDFW_OUTSIDE_CBFS is selected.
Yes, you're right!! With AMDFW_OUTSIDE_CBFS the AMDFW file is dd to the fixed positionand I have to play with the AGESA blob. Then I've tried to set RO_REGION_ONLY to 'AGESA.bin' or '3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin' but the build process insist putting the file in RO and RW partition. I don't know why?
But I have a progress. I've been able to create a coreboot.rom with your fmap file and using cbfstool to manually craft the final rom. Now, only the payload has no room in the FW_MAIN_A.
build/util/cbfstool/cbfstool build/coreboot.rom print -r COREBOOT,FW_MAIN_A FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 65316 none fallback/ramstage 0x10040 stage 68424 none cmos_layout.bin 0x20bc0 cmos_layout 1548 none pci1002,9874.rom 0x21240 optionrom 64512 none fallback/dsdt.aml 0x30ec0 raw 6656 none fallback/payload 0x32940 simple elf 2627360 none (empty) 0x2b40c0 null 151256 none AGESA 0x2d8fc0 raw 690436 none (empty) 0x381940 null 1405592 none bootblock 0x4d8c00 bootblock 944 none FMAP REGION: FW_MAIN_A Name Offset Type Size Comp fallback/ramstage 0x0 stage 68424 none pci1002,9874.rom 0x10b80 optionrom 64512 none fallback/dsdt.aml 0x20800 raw 6656 none
Now I'm able to boot and I see the VBOOT traces...
I've found in 'https://doc.coreboot.org/security/vboot/index.html' the next configuration: *VBOOT_ENABLE_CBFS_FALLBACK* I think it could be an interesting option to fallback to the RO payload if I can't make room for him, but nothing in the code for this configuration! Anyone knows something?
Regard, Jorge vboot - Verified Boot Support — coreboot 4.10-1302-g3e9061e27c documentation https://doc.coreboot.org/security/vboot/index.html Signing the coreboot Image¶. The following command script is an example of how to sign the coreboot image file. This script is used on the Intel Galileo board and creates the GBB area and inserts it into the coreboot image. It also updates the VBLOCK areas with the firmware signing key and the signature for the FW_MAIN firmware. More details are available in 3rdparty/vboot/README. doc.coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I haven't provided the RW CBFS size, so it may be automatically determining its size based on components size. Setting fixed size may lead to the presence of some empty space.
And the RO_REGION_ONLY should be 'AGESA' not 'AGESA.bin', since we pass CBFS names there, not filenes of binaries on the root file system.
Well, then there is some error some place because I've set RO_REGION_ONLY to 'AGESA' and I'm still seeing to calls to added to CBFS. With:
$ make V=1 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r COREBOOT -b 0xFFE00000 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r FW_MAIN_A -b 0xFFE00000
$ grep -r "RO_REGION_ONLY" src/security/vboot/Makefile.inc: $(call strip_quotes,$(CONFIG_RO_REGION_ONLY)) \ src/security/vboot/Kconfig:config RO_REGION_ONLY src/northbridge/intel/haswell/Kconfig:config RO_REGION_ONLY src/soc/intel/apollolake/Kconfig:config RO_REGION_ONLY src/soc/intel/broadwell/Kconfig:config RO_REGION_ONLY src/soc/amd/picasso/Kconfig:config RO_REGION_ONLY src/soc/amd/stoneyridge/Kconfig:config RO_REGION_ONLY .config.old:CONFIG_RO_REGION_ONLY="AGESA" .config:CONFIG_RO_REGION_ONLY="AGESA" build/auto.conf:CONFIG_RO_REGION_ONLY="AGESA" build/config.h:#define CONFIG_RO_REGION_ONLY "AGESA"
Thanks for your help Mikal! Regards
Ohh I see the problem. Quotes are problematic in these cbfstool calls:
"AGESA" but should be AGESA
Go to src/vendorcode/amd/pi/Makefile.inc and at the end of file replace the code that adds AGESA to CBFS with:
agesa_binary := $(call strip_quotes,$(CONFIG_AGESA_CBFS_NAME)) cbfs-files-$(CONFIG_CPU_AMD_AGESA_BINARY_PI) += $(agesa_binary) $(agesa_binary)-file := $(CONFIG_AGESA_BINARY_PI_FILE) $(agesa_binary)-type := raw $(agesa_binary)-position := $(CONFIG_AGESA_BINARY_PI_LOCATION) The RO_REGION_ONLY did not recognize the AGESA CBFS name due to the quotes and placed the file in both partitions still. Regards, Michał On 14.11.2019 14:15, Jorge Fernandez Monteagudo wrote:
I haven't provided the RW CBFS size, so it may be automatically determining its size based on components size. Setting fixed size may lead to the presence of some empty space.
And the RO_REGION_ONLY should be 'AGESA' not 'AGESA.bin', since we pass CBFS names there, not filenes of binaries on the root file system.
Well, then there is some error some place because I've set RO_REGION_ONLY to 'AGESA' and I'm still seeing to calls to added to CBFS. With:
$ make V=1 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r COREBOOT -b 0xFFE00000 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r FW_MAIN_A -b 0xFFE00000
$ grep -r "RO_REGION_ONLY" src/security/vboot/Makefile.inc: $(call strip_quotes,$(CONFIG_RO_REGION_ONLY)) \ src/security/vboot/Kconfig:config RO_REGION_ONLY src/northbridge/intel/haswell/Kconfig:config RO_REGION_ONLY src/soc/intel/apollolake/Kconfig:config RO_REGION_ONLY src/soc/intel/broadwell/Kconfig:config RO_REGION_ONLY src/soc/amd/picasso/Kconfig:config RO_REGION_ONLY src/soc/amd/stoneyridge/Kconfig:config RO_REGION_ONLY .config.old:CONFIG_RO_REGION_ONLY="AGESA" .config:CONFIG_RO_REGION_ONLY="AGESA" build/auto.conf:CONFIG_RO_REGION_ONLY="AGESA" build/config.h:#define CONFIG_RO_REGION_ONLY "AGESA"
Thanks for your help Mikal! Regards _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Ohh I see the problem. Quotes are problematic in these cbfstool calls:
agesa_binary := $(call strip_quotes,$(CONFIG_AGESA_CBFS_NAME)) cbfs-files-$(CONFIG_CPU_AMD_AGESA_BINARY_PI) += $(agesa_binary) $(agesa_binary)-file := $(CONFIG_AGESA_BINARY_PI_FILE) $(agesa_binary)-type := raw $(agesa_binary)-position := $(CONFIG_AGESA_BINARY_PI_LOCATION)
The RO_REGION_ONLY did not recognize the AGESA CBFS name due to the quotes and placed the file in both partitions still.
Yes! you're right again, now it's only called once.
Some more questions: - If I don't have CONFIG_VPD and CONFIG_SMMSTORE enabled, the entries RW_VPD(PRESERVE) and SMMSTORE(PRESERVE) are needed? - The RW_UNUSED@0x0 0x20000 could be used? Maybe is it possible to relocate the AMDFW to 0x0 instead of 0x20000? - CONSOLE 0x10000 is needed for something? - Is is possible to only have the payload in the RO area?
Thanks Jorge
Regards, Michał
On 14.11.2019 14:15, Jorge Fernandez Monteagudo wrote:
I haven't provided the RW CBFS size, so it may be automatically determining its size based on components size. Setting fixed size may lead to the presence of some empty space.
And the RO_REGION_ONLY should be 'AGESA' not 'AGESA.bin', since we pass CBFS names there, not filenes of binaries on the root file system.
Well, then there is some error some place because I've set RO_REGION_ONLY to 'AGESA' and I'm still seeing to calls to added to CBFS. With:
$ make V=1 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r COREBOOT -b 0xFFE00000 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r FW_MAIN_A -b 0xFFE00000
$ grep -r "RO_REGION_ONLY" src/security/vboot/Makefile.inc: $(call strip_quotes,$(CONFIG_RO_REGION_ONLY)) \ src/security/vboot/Kconfig:config RO_REGION_ONLY src/northbridge/intel/haswell/Kconfig:config RO_REGION_ONLY src/soc/intel/apollolake/Kconfig:config RO_REGION_ONLY src/soc/intel/broadwell/Kconfig:config RO_REGION_ONLY src/soc/amd/picasso/Kconfig:config RO_REGION_ONLY src/soc/amd/stoneyridge/Kconfig:config RO_REGION_ONLY .config.old:CONFIG_RO_REGION_ONLY="AGESA" .config:CONFIG_RO_REGION_ONLY="AGESA" build/auto.conf:CONFIG_RO_REGION_ONLY="AGESA" build/config.h:#define CONFIG_RO_REGION_ONLY "AGESA"
Thanks for your help Mikal! Regards _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On 14.11.2019 15:28, Jorge Fernandez Monteagudo wrote:
Ohh I see the problem. Quotes are problematic in these cbfstool calls:
agesa_binary := $(call strip_quotes,$(CONFIG_AGESA_CBFS_NAME)) cbfs-files-$(CONFIG_CPU_AMD_AGESA_BINARY_PI) += $(agesa_binary) $(agesa_binary)-file := $(CONFIG_AGESA_BINARY_PI_FILE) $(agesa_binary)-type := raw $(agesa_binary)-position := $(CONFIG_AGESA_BINARY_PI_LOCATION)
The RO_REGION_ONLY did not recognize the AGESA CBFS name due to the quotes and placed the file in both partitions still.
Yes! you're right again, now it's only called once.
Some more questions:
- If I don't have CONFIG_VPD and CONFIG_SMMSTORE enabled, the entries RW_VPD(PRESERVE) and SMMSTORE(PRESERVE) are needed?
No, not needed. You may remove them. My FMD was just an example.
- The RW_UNUSED@0x0 0x20000 could be used? Maybe is it possible to relocate the AMDFW to 0x0 instead of 0x20000?
Not possible. PSP check for certain offsets in search of its own firmware in SPI flash. All you cna do is to relocate it to CBFS to use different base address.
- CONSOLE 0x10000 is needed for something?
It is for SPI flash console logging. You also may remove it if not selected or needed.
- Is is possible to only have the payload in the RO area?
AFAIK it's not. If you put the fallback/payload name to RO_REGION_ONLY, it will probably do not launch the payload at all if executing from RW partition.
Thanks Jorge
Regards, Michał
On 14.11.2019 14:15, Jorge Fernandez Monteagudo wrote:
I haven't provided the RW CBFS size, so it may be automatically determining its size based on components size. Setting fixed size may lead to the presence of some empty space.
And the RO_REGION_ONLY should be 'AGESA' not 'AGESA.bin', since we pass CBFS names there, not filenes of binaries on the root file system.
Well, then there is some error some place because I've set RO_REGION_ONLY to 'AGESA' and I'm still seeing to calls to added to CBFS. With:
$ make V=1 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r COREBOOT -b 0xFFE00000 ... build/util/cbfstool/cbfstool build/coreboot.pre.tmp add -f 3rdparty/blobs/pi/amd/00660F01/FP4/AGESA.bin -n "AGESA" -t raw -r FW_MAIN_A -b 0xFFE00000
$ grep -r "RO_REGION_ONLY" src/security/vboot/Makefile.inc: $(call strip_quotes,$(CONFIG_RO_REGION_ONLY)) \ src/security/vboot/Kconfig:config RO_REGION_ONLY src/northbridge/intel/haswell/Kconfig:config RO_REGION_ONLY src/soc/intel/apollolake/Kconfig:config RO_REGION_ONLY src/soc/intel/broadwell/Kconfig:config RO_REGION_ONLY src/soc/amd/picasso/Kconfig:config RO_REGION_ONLY src/soc/amd/stoneyridge/Kconfig:config RO_REGION_ONLY .config.old:CONFIG_RO_REGION_ONLY="AGESA" .config:CONFIG_RO_REGION_ONLY="AGESA" build/auto.conf:CONFIG_RO_REGION_ONLY="AGESA" build/config.h:#define CONFIG_RO_REGION_ONLY "AGESA"
Thanks for your help Mikal! Regards _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Mikal,
- If I don't have CONFIG_VPD and CONFIG_SMMSTORE enabled, the entries RW_VPD(PRESERVE) and SMMSTORE(PRESERVE) are needed?
No, not needed. You may remove them. My FMD was just an example.
- The RW_UNUSED@0x0 0x20000 could be used? Maybe is it possible to relocate the AMDFW to 0x0 instead of 0x20000?
Not possible. PSP check for certain offsets in search of its own firmware in SPI flash. All you cna do is to relocate it to CBFS to use different base address.
- CONSOLE 0x10000 is needed for something?
It is for SPI flash console logging. You also may remove it if not selected or needed.
- Is is possible to only have the payload in the RO area?
AFAIK it's not. If you put the fallback/payload name to RO_REGION_ONLY, it will probably do not launch the payload at all if executing from RW partition.
Thank you again for this valuable info. I think I could get a booting system soon. I'll try without the 'lib/cbfs: Add fallback to RO region to cbfs_boot_locate' trying to move the AGESA to try to fill the empty space playing with 'CONFIG_AGESA_BINARY_PI_LOCATION'
fallback/dsdt.aml 0x30ec0 raw 6656 none (empty) 0x32940 null 2042712 none <-------------- AGESA 0x2254c0 raw 690436 none (empty) 0x2cde40 null 1405592 none <------------- bootblock 0x425100 bootblock 944 none
Regards,
On 14.11.2019 16:02, Jorge Fernandez Monteagudo wrote:
Hi Mikal,
- If I don't have CONFIG_VPD and CONFIG_SMMSTORE enabled, the
entries RW_VPD(PRESERVE) and SMMSTORE(PRESERVE) are needed?
No, not needed. You may remove them. My FMD was just an example.
- The RW_UNUSED@0x0 0x20000 could be used? Maybe is it possible to
relocate the AMDFW to 0x0 instead of 0x20000?
Not possible. PSP check for certain offsets in search of its own firmware in SPI flash. All you cna do is to relocate it to CBFS to use different base address.
- CONSOLE 0x10000 is needed for something?
It is for SPI flash console logging. You also may remove it if not selected or needed.
- Is is possible to only have the payload in the RO area?
AFAIK it's not. If you put the fallback/payload name to RO_REGION_ONLY, it will probably do not launch the payload at all if executing from RW partition.
Thank you again for this valuable info. I think I could get a booting system soon. I'll try without the 'lib/cbfs: Add fallback to RO region to cbfs_boot_locate' trying to move the AGESA to try to fill the empty space playing with 'CONFIG_AGESA_BINARY_PI_LOCATION'
Hi Jorge,
You can try to play with VBOOT_ENABLE_CBFS_FALLBACK option to use the payload from RO region, but it is under review currently (not in the main tree).
Please do not change CONFIG_AGESA_BINARY_PI_LOCATION. The value is fixed, because the AGESA is not relocatable code. It must be put at the given offset, otherwise processor initialization will fail.
fallback/dsdt.aml 0x30ec0 raw 6656 none (empty) 0x32940 null 2042712 none <-------------- AGESA 0x2254c0 raw 690436 none (empty) 0x2cde40 null 1405592 none <------------- bootblock 0x425100 bootblock 944 none
Regards,
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Jorge Fernandez Monteagudo -
Michal Zygowski