Writing AP firmware on x86 via servo (link)

[Kevin Cernekee]

Hi guys,

I am trying to reflash the AP firmware on my link (Pixel 1) via servo,
but following the instructions I found on the web has not panned out.

At [1] I see:

$ USE=dev emerge-link chromeos-u-boot
$ cros_bundle_firmware -b link --bootcmd vboot_twostop -w em100

This complains that I have no seabios.cbfs, so I specify -S and get this:

$ cros_bundle_firmware -b link --bootcmd vboot_twostop -w em100 -S
/build/link/firmware/seabios.cbfs
The 'em100' utility was not found in your path. Run the following command in
your chroot to install it: sudo -E emerge em100

This leads me down another rabbit hole:

$ sudo -E emerge em100
Calculating dependencies... done!

emerge: there are no ebuilds to satisfy "em100".

emerge: searching for similar names... nothing similar found.
$ emerge --search em100
Searching...
[ Results for search key : em100 ]
[ Applications found : 0 ]

Naively attempting to build em100 by running "make" in
~/trunk/src/third_party/em100, I see that the em100 package depends on
the 7z utility. "sudo emerge p7zip" tries to compile p7zip from
source, but apparently the p7zip-9.13 ebuild is not in working order
as it aborts on a missing symbol (SetCapacity). Running "make"
outside the chroot produces yet another set of errors.


Then I found [2], which claims that flashing a link firmware image is
as simple as:

$ cros_write_firmware /path/to/image.bin

So I ran "emerge-link coreboot chromeos-bootimage" to populate
/build/link with all (?) of the important files, and then tried it:

$ cros_write_firmware /build/link/firmware/image-link.bin
No fdtmap found in image '/build/link/firmware/image-link.bin'

The same thing happened when I grabbed the latest canary firmware
builds, and when I tried reflashing the original firmware I had pulled
off the device with "flashrom". All of these files are 8388608 bytes
long and very similar-looking. Nothing under /build/link contained
the magic "__FDTM__" signature it was looking for.

Explicitly adding the path to my newly built FDT just prompted
cros_write_firmware to complain about something else:

$ cros_write_firmware /build/link/firmware/image-link.bin -d
/build/link/firmware/dtb/link.dtb -b link
Command failed: /usr/bin/bct_dump /build/link/firmware/bct/board.bct
Error reading bct file /build/link/firmware/bct/board.bct.

I didn't see any BCT files under /build/link. Maybe there is a way to
extract it from a known-good image but I don't know how to do that.

Any thoughts on what I'm doing wrong?


[1] https://www.chromium.org/chromium-os/firmware-update
[2] https://chromium.googlesource.com/chromiumos/platform/dev-util/+/stabilize-4636.B%5E!/

[Kevin Cernekee]

On Saturday, May 23, 2015 at 12:31:23 PM UTC-7, Kevin wrote:

$ sudo -E emerge em100
Calculating dependencies... done!

emerge: there are no ebuilds to satisfy "em100".

emerge: searching for similar names... nothing similar found.
$ emerge --search em100
Searching...
[ Results for search key : em100 ]
[ Applications found : 0 ]

Naively attempting to build em100 by running "make" in
~/trunk/src/third_party/em100, I see that the em100 package depends on
the 7z utility.  "sudo emerge p7zip" tries to compile p7zip from
source, but apparently the p7zip-9.13 ebuild is not in working order
as it aborts on a missing symbol (SetCapacity).  Running "make"
outside the chroot produces yet another set of errors.

Tracing through cros_write_firmware, the comments indicate that it winds up running the em100 utility for link anyway:

https://chromium.googlesource.com/chromiumos/platform/dev-util/+/stabilize-4920.6.B/host/lib/write_firmware.py#974

So I debugged a couple of issues and made progress on compilation:

https://chromium-review.googlesource.com/273047

But now em100 says "Could not find em100pro" when I run it.  It is looking for USB VID:PID 04b4:1235, which doesn't show up in lsusb.  cros_write_firmware is running something like this to put it into the correct mode, but that has no effect for me:

dut-control spi2_vref:off spi2_buf_en:off spi2_buf_on_flex_en:off spi_hold:on

Does this require additional hardware beyond what is on the servo board (like an actual Em100Pro flash emulator device)?  If so, what is needed to flash the AP firmware using just the servo?

https://chromium-review.googlesource.com/273047

[Vincent Palatin]

On Sat, May 23, 2015 at 12:30 PM, Kevin Cernekee <cern...@chromium.org> wrote:

Hi guys,

I am trying to reflash the AP firmware on my link (Pixel 1) via servo,
but following the instructions I found on the web has not panned out.

