Missing build instructions for AMD mainboards

[imax9000]

Please update the docs to provide build instructions for all platforms. Instructions present in hx20-hx30 branch don't work in lotus-zephyr. I'm currently trying to use generic ChromiumOS build docs, but I've no idea if that's going to even work.

[DHowett]

Hey Max!

I put together some quick instructions for the AMD Laptop 13 in a gist.

This also applies to the AMD Laptop 16 if you replace azalea with lotus in all instances.

[imax9000]

Thanks! I'll try that next, once my already running repo sync runs out of space in /tmp and crashes 😅

Also, holy shit, that's a mess of a setup. I don't know how much time I'll have to spend diffing objdump -D outputs with the firmware currently running on my EC, to ensure that I don't end up bricking it.

[imax9000]

generic ChromiumOS build docs

error: Cannot checkout chromiumos/third_party/atrusctl: OSError: [Errno 28] No space left on device: '/tmp/cros/src/third_party/atrusctl'
error: unable to create file src/mm-base-sms.h: No space left on device
error: unable to create file src/mm-bearer-list.c: No space left on device
error: unable to create file src/mm-bearer-list.h: No space left on device
error: unable to create file src/mm-bearer-mbim.c: No space left on device
error: unable to create file src/mm-bearer-mbim.h: No space left on device
error: unable to create file src/mm-bearer-qmi.c: No space left on device
error: unable to create file src/mm-bearer-qmi.h: No space left on device
error: unable to create file src/mm-broadband-bearer.c: No space left on device
error: unable to create file src/mm-broadband-bearer.h: No space left on device
error: unable to create file src/mm-broadband-modem-mbim.c: No space left on device
error: unable to create file src/mm-broadband-modem-mbim.h: No space left on device
Checking out:  23% (64/270), done in 5.829s
================================================================================
Repo command failed: RepoUnhandledExceptionError
        [Errno 28] No space left on device: '/tmp/cros/src/platform/touchpad-tests'
                                                                                                                                                                                          
Report: "repo sync -j 8" completed in  38 minutes 53 seconds
[/tmp/cros][1]% df -h .
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            31G   31G   23M 100% /tmp

Yup, definitely not doing that to build a 512k binary

[DHowett]

ensure that I don't end up bricking it.

Well, I've got some good news there. You can reflash just the RW portion (ectool.efi reflash --rw foo, ectool.efi reboot rw) if you're feeling like not bricking your laptop on the first trip into the wilds. The two AMD Frameworks Laptop can successfully boot into RW, unlike hx20/30.

[imax9000]

You can reflash just the RW portion

IIUC, I'd also need to patch this to pack rw image instead of ro: https://github.com/FrameworkComputer/EmbeddedController/blob/lotus-zephyr/zephyr/zmake/zmake/output_packers.py#L245

(No datasheet for NPCX993 out there, so I'm pretty much flying blind)

[imax9000]

/tmp/zephyr-sdk-0.16.5-1/arm-zephyr-eabi/bin/arm-zephyr-eabi-objcopy --gap-fill 0xff --output-target=binary --remove-section=.comment --remove-section=COMMON --remove-section=.eh_frame zephyr.elf zephyr.bin

--output-target=binary

Welp, there goes my plan to do function-by-function comparison =/

[DHowett]

IIUC, I'd also need to patch this to pack rw image instead of ro

In this case, no. After the build finishes, ec.bin is a full flash image (RO, RW, Flash Map/Partition Table). You'll feed the whole thing to ectool.efi and it will flash only the parts you specify. If you do not make any choices it will reflash both RO and RW.

In all cases, it will skip any vital product data or local on-flash configuration unless you request otherwise.

[imax9000]

Ah, I see.

Anyway, the initial premise of this issue still stands, but I don't think I'll be moving forward with attempts to modify EC firmware. Even looking past build issues, with no access to a robust testing setup and reliable tools for un-bricking - maintaining modifications for all the different mainboard versions would be an absolute nightmare :(

[charlottia]

Hi all! I worked at this for the last day and ended up with a way to reliably build the EC firmware with Nix: https://github.com/charlottia/FrameworkEmbeddedController-nix. It's 100% undocumented and only just this minute actually working.

Now that I have a baseline, I'll extend it into a devShell that lets one have a working copy of the EC code to build from (right now everything is frozen to the same versions as declared in that gist's framework.xml), but may this be helpful or inspiring to others too before I get there. What a .. fun toolchain setup.

Example build:

kivikakk@piret ~> ls -l result/
ls: cannot access 'result/': No such file or directory
kivikakk@piret ~> nix build github:charlottia/FrameworkEmbeddedController-nix
kivikakk@piret ~> ls -l result/
total 8260
-r--r--r-- 1 root root  524288  1. jaan   1970 ec.bin
-r-xr-xr-x 1 root root     792  1. jaan   1970 npcx_monitor.bin
-r-xr-xr-x 1 root root 3961164  1. jaan   1970 zephyr.ro.elf
-r-xr-xr-x 1 root root 3961120  1. jaan   1970 zephyr.rw.elf
kivikakk@piret ~>

It builds on Linux and macOS. Crucially, I haven't yet tested one of these images! Next I'll try the RW image, and if all good will keep pushing my luck. :) :black_cat:

[charlottia]

It can do in-tree builds now :) and is now just a fork of this repo. Some instructions at https://github.com/charlottia/FrameworkEmbeddedController/blob/lotus-azalea-nix/NIX.md if you felt like trying it, but tl;dr it builds zmake, binman etc. and makes them just work.