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 <art...@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 <mikeb...@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 <rminn...@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-coreb...@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 <rminn...@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 <mikeb...@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 <jwer...@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 <pmen...@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-le...@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-le...@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
>>
>>
>>
>> --
>> 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-le...@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-le...@coreboot.org

Reply via email to