[flashrom] Re: One Build System Working Group

[Greg Troxel]

pkgsrc has cmocka 1.1.5.  Telling the flashrom package that it is needed
for running tests, or that it's always needed is one line in the control
Makefile.  Including it or downloading it is much more painful.


signature.asc
Description: PGP signature
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: One Build System Working Group

[Greg Troxel]

Some comments from a packager and experience with switching to cmake,
some of it ok, some of it bad.  I'm trimming stuff I don't have any
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 build new flashrom with ancient tools, on a system where
they have chosen to run old code to get some kind of stability.  Yet
people routinely demand that they be able to build the latest release of
Foo using an LTS with compiler, autoconf, cmake and the like from 5
years ago.  They want new Foo, but suggesting they get non-crufty tools
and they act like upstream is being unreasonable because their LTS is
"supported".  My respones is "well, tell RHEL/Ubuntu to do it for you
and stop demanding I do it".

> * SunOS / Solaris / the current version of it

There are two worlds: Oracle Solaris and illumos (OmniOS, OpenIndiana,
and more).  Probably doesn't need specific code for both, but good to be
aware.

>   * Architectures
> * X86
> * ARM
> * MIPS
> * POWER
> x86 supports port I/O (mostly relevant to PCI), others may through
> MMIO emulation

I guess that's an interesting question.  I'm not clear on the full set
of interfaces for reading/writing.  But really the code should be
portable to any reasonable CPU.  x86, arm, mips, and ppc are really
pairs of CPU architectures, each of which has a 32-bit and a 64-bit
variant.  And it's a pretty short list; NetBSD also runs on sparc,
sparc64, m68k, and less sensible for flashrom, vax, alpha, ia64, and
hppa.  And, RISC-V is coming and I expect it to appear whereever arm64
does in a few years.

In requirements, you left out (but I know you are thinking of cross):

  cross compilation

  Almost entirely, switch code on/off by feature tests, and attempt to
  drive the number of "#ifdef FooOS" to zero.  It's not doable entirely,
  but autoconf got this right and a lot of things that claim they are
  better do not.

>   * Write documentation
> * Build instructions for all platforms

Aside from windows, they really should not be different.

> ## Open questions
>   * System requirements
> * How long should we support systems / libraries?
>   * As long as they have vendor support

That's very messy.  On one hand if vendors (== "os maintainers") drop
support early, it's good to go back slightly further.  On the other, if
someone decides to freeze code in 2020 and maintain it with *security
patches only* for 10 years, then I think a reasonable response is "if
you want to run code from 2020 with only security patches, good luck -
the license gives you the freedom to do that, but it's not our
obligation to do work to make that be easy".  Note that such people are
welcome to keep running the flashrom version from 2020; that is after
all what they chose to do.

Yes, I sound cranky, but the crankiness comes from maintaining unison.

> * What should be the minimum required version of meson?
>   * The version of the oldest supported system.

Again, same issue.

>   * Build dependencies
> * Can we fetch dependencies like cmocka? This makes building for
> some systems easier

No, you can't fetch anything at build time.  Packaging systems view that
as a bug.  It means you can't build on a machine not on the internet.
Yes, I have built lots of packages on a disconnected machine after
fetching their releaes tarballs and transferring on CDROM, and it almost
entirely works.

So options are:

  if you want to depend on something, list in in the README and demand
  that the user have it installed already.  If it doesn't already exist
  as a package in most packaging systems, that's a clue you shouldn't
  use it.

  vendor it in.  But you really shouldn't do this, because then when
  there is a security release of that included code, you really need to
  have a new micro very fast, and I'll pick 7 days out of a hat.

>   * Shared libflashrom
> * How to handle versioning?

shared library major/minor is pretty well established (major bump on ABI
break, minor bump on ABI addition, and try really hard not to break the
ABI).  I'm not sure what the question is.

> ## Sequence for switching the primary build system
>   * Meson is feature equivalente with the Makefile
>   * Switch to meson as default build system, update the documentation
>   * Make a release with meson as the primary build system, keep the
> Makefile for legacy compatible.
>   * Drop the Makefile
>   * Drop dead code from Makefile only based option

Understand that packagers will need to put in work to switch, they
aren't usually paid 40h/week to package, and they don't think flashrom
is the most important thing in the world.  So what you said means that
they have the time between the release with meson documented as primary
and the release w/o Makefile.   If meson behaves as well as meson
proponents say 

[flashrom] Re: Future of DirectHW

[Thomas Heijligen]

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
module can be loaded.
Can you have a look at it?

Thanks
-- Thomas 

