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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 -- [email protected] > >>>> To unsubscribe send an email to [email protected] > >>> > >>> > >>> > >>> -- > >>> Best regards, Mike Banon > >>> Open Source Community Manager of 3mdeb - https://3mdeb.com/ > >>> _______________________________________________ > >>> coreboot mailing list -- [email protected] > >>> To unsubscribe send an email to [email protected] > > > > > > > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
