[coreboot] Flashing Coreboot on Lenovo G505s

[Matt B]

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 <matthewwbradley6 at 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 at 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 at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180923/ae9790fb/attachment.html>