Hi folks,
for a while now, we have some functions in the libflashrom API to query
information about supported devices and such. The original patch[1] left
some questions open. And, alas, as there was some broken code and no
feedback, parts of it were dropped.
So, I wonder if there are any users of this API already? Anything that
might break if we change it?
Why I'm picking this up is that there are some issues with the design.
For instance, the exposed structs form an ABI that might need …
[View More]versioning
if somebody wants to link a shared library. And the cleanup part of the
API is too simple, i.e. flashrom_data_free() doesn't allow anything but
a shallow free().
There's also an associated ticket[2].
Nico
[1] https://review.coreboot.org/c/flashrom/+/34363
[2] https://ticket.coreboot.org/issues/355
[View Less]
I am very proud because I have great news: we have 3 students joining
the flashrom community to do projects!
Aarya will be doing a GSoC project “Optimize Erase-Function Selection”
with Thomas (Mentor), Simon (backup Mentor) and Nikolai.
Chinmay will be doing a GSoC project “Refactor arguments parser” with
Felix (Mentor), Anastasia (backup Mentor) and Evan.
Joursoir is joining as an independent contributor and will be working
on a project “Restructure shutdown functions and remove global …
[View More]state”
with me and Thomas. This will be a more open-ended project and largely
a continuation of the effort I was doing last year.
Anyone who is also interested in supporting the projects and our
students, yes please, you are very welcome! :)
Aarya, Chinmay, Joursoir,
it would be really great if you can join the next flashrom dev meeting
on 2nd June, so that we can say hello to each other! Info in this
thread: https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/5EMH…
Between today and 2nd June you will be talking to your Mentors and
discussing project plans in more detail. Please prepare: look at the
timeline (https://developers.google.com/open-source/gsoc/timeline) and
tell if you plan for example vacations so that we can adjust the
project schedule.
You will have a conversation with your Mentor(s) once a week. You will
need to post to the mailing list at least once a week, to share with
the community what’s going on your project.
Remember if you have any questions, you can always ask your Mentor(s)
and/or me or Felix. Especially if you are confused, not sure what to
do: keep calm and talk to your Mentor(s) or Admin(s).
So, what to do now? Celebrate! ;)
And then prepare for next week's conversation with your Mentors.
Good Luck!
--
Anastasia.
[View Less]
Hi,
since GD25LQ128D is marked as untested I like to share my success.
I have an Acer TravelMate P215-41. The BIOS was bricked due to an
update issue. I successfully reflashed the Bios on the GD25LQ128D
(25LQ128DSIG) using a CH341A programmer [1] and flashrom.
I removed RAM, hard drive, CMOS battery and accumulator and connected
the clip direct to the mainboard using the 1.8V adapter.
Read, erase and write was successful.
Kind regards
Aaron
[1]
https://www.amazon.com/-/de/dp/B07VMPZFWH/ref=sr_1_4?keywords=ch341a+progra…
Hello!
The chip detects as both MT25QU256 and N25Q256..1E:
Found Micron/Numonyx/ST flash chip "N25Q256..1E" (32768 kB, SPI) on ft2232_spi.
Found Micron flash chip "MT25QU256" (32768 kB, SPI) on ft2232_spi.
Multiple flash chip definitions match the detected chip(s): "N25Q256..1E", "MT25QU256"
I tried both for reads and both worked. writes/erases were only tried on MT25QU256 and that’s what I am attaching the log file for (it contains both read and erase/write portions so no duplicate ones …
[View More]are needed I imagine?)
[View Less]
# 19th May 2022, 6:00 - 7:00 am UTC+0
Attendees: Anastasia, Nico, Edward, Martin, Felix, Thomas
## Decisions Summary
* We are targeting v1.3 release between 1st August and 15th December.
Until 1st August, we will fix as many bugs from the list as possible
and then we will review the status.
[https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/…
.
* We will be discussing bugs for release more often in the meeting, to
keep things moving.
* Split programmer lifecycle …
[View More]tests into separate files per programmer.
## Agenda
* [Martinr] When is the next flashrom release? It's been 2 years since
the last release (v1.2).
* [dhendrix] Should we start doing (semi-)automatic releases on a
schedule, with point fixes to address specific problems that come up?
We've tried the "wait until everything is perfect'' approach and it's
resulted in years-long release cycles and countless forks. Now that we
have unit tests we should be confident in doing more frequent releases.
* [quasisec]: I would be in favor of a semi-auto release
schedule +1.
* [Nico] Currently we are rather exercising “wait until everything
is broken”. When we set the bar higher in the past, releases were no
issue. I think we should return to that.
* [Edward] Using a bug tracker allows us to have release-blocker
bugs and to know who is responsible for what to help clear up
communication lines.
* [Martin] Maybe create a release branch to fix any bugs
without adding any more features that would introduce new bugs?
* [aklm] At the meeting 2022-04-21 community decided that I am a
release manager. I will do a release, but I very much appreciate any
help and advice from people who have experience. I have never done any
release before. I created a list of issues under parent task here
[https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/…
some of them already assigned.
* [aklm] Hopefully this year
* [aklm] We’ve created a list of bugs that should be fixed before
release.
* After the tests are run.
* Testing needs to be done for meson changes, and then another time
before the release.
* Once release branch is created, it needs to be tested
* Martin: if we get qemu images I can add them to jenkins
* Edward : intermediate step is one non-linux build bot
* Breaking lifecycle tests into separate files : really nice to
have
* [martin]: Can we set a specific date for a release? That gives
us something to aim for. If we need to postpone it, we can.
* December? Too far away?
* August 1? Is it too aggressive?
* Nico: set up for jenkins builders should not affect the
release
* Thomas: not sure if we finish meson support. We can just
document the meson builds for this release - it doesn’t have to be
complete.
* Edward: how about we have a release window between 1 Aug and
15 Dec
* Nico: we can fix all bugs, or disable the code
* Martin: We can work until 1 Aug and see how much is fixed.
* [Martinr] Who is responsible for flashrom binaries? There don't seem
to be links to binaries in
[https://www.flashrom.org/Downloads](https://www.flashrom.org/Downloads)
and I'm willing to bet that most of those maintainers aren't doing it
any more.
* [dhendrix] Upstream flashrom has only ever published sources
(except for certain Windows binaries?). Package maintainers for various
distros have been responsible for binary releases.
* The reason I was asking was that the download page is very
confusing and seems to be very out-of-date.
[https://www.flashrom.org/Downloads](https://www.flashrom.org/Downloads)
* Windows binaries are the only ones the users are asking for
* Thomas: I can build binaries for meson build testing.
* Felix: What about doing a static linux build?
* Nico: Let’s postpone that until someone asks for it.
* Nico: It could be useful to post a daily build off of master.
* Martin: We could do a nightly build with jenkins?
* Thomas: static libraries are libusb, libpci , libftdi ,
libjaylink.
* TODO: add a bug for updating the Downloads page.
* For linux systems use packaged binary, if you need latest,
build off master
* List of versions in each distro:
[https://repology.org/badge/vertical-allrepos/flashrom.svg](https://repology…
* [Martinr] What do we need to do for flashrom cross-platform build
testing?
* [Nico] We have a set of Docker containers prepared
(util/manibuilder/). FelixS is looking into buildbot integration. If
coreboot makes the switch eventually, it shouldn’t be an issue.
* These are somewhat out of date.
* Thomas has a number of qemu images as well.
* TODO: file a bug to update containers
* Martin or Nico will take care of updating these.
* [Martinr] What's the current state of flashrom testing?
* Is it mostly manual at this point?
* Unit tests are running on every push, but these are just
covering a very little bit. supplement documentation for what was
intended for the patch.
* Google is testing after downstreaming the code. Also get
tested in the commit queue. AVL test of customer roms.
* Martin: would this generate a bug upstream flashrom, or
only within google?
* The plan is to push all of these up to the flashrom
bug tracker.
* What tests are done for release?
* We need to document this.
* In the past, there has been testing on hardware, generate
a release candidate and ask the community to test.
* How do we test the different internal flashers? Just the
community - there’s not much change in these programmers.
* Martin: email alias flashrom-vvv to send logs ? something like
coreboot board status. People can send email “I have tested in, here is
an output”
* RC branch, when you run it, please email the results
* Edward: Do we want an owners file in the tree? “Here are drivers
that are officially supported”
* Felix: I have some ideas for a QA lab, like 9elements Lava QA but
for flashrom. So we could test at least some programmers
* Can we go through open patches manually?
* What’s needed to continue work on meson?
* Tests currently depend on libusb. So in the current setup at
least one libusb programmer needs to be selected to run tests. However
not all tests depend on libusb , only for some programmers.
* Lets split lifecycle.c into per-programmer files and then we can
run the tests that do not depend on libusb when the library is not
present.
[View Less]
Hi everyone,
after two crazy years, we decided it's time to do a open source
firmware hackathon. It will take place from 10th June - 12th June in
Darmstadt, Germany. For more details and tickets, have a look on this
site [1].
The hackathon will cover open source firmware projects, like coreboot,
oreboot, flashrom, LinuxBoot and any topics related to them. We have
two lecture rooms (2x 80 people) for discussions and presentations.
Currently, only 17 tickets are left. Everyone is welcome, no …
[View More]matter if
beginner or professional.
24h breakfast, snacks and soft drinks are provided for free.
Would love to see you there!
// Felix
[1] https://osfw.foundation/events/osff-summer-hackathon-2022/
[View Less]
Hello,
Ubuntu 20.04 boot from USB (try Ubuntu) and attempted install using Protectli Flashli. Cut and paste follows, any advice is appreciated!
John
\ == \ /\ == \ /\ __ \ /\__ _\ /\ ___\ /\ ___\ /\__ _\ /\ \ /\ \
\ \ _-/ \ \ __< \ \ \/\ \ \/_/\ \/ \ \ __\ \ \ \____ \/_/\ \/ \ \ \____ \ \ \
\ \_\ \ \_\ \_\ \ \_____\ \ \_\ \ \_____\ \ \_____\ \ \_\ \ \_____\ \ \_\
\/_/ \/_/ /_/ \/_____/ \/_/ \/_____/ \/_____/ \/_/ \…
[View More]/_____/ \/_/
_________________________________________________________________________________________
=========================================FlashLi=========================================
--Version 1.1.20--
Device: Protectli fw6e
CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
BIOS Mode: BIOS
Available BIOS:
[1]: ami (FW6_all_YKBR6L12.bin)
[2]: coreboot (protectli_all_fw6_vault_kbl_v1.0.14.rom)
Enter the [#] of an image file, or [0] to quit. Flahing will not begin yet
> 2
********************************************!********************************************
Are you sure you would like to flash this device?
Flashing new firmware onto any hardware is potentially dangerous in that if the
procedure is interrupted or otherwise not able to complete, your hardware may be rendered
useless. Please proceed with caution. If there are any questions, please contact
Protectli support BEFORE proceeding.
Unless there is a compelling reason to update the BIOS, we recommend to stay with your
current known working BIOS version
********************************************!********************************************
Acknowledgement Yes [Y]: y
flashrom v1.2-326-gf57486e on Linux 5.13.0-30-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 chipset "Intel Kaby Lake U w/ iHDCP2.2 Prem.".
Enabling flash write... SPI Configuration is locked down.
Enabling hardware sequencing because some important opcode is locked.
OK.
Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
Reading ich descriptor... done.
Using region: "bios".
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... FAILED at 0x00103056! Expected=0xff, Found=0xc5, failed byte count from 0x00000000-0x007fffff: 0x99c
Your flash chip is in an unknown state.
Get help on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"!
-------------------------------------------------------------------------------
DO NOT REBOOT OR POWEROFF!
BIOS Flash failed, is this script running with root permissions?
Please try again, but if problems persist, please let us know.
TODO: Collect info and display instructions on how to submit a Github issue.
[View Less]
Hello People,
I wanted to summarise the information on the time of Dev meeting. At some
point there was an idea to alternate times, but then we discovered that we
got really lucky and there is one time which everyone agrees on. That was
an open question at the last meeting, to confirm the time with those US
folks who were not present. Since no one was replying to the mailing list,
I reached out to folks and confirmed the time is fine.
—-------------
SUMMARY
—-------------
#1 Between November …
[View More]and March (inclusive) time of meeting:
Wednesday 21:00-22:00 UTC+0
also known as
Wednesday 13.00-14.00 Pacific Standard Time UTC-8
Wednesday 22.00-23.00 Central European Time UTC+1
Thursday 8.00-9.00am Australian Eastern Daylight Time UTC+11
#2 Between April and September (inclusive) time of meeting:
Thursday 6.00-7.00am UTC+0
also known as
Wednesday 11pm-midnight Pacific Daylight Time UTC-7
Thursday 8.00-9.00am Central European Summer Time UTC+2
Thursday 16.00-17.00 Australian Eastern Standard Time UTC+10
#3 Note that in the last week of March and 4 weeks of October there will be
no meetings, because daylight saving time changes are happening on
different dates in different locations, and setting up meeting time becomes
too complicated.
Once the regularity is stable, I will add info about Dev meeting on the
Contacts page.
Meanwhile:
—----
FAQ
—----
#1 When is the next meeting?
Look into the meeting notes document
<https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WF…>.
The top entry, on the first page, with the date in the future, and empty
list of attendees - is the next meeting.
#2 How to join the meeting?
Look into the meeting notes document
<https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WF…>.
On the top it says “to join, click the link”, click the link.
#3 Where is that document?
Meeting notes document is linked to the Home page of flashrom.org,
Developers menu at the bottom of the page.
#4 Do I need an invitation to join the meeting?
No, just join.
--
Anastasia.
[View Less]
Hello,
Some time ago I've revived an old patchset by Hatim Kanchwala and
extended it with support for more devices and unit tests.
It wasn't reviewed for a while and now that reviewing makes sense
(changes it's based on were accepted) it's not really needed for 3mdeb's
project anymore...
The question is whether there is a need for it? If there is interest
and wiliness to test it (wasn't tested on hardware), pursuing review
still makes sense.
Someone can even take over the patches and I'll …
[View More]become a reviewer and
help along the way.
If OTP isn't needed at the moment, the patchset will be abandoned at
least until some project which requires OTP in flashrom or until someone
else will pick it up.
The first change of the series is (no topic yet)
https://review.coreboot.org/c/flashrom/+/59402
To give you an idea of the amount of work it might take to upstream:
Makefile | 2
chipdrivers.h | 5
cli_classic.c | 243
dummyflasher.c | 351
flash.h | 6
flashchips.c | 61
flashrom.8.tmpl | 81
libflashrom.h | 18
meson.build | 2
otp.c | 490
otp.h | 91
otp_layouts.c | 210
spi.h | 40
spi25.c | 89
spi25_statusreg.c | 90
tests/chip_otp.c | 470
tests/meson.build | 1
tests/tests.c | 14
tests/tests.h | 12
19 files changed, 2186 insertions(+), 90 deletions(-)
Conflicts with current master for a couple of month, should be easy to
fix (I'll do that if someone else will take over). I also have a
bash script to test new CLI options via dummyflasher.
Best regards,
Sergii
[View Less]