[flashrom] Re: Unable to build flashrom from git repo without sphinx
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 the meson build system and the Makefile might be removed in the near feature. -- Thomas On April 7, 2023 6:01:59 AM GMT+02:00, Anastasia Klimchuk wrote: >Hi Alex, > >This is definitely not intended behaviour: sphinx is optional. If it >is not present, flashrom can be built, just without docs. >I didn't have sphinx locally for a while, and was building the sources >without it. Only installed it very recently, because I started to add >docs. > >Can you tell exactly how you are building? Logs maybe? I want to help. > >-- >Anastasia. >___ >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] Re: UEFI password
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 plenty of how-to's on the internet. I hope you'll be successfull -- Thomas On Tue, 2023-03-07 at 13:03 +, Paul Pascut wrote: > Hello, > > my name is Paul, thank you for the great work you are doing! > > I have bought an HP laptop (elitebook 840 g2) from a company that sat > an administration password on the UEFI. > I tried to remove it using the UEFI procedure but it was not > enrolled... > I tried removing the bios battery but it didn't work... > > I was wondering if flashing the BIOS chip could reset the password. > Do you know if it is possible? do you have any advice how to do it? > > Best regards, > Paul > > P.S. I have a IC CH341A USB Programmer with the chip clip > ___ > 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] Re: Mother MSI H97 PC Mate [WORKING]
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 "Intel H97" Chipset as working ; "modprobe -r > lpc_ich" do the > trick. I write AMIBIOS v5.8, tested ; and going back to AMIBIOS v5.9. > ALL OK. > > guille@goku:~/Desktop/7850v59/7850v58$ sudo flashrom -p internal -w > E7850IMS. > 580 > flashrom unknown on Linux 6.1.0-5-amd64 (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 H97". > 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@flashrom.org including a > verbose (-V) > log. > Thank you! > Enabling flash write... SPI Configuration is locked down. > FREG0: Flash Descriptor region (0x-0x0fff) is read-write. > FREG1: BIOS region (0x0098-0x00ff) is read-write. > FREG2: Management Engine region (0x1000-0x0097) is read- > write. > Enabling hardware sequencing because some important opcode is locked. > OK. > Found Programmer flash chip "Opaque flash chip" (16384 kB, > Programmer- > specific) on internal. > Reading old flash chip contents... done. > Erasing and writing flash chip... Erase/write done. > Verifying flash... VERIFIED. > > Greeteng > Guillermo Reisch > > > El martes, 28 de febrero de 2023 16:06:27 -03 Guillermo Reisch > escribió: > > Mother home page > > https://www.msi.com/Motherboard/H97-PC-Mate > > > > SO: > > Debian SID (x86_64) > > > > FlashROM version: > > guille@goku:~/Desktop/7850v59$ dpkg -l flashrom > > Deseado=desconocido(U)/Instalar/eliminaR/Purgar/retener(H) > > > > > Estado=No/Inst/ficheros-Conf/desempaqUetado/medio-conF/medio- > > > inst(H)/esper > > > a- > > disparo(W)/pendienTe-disparo > > > > > / Err?=(ninguno)/requiere-Reinst (Estado,Err: mayúsc.=malo) > > > > > > > / Nombre Versión Arquitectura Descripción > > > > +++-==--- > > = > > ii flashrom 1.3.0-2 amd64 Identify, read, write, > > erase, > > and verify BIOS/ROM/flash chips > > > > LOG: > > > > guille@goku:~/Desktop/7850v59$ sudo flashrom -p internal -r > > backup.bin -V > > flashrom unknown on Linux 6.1.0-5-amd64 (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 GCC 12.2.0, little endian > > Command line (5 args): flashrom -p internal -r backup.bin -V > > Initializing internal programmer > > /sys/class/mtd/mtd0 does not exist > > No coreboot table found. > > Using Internal DMI decoder. > > DMI string chassis-type: "Desktop" > > DMI string system-manufacturer: "MSI" > > DMI string system-product-name: "MS-7850" > > DMI string system-version: "1.0" > > DMI string baseboard-manufacturer: "MSI" > > DMI string baseboard-product-name: "H97 PC Mate(MS-7850)" > > DMI string baseboard-version: "1.0" > > Found chipset "Intel H97" with PCI ID 8086:8cc6. > > 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@flashrom.org including a > > verbose (-V) > > log. > > Thank you! > > Enabling flash write... Root Complex Register Block address = > > 0xfed1c000 > > Error accessing ICH RCRB, 0x4000 bytes at 0xfed1c000 > > /dev/mem mmap failed: Operation not permitted > > FAILED! > > FATAL ERROR! > > Error: Programmer initialization failed. > > > > > ___ > 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] Re: showing progress or remaining time on stdout
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 the API is not stable and might change. Feedback is welcome. There is also a patch laying around adding a GTK GUI to flashrom https://review.coreboot.org/c/flashrom/+/69714 I hope I could help -- Thomas On Tue, 2023-03-07 at 12:37 +0100, Sean Dekker wrote: > Hi all, > > Is there a way/switch to write flash progress into std. I want to > create a graphical wrapper for flashrom and want to show the progress > on the screen. > > I tried to use different verbose switches but it is kind of not easy > to parse. > > I would appriciate your help! > ___ > 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] Re: Optimized Erase Function Selection Algorithm
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 the flash region to erase/write. This > should make using our application quicker and more convenient. > > Please ensure you have the latest source code to test the new > feature. > Do the following change to the flashrom.c file : > ``` > -static bool use_legacy_erase_path = true; > +static bool use_legacy_erase_path = false; > ``` > and build flashrom using make or meson. > Makefile: > ``` > $ make clean && make > ``` > Meson: > ``` > $ meson setup out > $ ninja -C out > ``` > > This feature offers the following: > - Lesser flash erase/write times (upto 80 times less on tests done so > far) > On the long term, we plan to enable feature by default. For now, you > need to enable it manually and rebuild from source code. > We would love to hear your feedback! Please let us know if you have > any questions or encounter any issues. > > -Aarya > ___ > 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] Re: Mother MSI H97 PC Mate
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 successfull with this modifications. -- Thomas [0] https://wiki.debian.org/BuildADebianKernelPackage On Tue, 2023-02-28 at 16:06 -0300, Guillermo Reisch wrote: > Mother home page > https://www.msi.com/Motherboard/H97-PC-Mate > > SO: > Debian SID (x86_64) > > FlashROM version: > guille@goku:~/Desktop/7850v59$ dpkg -l flashrom > Deseado=desconocido(U)/Instalar/eliminaR/Purgar/retener(H) > > Estado=No/Inst/ficheros-Conf/desempaqUetado/medio-conF/medio- > > inst(H)/espera- > disparo(W)/pendienTe-disparo > > / Err?=(ninguno)/requiere-Reinst (Estado,Err: mayúsc.=malo) > > > / Nombre Versión Arquitectura Descripción > +++-==--- > = > ii flashrom 1.3.0-2 amd64 Identify, read, write, > erase, and > verify BIOS/ROM/flash chips > > LOG: > > guille@goku:~/Desktop/7850v59$ sudo flashrom -p internal -r > backup.bin -V > flashrom unknown on Linux 6.1.0-5-amd64 (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 GCC 12.2.0, little endian > Command line (5 args): flashrom -p internal -r backup.bin -V > Initializing internal programmer > /sys/class/mtd/mtd0 does not exist > No coreboot table found. > Using Internal DMI decoder. > DMI string chassis-type: "Desktop" > DMI string system-manufacturer: "MSI" > DMI string system-product-name: "MS-7850" > DMI string system-version: "1.0" > DMI string baseboard-manufacturer: "MSI" > DMI string baseboard-product-name: "H97 PC Mate(MS-7850)" > DMI string baseboard-version: "1.0" > Found chipset "Intel H97" with PCI ID 8086:8cc6. > 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@flashrom.org including a > verbose (-V) > log. > Thank you! > Enabling flash write... Root Complex Register Block address = > 0xfed1c000 > Error accessing ICH RCRB, 0x4000 bytes at 0xfed1c000 > /dev/mem mmap failed: Operation not permitted > FAILED! > FATAL ERROR! > Error: Programmer initialization failed. > > > > ___ > 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] Re: Flashrom experimental chip support report
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 Albader via flashrom wrote: > Hi, I just flashed a firmware image to a "XM25QH64C" which is labeled > experimental, the flash was successful with default options on a > ch341a_spi > clone, here is the log. Sorry I couldn't get the debug output. > Reading and > writing worked just fine. Thanks a lot for maintaining this awesome > software! > > I used the git master branch version as of today. > ___ > 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] Re: W25Q32FVSIG
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 16:43 +, verithas--- via flashrom wrote: > Hello, i have a problem. > I build coreboot rom and write it with option in menu security: Boot > media > protection mechanism < Lock boot media using the chip > Chip is W25Q32JVSIG > After this option I can't erase the chip, log says: > > > root@devuan:/home/user/Documents/flashrom-v1.3.0# ./flashrom -- > programmer > ch341a_spi -E > flashrom v1.3.0 on Linux 5.15.41-hardened1 (x86_64) > flashrom is free software, get the source code at > https://flashrom.org > > Calibrating delay loop... OK. > Found Winbond flash chip "W25Q32.V" (4096 kB, SPI) on ch341a_spi. > === > This flash part has status UNTESTED for operations: WP > 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@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! > Erasing and writing flash chip... FAILED at 0x0030! > Expected=0xff, > Found=0x5f, failed byte count from 0x0030-0x00300fff: 0xddf > ERASE FAILED! > Looking for another erase function. > FAILED at 0x0030! Expected=0xff, Found=0x5f, failed byte count > from > 0x0030-0x00307fff: 0x7883 > ERASE FAILED! > Looking for another erase function. > FAILED at 0x0030! Expected=0xff, Found=0x5f, failed byte count > from > 0x0030-0x0030: 0xf6c5 > ERASE FAILED! > Looking for another erase function. > > > Option with --wp-disable is not work for W25Q32FVSIG > I have a W25Q128FVSIG chip, and option --wp-disable is work. > Datasheets with chips is same, different in memory size. > I hope the problem will be fixed soon > Thanks for attention. > Regards. > > > ___ > 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] Re: Successfully read an XM25QH256C with a CH341a based programmer.
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 Fri, 2023-02-24 at 18:07 +0100, James Russell wrote: > Hi, I just did a backup of the BIOS chip of a new laptop I got. in > case something happened to be able to restore it all to sane > defaults. > > Freshly built Flashrom snapshot on a live Arch (Manjaro) environment, > the chip is an XM25QH256C[XIQ] in a WSON8 package (6x8), I didn't > want to desolder the chip and I noticed some exposed solder where the > contacts would be so I did the dump using a pogo pin contraption > attached to the CH341a. It is an old programmer I've had for years (I > don't think there's any cheap-ish alternative using at least USB 2.0 > that is supported by Flashrom, so... it was slow), both Vcc and the > data lines ran at 3.3-ish volts. > > After the message that appeared during the read I thought "damn, I > didn't enable verbose output nor was I logging the operation", so I > did a verify operation afterwards which is essentially the same. Log > is attached and if you need the contents of the ROM I can attach them > too (32MiB). > > I didn't do much in-depth analysis of the ROM but it seems correct, > at least I can see UEFI and ME structures in there. > > Sadly, I don't plan on writing to that chip anytime soon, at least > not until I get a replacement because the setup is not very stable > and I don't want to risk the connection getting interrupted. These > XMC chips are hard to come by in my area, but Mouser sells an > equivalent Winbond that is also supported and is greenlit to be used > in this laptop; so I had ordered one of those to have at hand. > > Anyway, I digress haha, you have the Verify log attached to this > email (I thought there'd be more data there). > > Regards, > James. > > PS. I think it's not implemented, but perhaps adding a progress > indicator (since the flash chip's size is known) to read/write > operations would be handy, if it weren't for an indicator LED on my > programmer board I wouldn't really know if it was progressing or not. > ___ > 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] Re: build automation tool
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 library and a cli build ontop of it. The cli, and an other programm, ich_descriptors_tool, uses internal symbols of the library. Also the "internal" programmer is mixed with some "core" functionality which makes it currently difficult to move files around. We would be happy to solve those issues to have a better structure in the repository. For the second part, we've almost finnished the migration from gnumake to meson/ninja. Only cross-compiling for DOS and libpayload (coreboot payload) and a better update of the documentation is not finished yet. Plese feel free to test it of the most obscure platforms you've access to. With meson we already genreating a shared library. -- Thomas On Thu, 2023-02-23 at 09:49 +0530, Prakhar Agrawal wrote: > Hello, I was going through the GitHub repo of flashrom, and I saw > some files outside the folders. > > Do you think it will be a good idea to organise the files in the > directory and use a build automation tool like waf,cmake or maybe > bazel to auto-generate Makefiles. > It can also be used to create and link shared libraries easily. > > Looking forward to your opinions. > > Best Regards > Prakhar > ___ > 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] manpage and documentation
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 readable format like md or rst into groff / man-pages. So I've played around with some and found a solution with `Sphinx`[0] that might fit flashrom well. Sphinx is well known in the Open Source Community for project documentation. Coreboot, the Linux kernel and many other projects are using it already. So it is time tested and nothing really new. Beside rendering to html sides, sphinx is also capable to render groff/manpages which is quite nice. My reason for choosing sphinx over other tools was: - It is known to many people - reStructuredText is easy to read and write - It can produce groff/manpages *and* html without plugins/extensions/quirks - It is, like our meson based build system, written in python. So it runs where the build system runs and has no additional software stack like nodejs or ruby on rails - It is extendable to our needs (e.g. generate documentation from data with python) The conversion of the manpage from groff to sphinx/rst can be found here: https://review.coreboot.org/c/flashrom/+/72619 Going forward I would also like to suggest integrating the existing documentation of the Wiki to Sphinx (flashrom source / Gerrit) and supersede the current homepage with it. What do you think about this? -- Thomas [0] https://www.sphinx-doc.org/en/master/ ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: wbsio_spi.c / Intel D201GLY
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 flashrom wrote: > G'day flashrom'ers, > > Does anyone use or still need the wbsio spi path specifically used > for the Intel D201GLY board? I wish to remove this code > https://review.coreboot.org/c/flashrom/+/72828 if at all possible. > > The reasoning is that a lot of board_enable changes would be required > to allow for the drivers entry-point to be passed configuration and > other data. The driver is a single exception to every other driver in > the tree that either has a direct driver entry from the driver table > (programmer_table) or via the specalised "internal" programmer that > directs entry via a chipset_enable dispatch. It would be preferably > for board_enable not to have a deep CFG going right though it to > driver entry-points for one very specific case especially if the > driver isn't even used anymore? > > Interested to hear your thoughts or users? > Cheers, > Edward. > ___ > 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 Meeting
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 October 14th, at 5:00 utc (7:00 Berlin) on https://meet.google.com/cnw-cegw-rad Everyone is welcome to join! The working document can be found on https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU -- Thomas___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: NULLity to represent the default state of struct's
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 reader, i.e. will > they > know that there is a default action or will they wrongfully assume > that > NULL means there will be no action carried out. In case of the > `delay` > action, I think we are safe. That we need to delay is not an aspect > of > the programmer driver; it can only decide how we delay. So that there > is > always a (default) delay seems clear. When combining some changes, such as combining spi_master.command() and spi_master.multicommand(), renaming spi_master.read() to spi_master.optimized_read() and allowing spi_master.optimized_read() to be NULL, there will be good improvement in understandability. The logic is expressed through direct branching (using if) instead of jumping along a concatination of function pointers. The simplefied callgraphs below can give a hint on how it may look then. // The current implementation // mst->spi.read = default_spi_read() // mst->spi.command = default_spi_send_command spi.c: spi_chip_read() programmer_impl: mst->spi.read spi.c: default_spi_read() ... spi.c: spi_send_command() programmer_impl: mst->spi.command() spi.c: default_spi_send_command() spi.c: spi_send_multicommand() programmer_impl: mst->spi.multicommand() // Possible future implementation with the changes // mst->spi.commands replaces mst->spi.command & mst->spi.multicommand // mst->spi.optimized_read replaces mst->spi.read // mst->spi.optimized_read = NULL (default NULL) spi.c: spi_chip_read() if (mst->spi.optimized_read) mst->spi.optimized_read() else spi_read_via_command() spi.c: spi_read_via_command() programmer_impl: mst->spi.commands() So using default NULL alone may be not good, but when combing it with other changes it can give a good improvement over the current way the code is working. > > Other cases might be less clear. And there are even cases where > explicit > NULL checks should still be done, for instance when two custom > implemen- > tations are mutually exclusive. And now the meanest example of all: > Our > default_spi_command() and default_spi_multicommand(). It's ok to have > custom implementations for each of them and also for both of them. > But > we need at least one of them. So rules may be more complex than 'NULL > is ok' / 'NULL is not ok', and then checks can't be avoided even if > we use NULL-means-default. IMO combining those too into one spi_master function pointer may bring a loop more into the programmer, but frees up complexity at the other end. Furthermore we can get in a state that an entry in the spi_master struct or other structs are either mandetory or optional. So having no mutally exclusions. Then the meaning of NULL is also clear. > > There is another aspect that I don't feel strong about. IMO, it is > more > important to educate each other to avoid NULL in the first place than > to > check for it everywhere. There are a few cases where it makes sense > to > check, though. For instance it is easy to miss a field in our structs > full of function pointers (e.g. `flashchip` `*_master`). Now, if we > pro- > vide a (default) meaning to NULL in some cases, that might trick > inex- > perienced developers into thinking that NULL is generally allowed. I can't agree with you. In a modern interpretation of C, 0 / NULL can be used in a well defined ways, especially as default value in structs and it is nothing to avoid. I would educate people how to use NULL in a good way, rather than avoiding it. > > Cheers, > Nico -- 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] Re: Maybe move dev meeting from 22 Sept to 23 Sept?
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 are attending. > Joining a meeting early in the morning right after the last day of > conference, from a hotel room, is not ideal. > > 2) All of a sudden, AU got a [one-off] public holiday on 22 Sept > (National Day of Mourning) > > With all that, an idea is to move the meeting one day forward, 23 > Sept, the same time. > What do people think? > ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Build System Changes / Call for testing
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 need to install meson (>=0.53.0) and ninja beside the other flashrom dependencies from your package distributor. Create a buildconfiguration in with `meson ` Compile the configuration with `ninja -C ` Newer versions of meson may offer a nicer set of commands. Have a look at https://mesonbuild.com/Quick-guide.html To create to build a configuration with custom flags, use `meson -Doption=value ` A single programmer can for example be selected by `-Dprogrammer=ch341a_spi` or multiple by `-Dprogrammer=ch341a_spi,dediprog`. All pci based programmers can be selected by `-Dprogrammer=group_pci`. The default for the programmer is `auto`, which selects all proper working programmers. The option `all` selects also those programmers. For all options, please have a look at meson_options.txt in the flashrom repository. For aditional documentation look at Documentation/building.md in the flashrom repository. Beside all efforts to get things working, there are still some limits: - On MacOS only external programmers are supported. The old solution for internal programmer with DirectHW is in an unknown state. - Crosscompiling to libpayload is not working. - Crosscompiling to dos with djgpp is likely to fail - Windows should be working with MinGW (MSYS2) but is not tested well - The unit tests might be failing to compile or run on non Linux platforms, use `meson -Dtests=disabled ` to exclude them from getting build. - Platforms with libusb < 1.0.16 or older FreeBSD / DragonFly BSDs might fail to compile. https://review.coreboot.org/c/flashrom/+67073 will drop this down to >=1.0.9. I hope you will all enjoy these improvements and have fun testing it. If you find bugs or have problems, please respond to this mail. -- Thomas ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: NULLity to represent the default state of struct's
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 refactoring flashrom.c to move towards a reentrant flashrom a > pragmatic choice of utilising NULLity to represent the default state > of a struct at instiation was used in the following and related > commits - https://review.coreboot.org/c/flashrom/+/67391/ > > It was brought to my attention that this is perhaps considered a more > substantive change to the general practice within flashrom and so I > just wanted to give a brief prelude to the rationale and if anyone > has any reason why they don't like it. > > Basically using NULL as the default state rather than an invalid > state allows for memory address by value to be in a boolean state of > either 'defined to be default' or 'defined to be custom' - over that > of a tristate of 'defiled to be default explicitly', 'defined to be > custom' or NULL which must be manually validated as 'invalid'. This > is quite pragmatic as we can rid ourselves of explicit nullarity > checks at runtime and instead have always defined reasonable defaults > at compile-time thus making functions domains more well defined at > compile-time. It is also pragmatic and arguably more modern from the > stand-point of requiring less code to effectively obtain a valid > value from the instantiated type not unlike Rust's Default trait or > Ada's ability to have default values in a Record and so on. > > While not particularly novel I did want to follow up on the request > to highlight it here. > > Kindly, > Edward. > ___ > 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] Re: libflashrom rust binding
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 solution would be to create new repositories in gerrit for the bindings and the user of it. This would imply that we fix our api versioning first. Imo the separate repositories in combination with some gerrit bots might be the best solution to make everyone happy. But I'll support you, Evan, on the solution you will choose. -- Thomas On 20 July 2022 01:28:34 CEST, Evan Benn wrote: >On Tue, 19 Jul 2022 at 03:46, Greg Troxel wrote: >> >> >> Evan Benn writes: >> >> > 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. >> >> I am more or less an outsider, but as a packager: >> >> I do not want the binding to be hooked into the main build system. >> >> Building flashrom is one thing, and I expect that to work pretty much >> everywhere. >> > >Good point, I will make sure the bindings are not part of the build system. > >> Building the rust bindings I expect to be not wanted by everyone who >> wants flashrom, to have heavier dependencies (rustc is beastly), and >> to have signficant portability problems. That's all fine, but if in >> the same release tarball there should be a way to cd to some subdir, >> and build, expecting that flashrom is already installed and using the >> installed headers and libs, and expecting a rust compiler. >> >> I don't care at all about upstream repo organization if the rust >> binding is its own release tarball. > >I agree, the bindings do not need to go in the flashrom tarball. > >> >> I'll observe that changes to libflashrom and changes to the bindings >> may not be connected. >> >> Given all of the above, I think it's better to have each language >> binding be a separate repo with separate release tarballs. > >I see it is possible to exclude files from the archive using .gitattributes, >but that does not make it easy to publish a libflashrom-rust-bindings >archive separately. > >Does anyone know the process or contact for creating a new archive on >review.coreboot.org? > >Thanks >___ >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] Re: One Build System Working Group
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 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 meeting. > > We > > will use the same Google Meet room. > > > > The main topic for the meeting will be the adaption of the unit > > tests > > to the updated meson file and the overall 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 date. > > > > > > On Gerrit, relevant patches can be found under the > > > `one_build_system` > > > topic. [1] > > > The working document can be found on Google Docs [3] and gets > > > also > > > posted in plain text to the mailing list after the meeting. > > > > > > -- Thomas > > > > > > [0] https://terminplaner4.dfn.de/Eha1mJJ8jS2z2dkw > > > [1] > > > https://review.coreboot.org/q/project:flashrom+topic:one_build_system > > > [3] > > > https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit#heading=h.s4e4f1wg7ujz > > > ___ > > > 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 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] Re: One Build System Working Group
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 meeting. We > will use the same Google Meet room. > > The main topic for the meeting will be the adaption of the unit tests > to the updated meson file and the overall 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 date. > > > > On Gerrit, relevant patches can be found under the > > `one_build_system` > > topic. [1] > > The working document can be found on Google Docs [3] and gets also > > posted in plain text to the mailing list after the meeting. > > > > -- Thomas > > > > [0] https://terminplaner4.dfn.de/Eha1mJJ8jS2z2dkw > > [1] > > https://review.coreboot.org/q/project:flashrom+topic:one_build_system > > [3] > > https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit#heading=h.s4e4f1wg7ujz > > ___ > > 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 mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: One Build System Working Group
Hi folks, the next One Build System Working Group Meeting will be on Thursday June 16th at 7:00UTC after the general flashrom developer meeting. We will use the same Google Meet room. The main topic for the meeting will be the adaption of the unit tests to the updated meson file and the overall 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 date. > > On Gerrit, relevant patches can be found under the `one_build_system` > topic. [1] > The working document can be found on Google Docs [3] and gets also > posted in plain text to the mailing list after the meeting. > > -- Thomas > > [0] https://terminplaner4.dfn.de/Eha1mJJ8jS2z2dkw > [1] > https://review.coreboot.org/q/project:flashrom+topic:one_build_system > [3] > https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit#heading=h.s4e4f1wg7ujz > ___ > 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
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 found on Google Docs [3] and gets also posted in plain text to the mailing list after the meeting. -- Thomas [0] https://terminplaner4.dfn.de/Eha1mJJ8jS2z2dkw [1] https://review.coreboot.org/q/project:flashrom+topic:one_build_system [3] https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnCzGU/edit#heading=h.s4e4f1wg7ujz ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: how to enable the internal programmer
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 08:35 +, Selva Harris via flashrom wrote: > Hi, > > I have an Intel Apollo lake board. I want to read the SPI chip. When > I run 'flashrom -p internal', this is the message I get: > > > > flashrom v1.2-735-gb728f4b on Linux 4.5.5-300.fc24.x86_64 (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). > Error: Unknown programmer "internal". Valid choices are: > dummy, serprog, buspirate_spi, rayer_spi, pony_spi, linux_mtd, > linux_spi. > Please run "flashrom --help" for usage info. > > > > Thanks in advance, > Selva > ___ > 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] Re: [PATCH] Add voltage data for chips
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
https://doc.coreboot.org/tutorial/part2.html
Thanks
-- Thomas
On Wed, 2022-05-11 at 23:17 +0530, Chinmay Lonkar wrote:
> From: ChinmayLonkar
>
> This patch adds voltage data for following chips:
> * Intel 28F002BC/BL/BV/BX-T
> * Intel 28F004B5/BE/BV/BX-B
> * Intel 28F004B5/BE/BV/BX-T
> * Intel 28F008S3/S5/SC
> * Intel 28F400BV/BX/CE/CV-B
> * Intel 28F400BV/BX/CE/CV-T
> * Micron/Numonyx/ST M25P40-old
> * SyncMOS/MoselVitelic {F,S,V}29C51002T
> * Winbond W29C010(M)/W29C011A/W29EE011/W29EE012
> * Winbond W29C010(M)/W29C011A/W29EE011/W29EE012-old
>
> Change-Id: I42bc546e03a899086c034c026231955088a7d400
> Signed-off-by: Chinmay Lonkar
> ---
> flashchips.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/flashchips.c b/flashchips.c
> index d155b24..f9cb0cd 100644
> --- a/flashchips.c
> +++ b/flashchips.c
> @@ -8112,6 +8112,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_82802ab,
> .read = read_memmapped,
> + .voltage= {4500, 5500},
> },
>
> {
> @@ -8139,6 +8140,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_82802ab,
> .read = read_memmapped,
> + .voltage= {4500, 5500},
> },
>
> {
> @@ -8166,6 +8168,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_82802ab,
> .read = read_memmapped,
> + .voltage= {4500, 5500},
> },
>
> {
> @@ -8189,6 +8192,7 @@ const struct flashchip flashchips[] = {
> .unlock = unlock_28f004s5,
> .write = write_82802ab,
> .read = read_memmapped,
> + .voltage= {2700, 3300},
> },
>
> {
> @@ -8217,6 +8221,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_82802ab,
> .read = read_memmapped,
> + .voltage= {2700, 3600},
> },
>
> {
> @@ -8245,6 +8250,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_82802ab,
> .read = read_memmapped,
> + .voltage= {2700, 3600},
> },
>
> {
> @@ -10521,6 +10527,7 @@ const struct flashchip flashchips[] = {
> .unlock = spi_disable_blockprotect_bp3_srwd,
> .write = spi_chip_write_256,
> .read = spi_chip_read,
> + .voltage= {2300, 3600},
> },
>
> {
> @@ -16884,6 +16891,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_jedec_1,
> .read = read_memmapped,
> + .voltage= {4500, 5500}
> },
>
> {
> @@ -16910,6 +16918,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_jedec_1,
> .read = read_memmapped,
> + .voltage= {4500, 5500}
> },
>
> {
> @@ -18607,6 +18616,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_jedec,
> .read = read_memmapped,
> + .voltage= {4500, 5500},
> },
>
> {
> @@ -18630,6 +18640,7 @@ const struct flashchip flashchips[] = {
> },
> .write = write_jedec,
> .read = read_memmapped,
> + .voltage= {4500, 5500},
> },
>
> {
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Future of DirectHW
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. https://github.com/CloverHackyColor/directhw/commit/2c1b9d339df313c0f0f288f77ad69ec169f513ef -- Thomas On Mon, 2022-04-11 at 07:35 +, Andy Pont wrote: > Thomas wrote... > > > 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? > I’ll try to make some time to look at it during this week. > > -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] Re: [GSoC 2022] Restructure Shutdown Function
is. In reality, that would be a
> > project that has both goals touched. But that’s fine, that’s even
> > more
> > fun :)
> >
> > More information on the topic.
> >
> > Given that the main side-effect of shutdown functions issues is
> > memory
> > leak and other resources leak, there is another idea. I have to
> > admit,
> > idea is currently exists in my head but still:
> >
> > At the moment every master has to do its own memory management,
> > allocate and free memory for its own state. Memory management can
> > be
> > also moved under API, so that master cannot “forget” to free
> > resources.
> >
> > Another way to enforce memory management is to write lifecycle unit
> > tests for all programmers. Unit tests are all configured with
> > memory
> > checks, so if you run a scenario “initialise programmer -> shutdown
> > programmer” and memory leaks 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 at the
> > moment,
> > whether it should be required for master to have a shutdown
> > function
> > (it is not required at the moment). If we decide positive on that,
> > there is work to do to make it possible to have shutdown function
> > required.
> >
> > 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 think! ;)
> >
> > On Wed, Apr 6, 2022 at 4:24 AM Thomas Heijligen
> > wrote:
> > >
> > > 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 note that
> > > > they are
> > > > all
> > > > SPI. As I understood, they use the following approaches:
> > > >
> > > > 1. Register a callback by its own
> > > >
> > > > if (register_shutdown(serprog_shutdown, NULL))
> > > > goto init_err_cleanup_exit;
> > > >
> > > > 2. Fill `struct spi_master` shutdown-callback
> > > >
> > > > static struct spi_master spi_master_dediprog = {
> > > > ...
> > > > .shutdown = dediprog_shutdown,
> > > > };
> > > >
> > > > Is there any significant difference in this approaches? Or does
> > > > it
> > > > just
> > > > depend on code flow?
> > > >
> > > The goal is the same. To reduce the global state and the number
> > > of
> > > calls to register_something. The differnt is the way how to use
> > > the
> > > shutdown stack. The shutdown function as part of the programmer
> > > struct
> > > is a more declarative approch. when working this further, the bus
> > > master could also be declared in the programmer struct. But
> > > that's a
> > > topic for a different project.
> > >
> > > Anastasia may give you more details about the shutdown function
> > > in the
> > > *_master struct.
> > >
> > > -- Thomas
> >
> >
> >
> > --
> > Anastasia.
> ___
> 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] [GSoC 2022] Restructure Shutdown Function
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 think! ;) To register the shutdown function with the bus master is a good step and in any case part of the project. What do you think of exposing the bus master(s) and the shutdown function through the programmer_entry struct instead of register them in the programmer code. This would make the programmers "API" declarative and move all manipulation of global structs, shutdown stack & bus master stack, out of the individual programmer into a common logic. -- Thomas ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: One Build System Working Group
Hi Greg, thanks for your feedback! I've updated the document with your suggestions. On Wed, 2022-04-06 at 20:55 -0400, Greg Troxel wrote: > > 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". The current policy with the Makefile is to stay backwards compatible. Since meson is not this long around we have to choose a way to go. Personally I had the problem that my system meson from a rolling release distro was to old to build a project from master branch. --- ## Open questions * System requirements * How long should we support systems / libraries? * The Makefile supports really old systems in theory (not tested) * Our dependencies are quite stable (libpci, libusb1, …) * Should we support systems until their EOL? What's with LTS systems? * Long-Term stable may a issue, as wee need workarounds on our side for older versions * What should be the minimum required version of meson? * How to find a compromise to satisfy all users of flashrom? --- > > > * 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. I didn't know the exact difference sice all systems get build as SunOS --- ## Platforms to support * Systems * SunOS, Solaris / illumos, OmniOS, OpenIndiana --- > > > * 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. There is code that works only on one architecture, like x86 port I/O or msr access. Some architectures need a sync call fall mmio. When trying flashrom on a unsupported architecture this may result in unwanted behavior. --- ## Platforms to support * Architectures (32 & 64bit sets) * x86 (much exclusive codes paths) * mips (some exclusive mips code paths, processor_enable.c) * ppc (single exclusive code path, hwaccess_physmap.c) * arm * sparc (single exclusive codepath, hwaccess_physmap.c) * alpha * hppa * m68k * riscv * sh * s390 * arc * (cross compiling architectures) ## Tasks * Make sure the mmio sync is implemented for all supported architectures --- > > 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. --- ## Tasks * Reduce the number of #ifdef by moving the decision to the build system --- > > > * Write documentation > > * Build instructions f
[flashrom] Re: Future of DirectHW
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
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] Future of DirectHW
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
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
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: [GSoC 2022] Restructure Shutdown Function
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 note that they are
> all
> SPI. As I understood, they use the following approaches:
>
> 1. Register a callback by its own
>
> if (register_shutdown(serprog_shutdown, NULL))
> goto init_err_cleanup_exit;
>
> 2. Fill `struct spi_master` shutdown-callback
>
> static struct spi_master spi_master_dediprog = {
> ...
> .shutdown = dediprog_shutdown,
> };
>
> Is there any significant difference in this approaches? Or does it
> just
> depend on code flow?
>
The goal is the same. To reduce the global state and the number of
calls to register_something. The differnt is the way how to use the
shutdown stack. The shutdown function as part of the programmer struct
is a more declarative approch. when working this further, the bus
master could also be declared in the programmer struct. But that's a
topic for a different project.
Anastasia may give you more details about the shutdown function in the
*_master struct.
-- Thomas
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: [GSoC 2022] Restructure Shutdown Function
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 make a successfull application for
GSoC.
> Almost of
> them use global variables, but I already have ideas on how to rewrite
> it. Now I start coding a prototype and want to implement struct
> example_data. But I have run into a problem with its initialization:
>
> 1) In theory, we can declare a static variable within each
> programmer's
> file. It would be convenient, but this method has a big disadvantage.
> We allocate private_data for every programmers but use only one.
Yes. Also this would keep the global state at the same place.
> 2) It's not possible to add a variable to struct programmer_entry
> because the structure is read only (structures in programmer.h are
> declared as const)
This could be possible. When converting `static const struct
programmer_entry *programmer` from flashrom.c into `struct
programmer_entry` and copying the function pointer from the selected
progtrammer.
Beside that, there is `flashrom_programmer` in the libflashrom api
which is currently an unused placeholder. This could used to hold the
programmer_entry and the data.
> 3) Use a static global variable in flashrom.c. Lesser of two evils
> principle as they say
>
> static const struct programmer_entry *programmer = NULL;
> static const char *programmer_param = NULL;
> static void *programmer_data = NULL;
This is the easiest version and would also the variant I would begin
with.
> The next issue is the initialization of programmer_data:
>
> a) Do it inside programmer->init(). The problem here is the
> duplication
> of programmer_data init code in each function.
>
> b) Do it outside programmer->init(). The problem here is that we
> can't
> find out the size of example_data (it can be drkaised_data,
> it85spi_data and etc)
>
> programmer_data = calloc(1, sizeof(EXAMPLE_DATA));
> if (!data) {
> ...
> }
> ...
> ret = programmer->init(_data);
Since the programmer data is unique to each programmer it can only be
initialized in that programmer init code.
The location of the programmer data can be hand over to the init
function.
`programmer_init(void **data);` and the called like `programmer-
>init(_data);
>
> Perhaps there is some simpler solution, but I don't notice it.
>
I hope this answers your questions enough. Otherwise please ask again.
--Thomas
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: [GSoC 2022] Restructure Shutdown Function
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 shutdown functions. Almost of
>them use global variables, but I already have ideas on how to rewrite
>it. Now I start coding a prototype and want to implement struct
>example_data. But I have run into a problem with its initialization:
>
>1) In theory, we can declare a static variable within each programmer's
>file. It would be convenient, but this method has a big disadvantage.
>We allocate private_data for every programmers but use only one.
>
>static struct example_data {
> ...
>} private_data;
>
>2) It's not possible to add a variable to struct programmer_entry
>because the structure is read only (structures in programmer.h are
>declared as const).
>
>3) Use a static global variable in flashrom.c. Lesser of two evils
>principle as they say
>
>static const struct programmer_entry *programmer = NULL;
>static const char *programmer_param = NULL;
>static void *programmer_data = NULL;
>
>The next issue is the initialization of programmer_data:
>
>a) Do it inside programmer->init(). The problem here is the duplication
>of programmer_data init code in each function.
>
>b) Do it outside programmer->init(). The problem here is that we can't
>find out the size of example_data (it can be drkaised_data,
>it85spi_data and etc)
>
>programmer_data = calloc(1, sizeof(EXAMPLE_DATA));
>if (!data) {
> ...
>}
>...
>ret = programmer->init(_data);
>
>Perhaps there is some simpler solution, but I don't notice it.
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Questions regarding Easy project and GSoC
Hi Aarya, in most scenarios you operate only on one region of the layout. Then overlapping regions doesn't matter. Also overlapping regions can be useful when dealing with nested structures. E.g. an Intel IFD image and the BIOS region contains a coreboot fmap. All in all the user of the layout function is responsible for taking the right actions. -- Thomas On 31 March 2022 21:51:40 WEST, Aarya Chaumal wrote: >Hi Thomas, > >Can overlapping regions in the layout file cause problems or lead to >ambiguous results. If yes, then I think we should do the checks. > >Aarya. > >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 >> >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 address. >> There are no checks for overlapping regions. The parsing of a layout file >> is done by layout_from_file() in layout.c >> >> -- Thomas >> ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Questions regarding Easy project and GSoC
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 address. There are no checks for overlapping regions. The parsing of a layout file is done by layout_from_file() in layout.c -- Thomas ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
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 defined and usable across all projects which uses meson. The build options are accessible without the need to dig into the buildfile or project documentation. With Makefiles every project has its own set of options and variables. That is an overhead you have to deal with as package maintainer. >From a project developer perspective meson takes away a lot of work you >otherwise have to do by your own in the Makefile. For example system >determination, searching for dependencies and cashing of the build >configuration. >Personally I am more familiar with >Make, but even I can see that our Makefile is one that only a flashrom >developer could love. I've spend a lot of time into the Makefile in the last month and my hope is that it's more readable by now. I'm truly not a fan of it and I would be happy if we can drop it. But implementation wise the meson.build is not better. It's a translation from the Makefile which makes only minimal use of mesons features. ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: Release preparations
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 of the Meson users are. >> >> My vote would be to remove the *Makefile*, and move 100% to Meson -- >> the modern build-system that's *already* being used by the packagers >> for all the supported architectures and OS builds on dozens of >> distros. > >FWIW, the pkgsrc build is currently using the Makefile. I use that to >get flashrom on NetBSD-9 amd64 to use with apu2. > >More importantly, the instructions in the README in flashrom 1.2 do not >mention meson and say to use make. > >Similary, > https://www.flashrom.org/Downloads#Installation_from_source >does not mention meson. >(It also doesn't mention that specifically GNU make is required, vs BSD >make, but that's pretty common to omit.) > >(I'm not claiming that building with meson wouldn't work, but just >pointing out that "all packaging system builds use meson" is incorrect.) > >So if there is any talk of removing makefiles, there needs to be a >release with formal support for meson including it being the standard >approach in REAMDE and a deprecation warning. > Beside from the documentation, the meson file currently only works for Linux and was never announced as official way to build flashrom. Dropping the Makefile is also no option as long as the meson.build does not work with all platforms supported by flashrom. In a release we should have a consisted build system across all those platforms. The two build systems are also topic of the next developer meeting. Imo we should find a proper solution for the meson build file and do not rush for the next release. -- Thomas ___ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-le...@flashrom.org
[flashrom] Re: [GSoC 2022] Restructure Shutdown Function
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 shutdown() function should take care of all initialized items from the init() function. That can also be a pointer to memory mapped I/O, a pci_dev or libusb context. When we take a simple programmer like the drkaiser pci programmer, there is a pci device, a pointer to memory mapped I/O and one register. This can easily be handled in a few lines. * The internal programmer is some kind of special, since it was part of the flashrom core before other programmers exits. * How to implement certain aspects is then part of the project. * We try to reduce the amount of global variables. This project is part of it. -- Thomas On Sat, 2022-03-19 at 15:59 +0300, Joursoir wrote: > Hello Thomas and Anastasia, > > Thank you for the quick answer. Now I understand the idea of the > project more correctly. It really will be great if programmers > have their own shutdown functions. > > In your example you have used pci_write_*(), but the real flashrom > code uses only rpci_write_* (it registers an undo-callback). Saving > the data to some structure on every pci_write_*() is unnecessary > complexity. So, we can continue to use rpci_write_*(), which will do > work for us, but in a different way. The main problem is that > register_shutdown() often occurs not in example_init(), but in its > called funcs. Let's see on the example of internal programmer: > > internal_init() -> chipset_flash_enable() -> > -> chipset_enables[i].doit() -> enable_flash_vt823x() > > The last one can contain 1 or more rpci_write_*(). I suggest not to > register shutdown in rcpi_write_*(), but to fill a linked list with > value that should be restored. It will be restored in > example_shutdown(). > > Should global variables be used? In the case of an internal > programmer, struct example_data will go a long way before data is > written to it. > ___ > 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] Re: Questions regarding Easy project and GSoC
Hi Aarya,
Yes, that is the plan. There is an open patch[1] in Gerrit to add
deserialization functions for endian specific encoding.
Parsing data to a struct can then look like this:
struct data {
uint16_t a;
uint32_t b;
};
void* buffer;
struct data my_data;
my_data.a = read_le16(bufer);
my_data.b = read_le32(buffer + 2);
The endian independent layout parsing is the main component for this
project. But we are glad of every closed issue.
For the fmap parsing I've stated an attempt last year but got deviated
by other tasks. The code is far from working, but you may want to have
a look. The first version on Gerrit [2] and a copy of my private
working tree [3].
Most data flashrom reads are just passed to the user. The user should
know how to handle it. This is not the job of flashrom. Only when
flashrom itself needs to interpret some data, like layout information
of the chip, we need to care about it.
[1] https://review.coreboot.org/c/flashrom/+/31016/12
[2] https://review.coreboot.org/c/flashrom/+/57265/4
[3] https://gist.github.com/heijligen/8828cec759f552549b201bdf35976f39
-- Thomas
On Sat, 2022-03-19 at 19:08 +0530, Aarya Chaumal wrote:
> Hi Thomas,
>
> Thank you for your quick reply on the "fixing endianness issues"
> project. I saw that in the code that functions
> flashrom_layout_read_from_* only work for little-endian machines and
> return an error code otherwise. Also, the function
> flashrom_layout_parse_fmap is defined for little-endian machines. So
> maybe we can have a function to convert the data into the endianness
> of the machine before parsing/reading it. Macros are defined for up
> to 64bit endianness conversion in hwaccess.h but they are not used
> anywhere. Doing this much should make the code run on both types of
> machines. This logic might also work in other parts of the code which
> are endian specific (currently not sure which parts are these)
>
> Furthermore, I think we should give the user 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 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 the memory. This works only
> > when
> > flashrom runs on a CPU with the same endian as fmap defines. We
> > have
> > two macros, __FLASHROM_LITTLE_ENDIAN__ and __FLASHROM_BIG_ENDIAN__
> > which handle code that works only on one endian. In the GSoC
> > project,
> > we want to make this code run on little and big endian systems.
> > Besides
> > that, we may find additional parts in the code which are endian
> > specific.
> >
> > -- Thomas
> >
> > On Sun, 2022-03-13 at 08:13 +0530, Aarya Chaumal wrote:
> > > As suggested, I have been doing some of the easy projects till
> > > now
> > > and
> > > I have enjoyed it. I have submitted a few patches till now and
> > > some
> > > of
> > > them have gotten +2 code-reviews but still, they were not merged.
> > > Is
> > > there anything that is required to get the changes to be merged?
> > > Also, I have fixed most of the issues I got by running scan-
> > > build,
> > > only 2 classes of issues were remaining which I feel are false
> > > positives (showing underflow error but those cases won't occur or
> > > are
> > > handled seprately) created by the tool and can be ignored.
> > > As was going through your proposed projects for GSoC, I found
> > > "optimizing erase-function" and "fixing endianness issues"
> > > interesting and would like to do that in the summer. Can you
> > > suggest
> > > some tasks so that I can know more about these projects and get
> > > an
> > > idea of how to write my proposal for GSoC for doing this project?
> > > Thanks :)
> > >
> > > On Thu, Mar 10, 2022 at 10:45 AM Anastasia Klimchuk
> > > wrote:
> > > >
> > > > Hello Aarya,
> > > >
> > > > Nice to meet you! I think I saw your question on the IRC
> > > > channel,
> > > > and someone replied, was that your question?
> > > > Do you still need more info? Let us know if yes.
> > > >
> > > > Thanks!
> > > >
> > > &
[flashrom] Re: [GSoC 2022] Restructure Shutdown Function
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 shutdown later. In this project, the state tracking and
shutdown of the programmer own data should be moved to each programmer.
E.g.:
const struct programmer_entry example_programmer = {
...
.init = example_init,
.shutdown = example_shutdown,
};
struct example_data {
int reg_a;
};
static int example_init(struct example_data* data)
{
...
// keep track of the original value
data->reg_a = pci_read_word(dev, PCI_MAGIC_ADDR, PCI_MAGIC_VALUE);
// write new value
pci_write_word(dev, PCI_MAGIC_ADDR, 0x42);
}
static int example_shutdown(struct example_data* data)
{
// restore the original value
pci_write_word(dev, PCI_MAGIC_ADDR, data->reg_a);
}
Feel free to contact me if you have further questions.
-- Thomas
On Fri, 2022-03-18 at 17:46 +0300, Joursoir wrote:
> Good day,
>
> I am a student and very interested in flashrom. I fit the description
> of experienced C programmer. Open-source and low-level programming
> are
> my interests. I already have real experience with flashrom (CH341A
> programmer + chip "MX25L6436E") and want to become a GSoC 2022
> contributor in this project.
>
> I find the "Restructure Shutdown Function" project interestring to
> me.
> But right now it has no mentors. Maybe someone from the mailing can
> help me.
>
> I have gone through sources and understand how things are now. The
> project description says "have a defined shutdown function in the
> programmer API". But we already have it. It's programmer_shutdown().
> Or no?
>
> The first and easiest thing that comes to my mind is to refuse using
> callbacks and use enums, thusly:
>
> enum shutdown_func {
> SERPROG = 1 << 0,
> SPI = 1 << 1,
> ...
> };
>
> int programmer_shutdown(enum shutdown_func execfunc)
> {
> ...
>
> if(execfunc & SERPROG)
> ret |= serprog_shutdown(...);
>
> if(execfunc & SPI) {
> /* the problem is that SPI programmers have own shutdown
> funcs,
> like dlc5_shutdown, byteblaster_shutdown,
> stlinkv3_spi_shutdown,
> so use struct spi_master, that contains shutdown callback
> */
> ret |= spi_master_shutdown(...);
> }
>
> ...
> }
>
> This system has disadvantages, but it'll make easier to track the
> code
> flow. What are the potential problems in this implementation?
>
> What's with struct flashrom_programmer? Is not implemented yet?
>
> I would appreciate any feedback.
>
> --
> Joursoir
> ___
> 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] Re: Questions regarding Easy project and GSoC
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 the memory. This works only when flashrom runs on a CPU with the same endian as fmap defines. We have two macros, __FLASHROM_LITTLE_ENDIAN__ and __FLASHROM_BIG_ENDIAN__ which handle code that works only on one endian. In the GSoC project, we want to make this code run on little and big endian systems. Besides that, we may find additional parts in the code which are endian specific. -- Thomas On Sun, 2022-03-13 at 08:13 +0530, Aarya Chaumal wrote: > As suggested, I have been doing some of the easy projects till now > and > I have enjoyed it. I have submitted a few patches till now and some > of > them have gotten +2 code-reviews but still, they were not merged. Is > there anything that is required to get the changes to be merged? > Also, I have fixed most of the issues I got by running scan-build, > only 2 classes of issues were remaining which I feel are false > positives (showing underflow error but those cases won't occur or are > handled seprately) created by the tool and can be ignored. > As was going through your proposed projects for GSoC, I found > "optimizing erase-function" and "fixing endianness issues" > interesting and would like to do that in the summer. Can you suggest > some tasks so that I can know more about these projects and get an > idea of how to write my proposal for GSoC for doing this project? > Thanks :) > > On Thu, Mar 10, 2022 at 10:45 AM Anastasia Klimchuk > wrote: > > > > Hello Aarya, > > > > Nice to meet you! I think I saw your question on the IRC channel, > > and someone replied, was that your question? > > Do you still need more info? Let us know if yes. > > > > Thanks! > > > > On Wed, Mar 9, 2022 at 2:42 PM Aarya Chaumal > > wrote: > > > > > > Hello there, > > > > > > I hope you are well today when you receive this email. I am Aarya > > > Chaumal, a Computer Engineering student at the College of > > > Engineering Pune, India. While going through organizations for > > > this year's Google's Summer of Code I came across your > > > organization, Flashrom. > > > > > > I am a part of onboard computers subsystem at my college's > > > satellite initiative. Through this, I have closely worked on > > > Atmel SAM E70 XPLAINED board. Also, I have strong knowledge about > > > C/C++ and assembly language. From your list of GSoC project > > > ideas, I liked the idea of “Remove global state from flashrom” > > > and "Optimize Erase-Function Selection", although I am not quite > > > sure which one is more suitable for me. Can you guide me through > > > this? > > > > > > As mentioned in your Contributor commitments and requirements, I > > > started to do one of the easy projects - Add new flash chip > > > definitions. For this, I read the relevant datasheets, one from > > > the unlisted chips and another of a listed one (for reference) > > > but still, I am not getting the information about some fields for > > > the structure in the datasheet, namely the feature_bits, > > > probe_timing. Also, do I have to write the probe, read, write and > > > erase functions for the chip separately? Also, how do I test if > > > my code is working as I don't have relevant hardware with me? Can > > > you help me with this? Also what resources should I use to learn > > > more about it? > > > > > > Thank you for looking into this for me. > > > Sincerely, > > > Aarya Chaumal > > > ___ > > > flashrom mailing list -- flashrom@flashrom.org > > > To unsubscribe send an email to flashrom-le...@flashrom.org > > > > > > > > -- > > Anastasia. > ___ > 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] Re: Questions regarding Easy project and GSoC
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 the memory. This works only when flashrom runs on a CPU with the same endian as fmap defines. We have two macros, __FLASHROM_LITTLE_ENDIAN__ and __FLASHROM_BIG_ENDIAN__ which handle code that works only on one endian. In the GSoC project, we want to make this code run on little and big endian systems. Besides that, we may find additional parts in the code which are endian specific. -- Thomas On Sun, 2022-03-13 at 08:13 +0530, Aarya Chaumal wrote: > As suggested, I have been doing some of the easy projects till now > and > I have enjoyed it. I have submitted a few patches till now and some > of > them have gotten +2 code-reviews but still, they were not merged. Is > there anything that is required to get the changes to be merged? > Also, I have fixed most of the issues I got by running scan-build, > only 2 classes of issues were remaining which I feel are false > positives (showing underflow error but those cases won't occur or are > handled seprately) created by the tool and can be ignored. > As was going through your proposed projects for GSoC, I found > "optimizing erase-function" and "fixing endianness issues" > interesting and would like to do that in the summer. Can you suggest > some tasks so that I can know more about these projects and get an > idea of how to write my proposal for GSoC for doing this project? > Thanks :) > > On Thu, Mar 10, 2022 at 10:45 AM Anastasia Klimchuk > wrote: > > > > Hello Aarya, > > > > Nice to meet you! I think I saw your question on the IRC channel, > > and someone replied, was that your question? > > Do you still need more info? Let us know if yes. > > > > Thanks! > > > > On Wed, Mar 9, 2022 at 2:42 PM Aarya Chaumal > > wrote: > > > > > > Hello there, > > > > > > I hope you are well today when you receive this email. I am Aarya > > > Chaumal, a Computer Engineering student at the College of > > > Engineering Pune, India. While going through organizations for > > > this year's Google's Summer of Code I came across your > > > organization, Flashrom. > > > > > > I am a part of onboard computers subsystem at my college's > > > satellite initiative. Through this, I have closely worked on > > > Atmel SAM E70 XPLAINED board. Also, I have strong knowledge about > > > C/C++ and assembly language. From your list of GSoC project > > > ideas, I liked the idea of “Remove global state from flashrom” > > > and "Optimize Erase-Function Selection", although I am not quite > > > sure which one is more suitable for me. Can you guide me through > > > this? > > > > > > As mentioned in your Contributor commitments and requirements, I > > > started to do one of the easy projects - Add new flash chip > > > definitions. For this, I read the relevant datasheets, one from > > > the unlisted chips and another of a listed one (for reference) > > > but still, I am not getting the information about some fields for > > > the structure in the datasheet, namely the feature_bits, > > > probe_timing. Also, do I have to write the probe, read, write and > > > erase functions for the chip separately? Also, how do I test if > > > my code is working as I don't have relevant hardware with me? Can > > > you help me with this? Also what resources should I use to learn > > > more about it? > > > > > > Thank you for looking into this for me. > > > Sincerely, > > > Aarya Chaumal > > > ___ > > > flashrom mailing list -- flashrom@flashrom.org > > > To unsubscribe send an email to flashrom-le...@flashrom.org > > > > > > > > -- > > Anastasia. > ___ > 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] Re: Flashrom Dev Meeting once a month?
My suggestion would be to have Europe in the morning. This is hard if someone from the US want to paticipate, but it's more pleasant for us. Here an example calculation for 07:00 UTC: 07:00 UTC 08:00 Central European Time; Germany, Poland... 09:00 Central European Summer Time (from march 27th) 17:00 Australian Eastern Standard Time; Sidney (from april 2nd?) 18:00 Australian Eastern Daylight Time; Sidney (23:00 Pacific Standard Time; California) -- Thomas On Thu, 2022-02-03 at 19:49 +1100, Anastasia Klimchuk wrote: > Thanks heaps Felix for sharing the experience from coreboot meetings, > 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 > wrote: > > 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, > > > > > > One good idea came up recently: to organize a “Flashrom > > > Developers > > > Meeting” so that we can talk to each other, discuss current > > > development and future plans! The idea is, specifically, to have > > > it > > > regularly - and once a month seems just about right. > > > The attendance will be, obviously, entirely optional, however one > > > thing is important: to take notes from what has been discussed > > > (and > > > notes should be public). > > > > > > The main two questions are: when? (time) and which software to > > > use. > > > > > > Time is a tricky question, and it depends on who is going to > > > attend > > > the meeting. We can optimize either for EU-US or for EU-AU. I can > > > say > > > for sure, we have at least one person from AU who is going to > > > attend > > > ;) (that’s me). > > > If it turns out that we have people all over the planet who want > > > to > > > attend, and there is no one time that suits all, then as a plan B > > > we > > > can alternate between two options. That will be time1 and time2 > > > alternating. > > > > > > Software. What do people use and like? I am used to Google Meet, > > > and > > > don’t know much about other options. > > > > > > What do people think of the idea? Let’s discuss! > > > ___ > > > 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 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] Re: Flashrom Dev Meeting once a month?
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, > > One good idea came up recently: to organize a “Flashrom Developers > Meeting” so that we can talk to each other, discuss current > development and future plans! The idea is, specifically, to have it > regularly - and once a month seems just about right. > The attendance will be, obviously, entirely optional, however one > thing is important: to take notes from what has been discussed (and > notes should be public). > > The main two questions are: when? (time) and which software to use. > > Time is a tricky question, and it depends on who is going to attend > the meeting. We can optimize either for EU-US or for EU-AU. I can say > for sure, we have at least one person from AU who is going to attend > ;) (that’s me). > If it turns out that we have people all over the planet who want to > attend, and there is no one time that suits all, then as a plan B we > can alternate between two options. That will be time1 and time2 > alternating. > > Software. What do people use and like? I am used to Google Meet, and > don’t know much about other options. > > What do people think of the idea? Let’s discuss! > ___ > 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] Re: Call for Mentors for GSoC 2022
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 preparing an application > for GSoC 2022 (also known as Google Summer of Code, FAQ). We have > gathered a list of Project Ideas, and it's time to call for Mentors! > If you are interested in being a Mentor, please let us know. If you > want to help, but not sure you can be a Mentor yourself, you can be a > secondary Mentor. Or you can help by doing code reviews. > > Have a look into our Projects ideas, are you interested to Mentor one > of these projects? > https://docs.google.com/document/d/1AxMobB2v8Dv2uUwZPZ_vCmmONYDJuliHcnjfWOs4qIs/edit?usp=sharing > > Or maybe you have another project idea that you want to mentor? > Great! > > GSoC runs by a timeline > https://developers.google.com/open-source/gsoc/timeline, check that > dates are OK for you. > > How to let us know if you are interested: Reply All to this email. If > you are in doubt, you can contact me (Anastasia/aklm) directly. > > Some more useful information: > > Mentor responsibilities (short) > https://developers.google.com/open-source/gsoc/help/responsibilities#mentor_responsibilities > > Mentor guides (long, lots of details) > https://google.github.io/gsocguides/mentor/ > > If you have any questions, you are welcome to ask! ;) > > Your GSoC Org Admin, > Anastasia. > ___ > 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
