[coreboot-gerrit] Change in coreboot[master]: Revert "lib/fmap: Disable pre-RAM cache for FSP 1.0"

[Aaron Durbin (Code Review)]

Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/37084 )

Change subject: Revert "lib/fmap: Disable pre-RAM cache for FSP 1.0"
......................................................................

Patch Set 2:
> Patch Set 2:
> > Patch Set 2:
> > > Patch Set 2:
> > > > Patch Set 2:
> > > > > Patch Set 2:
> > > > > > Patch Set 2: Code-Review-2
> > > > > >
> > > > > > > Patch Set 2:
> > > > > > > 
> > > > > > > > Patch Set 1:
> > > > > > > > 
> > > > > > > > What about rockchip? Julius added it on purpose I guess?
> > > > > > > 
> > > > > > > Then this gets -2 for the time being. I only read the title before hitting revert button :)
> > > > > >
> > > > > > And obviously SOC_INTEL_GLK wants it too...
> > > > >
> > > > > Both GLK and rk3288 do it because of code size constraints.
> > > >
> > > > We can fix GLK. Which stage failed to link with this?
> > >
> > > FYI: I just built meep w/o selecting no_fmap_cache:
> > >
> > > $ ./util/abuild/abuild -c 48 -p none -v -t GOOGLE_MEEP            
> > > Building config GOOGLE_MEEP_CROS
> > > Building GOOGLE_MEEP_CROS
> > >     GOOGLE_MEEP (default configuration)
> > >   Compiling GOOGLE_MEEP image on 48 cpus in parallel...                        
> > > GOOGLE_MEEP_CROS built successfully. (took 6s)                                 
> > > All 1 tested configurations passed.
> > >
> > > $ grep FMAP_CACHE coreboot-builds/GOOGLE_MEEP_CROS/config.h
> > > #define CONFIG_NO_FMAP_CACHE 0
> >
> > I first saw the build failures in https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/+... (visible to Googlers only, sorry). I was able to reproduce them on upstream master when I put up the config:
> >
> > i386-elf-ld.bfd: section .id LMA [00000000ffffff48,00000000ffffff7f] overlaps section .text LMA [00000000ffff8000,00000000ffffffd7]
> > i386-elf-ld.bfd: coreboot-builds/GOOGLE_MEEP_CROS/cbfs/fallback/bootblock.debug: section .id lma 0xffffff48 adjusted to 0xffffffd8
> > i386-elf-ld.bfd: coreboot-builds/GOOGLE_MEEP_CROS/cbfs/fallback/bootblock.debug: section .fit_pointer lma 0xffffffc0 adjusted to 0x100000010
> > i386-elf-ld.bfd: coreboot-builds/GOOGLE_MEEP_CROS/cbfs/fallback/bootblock.debug: section .reset lma 0xfffffff0 adjusted to 0x100000018
> >
> > So there must be something else that saved memory again, and lots of it:
> > fffffd98 T _etext
> > ffffff4a R __id_start
> >
> > Bisecting that, I found that the MIPS removal commit fixed it, which confused me, but alas, it removed 64bit int support in printf on all platforms (instead of disabling that on MIPS only), saving those precious bytes.
> >
> > With https://review.coreboot.org/c/coreboot/+/37113 applied and fmap cache enabled, meep fails again.
>
> Thanks, Patrick. I'll look into it further.

Phaser is sitting at 0x7c18 w/o 64-bit printf and 0x7e38 with 64-bit printf.
Meep is sitting at 0x7d98 w/o 64-bit printf and blows up with it (assuming 0x220 bytes for 64-bit printf support). We can make bootblock bigger. 32KiB isn't a hard limit.

Big piece of that are chip_info and the device tree devs: 
(gdb) p/x 0xffffefa0 - 0xffffb1c0                                               
$1 = 0x3de

Almost 1KiB worth.

Slimming that down would be helpful. Something to keep our eye on.