QEMU x86 i440fx/piix4 build fails for >= 32MB ROMs - Assertion IS_HOST_SPACE_ADDRESS(host_space_address) failed
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore: ... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
Dear Mike, Am 23.06.22 um 09:49 schrieb Mike Banon:
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore:
... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1]. Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`). Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/60018
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB. On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear Mike,
Am 23.06.22 um 09:49 schrieb Mike Banon:
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore:
... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1].
Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
Kind regards,
Paul
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash: OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134 Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote:
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB.
On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear Mike,
Am 23.06.22 um 09:49 schrieb Mike Banon:
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore:
... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1].
Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
Kind regards,
Paul
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
Can the system you are discussing actually use larger than 16 MB rom? I am wondering about your use of the phrase “out of curiosity” On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote:
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem
On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote:
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB.
On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de>
wrote:
Dear Mike,
Am 23.06.22 um 09:49 schrieb Mike Banon:
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore:
... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE
build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config)
CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool:
/home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed.
make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1].
Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
Kind regards,
Paul
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies , guess what wonders we can do with 31 MB... ;-) On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote:
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote:
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem
On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote:
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB.
On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear Mike,
Am 23.06.22 um 09:49 schrieb Mike Banon:
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore:
... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1].
Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
Kind regards,
Paul
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
Hi Mike, SPI NOR flash chips with more than 16MByte use 4 byte addresses while ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers on older systems often only support the 3 byte address mode. Also typically only up to 16 MBytes worth of SPI flash contents can be mapped right below the 4GB boundary, since the 16MByte below that contain the MMIO of for example LAPIC and IOAPIC. Had a quick look at the BKDG for family 16h model 30h, which is newer than the chip used on G505S or A88XM-E, and it didn't have the registers in the SPI controller that I'd expect to be present if it supports the 4 byte address mode. Regards, Felix On 19/02/2024 19:55, Mike Banon wrote:
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies , guess what wonders we can do with 31 MB... ;-)
On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote:
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote:
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem
On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote:
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB.
On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
Dear Mike,
Am 23.06.22 um 09:49 schrieb Mike Banon:
If I use a default config for i440fx/piix4, building a 16MB ROM works fine, but 32MB or 64MB doesn't work anymore:
... CC postcar/southbridge/intel/common/rtc.o LINK cbfs/fallback/postcar.debug OBJCOPY cbfs/fallback/romstage.elf CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) CC+STRIP src/lib/cbfs_master_header.c OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33553892 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1].
Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
Kind regards,
Paul
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible On Mon, Feb 19, 2024 at 12:11 Felix Held <felix-coreboot@felixheld.de> wrote:
Hi Mike,
SPI NOR flash chips with more than 16MByte use 4 byte addresses while ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers on older systems often only support the 3 byte address mode. Also typically only up to 16 MBytes worth of SPI flash contents can be mapped right below the 4GB boundary, since the 16MByte below that contain the MMIO of for example LAPIC and IOAPIC. Had a quick look at the BKDG for family 16h model 30h, which is newer than the chip used on G505S or A88XM-E, and it didn't have the registers in the SPI controller that I'd expect to be present if it supports the 4 byte address mode.
Regards, Felix
On 19/02/2024 19:55, Mike Banon wrote:
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies , guess what wonders we can do with 31 MB... ;-)
On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote:
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote:
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool:
/media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186:
cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem
On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote:
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB.
On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de>
wrote:
Dear Mike,
Am 23.06.22 um 09:49 schrieb Mike Banon: > If I use a default config for i440fx/piix4, building a 16MB ROM
works
> fine, but 32MB or 64MB doesn't work anymore: > > ... > CC postcar/southbridge/intel/common/rtc.o > LINK cbfs/fallback/postcar.debug > OBJCOPY cbfs/fallback/romstage.elf > CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) > CC+STRIP src/lib/cbfs_master_header.c > OBJCOPY cbfs/fallback/bootblock.elf > OBJCOPY bootblock.raw.elf > OBJCOPY bootblock.raw.bin > Created CBFS (capacity = 33553892 bytes) > BOOTBLOCK > CBFS cbfs_master_header > CBFS fallback/romstage > cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. > make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted
Thank you for the report. It looks like a regression of commit 20ad36547e25 (cbfstool: Do host space address conversion earlier when adding files) [1].
Building a 32 MB ROM also fails for emulation/qemu-q35 (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`).
Kind regards,
Paul
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ 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
Dear friends, thank you very much for all your replies - especially to Felix Held for his research on the possibility of >16 MB SPI flash on these AMD boards.
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
Hmmm... there could be newer boards with 4-byte SPI Flash controller, and by the way there is no physical impossibility for QEMU - which is also failing. I just tried the latest coreboot (so without any git reverts of restore_agesa.sh that restore the opensource AGESA boards) - picked a virtual BOARD_EMULATION_QEMU_X86_I440FX board with almost-default coreboot config (only set CONFIG_COREBOOT_ROMSIZE_KB_65536 and CONFIG_CBFS_SIZE=0x04000000 , everything else is unchanged) - but have exactly the same error: ... CC bootblock/mainboard/emulation/qemu-i440fx/bootmode.o CC bootblock/mainboard/emulation/qemu-i440fx/fw_cfg.o CC bootblock/southbridge/intel/common/reset.o CC bootblock/southbridge/intel/common/rtc.o CC bootblock/southbridge/intel/i82371eb/bootblock.o LINK cbfs/fallback/bootblock.debug /my-path-to/coreboot-new/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with RWX permissions OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 67108324 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 67108864 cbfstool: /my-path-to/coreboot-new/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1211: build/coreboot.pre] Error 13 On Mon, Feb 19, 2024 at 9:24 PM ron minnich <rminnich@gmail.com> wrote:
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
On Mon, Feb 19, 2024 at 12:11 Felix Held <felix-coreboot@felixheld.de> wrote:
Hi Mike,
SPI NOR flash chips with more than 16MByte use 4 byte addresses while ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers on older systems often only support the 3 byte address mode. Also typically only up to 16 MBytes worth of SPI flash contents can be mapped right below the 4GB boundary, since the 16MByte below that contain the MMIO of for example LAPIC and IOAPIC. Had a quick look at the BKDG for family 16h model 30h, which is newer than the chip used on G505S or A88XM-E, and it didn't have the registers in the SPI controller that I'd expect to be present if it supports the 4 byte address mode.
Regards, Felix
On 19/02/2024 19:55, Mike Banon wrote:
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies , guess what wonders we can do with 31 MB... ;-)
On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote:
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote:
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem
On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote:
I can see a little bug that makes this return a confusing error (it should have really failed with `SPI flash address(0x300) not in any mmap window!`), and we can fix that if you want. But that still won't make this build (and my patch didn't cause the underlying problem, before that it may have built an image but it probably wouldn't have booted). By default cbfstool only expects the top 16MB of the flash to be memory-mapped, so it cannot link XIP stages into areas outside of that. The real solution is to either change your FMAP to put the COREBOOT section into the top 16MB (we might want to change the auto-generated default FMAP to do that), or pass --ext-win-base/--ext-win-size options to cbfstool to tell it how to map areas below the top 16MB.
On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote: > > Dear Mike, > > > Am 23.06.22 um 09:49 schrieb Mike Banon: >> If I use a default config for i440fx/piix4, building a 16MB ROM works >> fine, but 32MB or 64MB doesn't work anymore: >> >> ... >> CC postcar/southbridge/intel/common/rtc.o >> LINK cbfs/fallback/postcar.debug >> OBJCOPY cbfs/fallback/romstage.elf >> CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) >> CC+STRIP src/lib/cbfs_master_header.c >> OBJCOPY cbfs/fallback/bootblock.elf >> OBJCOPY bootblock.raw.elf >> OBJCOPY bootblock.raw.bin >> Created CBFS (capacity = 33553892 bytes) >> BOOTBLOCK >> CBFS cbfs_master_header >> CBFS fallback/romstage >> cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. >> make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted > > Thank you for the report. It looks like a regression of commit > 20ad36547e25 (cbfstool: Do host space address conversion earlier when > adding files) [1]. > > Building a 32 MB ROM also fails for emulation/qemu-q35 > (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`). > > > Kind regards, > > Paul > > > [1]: https://review.coreboot.org/c/coreboot/+/60018 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ 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
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
Hi Mike Same thing as on that AMD platform. Qemu does not support that. In general x86 will require a special memory map for larger than 16M boot medium, as below 4G - 16M there are other default MMIO things that will conflict, like the LAPIC base. That capability to deal with larger flash is only present on fairly recent hardware and in that case coreboot often supports it. Kind regards. On Tue, Feb 20, 2024 at 4:42 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, thank you very much for all your replies - especially to Felix Held for his research on the possibility of >16 MB SPI flash on these AMD boards.
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
Hmmm... there could be newer boards with 4-byte SPI Flash controller, and by the way there is no physical impossibility for QEMU - which is also failing.
I just tried the latest coreboot (so without any git reverts of restore_agesa.sh that restore the opensource AGESA boards) - picked a virtual BOARD_EMULATION_QEMU_X86_I440FX board with almost-default coreboot config (only set CONFIG_COREBOOT_ROMSIZE_KB_65536 and CONFIG_CBFS_SIZE=0x04000000 , everything else is unchanged) - but have exactly the same error:
... CC bootblock/mainboard/emulation/qemu-i440fx/bootmode.o CC bootblock/mainboard/emulation/qemu-i440fx/fw_cfg.o CC bootblock/southbridge/intel/common/reset.o CC bootblock/southbridge/intel/common/rtc.o CC bootblock/southbridge/intel/i82371eb/bootblock.o LINK cbfs/fallback/bootblock.debug /my-path-to/coreboot-new/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with RWX permissions OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 67108324 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 67108864 cbfstool: /my-path-to/coreboot-new/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1211: build/coreboot.pre] Error 13
On Mon, Feb 19, 2024 at 9:24 PM ron minnich <rminnich@gmail.com> wrote:
I guess what I’m thinking is I’m not sure it’s worth the effort to make
a build work for something that is physically impossible
On Mon, Feb 19, 2024 at 12:11 Felix Held <felix-coreboot@felixheld.de>
wrote:
Hi Mike,
SPI NOR flash chips with more than 16MByte use 4 byte addresses while ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers on older systems often only support the 3 byte address mode. Also typically only up to 16 MBytes worth of SPI flash contents can be mapped right below the 4GB boundary, since the 16MByte below that contain the MMIO of for example LAPIC and IOAPIC. Had a quick look at the BKDG for family 16h model 30h, which is newer than the chip used on G505S or A88XM-E, and it didn't have the registers in the SPI controller that I'd expect to be present if it supports the 4 byte address mode.
Regards, Felix
On 19/02/2024 19:55, Mike Banon wrote:
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) -
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies
, guess what wonders we can do with 31 MB... ;-)
On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote:
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote:
Small bump, I am still having this error while (out of curiosity) trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash:
OBJCOPY bootblock.raw.bin Created CBFS (capacity = 33488356 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 33554432 cbfstool:
/media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186:
cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134
Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large sizes are a problem
On Sat, Jun 25, 2022 at 12:55 AM Julius Werner < jwerner@chromium.org> wrote: > > I can see a little bug that makes this return a confusing error (it > should have really failed with `SPI flash address(0x300) not in any > mmap window!`), and we can fix that if you want. But that still won't > make this build (and my patch didn't cause the underlying problem, > before that it may have built an image but it probably wouldn't have > booted). By default cbfstool only expects the top 16MB of the flash to > be memory-mapped, so it cannot link XIP stages into areas outside of > that. The real solution is to either change your FMAP to put the > COREBOOT section into the top 16MB (we might want to change the > auto-generated default FMAP to do that), or pass > --ext-win-base/--ext-win-size options to cbfstool to tell it how to > map areas below the top 16MB. > > On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote: >> >> Dear Mike, >> >> >> Am 23.06.22 um 09:49 schrieb Mike Banon: >>> If I use a default config for i440fx/piix4, building a 16MB ROM works >>> fine, but 32MB or 64MB doesn't work anymore: >>> >>> ... >>> CC postcar/southbridge/intel/common/rtc.o >>> LINK cbfs/fallback/postcar.debug >>> OBJCOPY cbfs/fallback/romstage.elf >>> CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) >>> CC+STRIP src/lib/cbfs_master_header.c >>> OBJCOPY cbfs/fallback/bootblock.elf >>> OBJCOPY bootblock.raw.elf >>> OBJCOPY bootblock.raw.bin >>> Created CBFS (capacity = 33553892 bytes) >>> BOOTBLOCK >>> CBFS cbfs_master_header >>> CBFS fallback/romstage >>> cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. >>> make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted >> >> Thank you for the report. It looks like a regression of commit >> 20ad36547e25 (cbfstool: Do host space address conversion earlier when >> adding files) [1]. >> >> Building a 32 MB ROM also fails for emulation/qemu-q35 >> (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`). >> >> >> Kind regards, >> >> Paul >> >> >> [1]: https://review.coreboot.org/c/coreboot/+/60018 > _______________________________________________ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ 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
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi there Arthur, since QEMU could be a convenient playground for those who are using this recent hardware (i.e. they would like to try embedding a small Linux ISO into a coreboot+SeaBIOS ROM for QEMU and see how it works from there) - it would've been nice to have this capability On Tue, Feb 20, 2024 at 7:05 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
Hi Mike
Same thing as on that AMD platform. Qemu does not support that. In general x86 will require a special memory map for larger than 16M boot medium, as below 4G - 16M there are other default MMIO things that will conflict, like the LAPIC base. That capability to deal with larger flash is only present on fairly recent hardware and in that case coreboot often supports it.
Kind regards.
On Tue, Feb 20, 2024 at 4:42 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, thank you very much for all your replies - especially to Felix Held for his research on the possibility of >16 MB SPI flash on these AMD boards.
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
Hmmm... there could be newer boards with 4-byte SPI Flash controller, and by the way there is no physical impossibility for QEMU - which is also failing.
I just tried the latest coreboot (so without any git reverts of restore_agesa.sh that restore the opensource AGESA boards) - picked a virtual BOARD_EMULATION_QEMU_X86_I440FX board with almost-default coreboot config (only set CONFIG_COREBOOT_ROMSIZE_KB_65536 and CONFIG_CBFS_SIZE=0x04000000 , everything else is unchanged) - but have exactly the same error:
... CC bootblock/mainboard/emulation/qemu-i440fx/bootmode.o CC bootblock/mainboard/emulation/qemu-i440fx/fw_cfg.o CC bootblock/southbridge/intel/common/reset.o CC bootblock/southbridge/intel/common/rtc.o CC bootblock/southbridge/intel/i82371eb/bootblock.o LINK cbfs/fallback/bootblock.debug /my-path-to/coreboot-new/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with RWX permissions OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 67108324 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 67108864 cbfstool: /my-path-to/coreboot-new/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1211: build/coreboot.pre] Error 13
On Mon, Feb 19, 2024 at 9:24 PM ron minnich <rminnich@gmail.com> wrote:
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
On Mon, Feb 19, 2024 at 12:11 Felix Held <felix-coreboot@felixheld.de> wrote:
Hi Mike,
SPI NOR flash chips with more than 16MByte use 4 byte addresses while ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers on older systems often only support the 3 byte address mode. Also typically only up to 16 MBytes worth of SPI flash contents can be mapped right below the 4GB boundary, since the 16MByte below that contain the MMIO of for example LAPIC and IOAPIC. Had a quick look at the BKDG for family 16h model 30h, which is newer than the chip used on G505S or A88XM-E, and it didn't have the registers in the SPI controller that I'd expect to be present if it supports the 4 byte address mode.
Regards, Felix
On 19/02/2024 19:55, Mike Banon wrote:
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies , guess what wonders we can do with 31 MB... ;-)
On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote:
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote: > > Small bump, I am still having this error while (out of curiosity) > trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash: > > OBJCOPY bootblock.raw.bin > Created CBFS (capacity = 33488356 bytes) > BOOTBLOCK > CBFS cbfs_master_header > CBFS fallback/romstage > Image SIZE 33554432 > cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: > cbfstool_convert_mkstage: Assertion > `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. > Aborted (core dumped) > make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134 > > Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large > sizes are a problem > > On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote: >> >> I can see a little bug that makes this return a confusing error (it >> should have really failed with `SPI flash address(0x300) not in any >> mmap window!`), and we can fix that if you want. But that still won't >> make this build (and my patch didn't cause the underlying problem, >> before that it may have built an image but it probably wouldn't have >> booted). By default cbfstool only expects the top 16MB of the flash to >> be memory-mapped, so it cannot link XIP stages into areas outside of >> that. The real solution is to either change your FMAP to put the >> COREBOOT section into the top 16MB (we might want to change the >> auto-generated default FMAP to do that), or pass >> --ext-win-base/--ext-win-size options to cbfstool to tell it how to >> map areas below the top 16MB. >> >> On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote: >>> >>> Dear Mike, >>> >>> >>> Am 23.06.22 um 09:49 schrieb Mike Banon: >>>> If I use a default config for i440fx/piix4, building a 16MB ROM works >>>> fine, but 32MB or 64MB doesn't work anymore: >>>> >>>> ... >>>> CC postcar/southbridge/intel/common/rtc.o >>>> LINK cbfs/fallback/postcar.debug >>>> OBJCOPY cbfs/fallback/romstage.elf >>>> CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) >>>> CC+STRIP src/lib/cbfs_master_header.c >>>> OBJCOPY cbfs/fallback/bootblock.elf >>>> OBJCOPY bootblock.raw.elf >>>> OBJCOPY bootblock.raw.bin >>>> Created CBFS (capacity = 33553892 bytes) >>>> BOOTBLOCK >>>> CBFS cbfs_master_header >>>> CBFS fallback/romstage >>>> cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. >>>> make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted >>> >>> Thank you for the report. It looks like a regression of commit >>> 20ad36547e25 (cbfstool: Do host space address conversion earlier when >>> adding files) [1]. >>> >>> Building a 32 MB ROM also fails for emulation/qemu-q35 >>> (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`). >>> >>> >>> Kind regards, >>> >>> Paul >>> >>> >>> [1]: https://review.coreboot.org/c/coreboot/+/60018 >> _______________________________________________ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-leave@coreboot.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ > _______________________________________________ > 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
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
With --ext-win-base now replaced by --mmap (since https://review.coreboot.org/68160), it should be easier to make the QEMU Makefiles adapt automatically to the right flash window. I think if you just add something like CBFSTOOL_ADD_CMD_OPTIONS += --mmap 0:$(call int-subtract, 0x100000000 $(CONFIG_ROM_SIZE)):$(CONFIG_ROM_SIZE) to src/cpu/qemu-x86/Makefile.mk, that should solve your problem in a clean way. On Tue, Feb 20, 2024 at 9:36 AM Mike Banon <mikebdp2@gmail.com> wrote:
Hi there Arthur,
since QEMU could be a convenient playground for those who are using this recent hardware (i.e. they would like to try embedding a small Linux ISO into a coreboot+SeaBIOS ROM for QEMU and see how it works from there) - it would've been nice to have this capability
On Tue, Feb 20, 2024 at 7:05 PM Arthur Heymans <arthur@aheymans.xyz> wrote:
Hi Mike
Same thing as on that AMD platform. Qemu does not support that. In general x86 will require a special memory map for larger than 16M boot medium, as below 4G - 16M there are other default MMIO things that will conflict, like the LAPIC base. That capability to deal with larger flash is only present on fairly recent hardware and in that case coreboot often supports it.
Kind regards.
On Tue, Feb 20, 2024 at 4:42 PM Mike Banon <mikebdp2@gmail.com> wrote:
Dear friends, thank you very much for all your replies - especially to Felix Held for his research on the possibility of >16 MB SPI flash on these AMD boards.
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
Hmmm... there could be newer boards with 4-byte SPI Flash controller, and by the way there is no physical impossibility for QEMU - which is also failing.
I just tried the latest coreboot (so without any git reverts of restore_agesa.sh that restore the opensource AGESA boards) - picked a virtual BOARD_EMULATION_QEMU_X86_I440FX board with almost-default coreboot config (only set CONFIG_COREBOOT_ROMSIZE_KB_65536 and CONFIG_CBFS_SIZE=0x04000000 , everything else is unchanged) - but have exactly the same error:
... CC bootblock/mainboard/emulation/qemu-i440fx/bootmode.o CC bootblock/mainboard/emulation/qemu-i440fx/fw_cfg.o CC bootblock/southbridge/intel/common/reset.o CC bootblock/southbridge/intel/common/rtc.o CC bootblock/southbridge/intel/i82371eb/bootblock.o LINK cbfs/fallback/bootblock.debug /my-path-to/coreboot-new/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: warning: build/cbfs/fallback/bootblock.debug has a LOAD segment with RWX permissions OBJCOPY cbfs/fallback/bootblock.elf OBJCOPY bootblock.raw.elf OBJCOPY bootblock.raw.bin Created CBFS (capacity = 67108324 bytes) BOOTBLOCK CBFS cbfs_master_header CBFS fallback/romstage Image SIZE 67108864 cbfstool: /my-path-to/coreboot-new/util/cbfstool/cbfstool.c:1186: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. Aborted (core dumped) make: *** [Makefile.mk:1211: build/coreboot.pre] Error 13
On Mon, Feb 19, 2024 at 9:24 PM ron minnich <rminnich@gmail.com> wrote:
I guess what I’m thinking is I’m not sure it’s worth the effort to make a build work for something that is physically impossible
On Mon, Feb 19, 2024 at 12:11 Felix Held <felix-coreboot@felixheld.de> wrote:
Hi Mike,
SPI NOR flash chips with more than 16MByte use 4 byte addresses while ones with up to 16MBytes use 3 byte addresses. The SPI flash controllers on older systems often only support the 3 byte address mode. Also typically only up to 16 MBytes worth of SPI flash contents can be mapped right below the 4GB boundary, since the 16MByte below that contain the MMIO of for example LAPIC and IOAPIC. Had a quick look at the BKDG for family 16h model 30h, which is newer than the chip used on G505S or A88XM-E, and it didn't have the registers in the SPI controller that I'd expect to be present if it supports the 4 byte address mode.
Regards, Felix
On 19/02/2024 19:55, Mike Banon wrote:
Theoretically - yes, if someone finds & solders there a 32 MB (256 megabit) SPI Flash chip with 8 pins. Hopefully, as the proprietary UEFIs become more & more bloated, these large capacity chips will become more widely available in the near future. And, since a coreboot itself consumes less than 1MB on these "opensource AGESA" AMD systems such as G505S and A88XM-E, all this room will allow some very interesting experiments! If even 3 MB is enough for me to put 9 of 10 floppies of the collection described here (thanks to LZMA compression) - http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies , guess what wonders we can do with 31 MB... ;-)
On Mon, Feb 19, 2024 at 7:17 PM ron minnich <rminnich@gmail.com> wrote: > > Can the system you are discussing actually use larger than 16 MB rom? > > I am wondering about your use of the phrase “out of curiosity” > > On Mon, Feb 19, 2024 at 07:05 Mike Banon <mikebdp2@gmail.com> wrote: >> >> Small bump, I am still having this error while (out of curiosity) >> trying to build the Lenovo G505S ROM for 32 MB or 64 MB spi flash: >> >> OBJCOPY bootblock.raw.bin >> Created CBFS (capacity = 33488356 bytes) >> BOOTBLOCK >> CBFS cbfs_master_header >> CBFS fallback/romstage >> Image SIZE 33554432 >> cbfstool: /media/mint/2183183a-158f-476a-81af-b42534a68706/shared/core/coreboot/util/cbfstool/cbfstool.c:1186: >> cbfstool_convert_mkstage: Assertion >> `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. >> Aborted (core dumped) >> make: *** [Makefile.mk:1210: build/coreboot.pre] Error 134 >> >> Meanwhile, it builds fine for 4 MB / 8 MB / 16 MB , only these large >> sizes are a problem >> >> On Sat, Jun 25, 2022 at 12:55 AM Julius Werner <jwerner@chromium.org> wrote: >>> >>> I can see a little bug that makes this return a confusing error (it >>> should have really failed with `SPI flash address(0x300) not in any >>> mmap window!`), and we can fix that if you want. But that still won't >>> make this build (and my patch didn't cause the underlying problem, >>> before that it may have built an image but it probably wouldn't have >>> booted). By default cbfstool only expects the top 16MB of the flash to >>> be memory-mapped, so it cannot link XIP stages into areas outside of >>> that. The real solution is to either change your FMAP to put the >>> COREBOOT section into the top 16MB (we might want to change the >>> auto-generated default FMAP to do that), or pass >>> --ext-win-base/--ext-win-size options to cbfstool to tell it how to >>> map areas below the top 16MB. >>> >>> On Thu, Jun 23, 2022 at 1:09 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote: >>>> >>>> Dear Mike, >>>> >>>> >>>> Am 23.06.22 um 09:49 schrieb Mike Banon: >>>>> If I use a default config for i440fx/piix4, building a 16MB ROM works >>>>> fine, but 32MB or 64MB doesn't work anymore: >>>>> >>>>> ... >>>>> CC postcar/southbridge/intel/common/rtc.o >>>>> LINK cbfs/fallback/postcar.debug >>>>> OBJCOPY cbfs/fallback/romstage.elf >>>>> CREATE build/mainboard/emulation/qemu-i440fx/cbfs-file.vqaXlP.out (from /home/my_custom_path_to/coreboot/.config) >>>>> CC+STRIP src/lib/cbfs_master_header.c >>>>> OBJCOPY cbfs/fallback/bootblock.elf >>>>> OBJCOPY bootblock.raw.elf >>>>> OBJCOPY bootblock.raw.bin >>>>> Created CBFS (capacity = 33553892 bytes) >>>>> BOOTBLOCK >>>>> CBFS cbfs_master_header >>>>> CBFS fallback/romstage >>>>> cbfstool: /home/my_custom_path_to/coreboot/util/cbfstool/cbfstool.c:1145: cbfstool_convert_mkstage: Assertion `IS_HOST_SPACE_ADDRESS(host_space_address)' failed. >>>>> make: *** [Makefile.inc:1116: build/coreboot.pre] Aborted >>>> >>>> Thank you for the report. It looks like a regression of commit >>>> 20ad36547e25 (cbfstool: Do host space address conversion earlier when >>>> adding files) [1]. >>>> >>>> Building a 32 MB ROM also fails for emulation/qemu-q35 >>>> (`CONFIG_BOARD_EMULATION_QEMU_X86_Q35=y`). >>>> >>>> >>>> Kind regards, >>>> >>>> Paul >>>> >>>> >>>> [1]: https://review.coreboot.org/c/coreboot/+/60018 >>> _______________________________________________ >>> coreboot mailing list -- coreboot@coreboot.org >>> To unsubscribe send an email to coreboot-leave@coreboot.org >> >> >> >> -- >> Best regards, Mike Banon >> Open Source Community Manager of 3mdeb - https://3mdeb.com/ >> _______________________________________________ >> 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
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
participants (6)
-
Arthur Heymans -
Felix Held -
Julius Werner -
Mike Banon -
Paul Menzel -
ron minnich