[1] https://review.coreboot.org/c/flashrom/+/62929

On Wed, 2022-04-06 at 16:38 +, Andy Pont wrote:
> Thomas wrote...
> 
> > is there someone in the flashrom community who has worked with
> > DirectHW
> > and knows if it's still working on supported MacOS systems?
> I haven’t used it before but I do have a macOS system that can be
> used 
> for testing if needed (currently running Monterey 12.2.1).
> 
> > I want to figure out how to deal with it in the future of flashrom.
> Everything post Mojave (10.14) is 64bit only.  I also seem to recall 
> that kernel extensions weren’t the preferred solution any more and
> that 
> system extensions were the way forward.
> 
> -Andy.
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org

___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] One Build System Working Group

[Thomas Heijligen]

Hi,

Here an overview about the One Build System Project for flashrom. I'm
sorry for the extreme late anouncement of the passed meeting. We had
some diffent ideas about it. The next one will be anounced in a prper
advanced and with a survay to choose a time.

Please feel free to contribute, take over a task, start a discousion,
comment in the document or reply to this mail.


https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit?usp=sharing
---
# Flashrom One Build System Working Group [Draft]

## Goal
  Make meson the only build system for flashrom. Support all currently
supported platforms.

## Abstract
  Modify, extend, rewrite the meson based build system to accommodate
all requirements from flashrom. Rearrange the code for a best fit with
the meson build system. Adapt the Makefile 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
* Android?
* SunOS / Solaris / the current version of it
* Debian kFreeBSD
* GNU / HURD 
* Windows (mingw cross / cygwin)
* DOS (djgpp cross from Linux)
* libpayload (cross from Linux)
  * Architectures
* X86
* ARM
* MIPS
* POWER
x86 supports port I/O (mostly relevant to PCI), others may through
MMIO emulation

## Tasks
  * Update the meson programmer selection to a positive list (see meson
snippets)
  * Clean up the meson file and use best practices for meson
  * PoC: crosscompile “Hello World” for dos / djgpp with meson (with
pci support)
  * PoC: crosscompile “Hello World” for libpayload with meson (with pci
support)
  * Identify the active programmer in the man page
* Add a note for each programmer that is not active in the build
  * Integrate getopt for dos based builds
  * Write documentation
* Build instructions for all platforms
* Design of meson.build 
  * Reason for minimal meson version
