Hello flashrom,
I have uploaded 2 CLs implementing a libflashrom rust binding:
https://review.coreboot.org/c/flashrom/+/65280https://review.coreboot.org/c/flashrom/+/65281
The first creates a bindgen
(https://github.com/rust-lang/rust-bindgen) 'thin' binding generated
from the header.
The second creates a 'fat' binding, translating from more idiomatic
rust into the libflashrom API calls. The fat binding is not complete,
I have added only the parts I am using.
I have also added the first user of the fat binding, flashrom-tester:
https://review.coreboot.org/c/flashrom/+/65282
I think the first question is is the flashrom community happy to have
these bindings live inside the flashrom git repo? They could live in
their own separate repos, but keeping them with flashrom will make
keeping up with libflashrom API changes more straightforward.
Otherwise please review the implementation if you are interested.
Thanks
Evan Benn
Hello everyone,
Today I had a first meeting with my mentor Anastasia. And I'm looking
forward to see Thomas as soon as possible. We've discussed our project
goals, initial tasks and current state of the code.
My next tasks:
1) Move all par masters to new API. It includes reducing the use of
static global variables by storing them in a specific programmer data
structure.
2) Introduce default shutdown function that can be very useful.
We already have a patch for it: https://review.coreboot.org/c/flashrom/+/54890
It will be done in small steps/commits. So I hope to send a first patch
soon.
--
Joursoir
Hi, I'm trying to flash the rom of a bricked Chromebook. I've tried
multiple times, removing and reattaching the ch341a. The rom chip is still
attached to the motherboard (I've never soldered). Any help would be
appreciated!
Thanks,
Jen
jen@localhost:~> sudo ./flashrom -p ch341a_spi -w
coreboot_tiano-candy-mrchromebox_20220704.rom
flashrom v1.2-99-gfbb2b25f61 on Linux 5.14.21-150400.24.11-default (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x0000ef66! Expected=0xff,
Found=0xfb, failed byte count from 0x0000e000-0x0000efff: 0x1
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
FAILED at 0x00004de1! Expected=0xff, Found=0xf7, failed byte count from
0x00000000-0x00007fff: 0x3
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
FAILED at 0x0000561e! Expected=0xff, Found=0x7f, failed byte count from
0x00000000-0x0000ffff: 0x2
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
FAILED at 0x00008b98! Expected=0xff, Found=0xfe, failed byte count from
0x00000000-0x007fffff: 0x1f9
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
FAILED at 0x0000aa4b! Expected=0xff, Found=0xfe, failed byte count from
0x00000000-0x007fffff: 0x444
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
Looking for another erase function.
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Apparently at least some data has changed.
Your flash chip is in an unknown state.
# 28th July 2022, 6:00 - 7:00 UTC+0
Attendees: Thomas, Edward, Alex, Felix, Nikolai, Anastasia
## Decisions Summary
* As a result of going through realtek_mst_i2c_spi few feature requests
can be created for i2c infra (not release blocking). TODO aklm
* We need to contact top5 distros that use flashrom because they will
break after meson change is merged. TODO aklm to contact Gentoo first,
TODO Thomas to contact others.
## Agenda
* [quasisec] reminder that we should at some point soon have an end of
week burn down of patches that look ready to merge and try and have a
situation where authors are not merging their own patches and instead
having a consensus merge window at the end of the week. This way we can
all agree that at the time of merge everything was fine as far as we
knew if anything came up later.
* [aklm] Bugs for release “document this programmer”. Is there anything
left to do, if yes then what is left?
* (I_want_brick for programmer param for all i2c programmers
already decided on the previous meeting, so everything else)
* realtek_mst_i2c_spi
[https://ticket.coreboot.org/issues/361](https://ticket.coreboot.org/issues/…
(man page added)
* Where do opcodes come from ? should this become opaque? Not
blocking for release. TODO file bug (or change existing ticket to say
“all i2c programmers should be opaque”.)
* Abstract i2c interface to allow other OSes to work with i2c.
TODO file a bug. Not release blocking.
* Otherwise all good
* Maybe we can make a programmer type “i2c” as a part of
refactoring.
* TODO For Peter: test the programmer works and close the
ticket
* Serial has global state
* Nikolai: we need to know which chip we have
* Upstream ichspi is opaque chip
* We have another loop in our tree, which goes through flash
chips and tries to find which chip it is. This is kind of re-
implementing what is done on flashrom initialisation. There is no other
way for ichspi opaque to expose how it reads chip id in opaque master.
* Long term Thomas/Edward/Nick agree, one master with
capabilities is a better pattern but this is a very large and complex
change.
* We can send the patch upstream! With good commit message
*
[https://ticket.coreboot.org/issues/376](https://ticket.coreboot.org/issues/…
(it says review mediatek_i2c_spi)
* Why are isp and debug ports shifted? It is unusual to shift
from left to right ()
[https://github.com/flashrom/flashrom/blob/master/mediatek_i2c_spi.c#L29](ht…
* We need to resolve the comment from original patch
[https://review.coreboot.org/c/flashrom/+/61288](https://review.coreboot.org…
* TODO aklm, get scout board to test the mediatek programmer
* Assign bug to Peter
* Needs to be tested and allow_brick merged, and then it is
fine.
* Edward: two phase project for future
* Refactor board_enable.c , so that search logic separated out
* (phase 0) GPIO logic moved out from board_enable.c into
board_gpios.c here
[https://review.coreboot.org/c/flashrom/+/66174/](https://review.coreboot.or…
but that is a step towards the next step,
* (phase 1) Move the `flash_enable` code into the programmer init
so programmers are fully qualified.
* (phase 2) Board_matches logic have entries for each supported
programmer with their parameters
* quasisec put all the board data in declarative JSON that is
parsed and then fully qualifies the programmer at initialisation.
* dmi probably needs some love, this is fine ;) ..
* Thomas: What's with meson patch? We need to test
[https://review.coreboot.org/c/flashrom/+/63724](https://review.coreboot.org…
* Can break distros, we can maybe contact popular distros distros?
*
[Gentoo](https://packages.gentoo.org/packages/sys-apps/flashrom)
*
[Fedora](https://packages.fedoraproject.org/pkgs/flashrom/flashrom/)
* [SUSE /
openSUSE](https://build.opensuse.org/package/show/openSUSE:Factory/flashrom
)
* [Ubuntu](https://packages.ubuntu.com/jammy/flashrom)
* [Debian](https://packages.debian.org/bullseye/flashrom)
* [openWRT](https://openwrt.org/packages/pkgdata/flashrom)
* [Arch
Linux](https://archlinux.org/packages/community/x86_64/flashrom/)
* [Arch Linux
ARM](https://archlinuxarm.org/packages/aarch64/flashrom)
*
[NixOS](https://search.nixos.org/packages?channel=22.05&from=0&size=50&sort=…
)
*
[Alpine](https://pkgs.alpinelinux.org/package/edge/main/x86_64/flashrom
)
* aklm TODO contact Gentoo maintainer, because they also have
ebuild
* Felix: I already tested on NixOS. I am also the maintainer for
flashrom in NixOS
* Thomas: cmocka deps, most distros already have cmocka? We don’t
need this subproject. I will make a patch to remove it.
* FreeBSD needs testing and then enabling in meson build
* Minimum versions for build system? We currently have only minimum
versions in code, but not in the build system.
* For package maintainers we need to say: this is required minimum
version
Hello People,
We just got a flashrom’s own MAINTAINERS file! I wanted to share the
news with everyone.
https://github.com/flashrom/flashrom/blob/master/MAINTAINERS
There is a script which will automatically add people as reviewers to
the patch, if the patch is touching the files/area they are
“registered” for. This makes sure patches are not lost and also
answers the question “who are the best reviewers for this patch?”
Anyone else can join any code review (as usual, as it was before), but
the people from the file will be added automatically.
Is anyone interested in being a maintainer/reviewer? Maybe you know
some specific area well, and/or maybe you don’t want to miss when a
patch comes along and touches that area.
“Area” can be just one programmer that you know well, and you can take
it with “Odd Fixes” status - this is the smallest possible commitment,
but still will be very useful for flashrom.
Any area can have multiple maintainers.
Also, MAINTAINERS file have some content already, but you can of
course join the existing category if you are interested.
What to do if you are interested? You can reply to this thread or just
send a patch.
I have some thoughts on what categories/areas we can have, but that’s
my initial suggestion, it is not a complete list and everyone’s ideas
are welcome.
Many thanks!
# Programmers
In general, one programmer can be a category by itself. Some others
can be grouped (for example we have an i2c group with 3 items).
# Libflashrom (can be sub-category of Core)
libflashrom*
include/libflashrom*
# Documentation
Doxyfile
README
flashrom.8.tmpl
# Core
Flashrom.c
Layout.c
Jedec.c
Opaque.c
Spi.c
Programmer.c
Programmer_table.c
Spi25.c
Spi25_statusreg.c
Spi95.c
… and more files here, and headers
# internal
List of files here, also headers
# Configs
MAINTAINERS
# Git (can be sub-category of Configs)
.gitattributes
.gitignore
# Scripts
*.sh
util/*.nix
util/*.sh
#CLI
cli*
# Utils
Manibuilder
Flashrom_tester
ubertest
# Flashchips
flashchips.c
One file, but it has a constant stream of patches. Would be great to
have someone keeping an eye on it.
# Tests
--
Anastasia.
chronos@localhost / $ sudo flashrom -N -V --wp-disable
flashrom 99408625 on Linux 4.14.288-19292-g05373cf217cb (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
flashrom was built with LLVM Clang 15.0.0
(/var/tmp/portage/sys-devel/llvm-15.0_pre458507_p20220602-r12/work/llvm-15.0_pre458507_p20220602/clang
a58d0af058038595c93de961b725f86997cf8d4a), little endian
Command line (3 args): flashrom -N -V --wp-disable
Using default programmer "internal" with arguments "".
Acquiring lock (timeout=180 sec)...
Opened file lock "/run/lock/firmware_utility_lock"
Lock acquired.
Initializing internal programmer
/sys/class/mtd/mtd0 does not exist
Found candidate at: 00000500-00000528
Found coreboot table at 0x00000500.
Found candidate at: 00000000-000005d4
Found coreboot table at 0x00000000.
coreboot table found at 0x79b2a000.
coreboot header(24) checksum: ab1a table(1468) checksum: bd4e entries: 45
Vendor ID: Google, part ID: Phaser
Using Internal DMI decoder.
DMI string chassis-type: "Laptop"
Laptop detected via DMI.
DMI string system-manufacturer: "Google"
DMI string system-product-name: "Phaser"
DMI string system-version: "rev4"
DMI string baseboard-manufacturer: "Google"
DMI string baseboard-product-name: "Phaser"
DMI string baseboard-version: "rev4"
Found chipset "Intel Gemini Lake" with PCI ID 8086:3197.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with
it,
then please email a report to flashrom(a)flashrom.org including a verbose
(-V) log.
Thank you!
Enabling flash write... BIOS_SPI_BC = 0x9: BIOS Interface Lock-Down:
disabled, Boot BIOS Straps: 0x0 (SPI)
Top Swap: not enabled
SPI Read Configuration: prefetching enabled, caching enabled,
BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
SPIBAR = 0x0000799bbee0a000 (phys = 0xc1121000)
0x04: 0x6000 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=0, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=0
Programming OPCODES... done
0x06: 0x0010 (HSFC)
HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0
0x0c: 0x00000000 (DLOCK)
DLOCK: BMWAG_LOCKDN=0, BMRAG_LOCKDN=0, SBMWAG_LOCKDN=0, SBMRAG_LOCKDN=0,
PR0_LOCKDN=0, PR1_LOCKDN=0, PR2_LOCKDN=0, PR3_LOCKDN=0, PR4_LOCKDN=0,
SSEQ_LOCKDN=0
0x50: 0x000042c3 (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0x42, BRRA 0xc3
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is
read-only.
0x58: 0x0f7e0001 FREG1: BIOS region (0x00001000-0x00f7efff) is read-write.
0x68: 0x0fff0f7f FREG5: Device Expansion region (0x00f7f000-0x00ffffff) is
locked.
0x7C: 0x7fff7fff FREG10: unknown region (0x07fff000-0x07ffffff) has unknown
permissions.
0x80: 0x7fff7fff FREG11: unknown region (0x07fff000-0x07ffffff) has unknown
permissions.
0xE0: 0x7fff7fff FREG12: unknown region (0x07fff000-0x07ffffff) has unknown
permissions.
0xE4: 0x7fff7fff FREG13: unknown region (0x07fff000-0x07ffffff) has unknown
permissions.
0xE8: 0x7fff7fff FREG14: unknown region (0x07fff000-0x07ffffff) has unknown
permissions.
0xEC: 0x7fff7fff FREG15: unknown region (0x07fff000-0x07ffffff) has unknown
permissions.
Not all flash regions are freely accessible by flashrom. This is most likely
due to an active ME. Please see https://flashrom.org/ME for details.
At least some flash regions are read protected. You have to use a flash
layout and include only accessible regions. For write operations, you'll
additionally need the --noverify-all switch. See manpage for more details.
0xa0: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0xa1: 0xfe0000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=6
0xa4: 0x5006 (PREOP)
0xa6: 0x463b (OPTYPE)
0xa8: 0x05200302 (OPMENU)
0xac: 0xc79f0190 (OPMENU+4)
0xc4: 0xb1d82004 (LVSCC)
LVSCC: BES=0x0, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1
0xc8: 0x00002000 (UVSCC)
UVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x20
Enabling hardware sequencing by default for
Apollo/Gemini/Jasper/Elkhart/Meteor Lake.
OK.
The following protocols are supported: Programmer-specific.
Probing for Programmer Opaque flash chip, 0 kB: Chip identified:
GD25LQ128C/GD25LQ128D/GD25LQ128E
Hardware sequencing reports 1 attached SPI flash chip with a density of
16384 kB.
Added layout entry 00000000 - 00ffffff named complete flash
Found GigaDevice flash chip "GD25LQ128C/GD25LQ128D/GD25LQ128E" (16384 kB,
Programmer-specific) mapped at physical address 0x0000000000000000.
Found GigaDevice flash chip "GD25LQ128C/GD25LQ128D/GD25LQ128E" (16384 kB,
Programmer-specific).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
Reading Status register
w25_set_srp0: old status: 0x82
Writing status register
Reading Status register
w25_set_srp0: new status: 0x82
w25_disable_writeprotect(): error=1.
Restoring MMIO space at 0x799bbee0a084
Restoring MMIO space at 0x799bbee0a0ac
Restoring MMIO space at 0x799bbee0a0a8
Restoring MMIO space at 0x799bbee0a0a6
Restoring MMIO space at 0x799bbee0a0a4
restore_power_management: Re-enabling power management.
Flashrom was unable to identify the bios chip on my ASROCK AB350 PRO4
R2.0 motherboard. This isn't urgent the board is operational. I
unbricked another board with flashrom it worked well thanks. The
requested info is attached.