i don't know if my screen is blank because of a hardware issue or setting,
but i can not even access the bios. the screen is blank at the very start
i came across flashrom and coreboot pages after a duckduck search, but i
can't figure out what environment these programs are designed for, or how
to use the programs. for example, i can't figure out if i can use these
programs to flash a bios without any keyboard input (because there's no
video)
are there pages on what flashrom is and how to …
[View More]use it
or what coreboot is, and how to use it
i did look around, but these questions weren't part of the faqs
[View Less]
Hi,
I just tried to flash bios in nvidia p106-100 with. But I get errors :
sudo flashrom --programmer ch341a_spi -w p106v.rom
flashrom v1.2 on Linux 5.15.0-46-generic (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 "W25Q40EW" (512 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, …
[View More]Found=0xe0, failed byte count from 0x00000000-0x00000fff: 0x1000
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x00007fff: 0x8000
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x0000ffff: 0x10000
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x0007ffff: 0x80000
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase function.
FAILED at 0x00000000! Expected=0xff, Found=0xe0, failed byte count from 0x00000000-0x0007ffff: 0x80000
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.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
What to do next ?
Best Regards
Delevic
[View Less]
# 25th Aug 2022, 6:00 - 7:00 UTC+0
Attendees: Alex, Felix, Evan, Anastasia, Edward
## Decisions Summary
* A link pointing to the meeting will be added on the Contacts page.
* We want to discuss the minimum required versions of our (build-
)dependencies. We don’t want ifdefs checking for library versions in
the code. When a programmer doesn’t support a library version, the
build system should not enable it.
## Agenda
* [aklm] Are there any objections if I will add info about this meeting
…
[View More]on the Contacts page?
* Clarify this is NOT a support forum, not a troubleshooting forum
* [Felix] Rework the flash chips database / minimize the compiled
version of flashchips.c in size
* In most cases, embedded applications only need a small selection
of the available flash chips. If we are able to shrink it somehow, this
could free useful space for other applications or use cases.
* One approach: Currently, flash chips are grouped by vendors. So
add compiler flags enabling or disabling these.
* Another approach: Rework the way flash chips are organized.
* flashchips.c is pretty inflexible and it’s complicated to get
this in a format so that flash chips can be listed on the website.
* Thus, store flash chips in an JSON file (may be any other
format), which opens lots of possibilities.
* The website could just use the JSON and list the data. For
flashrom itself, we could write a little script (and add this to the
build system) which converts the JSON data to C code. This way, we also
could filter for specific flash chip characteristics (protocols,
vendor, name, …), in case only a group or some specific chips are
wanted.
* Another advantage: We could add an API to (lib-)flashrom so
that the user can use their own JSON file and so the user can add new
(or change) flash chips without recompiling flashrom very easily. So
flash chips can be compiled into flashrom but they also can be loaded
using the JSON format.
* Edward: there are patches for review
[https://review.coreboot.org/q/topic:declarative_flashchips.c_complete](http…
* [Felix/Thomas] We should define minimum required versions of
libraries and (build-)dependencies
*
[https://review.coreboot.org/c/flashrom/+/65919](https://review.coreboot.org…
* Created a sheet to collect the versions
*
[https://review.coreboot.org/c/flashrom/+/66436](https://review.coreboot.org…
* If defs is not great
* If someone is using such an old libusb version, then ch341a
programmer should not be built in at all
* We want to hold the patch for a moment
* TODO : create ticket to move the discussion there, add a comment
to the patch 66436 , link the ticket >>
[https://ticket.coreboot.org/issues/409](https://ticket.coreboot.org/issues/…
* Programmer param discussion
* Board enable for i2c
* [Joursoir] Flashrom CLI should have bash-completion (auto-complete
text with TAB key while typing a command). Task for new
contributors/next GSoC.
* Useful for new users
* Can be smaller project or larger project, can be broken into
several phases
* Felix: Not supported by standard bash, needs one extra packet.
But most systems have it anyway.
* Joursoir: Might need a bit of planning, think how to structure
bash
* We need to agree on what’s the end goals
* Flashchips: too many of them, let’s not include it
* Edward: Start as simple as possible, and then see how it goes.
* Everyone: A very good idea
* Joursoir (Alex) is a contact person for the project
[View Less]
# Introduction
The goal is to unify the integer type used for ranges. libflashrom has
2 ranges in the API: write protect (wp) ranges and layout ranges. The
types for these are not consistent between wp and layout, between
getters and setters, and between the API and the implementation.
Additionally the types are different sized depending on the platform
(ie size_t on 32 vs 64 bit).
Demo: https://review.coreboot.org/c/flashrom/+/67004
# Background / Motivation
Assertion: Flashrom only cares …
[View More]about fairly normal platforms (32 and
64 bit pointers).
size_t: size_t is the C type returned by sizeof. It is an unsigned
integer. Throughout the C library it is used as the type for counting
the length of and indexing into arrays. It is at least 16 bits. It is
often the same size as uintptr_t and void* but this is not required.
uintptr_t: A C type large enough to hold a pointer.
unsigned int: At least 16 bits, probably 32 bits on all the platforms
we care about.
uint32_t: Exactly 32 bit type, not required to exist (ie, flashrom
won't compile on platforms where this doesn’t exist).
usize: A rust type corresponding to uintptr_t.
uintptr: A go type corresponding to uintptr_t. Go also has C.size_t.
# Flashrom Today
getsize -> size_t
read/write/verify -> size_t
implementation: unsigned int
https://source.chromium.org/chromiumos/chromiumos/codesearch/+/cc9524d9ebf5…
Based on the implementation using `unsigned int`, Flashrom probably
only works with up to 32 bit sized flashes.
layout_add_region -> size_t, (start, end)
layout_get_region -> unsigned int (start, len)
impl: uint32_t (start, end)
https://source.chromium.org/chromiumos/chromiumos/codesearch/+/cc9524d9ebf5…
These types are probably fine on 32 bit platforms where they are all
the same. On 64 bit you could add a region that will be truncated /
wrapped without warning. The get and add using different ranges;
(start, end) and (start, len) is very confusing - I have already
gotten this wrong several times while refactoring.
wp_set_range -> size_t (start, len)
wp_get_range -> size_t (start, len)
impl: size_t (start, len)
All consistent here.
wp_ranges_count -> size_t
wp_ranges_get_range -> unsigned int
impl: size_t
Changing the get_range to take a size_t seems like a simple fix here.
This is unlikely to ever cause a bug but is a strange style.
# Rust
Bindgen can be told to treat size_t as usize. Without this flag a rust
type for size_t is chosen for the platform (ie u32 on 32 bit, u64 on
64 bit). Only usize can be used to index slices in rust.
# Proposal
## Goal
Unify all the length types (internal and external)
Unify all the range bounds ((start, len) vs (start, end))
Make bindings straightforward
## Non goal
16 bit platforms
>32 bit sized flashes
Change the libflashrom API and the flashrom internals to use uint32_t
for all flash sizes and ranges. Keep size_t for host related sizes, eg
the buffer size in flashrom_layout_read_fmap_from_buffer or
flashrom_image_verify.
Add a layout_add (start, len) method and try to deprecate the (start,
end) method. This will make all of the methods use the same concept of
range. The wp implementation uses (start, len) while the layout
implementation uses (start, end). I do not propose to change this.
In the rust fat bindings, use usize to represent all ranges and
offsets. After libflashrom changes from the current implementation to
uint32_t, the rust bindings must convert between u32 and usize. We
will only support 32 and 64 bit usize, so this will be
straightforward. The rust bindings will reject attempts to provide
values > 32bit at runtime.
# Alternatives
Use uint64_t. This has the pro of supporting large SPI flash on 64 bit
platforms. However this wont make large flash supported on 32 bit
platforms, as single buffers are passed around for data access;
flashrom_image_write (struct flashrom_flashctx *flashctx, void
*buffer, size_t buffer_len, const void *refbuffer)
Use size_t everywhere. Size_t makes some sense to use, as the
implementation and API deals with full flash sized buffers, and they
can only be indexed by size_t sized ranges anyway. For example
flashrom would support 16 bit of flash on a 16 bit platform, and 64
bit of flash on a 64 bit platform. However, tying the usable flash
size to the platform size doesn't really make sense and is likely to
cause confusion, and we probably only care about 32 bit flash.
Use a typedef, eg chipsize_t. I think this is reasonable internally
but don't prefer it. It would theoretically allow a simple change to
swap from 32 to 64 bit flashes. However C won't warn about code using
the wrong type while they are 'compatible', see for example the
functions using unsigned int and uint32_t interchangeably in the
codebase already. And this won't really work for libflashrom, it's too
messy to make the API function differently depending on library
compile time choices, this really creates incompatible APIs with
identical names.
For supporting larger-than-size_t size data objects, see posix lseek64
and friends.
Use u32 for the rust API. This makes sense as it pushes out-of-range
errors into the user code. However it complicates a lot of usage as
u32 constantly need to be converted into usize to do array indexing.
https://review.coreboot.org/c/flashrom/+/67004
[View Less]
Hi all,
the Redmine developers released version 5.0 some months ago and
updating to this version will have some effects on us. So, I would like
to open a thread to discuss these issues with you and how we deal with
that situation.
Currently, we are on the 4.2 branch and it still gets security and bug
fixes, but I can't tell at which point they will stop supporting it.
We enabled the login over OpenID, which is implemented natively and not
integrated over a plugin. With version 5.0, support …
[View More]for that was
removed. I assume this is due to that the implementation is based on an
older OpenID standard and there are not many users of it anymore (TM).
The newer standard seems to be called "OpenID Connect", but it's not
supported by Redmine.
Also, we are using a plugin which allows the login over a Google
account. The compatibility of that plugin breaks with version 5.0.
The problem is that we have users for both and with version 5.0 they
won't be able to use these methods anymore.
However, I have an idea for a solution. I took a look at the Redmine
database and I played around with the Google login method. My tests
showed that it creates a normal user account, as it is done with the
registration, just with the little difference that no password is set
disabling the login over password. These accounts also have an user
name and an email address. As soon as I set a password, I was able to
login using the user name.
So, my idea is that we just go with these changes and affected users
use the functionality to reset their password, which means they will
have a "normal" user account then. In preparation to that version
update, we should disable these login methods so that no new users will
make use of them.
Other ideas? What's your opinion?
// Felix
[View Less]
Hi,
im trying to apply me_cleaner to a HP ProBook 450 G8. It has a
W25Q256JVEQ WSON8 chip soldered so i bought a WSON connector thingy and
try to read from it with a pi:
olle@raspberrypi:~ $ sudo flashrom/flashrom -p
linux_spi:dev=/dev/spidev0.0,spispeed=10000 -c W25Q256JV_Q -V -r
hp-bios-original.bin
flashrom v1.2-887-g6c1b0ac on Linux 5.15.56-v7+
(armv7l) flashrom is free software, get the source code at
https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: …
[View More]1ns).
flashrom was built with GCC 10.2.1 20210110, little endian
Command line (7 args): flashrom/flashrom -p
linux_spi:dev=/dev/spidev0.0,spispeed=10000 -c W25Q256JV_Q -V -r
hp-bios-original.bin Initializing linux_spi programmer Using device
/dev/spidev0.0 Using 10000kHz clock
get_max_kernel_buf_size: Using value from
/sys/module/spidev/parameters/bufsiz as max buffer size.
linux_spi_init: max_kernel_buf_size: 4096 The following protocols are
supported: SPI. Probing for Winbond W25Q256JV_Q, 32768 kB: compare_id:
id1 0xef, id2 0x4019 Added layout entry 00000000 - 01ffffff named
complete flash Found Winbond flash chip "W25Q256JV_Q" (32768 kB, SPI)
on linux_spi. Chip status register is 0x00.
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).
===
This flash part has status UNTESTED for operations: PROBE READ ERASE
WRITE The test status of this chip may have been updated in the latest
development version of flashrom. If you are running the latest
development version, please email a report to flashrom(a)flashrom.org if
any of the above operations work correctly for you with this flash
chip. Please include the flashrom log file for all operations you
tested (see the man page for details), and mention which mainboard or
programmer you tested in the subject line. Thanks for your help!
Reading flash... done.
Looks great? It correctly identifies the chip and i get a file of the
right size. Its just that it contains only zeroes. Thirty-two million
of them. Not great.
I used freshly compiled flashrom from git, hardware was a raspi 2b
rev1.1 running raspbian bullseye freshly updated. What would you
suggest as a next step? Try different speed settings, desolder the
chip, what more? And yeah, the batteries (main, clock) were
disconnected.
Regards,
Olof
[View Less]
sudo flashrom -p ft2232_spi:type=arm-usb-ocd-h,port=A,divisor=8 -c
MT25QU256 -w
image.img
flashrom v1.2 on Linux 5.4.0-58-generic (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 Micron flash chip "MT25QU256" (32768 kB, SPI) on ft2232_spi.
===
This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest …
[View More]development
version of flashrom. If you are running the latest development version,
please email a report to flashrom(a)flashrom.org if any of the above
operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and
mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... FAILED at 0x00001000! Expected=0x00, Found=0xff,
failed byte count from 0x00000000-0x01ffffff: 0x250e23
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
[View Less]
HEllo,
I have a problem
I am trying to flash a W25Q64JVSIM flash memory
I get this answer when I type the following command
$ sudo flashrom --programmer linux_spi:dev=/dev/spidev0.0 -E
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Using default 2000kHz clock. Use 'spispeed' parameter to override.
Found Winbond flash chip "unknown Winbond (ex Nexcom) SPI chip" (0 kB, SPI) on linux_spi.
===
…
[View More]This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom(a)flashrom.org if any of the above operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
No operations were specified.
[View Less]