Some additional origami info. A talk from last year: https://ecc2017.coreboot.org/uploads/talk/presentation/51/origami-ec-status-update-g505s.pdf Some info in a thread from earlier this year: https://mail.coreboot.org/pipermail/coreboot/2018-February/086107.html The git repo: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary
I haven't heard anything more up to date. It appears the author also has his hands full with some (pretty cool) replicant work. -Matt On Sun, Sep 23, 2018 at 1:26 PM Matt B <matthewwbradl...@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@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#Flashing >> > 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@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot