coreboot February 2019

coreboot@coreboot.org

51 participants
43 discussions

Re: Microcode in ROM is not loaded with X60s

by Masanori Ogino

Dear Lance, 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. Best regards, Masanori

2 years, 2 months

CBMEM console to be made verbose

by Kyösti Mälkki

Hi all A change [1] 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 buffer size. Regards, Kyösti [1] https://review.coreboot.org/c/coreboot/+/31370

2 years, 2 months

Data.vbt located in wrong directory

by Neelix

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, 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 to src/mainboard/lenovo/x220/? Regards, Neelix -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMqZdepVcVGwOm/VZ6wnQKDajeeAFAlx1tZoACgkQ6wnQKDaj eeDSuQf/eKugmmLhbvsp3dqkFWOrJ/CJ9BpI9JXgiItBGtelOVk5ua/a5Sax2NKV 3AnmTYgSiaB24FECADq8yzTAnpbAM5Xvw5oj7rIFMVRrPUYSKeveQ0JE07tIuICd uZplqRBWKQty80Cj82Krs8krKDmhgTqePgoVsR8fFoikWzVs1qOThAs2HsLmDqbQ 9U+Pp668H2BcNjEgD2V4hLL+gLZrmGowPgKVlx920BVAzdoRIIjY0Zyfv4TmuRwb CGirjO/0dI+pLBBPQzuZoA4ppfb7iw7++4dzBzJZAhat0vMxUJun0FoENGxuDS/D 69BA4w15lfAN38wOuMGzhkAgIPtDRQ== =unfu -----END PGP SIGNATURE-----

2 years, 2 months

Coreboot Self-Flashing Through Payload?

by Matt B

Hi, 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 Coreboot. 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 the time) -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 flash itself 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 ourselves. 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 on seabios. -Matt

2 years, 2 months

Changed only the commit message, but Jenkins build bot still rebuilds - why?

by Mike Banon

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.

2 years, 2 months

RAM without SPD

by Zvi Vered

Hello, 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. Thank you, Zvika

2 years, 2 months

if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build

by Mike Banon

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: https://github.com/informer2016/shared_devfiles/blob/master/coreboot.rom SHA256 sum of this image = ab173394ba3ed57a73d1455a02f7d903a5f5c55a0ab5ba43b4c445e4eeeead20 Download this image, run sha256sum ./Downloads/coreboot.rom , and if it is correct - please flash it by executing sudo ./flashrom -p internal:laptop=force_I_want_a_brick,amd_imc_force=yes -w ./coreboot.rom - according to http://dangerousprototypes.com/docs/Lenovo_G505S_hacking instructions - 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: cd ./coreboot/util/cbmem make sudo ./cbmem -c > ./console.log and also 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...

2 years, 2 months

VBIOS/VBT in Coreboot

by Alex Feinman

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. CBFSPRINT coreboot.rom 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

2 years, 2 months

AMDFlaws

by Shawn

https://storage.googleapis.com/wzukusers/user-28822230/documents/5c5b3fd28b… PSP is so powerful just like ME/SPS on Intel chipset. AMD user might need a similar tool like me_cleaner? psp_cleaner? -- GNU powered it... GPL protect it... God blessing it... regards Shawn

2 years, 2 months

4.9: FSP debug level (0-3)

by Zvi Vered

Helllo, 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" ? Thank you, Zvika

2 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2019