Hi Nico, with the following patch, the Qemu coreboot image indeed does not write to ROM anymore.
The question is whether this is behavior that is also considered broken on qemu?
diff --git a/src/mainboard/emulation/qemu-i440fx/Kconfig
b/src/mainboard/emulation/qemu-i440fx/Kconfig
index 19f0fca5abe9..eba8d00bd761 100644
--- a/src/mainboard/emulation/qemu-i440fx/Kconfig
+++ b/src/mainboard/emulation/qemu-i440fx/Kconfig
@@ -15,7 +15,7 @@ config BOARD_SPECIFIC_OPTIONS
select MAINBOARD_FORCE_NATIVE_VGA_INIT
select HAVE_ASAN_IN_ROMSTAGE
select NO_SMM
- select BOOT_DEVICE_NOT_SPI_FLASH
+ select BOOT_DEVICE_SPI_FLASH
Julian
On Thu, 2021-11-11 at 12:20 +0100, Julian Stecklina wrote:
> Hi Nico,
>
> On Wed, 2021-11-10 at 10:54 +0100, Nico Huber wrote:
> > >
> > > AIUI, this "hacky way" should be taken, so cbfs_load_and_decompress()
> > > would never be called. First, I'd check if the path is tried, i.e.
> > > check the .config file if these are set to `y`:
> > >
> > > * CONFIG_NO_XIP_EARLY_STAGES
> >
> > Sorry, this one is inverted in the condition, it should be set to no /
> > unset, of course.
> >
> > Nico
> >
> > > * CONFIG_BOOT_DEVICE_MEMORY_MAPPED
>
> Both of thise are disabled for qemu platforms (which we use). The Qemu
> platforms
> explicitly select BOOT_DEVICE_NOT_SPI_FLASH which in turn disables
> CONFIG_BOOT_DEVICE_MEMORY_MAPPED.
>
> > >
> > > If they are, it's still possible that something fails and it falls back
> > > to cbfs_load_and_decompress(). In that case, further debugging might be
> > > needed.
>
> Julian
signature.asc
Description: This is a digitally signed message part
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
