Some additional origami info.
A talk from last year: https://ecc2017.coreboot.org/uploads/talk/presentation/51/origami-ec-status-... 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 matthewwbradley6@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#Fla...
suggest the following order of operations:
- receive a flashrom help
- erase a flash chip
- read from a flash chip
- write to a flash chip
- 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
-
Matt B