coreboot September 2018

coreboot@coreboot.org

59 participants
160 discussions

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
by Jose Trujillo 24 Sep '18

24 Sep '18

Hi Alex, I will keep in mind this but before I will check about the EC on my system because this is not an RVP board. Thank you for your advise, I'll do that. Jose Trujillo. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, September 24, 2018 4:46 PM, Alex Feinman <alexfeinman(a)hotmail.com> wrote: > Keep in mind that Intel RVP boards ship with Intel EC code, which is not compatible with Coreboot. You need to reflash it with Google EC - it's built as a part of Coreboot, or it can be built separately as well. > > --------------------------------------------------------------- > > From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Nico Huber <nico.h(a)gmx.de> > Sent: Thursday, September 20, 2018 1:16 PM > To: Jose Trujillo; Naresh G. Solanki > Cc: coreboot > Subject: Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met" > > Hi Jose, > > On 20.09.2018 15:58, Jose Trujillo via coreboot wrote: >> I will follow your advise of checking EC and about the base FW I am >> using the original UEFI AMI FW but, if still doesn't boot I will replace >> ME and descriptor as you suggested. > > Better don't. The Firmware Descriptor and ME are orthogonal to coreboot. > It's best to leave them in flash as they are once you have them working > with the original firmware. If you use flashrom, you can use a layout > file or the --ifd option and include only the BIOS region when writing. > > Nico > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
by Nico Huber 24 Sep '18

24 Sep '18

Hi Jose, On 20.09.2018 15:58, Jose Trujillo via coreboot wrote: > I will follow your advise of checking EC and about the base FW I am > using the original UEFI AMI FW but, if still doesn't boot I will replace > ME and descriptor as you suggested. Better don't. The Firmware Descriptor and ME are orthogonal to coreboot. It's best to leave them in flash as they are once you have them working with the original firmware. If you use flashrom, you can use a layout file or the --ifd option and include only the BIOS region when writing. Nico

2 1

compile coreboot for xeon 5570
by zahra rahimkhani 24 Sep '18

24 Sep '18

I am trying to use coreboot for a motherboard that have cpu of Xeon x5570. I searched about similar motherboards that coreboot support them . It is a motherboard from supermicro that is X7DB8 and support Intel Xeon™ 5000 series that were 5400/5300. but I do not know about 5500. It was in this list https://www.coreboot.org/Supported_Motherboards/old I would be grateful if you let me know about your experiences for this cpu. Do coreboot work with 5500 or not? Can I change model of motherboard ? Best,

1 0

Wired problems with Intel skylake based board
by Christian Gmeiner 24 Sep '18

24 Sep '18

Hi all I have an almost working coreboot/u-boot boot solution based on kabylake FSP. Most of the time the system works as expected but from time to rebooting the system fails completely. On my board, which is powered by an COM Express module (i3-6100U), there are two FPGAs connected via PCIe to the system where one is used to reset the system. The reset is done via SYS_RESET#. Now I run into different kind of issues: - pcie link training fails from time to time multiple times with the end result at FSP does multiple global resets. - looks like PLTRST# of the sunrisepoint pch holds the system in reset for minutes. Are there any hints to debug my issues? -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info

1 0

Re: [coreboot] Tianocore and TPM
by Jorge Fernandez Monteagudo 24 Sep '18

24 Sep '18

Hi Ben, Changing gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid do the trick! Now when I boot my system I can see the PCRs 0 to 9 populated. I have some questions regarding the values I see in the PCRs (different versions of coreboot+tianocore populate the PCRs0-7 with the same values) but I'll ask in the UEFI/EDKII mailing list. Attached are the changes I've imported into the tianocore master branch to make it works, if someone else wants to play with it... Thanks for your help! Jorge ________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: sábado, 22 de septiembre de 2018 5:33:30 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM Hi Jorge, Could you please try setting gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid to the expected value (0x286bf ...) in your .dsc file? Since there has been a change of the Tmp2IntanceLib, this GUID setting has to be changed accordingly. Since these are generic UEFI / EDKII questions and not Coreboot payload specific, could you please try posting further questions to the EDKII mailing list (https://lists.01.org/mailman/listinfo/edk2-devel)? -- there are much more EDKII expertise there. Thanks, - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Friday, September 21, 2018 10:04 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Benjamin, Enabling debug messages I've found something: Loading driver FDFF263D-5F68-4591-87BA-B768F445A9AF InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 8F3EE7C0 PDB = /mnt/develop/bettong/coreboot/master/coreboot_tiano_master/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/DEBUG_COREBOOT/X64/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe/DEBUG/Tcg2Dxe.dll Loading driver at 0x0008F3D2000 EntryPoint=0x0008F3D2240 Tcg2Dxe.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 8F3EEA18 ProtectUefiImageCommon - 0x8F3EE7C0 - 0x000000008F3D2000 - 0x000000000000D800 PROGRESS CODE: V03040002 I0 WARNING: Tpm2RegisterTpm2DeviceLib - does not support 286BF25A-C2C3-408C-B3B4-25E6758B7317 registration TPM2 not detected! Error: Image at 0008F3D2000 start failed: Unsupported PDB = /mnt/develop/bettong/coreboot/master/coreboot_tiano_master/payloads/external/tianocore/tianocore/Build/CorebootPayloadPkgX64/DEBUG_COREBOOT/X64/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe/DEBUG/Tcg2Dxe.dll PROGRESS CODE: V03040003 I0 I'll try to find more info about this warning and I'll try to see the code where the TPM2 is detected in the edk2-staging branch ________________________________________ De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> Enviado: viernes, 21 de septiembre de 2018 13:01:23 Para: You, Benjamin; coreboot(a)coreboot.org Asunto: Re: [coreboot] Tianocore and TPM Hi, I'll try modifying the Setup/Miscs/Setup.ini from CustomizationSample/Boards/Qemu to enable ftpm and generate an external payload but when boot with this coreboot.rom flashed I only get a black screen once the tianocore is executed with the next traces: BS: BS_PAYLOAD_LOAD times (us): entry 0 run 101395 exit 0 Jumping to boot code at 006009a0(8fe0f000) CPU0: stack: 8ff20000 - 8ff21000, lowest used address 8ff205e0, stack used: 2592 bytes PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03020002 I0 PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03020002 I0 PROGRESS CODE: V03020003 I0 PROGRESS CODE: V03021001 I0 PROGRESS CODE: V03040003 I0 PROGRESS CODE: V03040002 I0 PROGRESS CODE: V03040003 I0 PROGRESS CODE: V03040002 I0 I've tried mixing the dsc, dec and fdf files from the edk2-staging and the CorebootPayloadPkg ones but no TPM menu in the device manager menu is shown. I'm using NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf instead of NULL|UefiPayloadPkg/Library/Tpm2InstanceLib/Tpm2InstanceLib.inf Is it correct? Or I have to integrate this library in the CorebootPayloadPkg? Now I'm trying with the tianocore master version instead of the stable one. Do you know if there is a TPM menu shown in the device manager menu once is detected? How the TPM2 is detected? Do you have a "generic" CustomizationSample/Board? I think it's more complicated that I expected! Any hint is welcome! Jorge ________________________________________ De: coreboot <coreboot-bounces(a)coreboot.org> en nombre de Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com> Enviado: jueves, 20 de septiembre de 2018 10:31:20 Para: You, Benjamin; coreboot(a)coreboot.org Asunto: Re: [coreboot] Tianocore and TPM Hi Ben, Adding the 'generic' board it's an interesting option as a starting point to develop/porting to new boards. I'll try your suggestion to incorporate the changes from dsc and fdf files to my current working Tianocore coreboot payload. I'll report back the results! Thanks! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: jueves, 20 de septiembre de 2018 10:21:55 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: [coreboot] Tianocore and TPM Hi Jorge, You could use UEFI Payload's .dsc and .fdf files as a reference and modify the TianoCore CorebootPayload's .dsc and .fdf files accordingly for those TPM related modules. UEFI Payload is under development (in staging area) and hasn't reached the quality standard required by EDKII master. On CustomizationSample/Boards, yes it is required. However, a board's content may be trivial (as in the Qemu folder). Per your suggestion, probably we can add a board named "generic" that has all the minimalized settings so user won't have to create a new one if the "generic" one meets the needs. Thanks! - ben From: Jorge Fernandez Monteagudo [mailto:jorgefm@cirsa.com] Sent: Thursday, September 20, 2018 3:24 PM To: You, Benjamin <benjamin.you(a)intel.com>; coreboot(a)coreboot.org Subject: Re: Tianocore and TPM Hi Ben! Thanks for the info! I have one question. Have I to implement a CustomizationSample/Boards for my board? With the current tianocore payload I don't have to implement nothing to have a working UEFI... Thanks! Jorge ________________________________________ De: You, Benjamin <benjamin.you(a)intel.com> Enviado: jueves, 20 de septiembre de 2018 3:42:33 Para: Jorge Fernandez Monteagudo; coreboot(a)coreboot.org Asunto: RE: Tianocore and TPM Hi, Another note is on the use of NULL|UefiPayloadPkg/Library/Tpm2InstanceLib/Tpm2InstanceLib.inf. This lib is not fully populated right now. Please consider using NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf depending on your needs. Thanks, - ben From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of You, Benjamin Sent: Thursday, September 20, 2018 8:44 AM To: Jorge Fernandez Monteagudo <jorgefm(a)cirsa.com>; coreboot(a)coreboot.org Subject: Re: [coreboot] Tianocore and TPM Hi Jorge, The staging UEFI Payload project (https://github.com/tianocore/edk2-staging/tree/UEFIPayload) has TPM support (although turned off by default, and using "FTPM" as the name (which needs to be fixed)). Please have a look at UefiPayloadPkgIA32X64.dsc for the components under tag "$(FTPM_ENABLE)". These components mainly do the measuring of firmware components and log the results. Also there is parsing logic in Library/PlatformInfoParseLib/ParseLib.c that parses TPM info in ACPI table passed from Coreboot. (This logic hasn't been sufficiently verified as this is still a "staging" project). You might have a try. Please let us know if you see any bugs / problems in these. You might also use the EDKII mailing list for discussing issues with the UEFI Payload. Thanks, - ben From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Jorge Fernandez Monteagudo Sent: Wednesday, September 19, 2018 5:24 PM To: coreboot(a)coreboot.org Subject: [coreboot] Tianocore and TPM Hi all! I'm trying to enable the TPM2 support in the tianocore payload. The TPM2 device is working, because I've enabled the DEBUG_TPM and coreboot reports is up. I guess that I have to modify the 'CorebootPayloadPkgIa32X64.dsc' file to enable the TPM support but there are so many dependencies. Anybody has a working tianocore payload with TPM? Thanks!

1 0

Re: [coreboot] compile coreboot for xeon 5570
by Nico Huber 24 Sep '18

24 Sep '18

Hello Zahra, On 9/24/18 2:51 PM, zahra rahimkhani wrote: > I am trying to use coreboot for a motherboard that have cpu of Xeon x5570. TLDR; it won't work. coreboot needs to be adapted to every mainboard, and, in this case, even to the processor and chipset. Without docu- mentation from Intel (that we don't have), it might take an experienced coreboot developer 1 or 2 years to support this processor. > I searched about similar motherboards that coreboot support them . > It is a motherboard from supermicro that is X7DB8 and support > Intel Xeon™ 5000 series that were 5400/5300. > but I do not know about 5500. > It was in this list > https://www.coreboot.org/Supported_Motherboards/old Xeon 5400 and 5500 are very different. The older one still used FSB and had the memory controller (two channel DDR2, I guess) in the north- bridge, the newer uses QPI and has the memory controller integrated (three channel DDR3, a much different beast). There is still not a single platform with QPI supported in coreboot and the memory control- ler is likely not close to any supported one either. > > I would be grateful if you let me know about your experiences for this > cpu. Do coreboot work with 5500 or not? No, it doesn't. > Can I change model of motherboard ? Not sure, what your question is. You can use a different (supported) motherboard. But not with this CPU. Nico

