Yea, there is a error in the Makefile logic which requires sphix when run 'make
[all]'. I'll fix this.
To mitigate this in the meanwhile you can comment out Makefile line 1035
'FLASHROM_VERSION=$(VERSION) $(SPHINXBUILD) -b man doc .'
Please be aware, that we are in the process of switching to
Hi Paul,
a short search on the internet found that the UEFI password protection
can be reset by modifying the content of one of the flash chips. To
read and write to that chip you can of cause use fashrom. But with the
other parts of the procedure we can't help you. But it seems that there
are
Great to here that you have been successful!
And thanks for the info with the lpc_ich driver.
I've create a patch [0] marking the Intel H97 as working
-- Thomas
[0] https://review.coreboot.org/c/flashrom/+/73581
On Wed, 2023-03-01 at 07:59 -0300, Guillermo Reisch wrote:
> You can mark the
Hi Sean,
The progress reporting is unfortunately in a bad shape and may not work
as expected. The flashrom cli has a `--progress` switch. The `-V[V[V]]`
flags are only to generate more debug output.
Beside the flashrom binary we have a libflashrom API to use directly.
But please be aware that
Great job!!! Thank you so much!!
-- Thomas
On Tue, 2023-02-28 at 22:04 +0530, Aarya Chaumal wrote:
> Hi everyone,
>
> I am excited to announce that we've added the optimized erase
> function selection algorithm to the master branch. It will optimally
> select the
> erase functions according to
Hi Guillermo,
it seems that your kernel does not permit access to the needed regions
of /dev/mem.
Can you build a custom kernel with `CONFIG_STRICT_DEVMEM=n` and
`CONFIG_IO_STRICT_DEVMEM=n` and try again?
Debian has a good starting point in their documentation [0]
I hope you will be
Hi Sadoon,
thank you for the report!
I've created a patch which marks the chip as successfully probed, read,
erased and written [0].
Nice to see flashrom running on non x86 hardware ;)
-- Thomas
[0] https://review.coreboot.org/c/flashrom/+/73363
On Tue, 2023-02-28 at 21:04 +0300, Sadoon
Hi verithas,
since the last release there was an update to the flashchips database
affecting the chip you're trying to operate on. Can you try to use an
self-compiled up-to-date flashrom fom the git master branch?
I wish you a successful solving of your problem
-- Thomas
On Tue, 2023-02-28 at
Hi James,
thank you for the report!
I've created a patch which marks the chip as successfully probed and
read [0].
We've have a somewhat working progress indicator with `--progress`, but
it needs a big overhaul to work proper.
-- Thomas
[0] https://review.coreboot.org/c/flashrom/+/73362
On
Hi Prakhar,
historical flashrom lived mostly in the root directory. We have started
with moving stuff around. E.g the headers are now in a include
directory and some platform specific stuff has also found a new home.
The bigger problem with moving stuff around is, that flashrom is not
just a
Hi flashromers,
For all the time I'm now working on flashrom I've avoided to touch the
man-page. The reason: it is written in plain groff (the manpage
format), which is, IMO, neither great to read in source nor makes it
fun to edit.
Nowadays there are a lot of tools for converting a source
Hi Edward,
could we instead of removing it convert it into its own programmer?
Renaming the wbsio_check_for_spi to wbsio_init and add a
allow_brick=yes parameter.
This should allow you to move forward and also keep the code?
-- Thomas
On Mon, 2023-02-06 at 12:23 +1100, Edward O'Callaghan via
Hi flashrom community,
In the last weeks we got some big improvements merged to build flashrom with
meson. The programmer selection got an complete overhaul and now it's also
possible to use meson on non linux systems.
To plan the next step under this Topic we will meet us again on Friday
On Fri, 2022-09-09 at 15:35 +0200, Nico Huber wrote:
> Hi Edward,
>
> TL;DR
> I agree it seems modern. But implicit behavior can also make it
> harder
> to understand code, especially for new people. Also, every case can
> be
> different.
>
> There is always the question how it looks to the
Hi,
for me it's ok, but I can't guarantee to make it.
-- Thomas
On Thu, 2022-09-15 at 14:51 +1000, Anastasia Klimchuk wrote:
> Hello,
>
> The next dev meeting is scheduled for 22 Sept, but it turns out there
> are some things happening:
>
> 1) This is a day right after OSFC which many people
Hi flashrom community,
we've just merged a big overhaul to the meson build system, especially
the programmer selection. Now it is easy to select a singe or a group
of programmers, which was really painful before.
Besides that, the meson file now works on non Linux systems, too.
To use meson you
Hi Edward,
thanks for bringing concepts of modern C to flashrom. +1 for using NULL
and then falling back to a default implementation in the logic. IMO it
makes the code much better.
-- Thomas
On Fri, 2022-09-09 at 12:15 +1000, Edward O'Callaghan via flashrom
wrote:
> Hello,
>
> While
Hi Evan, Greg,
sorry for my late response.
I'm fine with having language bindings in the flashrom repository. Especially
when a user of those bindings lives also in the repository.
But then we have to find a way to make building everything convenient for
developers and distributers.
The other
Here the meeting link...
flashrom One Build System Working Group
Thursday, June 23 · 9:15 – 10:15 UTC
Google Meet joining info
Video call link: https://meet.google.com/jgd-vopr-tkv
-- Thomas
On Fri, 2022-06-17 at 22:56 +, Thomas Heijligen wrote:
> Hi,
>
> we will m
Hi,
we will meet again on Thursday 23 June 9.15-10.15 am UTC.
-- Thomas
On Sun, 2022-06-12 at 17:45 +, Thomas Heijligen wrote:
> Hi folks,
>
> the next One Build System Working Group Meeting will be on Thursday
> June 16th at 7:00UTC after the general flashrom developer
progress.
-- Thomas
On Wed, 2022-05-18 at 18:44 +, Thomas Heijligen wrote:
> Hi folks,
>
> we want to meet again to discuss the progress and problems under the
> One Build Sytem Topic. If you are interested, please participate on
> the
> poll [0] to find a suitable da
Hi folks,
we want to meet again to discuss the progress and problems under the
One Build Sytem Topic. If you are interested, please participate on the
poll [0] to find a suitable date.
On Gerrit, relevant patches can be found under the `one_build_system`
topic. [1]
The working document can be
Hi Selva,
You've compiled flashrom without the support for the internal
programmer. Please install `pkg-config` or `pkgconf` and `libpci`
(`pciutils-devel`) and rebuild flashrom. Use `make CONFIG_INTERNAL=yes`
to enforce the build with the internal programmer.
-- Thomas
On Fri, 2022-05-13 at
Hi Chinmay,
Thanks for adding voltage informations to those chips.
Can you plese upload the patch to Gerrit. https://review.coreboot.org
There are usefull HOWTOs in the flashrom wiki and coreboot doc.
https://www.flashrom.org/Development_Guidelines#Sending_a_patch
Hi Andy,
Thanks for your help.
I've found someone on github has published a patch last year to get
DirectHW compatible with sdk11. I've no idea if this is usefull for use
but may help you getting things running.
s after that, then the test will fail.
> > There is a gsoc project idea for unit tests :) As a fact from
> > flashrom
> > history, the very first lifecycle unit test I wrote found a memory
> > leak!
> >
> > And the last thing, there is an idea, an open question a
On Sat, 2022-04-09 at 20:29 +1000, Anastasia Klimchuk wrote:
> I think that’s all that I wanted to say. But I am wondering what
> Thomas is thinking about it?
> In any case there is plenty of useful stuff that can be done, and it
> is not a problem to wrap it as a project.
> Let us know what you
gt; comments on as I think you have this mostly right.
>
> Thomas Heijligen writes:
>
> > ## Platforms to support
> > * Systems
> > * Linux (Distros / ChromeOS)
>
> Long-Term Stable is a real issue. It's not really reasonable for
> people
> to expect to
Hi Andy,
Do you have time to test if flashrom can be build on MacOS with
DirectHW support? I had tried it on a Hackintosh VM but run out of
MacOS knowledge.
With this [1] patch it compiles when providing DirectHW.h in the
include path. only the linking fails. Also I don't know if the kernel
to these changes to have it
working until its end.
## Notify me
Add me to all to all build system related patches. (Or only to Make /
Meson related one.)
* Thomas Heijligen
## Platforms to support
* Systems
* Linux (Distros / ChromeOS)
* BSD (Free, Net, Open, Dragonfly)
* MacOS
Hi,
is there someone in the flashrom community who has worked with DirectHW
and knows if it's still working on supported MacOS systems?
I want to figure out how to deal with it in the future of flashrom.
-- Thomas
___
flashrom mailing list --
Sorry, it's 9:30 UTC, wich is 11:30 German time, 19:30 Sydney time
-- Thomas
On Wed, 2022-04-06 at 07:19 +, Thomas Heijligen wrote:
> Hi,
>
> As discoursed last dev meeting, we are going to start a working group
> to adopt meson as single, all cases covering, build system fo
Hi,
As discoursed last dev meeting, we are going to start a working group
to adopt meson as single, all cases covering, build system for
flashrom.
The first step will be to write down all requirements that we need to
meet. Therefor, we'll meet today at 8:30 UTC at
Hi Joursoir,
On Mon, 2022-04-04 at 14:57 +0300, Joursoir wrote:
> Hello Thomas,
>
> No problem, thanks for your reply. I have one more question. I have
> noticed
> that some programmers already have their own context (for example
> pony_spi.c,
> rayer_spi.c. serprog.c, dediprog.c and others). I
Hi Joursoir
On Fri, 2022-04-01 at 22:43 +0300, Joursoir wrote:
> Hello Thomas,
>
> I went ahead and started looking into shutdown functions.
Gread that you've already looked so deep into the problem. Over that,
plese don't forget the other importent tasks
at https://www.flashrom.org/GSoC to
Hi Joursoir,
I'm going to reply to your questions on Monday. Sorry for the delay, I'm
currently not in reach of my Computer and want to look a few things up before
answering.
-- Thomas
On 1 April 2022 20:43:10 WEST, Joursoir wrote:
>Hello Thomas,
>
>I went ahead and started looking into
>
>On Tue, Mar 29, 2022 at 2:48 PM Thomas Heijligen wrote:
>
>>
>>
>> On 26 March 2022 05:44:56 WET, Aarya Chaumal
>> wrote:
>> Hi Aarya,
>>
>> >I performed (read, write, erase) on specific regions of the flash using
>> the
>> >
On 26 March 2022 05:44:56 WET, Aarya Chaumal wrote:
Hi Aarya,
>I performed (read, write, erase) on specific regions of the flash using the
>layout file. Do the regions in the layout file have to be exclusive or they
>can overlap?
A flashrom layout region is just a name with a start and end
On 22 March 2022 06:01:25 WET, David Hendricks
wrote:
>It will be good to understand why they are going this route and if it's
>better for the project in the long run.
Meson is easier to use, especially when you have to deal with a lot of
different projects. All variables you need are well
On 21 March 2022 22:04:07 WET, Greg Troxel wrote:
>
>Richard Hughes writes:
>
>> On Mon, 21 Mar 2022 at 20:04, Nico Huber wrote:
>>> There is also one big general issue: we need to maintain two build
>>> systems now. We can't use GNU make only, because nobody knows what
>>> the requirements
Hi Joursoir,
Beside the internal programmer, most programmer manipulate only a few
things, so it is not that much. A data struct for each programmer
should be used to store the context of the programmer instead of
setting global variables. This gives the programmer a defined lifecycle
. The
er the specify in which
> endian he wants to write/read the data.
>
> Aarya.
>
> On Fri, Mar 18, 2022 at 2:54 AM Thomas Heijligen
> wrote:
> > Hi Aarya,
> >
> > Thank you for contributing to flashrom. The merge of a patch
> > sometimes
> > needs j
Hi Joursoir,
The idea for the "Restructure Shutdown Functions" project is to extend
the struct programmer_entry with a function to handle programmer
related shutdowns. Currently, the init function of each programmer
calls, mostly indirect, register_shutdown on each item separately to
handle its
Hi Aarya,
Thank you for contributing to flashrom. The merge of a patch sometimes
needs just time, even if it has +2.
The topic "fixing endianness issues" consists of tasks to rewrite code
that assumes a specific endianness. For example, the flashrom fmap
parser just maps packed c structs onto
Hi Aarya,
Thank you for contributing to flashrom. The merge of a patch sometimes
needs just time, even if it has +2.
The topic "fixing endianness issues" consists of tasks to rewrite code
that assumes a specific endianness. For example, the flashrom fmap
parser just maps packed c structs onto
ngs,
> it is useful! We can learn something from it.
>
> We can, meanwhile, start thinking about: what EU-AU time could be?
> There are two options: earlier in the morning and later in the
> evening (or swapped).
>
> On Thu, Feb 3, 2022 at 11:00 AM Thomas Heijligen
> wrot
Hej hej,
+1 for this idea also from my side. I'm in.
Until now I haven't used Google Meet, but don't see a problem with
trying it. Since you have initialized this, feel free to set the time
to EU-AU.
-- Thomas
On Tue, 2022-02-01 at 21:49 +1100, Anastasia Klimchuk wrote:
> Hello Everyone,
>
>
Hej Anastasia,
since some of the ideas from the brainstorming are mine, I would also
offer to help as (co)mentor for GSoC on those projects.
-- Thomas
On Tue, 2022-01-25 at 22:31 +1100, Anastasia Klimchuk wrote:
> Good Day Flashrom People!
>
> As you might know already, we are currently
48 matches
Mail list logo