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-le...@coreboot.org > > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