1 0

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by Matt B 23 Sep '18

23 Sep '18

I'm definitely interested in helping fund the Origami-EC's development. I've been kicking around the idea of sending him an email on the subject for about a month or two. (not to mention, working open-source EC firmware could potentially benefit a LOT of other x86 boards) -Matt On Sun, Sep 23, 2018 at 2:56 PM Mike Banon <mikebdp2(a)gmail.com> wrote: > Is it possible to crowdfund Paul's KB9012 Origami EC development? > Judging by git code website he's busy working on Paper (if I > understood correctly, a libreboot fork) and some side-projects, but > hopefully he still has some interest in Origami. From paulk fr page at > personal donations: accepting "bitcoin, bank transfer or credit card > payment". Although maybe a 4th way of payments is possible: > sending/ordering some hardware to Paul's address. Would be nice to get > some comments from Paul regarding the cost estimates of completing the > Origami, then we could think about splitting the development costs > between us the G505S owners... > > Best regards, > Mike Banon >

1 0

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by Mike Banon 23 Sep '18

23 Sep '18

Is it possible to crowdfund Paul's KB9012 Origami EC development? Judging by git code website he's busy working on Paper (if I understood correctly, a libreboot fork) and some side-projects, but hopefully he still has some interest in Origami. From paulk fr page at personal donations: accepting "bitcoin, bank transfer or credit card payment". Although maybe a 4th way of payments is possible: sending/ordering some hardware to Paul's address. Would be nice to get some comments from Paul regarding the cost estimates of completing the Origami, then we could think about splitting the development costs between us the G505S owners... Best regards, Mike Banon