to flash the firmware on Link using a Servo v2, we are normally using the following recipe :

dut-control spi2_vref:pp3300 spi2_buf_en:on spi2_buf_on_flex_en:on spi_hold:off cold_reset:on

sudo flashrom -p ft2232_spi:type=servo-v2 --fast-verify -w bios.bin

dut-control spi2_vref:off spi2_buf_en:off spi2_buf_on_flex_en:off cold_reset:off

There is no Device Tree on Link, that's probably instructions for ARM based machines.

 

cros_write_firmware to complain about something else:

$ cros_write_firmware /build/link/firmware/image-link.bin -d
/build/link/firmware/dtb/link.dtb -b link
Command failed: /usr/bin/bct_dump /build/link/firmware/bct/board.bct
Error reading bct file /build/link/firmware/bct/board.bct.

I didn't see any BCT files under /build/link.  Maybe there is a way to
extract it from a known-good image but I don't know how to do that.

BCT files are firmware configuration files for NVidia Tegra platforms.

 

 

Any thoughts on what I'm doing wrong?


[1] https://www.chromium.org/chromium-os/firmware-update
[2] https://chromium.googlesource.com/chromiumos/platform/dev-util/+/stabilize-4636.B%5E!/

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Vincent Palatin]

em100pro stuff is for people using real EM100 hardware to accelerate their firmware development time (by loading the SPI flash emulator rather than re-flashing the whole 8MB SPI flash every time)

it's not really related to servo (excepted we usually connect the EM100 on the servo flex). 

 

https://chromium-review.googlesource.com/273047

[Kevin Cernekee]

On Sat, May 23, 2015 at 7:55 PM, Vincent Palatin <vpal...@chromium.org> wrote:
> to flash the firmware on Link using a Servo v2, we are normally using the
> following recipe :
>
> dut-control spi2_vref:pp3300 spi2_buf_en:on spi2_buf_on_flex_en:on
> spi_hold:off cold_reset:on
> sudo flashrom -p ft2232_spi:type=servo-v2 --fast-verify -w bios.bin
> dut-control spi2_vref:off spi2_buf_en:off spi2_buf_on_flex_en:off
> cold_reset:off

Thanks, that worked.

Now that I can unbrick my device, I found that image-link.bin from the
latest firmware_from_source.tar.bz2 works OK. But if I build and
flash u-boot from ToT it just hangs. So I rewound u-boot and
vboot_reference to the firmware-link-2695.B tag, but that doesn't even
build:

i686-pc-linux-gnu-gcc -g -DVBOOT_DEBUG -Os -ffunction-sections
-fvisibility=hidden -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x01110000
-fno-builtin -ffreestanding -nostdinc -isystem
/usr/lib/gcc/i686-pc-linux-gnu/4.9.x-google/include -pipe
-fno-strict-aliasing -Wstrict-prototypes -mregparm=3
-fomit-frame-pointer -ffreestanding -fno-toplevel-reorder
-fno-stack-protector -mpreferred-stack-boundary=2 -fno-dwarf2-cfi-asm
-DREALMODE_BASE=0x7c0 -DCONFIG_X86 -D__I386__ -march=i386 -Werror
-Werror -Wall -Wstrict-prototypes -fno-stack-protector
-Wno-format-nonliteral -Wno-format-security -DNDEBUG
-DTPM_BLOCKING_CONTINUESELFTEST
-I/mnt/host/source/src/platform/vboot_reference/firmware/include
-I/mnt/host/source/src/platform/vboot_reference/firmware/lib/include
-I/mnt/host/source/src/platform/vboot_reference/firmware/lib/cgptlib/include
-I/mnt/host/source/src/platform/vboot_reference/firmware/lib/cryptolib/include
-I/mnt/host/source/src/platform/vboot_reference/firmware/lib/tpm_lite/include
-I/mnt/host/source/src/platform/vboot_reference/firmware/arch/x86/include
-MMD -MF /build/link/tmp/portage/sys-boot/chromeos-u-boot-9999/work/build/include/generated/vboot/firmware/./lib/tpm_lite/tlcl.o.d
-c -o /build/link/tmp/portage/sys-boot/chromeos-u-boot-9999/work/build/include/generated/vboot/firmware/./lib/tpm_lite/tlcl.o
lib/tpm_lite/tlcl.c
In file included from
/mnt/host/source/src/platform/vboot_reference/firmware/lib/cgptlib/include/cgptlib.h:9:0,
from lib/cgptlib/cgptlib.c:6:
/mnt/host/source/src/platform/vboot_reference/firmware/include/sysincludes.h:39:26:
fatal error: biosincludes.h: No such file or directory
#include "biosincludes.h"
^
compilation terminated.
../build.mk:18: recipe for target
'/build/link/tmp/portage/sys-boot/chromeos-u-boot-9999/work/build/include/generated/vboot/firmware/./lib/cgptlib/cgptlib.o'
failed
make[2]: *** [/build/link/tmp/portage/sys-boot/chromeos-u-boot-9999/work/build/include/generated/vboot/firmware/./lib/cgptlib/cgptlib.o]
Error 1