* How to add programmer
  * Sync compile options (WIP
https://review.coreboot.org/c/flashrom/+/58561)
  * Create directories for platform abstraction, programmer, include
files (https://review.coreboot.org/c/flashrom/+/62899)

## Open questions
  * System requirements
* How long should we support systems / libraries?
  * As long as they have vendor support
* What should be the minimum required version of meson?
  * The version of the oldest supported system.
  * MacOS and DirectHW
* What is the current status?
* What is useful to support?
* Can we integrate it into flashrom?
* How to test it?
  * Internal programmer
* Should a programmer call / access another programmer?
* Can we split the internal programmer into smaller units
(x86_bios, mips_longson, xyz_superio, linux_mtd) and use internal as a
keyword to select one of those?
* Would that make it easier to build and modify?
  * Build dependencies
* Can we fetch dependencies like cmocka? This makes building for
some systems easier
  * Unit tests
* Can we build the cmoka test on top of libflashrom.a?
* Can this replace self tests?
  * Meson feature options
* Build the shared library as feature
* Build the classic_cli as feature
  * Can be easily deselectet if not needed of not supported
(libpayload)
* Build the tests as feature
* Build man-pages as feature
* Build ich_descriptor_tool as feature
  * Shared libflashrom
* How to handle versioning?

## Sequence for switching the primary build system
  * Meson is feature equivalente with the Makefile
  * Switch to meson as default build system, update the documentation
  * Make a release with meson as the primary build system, keep the
Makefile for legacy compatible.
  * Drop the Makefile
  * Drop dead code from Makefile only based option

## meson snippets - Ideas
  | option('programmer', type : 'array', choices : ['auto' 'all' 
'group_pci' 'group_usb' 'ch341a_spi' ‘drkaiser’])
  * auto selects all programmer available on the platform if the
dependencies are found
  * all selects all programmer available on the platform, failing id a
dependency is not found
  * group_* selects all programmer in this group, fails if the system
does not support the group or a dependency is not found
  *  selects this programmer, fails if not available
on system or missing dependency

  | libusb1 = dependency(...)
  | libusb1_systems = [ ‘linux’ ‘freebsd’ ‘windows’ ‘mac’ … ]
  | libpci = dependency(...)
  | libpci_systems = [...] # systems where libpci is available
  | port_io = declare_dependency(...) # files needed for port I/O
support
  | programmer = {
  |   'ch341a_spi' {
  | 'system' = libusb1_systems,
  | 'srcs' = [ 'ch341a_spi.c' 'usbdev.c' ],
  | 'flags' = [ 'CONFIG_CH341A_SPI=1'],
  | 

[flashrom] Re: Join GSoC

[Sayed Mohsen]

I also need to know if am I late for joining or its good time for me to join
Thank you

On Wed, Apr 6, 2022 at 5:59 PM Sayed  wrote:

> Hello
> I need to contribute a project of yours in GSoC
> Please tell me what I’m supposed to do to be able to join this program
> Thanks alot
>
>
>
> Sent from Mail  for
> Windows
>
>
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Join GSoC

[Sayed]

HelloI need to contribute a project of yours in GSoCPlease tell me what I’m supposed to do to be able to join this programThanks alot Sent from Mail for Windows 
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Future of DirectHW

[Andy Pont]

Thomas wrote...

>is there someone in the flashrom community who has worked with DirectHW
>and knows if it's still working on supported MacOS systems?
I haven’t used it before but I do have a macOS system that can be used 
for testing if needed (currently running Monterey 12.2.1).

>I want to figure out how to deal with it in the future of flashrom.
Everything post Mojave (10.14) is 64bit only.  I also seem to recall 
that kernel extensions weren’t the preferred solution any more and that 
system extensions were the way forward.

-Andy.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Future of DirectHW

[Stefan Reinauer]

I have not been testing it lately, but I am pretty sure it will need a good
chunk of work to function on newer macOS systems.

Stefan

On Wed, Apr 6, 2022 at 5:24 AM Thomas Heijligen  wrote:

> 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 -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Future of DirectHW

[Thomas Heijligen]

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 -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: One Build System Working Group

[Thomas Heijligen]

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 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
> https://meet.google.com/sag-dyik-bbr and posting the working draft
> afterwards on the mailing list. The google doc can be visited at any
> time.
> https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit?usp=sharing
> 
> Please feel free to join the meetings, the next ones will be
> announced
> much earlier, add comments to the document or reply to this mail with
> and question or suggestion.
> 
> -- Thomas
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org

___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] One Build System Working Group

[Thomas Heijligen]

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
https://meet.google.com/sag-dyik-bbr and posting the working draft
afterwards on the mailing list. The google doc can be visited at any
time.
https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit?usp=sharing

Please feel free to join the meetings, the next ones will be announced
much earlier, add comments to the document or reply to this mail with
and question or suggestion.

-- Thomas
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: ERASE FAILED!

[Buhrow, Simon]

Hi Pascal,

did you check whether WP# pin (write protection) is passive?

Regards,

Simon

Von: Pascal Boidart 
Gesendet: Freitag, 1. April 2022 23:40
An: flashrom@flashrom.org
Betreff: [flashrom] ERASE FAILED!

Hello Flashrom,

I'm on latest Linux Mint.
programmer ch341a_spi
chip is a Macronix type MX25L6406E

I'm trying to erase a chip with: sudo flashrom --programmer ch341a_spi --erase 
-c "MX25L6406E/MX25L6408E"

And I'm getting a erase failed.
See log.
pascal@pascal-mini:~/Desktop/Flashrom$ sudo flashrom --programmer ch341a_spi 
--erase -c "MX25L6406E/MX25L6408E"
flashrom v1.2 on Linux 5.4.0-107-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 Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on ch341a_spi.
Erasing and writing flash chip... FAILED at 0x! Expected=0xff, 
Found=0x00, failed byte count from 0x-0x0fff: 0x1000
ERASE FAILED!
Looking for another erase function.
FAILED at 0x! Expected=0xff, Found=0x00, failed byte count from 
0x-0x: 0xfad7
ERASE FAILED!
Looking for another erase function.
FAILED at 0x! Expected=0xff, Found=0x00, failed byte count from 
0x-0x: 0xfad7
ERASE FAILED!
Looking for another erase function.
FAILED at 0x! Expected=0xff, Found=0x00, failed byte count from 
0x-0x007f: 0x6b7ef1
ERASE FAILED!
Looking for another erase function.
FAILED at 0x! Expected=0xff, Found=0x00, failed byte count from 
0x-0x007f: 0x6b7ef1
ERASE FAILED!
Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
No usable erase functions left.
FAILED!
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom@flashrom.org, thanks!

Any idea?
Thanks
Pascal
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org