1 0

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by Mike Banon 23 Sep '18

23 Sep '18

> I'm looking at chronicling my experience on an ifixit article as I go Hi Matt, Please also consider expanding that G505S hacking article at dangerousprototypes wiki ( http://dangerousprototypes.com/docs/Lenovo_G505S_hacking ) , need to register at dangerousprototypes forums to get a wiki account - luckily they've fixed their captcha recently so its' possible to register again. It'd be nice to collect the available info at one place, especially such an opensource/hackers friendly one. Just drop some info like awokd did and I'd care about the formatting and other housekeeping :) > Sadly, the ebay seller sent me a G505s without discrete graphics chip when one with a chip was advertised If that's indeed so - I hope you got a partial refund from him, it's quite easy to prove that G505S doesn't have a dGPU: 1) linux logs 2) photo of the interior (don't even need to disassemble it further than a small bottom cover, LA-A092P motherboard is a version of LA-A091P motherboard with a cut out dGPU chip area and there's only one heatpipe) . Would be nice if you could double check if your motherboard there is LA-A091P or indeed LA-A092P. Or maybe I misunderstood you and you have two G505S: one "discrete version" and one "integrated only version" > (and there are tempting replacement boards for 60 bucks available should I get adventurous.) Yes, you could get LA-A091P board to replace your LA-A092P, but what about the cooling system? You'd have to get a cooling system with two heatpipes, or your discrete GPU will overheat quickly (hopefully there are some anti-burning protections). In addition to the cooling system itself, according to G505S hardware maintenance manual ( https://github.com/g505s-opensource-researcher/g505s-proprietary/blob/maste… , page 63 ) you also need to get 5 screws: two are M2.0 x 3.5mm (should be a part of any cheap "laptop screws" kit), and three are M2.0 x 3.2mm rare special screws with springs, could be extracted from some old GPU or there are some kits like this one ( https://www.aliexpress.com/item/50pcs-M2-M2-5-Spring-Screws-Computer-Graphi… , searched for 50pcs spring screws graphic ) which aren't cheap - more than $10 for screws :P > B) I would back up the factory image SEVERAL times and compare them to make sure they're the same before doing anything Please check a message above: we have a backup ROM which is "clean" (no serial numbers), so no need to have your own backup. > E) There was something a long time ago about using HVM (hardware virtualization) causing Qubes to freeze on the G505s under coreboot. I don't know if it was ever resolved or could even be reproduced It's resolved by upgrading AMD microcode at coreboot with the latest one (although it hasn't been released "officially" by AMD, just extracted from some UEFIs, so couldn't be merged to coreboot yet). > I've seen on other threads that the microcode has to be manually updated for some boards, and for the g505s this is especially complicate with many manual steps. Please check http://dangerousprototypes.com/docs/Lenovo_G505S_hacking , I wrote some scripts to do these microcode updates in a semi-automatic mode, now its' very fast to "upgrade" your freshly cloned coreboot sources - could be done in just a couple of minutes On Sun, Sep 23, 2018 at 8:28 PM Matt B <matthewwbradley6(a)gmail.com> wrote: > > Hi, > I'm in basically the same situation, having just got a g505s. I'm looking at chronicling my experience on an ifixit article as I go, though I don't really have any time right now while in class. Right now the winter break looks most likely for some serious coreboot fun. > > Sadly, the ebay seller sent me a G505s without discrete graphics chip when one with a chip was advertised. All things considered though, the machine is in really good condition and the discrete graphics chip afaik doesn't work in coreboot (yet) and has to be disabled to boot successfully (that and crossfire never caught on) so I'm not too broken up about it. Still if it ever is supported properly, it might make a nice machine learning accelerator even if crossfire graphics never gets good support. (and there are tempting replacement boards for 60 bucks available should I get adventurous.) > > As for your questions: > A) I would have thought pi would work, though I haven't looked at all into the flashing procedure yet > B) I would back up the factory image SEVERAL times and compare them to make sure they're the same before doing anything > C) See above answers. idk on this, haven't got there yet > D) Flash with factory EC firmware. Origami is an *amazing* project, but it's still going to be a bit before even "just boots the board" is possible > E) There was something a long time ago about using HVM (hardware virtualization) causing Qubes to freeze on the G505s under coreboot. I don't know if it was ever resolved or could even be reproduced. I think at the very least you want to have the most up-to-date microcode patch to fix a RANGE of issues (irq privilege escalation, IOMMU bugs, proper spectre V2 mitigation, ect.) with the stock microcode that's burned into the CPU. > > Speaking of microcode, I've seen on other threads that the microcode has to be manually updated for some boards, and for the g505s this is especially complicate with many manual steps. Can anyone provide a more explicit series of steps than the below? Is this something being worked on? > >> Regarding a NOTE from your last message: >> > For microcode embedding in coreboot to work you must check >> > both the "generate microcode update from tree" option and the >> > "use non-free blob repo" option - >> > doing the first but not the second will result in a silent fail. >> It works for KGPE-D16 but doesn't work for G505S and maybe some other >> AMD boards. Currently the only working way for those "other boards" to >> get the latest microcodes is to " xxd -i -c 8 " a microcode binary and >> then put this array of hex values into their .c file containing a >> microcode ( path like [1] ) . Tired of doing this manually, yesterday >> I wrote these microcode updating scripts : >> https://review.coreboot.org/c/coreboot/+/28425 >> AMD microcodes: scripts for applying the unofficial (not-merged-yet) updates >> Put those 4 files to your freshly cloned coreboot directory, >> run ./get_ucode_patches.sh , ./check... and ./apply... , >> and your fresh coreboot now has the latest microcodes ;-) >> But thats only for those "other boards" like G505S. To get the latest >> microcode for your KGPE-D16, you may also need to patch its' >> microcode_amd_fam15h.bin with a new 2018 microcode which sadly is not >> merged yet neither to linux-firmware nor to coreboot >> [1] example of a path to .c file with microcode - >> ./coreboot/src/vendorcode/amd/agesa/f16kb/Proc/CPU/Family/0x16/KB/F16KbId7001MicrocodePatch.c > > > That's from this thread here: > https://mail.coreboot.org/pipermail/coreboot/2018-August/087279.html > There are also instructions in this thread, that I can't make sense of: > https://mail.coreboot.org/pipermail/coreboot/2018-August/087150.html > > Sincerely, > -Matt > > On Sun, Sep 23, 2018 at 10:09 AM awokd via coreboot <coreboot(a)coreboot.org> wrote: >> >> Anac: >> > Greetings >> > >> > Following various recommendations on Lenovo G505s, I finally got myself >> > a A10-5750M with dedicated GPU. At least I think it has dedicated >> > graphics, due to the following output: >> > >> > # inxi -G >> > >> > Card-1: AMD Richland [Radeon HD 8650G] >> > Card-2: AMD Sun Pro [Radeon HD 8570A/8570M] >> > >> > While waiting for some AliExpress deliveries, I'd like to ask a few >> > questions that worry me. I have never flashed anything, but I'm used to >> > Linux, the command line and soldering. >> > >> > A) >> > According to >> > http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate >> > either a Bus Pirate or a CH341A programmer is needed for flashing >> > CoreBoot. LibreBoot folks can just take a Raspberry Pi (or better a >> > Beagle Bone Black) and a SOIC clip, while CoreBoot needs more equipment. >> > Why is that? >> > Somewhere it reads that the CH341A was faster than BusPirate. But is it >> > faster than a Raspi or BeagleBone? >> > Btw. Flashrom does in fact support RaspberryPi: >> > https://www.flashrom.org/RaspberryPi >> > >> > The reason for asking is because I really don't want to brick anything >> > and/or destroy the G505s. And I don't know how to operate a CH341A and >> > feel that I'm not really in control of this whole undertaking. Hence, >> > I'm trying to keep things as clear and easy as possible. >> >> No special hardware requirements for Coreboot vs. Libreboot. As long as >> Flashrom supports it, the Raspi should work fine. >> >> > B) >> > The instructions on >> > http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate#Fl… >> > suggest the following order of operations: >> > 1) receive a flashrom help >> > 2) erase a flash chip >> > 3) read from a flash chip >> > 4) write to a flash chip >> > 5) verify a flash chip against the file >> > >> > But should't the original content of the flash chip first got read and >> > saved before erasing it? Just in case anything goes wrong and the >> > original BIOS would be needed for some reason? So, step 2 and 3 are to >> > be swapped, right? >> >> Not sure what step #2 is for there. I'd make a backup image of the >> existing flash, then write the new one. >> >> > C) >> > Which Coreboot version should I use? v4.6 or the newest v4.8.1 ? I >> > remember @Taiidan mentioning that he used v4.6 and somewhere else it >> > reads that there will be some major changes after v4.8. Should I avoid it? >> >> Try newest, go back to older if problems. >> >> > D) >> > About flashing KB9012: Is it advisable to flash it with Origami-EC ? >> > Getting rid of serial numbers sounds nice. But is it save to do? Or is >> > there a risk of bricking the KB9012? >> > http://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary >> > http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate >> >> Have not attempted. If you want to, recommend getting Coreboot working >> first, then work on it separately. >> >> > E) >> > This machine is going to be a Qubes workstation. Are there any special >> > Coreboot options for Qubes OS that one should be aware of? >> >> See some further discussion here: >> http://dangerousprototypes.com/docs/Lenovo_G505S_hacking >> >> > Thank you! And thanks for all the work that the good folks from >> > dangerousprototypes have done and shared! >> > >> > >> > >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Flashing Coreboot on Lenovo G505s
by awokd 23 Sep '18