I had to override $FIRMWARE_ARCH in vboot_reference/Makefile to work
around it. But it seems like many other parts of my build environment
(such as cros_bundle_firmware) are no longer able to build firmware
images for link, either. Is there a documented procedure to "go back
in time" and build the firmware from this branch?

FWIW I tried "repo init -b firmware-link-2695.B ; repo sync". That
spent a couple of hours downloading stuff, then it tried to delete a
whole bunch of trees and errored out.

The goal of this exercise is to disable ec_software_sync in u-boot,
since the released version of u-boot doesn't honor the GBB flag. If
there's an easier way of doing that, maybe I don't need to rebuild
u-boot at all.

[Vincent Palatin]

On Sat, May 23, 2015 at 9:47 PM, Kevin Cernekee <cern...@chromium.org> wrote:

On Sat, May 23, 2015 at 7:55 PM, Vincent Palatin <vpal...@chromium.org> wrote:
> to flash the firmware on Link using a Servo v2, we are normally using the
> following recipe :
>
> dut-control spi2_vref:pp3300 spi2_buf_en:on spi2_buf_on_flex_en:on
> spi_hold:off cold_reset:on
> sudo flashrom -p ft2232_spi:type=servo-v2 --fast-verify -w bios.bin
> dut-control spi2_vref:off spi2_buf_en:off spi2_buf_on_flex_en:off
> cold_reset:off

Thanks, that worked.

Now that I can unbrick my device, I found that image-link.bin from the
latest firmware_from_source.tar.bz2 works OK.  But if I build and
flash u-boot from ToT it just hangs. 

To build a proper Link firmware, you need to build more packages than just u-boot (vboot_reference, coreboot, mrc), then emerge chromeos-bootimage at the end to generate the image-link you can flash.

On the firmware branch builder, today build happens to be green and it did sync the tree properly (though it didn't build anything for whatever reason, but the last PFQ on this branch was also green) :

https://<da magic builder URL>/i/chromeos.branch/builders/link%20firmware%20firmware-link-2695.B/builds/31

Actually doing it with the internal manifest (I'm not sure the external manifest ever fully built for this branch)

seems to work for me, ie :

repo init -u https://chrome-internal.googlesource.com/chromeos/manifest-internal.git --repo-url='https://chromium.googlesource.com/external/repo.git' -b firmware-link-2695.B

repo sync

./setup_board --board=link

./build_packages --board=link

cros_workon start --board=link chromeos-ec chromeos-mrc vboot_reference chromeos-coreboot-link chromeos-u-boot

emerge-link chromeos-ec chromeos-mrc vboot_reference chromeos-coreboot-link chromeos-u-boot chromeos-bootimage

[Kevin Cernekee]

On Sun, May 24, 2015 at 5:48 PM, Vincent Palatin <vpal...@chromium.org> wrote:
> On the firmware branch builder, today build happens to be green and it did
> sync the tree properly (though it didn't build anything for whatever reason,
> but the last PFQ on this branch was also green) :
> https://<da magic builder
> URL>/i/chromeos.branch/builders/link%20firmware%20firmware-link-2695.B/builds/31
>
> Actually doing it with the internal manifest (I'm not sure the external
> manifest ever fully built for this branch)
> seems to work for me, ie :
> repo init -u
> https://chrome-internal.googlesource.com/chromeos/manifest-internal.git
> --repo-url='https://chromium.googlesource.com/external/repo.git' -b
> firmware-link-2695.B
> repo sync
>
> ./setup_board --board=link
> ./build_packages --board=link
>
> cros_workon start --board=link chromeos-ec chromeos-mrc vboot_reference
> chromeos-coreboot-link chromeos-u-boot
> emerge-link chromeos-ec chromeos-mrc vboot_reference chromeos-coreboot-link
> chromeos-u-boot chromeos-bootimage

Thanks again for the off-hours tips. I was able to build
firmware-link-2695.B from a fresh tree as you described, and then
create a special AP firmware image that skips the EC software sync by
tweaking link.dts.

Not sure why rewinding my existing tree didn't work, but that's not a
blocking issue right now.