Thank you for your reply.
On Mon, Feb 25, 2019 at 4:27 AM Lance Zhao <lance.zhao(a)gmail.com> wrote:
> Current coreboot should have same level of microcode compare to intel-microcode for Linux.
Indeed. I saw a commit updating Intel microcode in last December, so I
am sure the microcode is not so ancient that it does not contain the
fix for a known errata.
A change  has been approved that applys a minimum loglevel of BIOS_DEBUG
for CBMEM console. There should be miminal performance impact as it is
nothing but writes to cacheable memory.
For some platform this could cause that pre-ram console buffer runs out of
space. My opinion is that those are too verbose and some logging should be
moved to BIOS_SPEW. If you are debugging raminit you cannot rely on
readable CBMEM console anyways so I suggest against increasing the pre-ram
-----BEGIN PGP SIGNED MESSAGE-----
I just compiled coreboot for a x220 and I got a error saying that
data.vbt wasn't located in src/mainboard/lenovo/x220. It's indeed not
in directory it should be in. Its located in
src/mainboard/lenovo/x220/variants/x220/. Can you guys return data.vbt
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
I was helping a friend with a bios issue (we may have an involuntary
coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide
a way for the BIOS to flash itself but Coreboot doesn't.
For Coreboot afaik the only two methods available are to flash with a
programmer or to flash internally from linux with iomem=relaxed. For most
proprietary BIOSs, you can boot a utility that knows what USB drives are
and flash from there.
What I'm thinking of trying, and would appreciate feedback on, is the idea
of making a Seabios floppy image specifically intended for flashing
I figure this has a few advantages:
-It's OS-agnostic, meaning you can reflash the BIOS regardless of what you
boot into, or even if there's nothing to boot at all (without running to
grab some jumper cables)
-It means you don't have to fiddle with setting iomem=relaxed on your main
install and un-setting it when you're done (I don't fancy leaving it on all
-Some level of confidence that you can trust the flashing environment,
being as it's stripped down and purpose built, while also residing on the
Might be a security advantage if flashing could be restricted to only this
pathway (and not say, through the main OS), but let's not get ahead of
I figure the easiest way would be to build a floppy image for seabios with
a kernel and a copy of busybox, with the bare essentials to find an image
on a usb drive and run flashrom. (maybe even a convenient shell script :P)
What I'm not sure on (not having built an install completely from scratch)
is what else those bare essentials might include.
Eventually something akin to (or included in?) LinuxBoot might be better,
integrating everything into a single payload and cutting out the dependency
It is guaranteed that, if I changed only the commit message, the
results of a previous build ("success +1 / failure -1") will be
repeated for a change. So it is probably a waste of resources to
rebuild even for this case, and could be more efficient to just repeat
the previous results.
I suspect the RAM on my bay-trail module has no SPD interface.
Can Intel's FSP work without SPD ?
I tried to run decode-dimms with vendor's bios and got:
No EEPROM found, try loading the eeprom or at24 module
I ran an FSP with debug info and got:
C0.D0: SPD not present.
C1.D0: SPD not present.
I almost completed refining the HJK's dGPU patches and discrete GPU is
still working at my G505S after these changes, but before submitting
the patches I would like to make sure that they are not breaking the
things for G505S without a discrete GPU. So if you have some free time
and ready to "unbrick" by the hardware flashing - although I hope the
things would go well ! - please help me by testing this coreboot build
at your G505S:
SHA256 sum of this image =
Download this image, run sha256sum ./Downloads/coreboot.rom , and if
it is correct - please flash it by executing
sudo ./flashrom -p
- according to http://dangerousprototypes.com/docs/Lenovo_G505S_hacking
then shutdown and try turning it on. It could take up to minute for
G505S to boot because of high debug level and USB debug enabled, so
wait patiently. After it reaches the SeaBIOS screen, press ESC and
choose your Linux USB or HDD to boot from - otherwise the
first-in-the-list floppy OS (MichalOS, btw it has a cool PLAYER .APP
-> Piano) will be booted by default.
If it could boot to Linux, clone the coreboot repository (if you
haven't already) and get the logs:
sudo ./cbmem -c > ./console.log
sudo dmesg > ./kernel.log
Remove the private information from these logs (such as your MAC
addresses from kernel.log or USB model from console.log) and share
these logs with me - I would like to take a look to see that there
aren't any new angry messages. Also try S3 suspend (aka
"hibernation"), see if it could resume successfully to Linux and
report the results.
If it could not boot to Linux and you don't have a FT232H or another
debug dongle to capture the logs by USB, just tell me it didn't work
and unbrick by following the hardware flashing instructions. Then I'll
try to add more precautions...
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
During the build I can see cbfstool reporting that both blobs were placed in the image:
To see the image's read-only sections as well, rerun with the -w option.
Name Offset Type Size Comp
cbfs master header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 41372 none
cpu_microcode_blob.bin 0xa280 microcode 98304 none
fallback/ramstage 0x22300 stage 90199 none
config 0x383c0 raw 1302 none
revision 0x38940 raw 612 none
spd.bin 0x38c00 spd 2048 none
--> vbt.bin 0x39440 raw 1168 LZMA (4608 decompressed)
cmos_layout.bin 0x39940 cmos_layout 904 none
(empty) 0x39d00 null 664 none
fspm.bin 0x39fc0 fsp 401408 none
(empty) 0x9c000 null 3992 none
fsps.bin 0x9cfc0 fsp 188416 none
--> pci8086,591e.rom 0xcb000 optionrom 65536 none
fallback/postcar 0xdb080 stage 16512 none
fallback/dsdt.aml 0xdf140 raw 19077 none
fallback/payload 0xe3c40 simple elf 1166029 none
(empty) 0x200780 null 997400 none
bootblock 0x2f3fc0 bootblock 49152 none
However, once the system boots, the VBIOS is not found at address 0xc0000 and VBT cannot be located either.
I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
I'm porting core boot to a bay trail board.
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it.
But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?