23 Sep '18

Mike Banon: > Problem here is that the latest AMD microcodes officially released by > AMD at linux-firmware.git are far from being the latest... AMD's f15h > recent May 2018 commit contains a version 0x6001119 [2012-07-13] > microcode for TN (CPU ID 0x610F01). Although thats slightly more > recent than what coreboot has at the moment inside > F15TnMicrocodePatch0600110F_Enc.c file, I don't understand why AMD > didn't include 0x600111F [2018-03-05] despite it has been already > available as a part of UEFI updates as early as March 2018. > > Please take a look at these two changes: > https://review.coreboot.org/c/coreboot/+/28273/ - > src/vendorcode/amd/agesa/f15tn: Update microcode to version 0x600111F > 2018-03-05 > https://review.coreboot.org/c/coreboot/+/28370/ - > src/vendorcode/amd/agesa/f16kb: Update microcode to version 0x7000110 > 2018-02-09 > Sadly it seems they couldn't be merged to coreboot until AMD releases > these microcodes "officially" to linux-firmware.git . To avoid the > manual patching work I wrote some scripts to apply these unofficial > patches (with SHA256 checksum verification) : > https://review.coreboot.org/c/coreboot/+/28425/ - AMD microcodes: > scripts for applying the unofficial (not-merged-yet) updates > > Although its' possible to manually upgrade that binary inside > linux-firmware.git to the truly latest version (with the help of > hexedit / Okteta) - its' not very convenient, and your microcode > version will always depend on your OS configuration. In addition, > there are some OS like KolibriOS which don't have any microcode > updating mechanism at all, so have to rely on coreboot in these cases > On Sun, Sep 23, 2018 at 8:57 PM Nico Huber <nico.h(a)gmx.de> wrote: >> >> On 9/23/18 7:26 PM, Matt B wrote: >>> Speaking of microcode, I've seen on other threads that the microcode has to >>> be manually updated for some boards, and for the g505s this is especially >>> complicate with many manual steps. Can anyone provide a more explicit >>> series of steps than the below? Is this something being worked on? >> >> I might be wrong on this (not experienced with AMD) but usually you can >> apply microcode updates much easier from the OS (e.g. firmware updates >> to a state sufficient to boot; OS updates to the final microcode with >> all current fixes). Plus from what I've gathered in those discussions, linux-firmware.git is lacking the appropriate equivalence table for these AMDs so even if the microcode gets updated in the file, the OS will ignore it. I noticed that same behaviour when I was hacking on it so approached it from the Coreboot side instead, but I think there's enough info now I (or anyone) could try testing and submitting a patch against linux-firmware.git adding that table. Hopefully AMD releases the updated microcode soon.

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2018