flashrom

flashrom@flashrom.org

1 participants
9187 discussions

Start a nNew thread

Erase/write error
by domimoel＠web.de 28 Aug '22

28 Aug '22

2 1

flashrom dev meeting notes 26.08.22
by Felix Singer 26 Aug '22

26 Aug '22

# 25th Aug 2022, 6:00 - 7:00 UTC+0 Attendees: Alex, Felix, Evan, Anastasia, Edward ## Decisions Summary * A link pointing to the meeting will be added on the Contacts page. * We want to discuss the minimum required versions of our (build- )dependencies. We don’t want ifdefs checking for library versions in the code. When a programmer doesn’t support a library version, the build system should not enable it. ## Agenda * [aklm] Are there any objections if I will add info about this meeting on the Contacts page? * Clarify this is NOT a support forum, not a troubleshooting forum * [Felix] Rework the flash chips database / minimize the compiled version of flashchips.c in size * In most cases, embedded applications only need a small selection of the available flash chips. If we are able to shrink it somehow, this could free useful space for other applications or use cases. * One approach: Currently, flash chips are grouped by vendors. So add compiler flags enabling or disabling these. * Another approach: Rework the way flash chips are organized. * flashchips.c is pretty inflexible and it’s complicated to get this in a format so that flash chips can be listed on the website. * Thus, store flash chips in an JSON file (may be any other format), which opens lots of possibilities. * The website could just use the JSON and list the data. For flashrom itself, we could write a little script (and add this to the build system) which converts the JSON data to C code. This way, we also could filter for specific flash chip characteristics (protocols, vendor, name, …), in case only a group or some specific chips are wanted. * Another advantage: We could add an API to (lib-)flashrom so that the user can use their own JSON file and so the user can add new (or change) flash chips without recompiling flashrom very easily. So flash chips can be compiled into flashrom but they also can be loaded using the JSON format. * Edward: there are patches for review [https://review.coreboot.org/q/topic:declarative_flashchips.c_complete](http… * [Felix/Thomas] We should define minimum required versions of libraries and (build-)dependencies * [https://review.coreboot.org/c/flashrom/+/65919](https://review.coreboot.org… * Created a sheet to collect the versions * [https://review.coreboot.org/c/flashrom/+/66436](https://review.coreboot.org… * If defs is not great * If someone is using such an old libusb version, then ch341a programmer should not be built in at all * We want to hold the patch for a moment * TODO : create ticket to move the discussion there, add a comment to the patch 66436 , link the ticket >> [https://ticket.coreboot.org/issues/409](https://ticket.coreboot.org/issues/… * Programmer param discussion * Board enable for i2c * [Joursoir] Flashrom CLI should have bash-completion (auto-complete text with TAB key while typing a command). Task for new contributors/next GSoC. * Useful for new users * Can be smaller project or larger project, can be broken into several phases * Felix: Not supported by standard bash, needs one extra packet. But most systems have it anyway. * Joursoir: Might need a bit of planning, think how to structure bash * We need to agree on what’s the end goals * Flashchips: too many of them, let’s not include it * Edward: Start as simple as possible, and then see how it goes. * Everyone: A very good idea * Joursoir (Alex) is a contact person for the project

1 0

Unify flashrom range types
by Evan Benn 25 Aug '22

25 Aug '22

# Introduction The goal is to unify the integer type used for ranges. libflashrom has 2 ranges in the API: write protect (wp) ranges and layout ranges. The types for these are not consistent between wp and layout, between getters and setters, and between the API and the implementation. Additionally the types are different sized depending on the platform (ie size_t on 32 vs 64 bit). Demo: https://review.coreboot.org/c/flashrom/+/67004 # Background / Motivation Assertion: Flashrom only cares about fairly normal platforms (32 and 64 bit pointers). size_t: size_t is the C type returned by sizeof. It is an unsigned integer. Throughout the C library it is used as the type for counting the length of and indexing into arrays. It is at least 16 bits. It is often the same size as uintptr_t and void* but this is not required. uintptr_t: A C type large enough to hold a pointer. unsigned int: At least 16 bits, probably 32 bits on all the platforms we care about. uint32_t: Exactly 32 bit type, not required to exist (ie, flashrom won't compile on platforms where this doesn’t exist). usize: A rust type corresponding to uintptr_t. uintptr: A go type corresponding to uintptr_t. Go also has C.size_t. # Flashrom Today getsize -> size_t read/write/verify -> size_t implementation: unsigned int https://source.chromium.org/chromiumos/chromiumos/codesearch/+/cc9524d9ebf5… Based on the implementation using `unsigned int`, Flashrom probably only works with up to 32 bit sized flashes. layout_add_region -> size_t, (start, end) layout_get_region -> unsigned int (start, len) impl: uint32_t (start, end) https://source.chromium.org/chromiumos/chromiumos/codesearch/+/cc9524d9ebf5… These types are probably fine on 32 bit platforms where they are all the same. On 64 bit you could add a region that will be truncated / wrapped without warning. The get and add using different ranges; (start, end) and (start, len) is very confusing - I have already gotten this wrong several times while refactoring. wp_set_range -> size_t (start, len) wp_get_range -> size_t (start, len) impl: size_t (start, len) All consistent here. wp_ranges_count -> size_t wp_ranges_get_range -> unsigned int impl: size_t Changing the get_range to take a size_t seems like a simple fix here. This is unlikely to ever cause a bug but is a strange style. # Rust Bindgen can be told to treat size_t as usize. Without this flag a rust type for size_t is chosen for the platform (ie u32 on 32 bit, u64 on 64 bit). Only usize can be used to index slices in rust. # Proposal ## Goal Unify all the length types (internal and external) Unify all the range bounds ((start, len) vs (start, end)) Make bindings straightforward ## Non goal 16 bit platforms >32 bit sized flashes Change the libflashrom API and the flashrom internals to use uint32_t for all flash sizes and ranges. Keep size_t for host related sizes, eg the buffer size in flashrom_layout_read_fmap_from_buffer or flashrom_image_verify. Add a layout_add (start, len) method and try to deprecate the (start, end) method. This will make all of the methods use the same concept of range. The wp implementation uses (start, len) while the layout implementation uses (start, end). I do not propose to change this. In the rust fat bindings, use usize to represent all ranges and offsets. After libflashrom changes from the current implementation to uint32_t, the rust bindings must convert between u32 and usize. We will only support 32 and 64 bit usize, so this will be straightforward. The rust bindings will reject attempts to provide values > 32bit at runtime. # Alternatives Use uint64_t. This has the pro of supporting large SPI flash on 64 bit platforms. However this wont make large flash supported on 32 bit platforms, as single buffers are passed around for data access; flashrom_image_write (struct flashrom_flashctx *flashctx, void *buffer, size_t buffer_len, const void *refbuffer) Use size_t everywhere. Size_t makes some sense to use, as the implementation and API deals with full flash sized buffers, and they can only be indexed by size_t sized ranges anyway. For example flashrom would support 16 bit of flash on a 16 bit platform, and 64 bit of flash on a 64 bit platform. However, tying the usable flash size to the platform size doesn't really make sense and is likely to cause confusion, and we probably only care about 32 bit flash. Use a typedef, eg chipsize_t. I think this is reasonable internally but don't prefer it. It would theoretically allow a simple change to swap from 32 to 64 bit flashes. However C won't warn about code using the wrong type while they are 'compatible', see for example the functions using unsigned int and uint32_t interchangeably in the codebase already. And this won't really work for libflashrom, it's too messy to make the API function differently depending on library compile time choices, this really creates incompatible APIs with identical names. For supporting larger-than-size_t size data objects, see posix lseek64 and friends. Use u32 for the rust API. This makes sense as it pushes out-of-range errors into the user code. However it complicates a lot of usage as u32 constantly need to be converted into usize to do array indexing. https://review.coreboot.org/c/flashrom/+/67004

1 0

Issue tracker version update / disabling of login methods
by Felix Singer 19 Aug '22

19 Aug '22

Hi all, the Redmine developers released version 5.0 some months ago and updating to this version will have some effects on us. So, I would like to open a thread to discuss these issues with you and how we deal with that situation. Currently, we are on the 4.2 branch and it still gets security and bug fixes, but I can't tell at which point they will stop supporting it. We enabled the login over OpenID, which is implemented natively and not integrated over a plugin. With version 5.0, support for that was removed. I assume this is due to that the implementation is based on an older OpenID standard and there are not many users of it anymore (TM). The newer standard seems to be called "OpenID Connect", but it's not supported by Redmine. Also, we are using a plugin which allows the login over a Google account. The compatibility of that plugin breaks with version 5.0. The problem is that we have users for both and with version 5.0 they won't be able to use these methods anymore. However, I have an idea for a solution. I took a look at the Redmine database and I played around with the Google login method. My tests showed that it creates a normal user account, as it is done with the registration, just with the little difference that no password is set disabling the login over password. These accounts also have an user name and an email address. As soon as I set a password, I was able to login using the user name. So, my idea is that we just go with these changes and affected users use the functionality to reset their password, which means they will have a "normal" user account then. In preparation to that version update, we should disable these login methods so that no new users will make use of them. Other ideas? What's your opinion? // Felix

3 4

Read from W25Q256JV_Q returns only zeroes
by Olof Gross 18 Aug '22

18 Aug '22

Hi, im trying to apply me_cleaner to a HP ProBook 450 G8. It has a W25Q256JVEQ WSON8 chip soldered so i bought a WSON connector thingy and try to read from it with a pi: olle@raspberrypi:~ $ sudo flashrom/flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=10000 -c W25Q256JV_Q -V -r hp-bios-original.bin flashrom v1.2-887-g6c1b0ac on Linux 5.15.56-v7+ (armv7l) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). flashrom was built with GCC 10.2.1 20210110, little endian Command line (7 args): flashrom/flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=10000 -c W25Q256JV_Q -V -r hp-bios-original.bin Initializing linux_spi programmer Using device /dev/spidev0.0 Using 10000kHz clock get_max_kernel_buf_size: Using value from /sys/module/spidev/parameters/bufsiz as max buffer size. linux_spi_init: max_kernel_buf_size: 4096 The following protocols are supported: SPI. Probing for Winbond W25Q256JV_Q, 32768 kB: compare_id: id1 0xef, id2 0x4019 Added layout entry 00000000 - 01ffffff named complete flash Found Winbond flash chip "W25Q256JV_Q" (32768 kB, SPI) on linux_spi. Chip status register is 0x00. This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. Thanks for your help! Reading flash... done. Looks great? It correctly identifies the chip and i get a file of the right size. Its just that it contains only zeroes. Thirty-two million of them. Not great. I used freshly compiled flashrom from git, hardware was a raspi 2b rev1.1 running raspbian bullseye freshly updated. What would you suggest as a next step? Try different speed settings, desolder the chip, what more? And yeah, the batteries (main, clock) were disconnected. Regards, Olof

1 0

"MT25QU256" Verifying flash... FAILED
by svv 18 Aug '22

18 Aug '22

sudo flashrom -p ft2232_spi:type=arm-usb-ocd-h,port=A,divisor=8 -c MT25QU256 -w image.img flashrom v1.2 on Linux 5.4.0-58-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found Micron flash chip "MT25QU256" (32768 kB, SPI) on ft2232_spi. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. Thanks for your help! Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x00001000! Expected=0x00, Found=0xff, failed byte count from 0x00000000-0x01ffffff: 0x250e23 Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks!

1 0

flashrom v1.2 on Linux 5.10.63-v7+ (armv7l)
by Imed Hanchour 16 Aug '22

16 Aug '22

HEllo, I have a problem I am trying to flash a W25Q64JVSIM flash memory I get this answer when I type the following command $ sudo flashrom --programmer linux_spi:dev=/dev/spidev0.0 -E flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Using default 2000kHz clock. Use 'spispeed' parameter to override. Found Winbond flash chip "unknown Winbond (ex Nexcom) SPI chip" (0 kB, SPI) on linux_spi. === This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. Thanks for your help! No operations were specified.

1 0

not able to successfully update my firmware
by Wagner Rodrigo 14 Aug '22

14 Aug '22

flashrom v1.2 on Linux 5.15.58-2-lts (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.8.0, GCC 12.1.0, little endian Command line (3 args): flashrom --programmer internal -V Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer get_mtd_info: device_name: "intel-spi", is_writeable: 0, numeraseregions: 0, total_size: 8388608, erasesize: 4096 No coreboot table found. Using Internal DMI decoder. No DMI table found. Found chipset "Intel Lynx Point LP Premium" with PCI ID 8086:9c43. 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(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0x61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x0 (SPI) Top Swap: not enabled 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x2a: BIOS Lock Enable: enabled, BIOS Write Enable: disabled SPIBAR = 0x00007fc4b4d56000 + 0x3800 0x04: 0xe008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 SPI Configuration is locked down. Reading OPCODES... done 0x06: 0x0000 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 0x50: 0x00004a4b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x4a, BRRA 0x4b 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x07ff0400 FREG1: BIOS region (0x00400000-0x007fffff) is read-write. 0x5C: 0x03ff0001 FREG2: Management Engine region (0x00001000-0x003fffff) is locked. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. 0x90: 0xc4 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xfc4540 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=5, SME=0, SCF=4 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05203b02 (OPMENU) 0x9c: 0x0000019f (OPMENU+4) 0xa0: 0x00000000 (BBAR) 0xc4: 0x80802025 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xc8: 0x00002025 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xd0: 0x50444653 (FPB) Enabling hardware sequencing because some important opcode is locked. OK. The following protocols are supported: Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 1 attached SPI flash chip with a density of 8192 kB. The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0x7fffff. In that range are 429 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific). No operations were specified. Restoring MMIO space at 0x7fc4b4d598a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

Fwd: Setting page size in AT45db081d spi flash
by Shreeyash Pandey 11 Aug '22

11 Aug '22

---------- Forwarded message --------- From: <rh100605(a)aol.com> Date: Thu, 11 Aug 2022, 2:56 pm Subject: Re: [flashrom] Setting page size in AT45db081d spi flash To: shreeyash335(a)gmail.com <shreeyash335(a)gmail.com> Shreeyash, Just for your information, the chinese flash programmers have specific device types for each page size such as AT45DB081E-264 or AT45DB081E-256 and presumably what ever the setting for page size it overwrites if necessary. Beware the AT45DB081D version is one time programmable for page size so that, I believe, the existing code is acting correctly as only the change from 264( default shipped state) to 256 bytes is allowed and only once. The E version allows the change up to 10,000 times! See chapter 13 of the D specification. I think we need a specific new flashrom device type for the AT45DB081E-264/256 family unless you have a better idea Regards Rob -----Original Message----- From: Shreeyash Pandey <shreeyash335(a)gmail.com> To: rh100605(a)aol.com Sent: Tue, 9 Aug 2022 10:40 Subject: Re: [flashrom] Setting page size in AT45db081d spi flash >What I was looking for was maybe a flag that defined the page size required >and altered it if necessary. This would be great. I suspect other AT45* chips may have this feature as well, they'd benefit from a universal scheme. Are you able to read the status register without any mods?. The man page makes it clear that ch341 doesn't support any parameters. Something like `flashrom -p ch341:read_status` is what we need. Moreover, What output does --wp-status produce? >I am not a contributor to Flashrom but any mod I make I would like to share >with others. I believe it would be better if a maintainer came up with a >scheme that fitted all spi flash that you support with different page sizes. Totally. I'd be up to volunteer help if needed. Regards Shreeyash On Mon, Aug 8, 2022 at 3:53 PM <rh100605(a)aol.com> wrote: Shreeyash, Thank you for such a prompt reply. I can see what you have done in the code you supplied. The rest of the code is very aware of page size on read/write/erase, so needs to read the status register to work correctly The programmer I am using is the CH341A modified to work at 3.3v As I see it I would have to have 3 builds of Flashrom 1. Set 256 page size 2. Set 264 page size 3. as before modification to perform write and reads What I was looking for was either a CLI flag that allowed me to issue a one time command. Dangerous I know ! Or maybe a flag that defined the page size required and altered it if necessary. I am not a contributor to Flashrom but any mod I make I would like to share with others. I believe it would be better if a maintainer came up with a scheme that fitted all spi flash that you support with different page sizes. Regards Rob -----Original Message----- From: tunabomber <shreeyash335(a)gmail.com> To: rh100605(a)aol.com Sent: Mon, 8 Aug 2022 15:31 Subject: Re: [flashrom] Setting page size in AT45db081d spi flash Hey Rob, I don't see that flashrom has an option to re-configure the chip's page size, nor did I find a way to send a command directly to the chip. However, I am thinking of a hack you could use here. File at45db.c implements the operations of your chip. We could modify one of the functions here that we shall use to send our four bytes of data. The very first function `at45db_read_status_register` is simple enough and should get the job done. Replacing 'AT45DB_STATUS' with '0x3d, 0x2a, 0x80, 0xa7' will send these bytes to the chip when we ask flashrom to read the status register for us. I've attached the modified file with this email. Diff it, if you may to see the difference. Re-compile flashrom by following build instructions in the README. Now read the status registers, this should send our string to the chip, re-configuring it. Reading status registers, I believe depends on the programmer? (Which one are you using?). There's very little on this in the man page except for the section on SPI Status Register for the dummy programmer. See if that is of any help. Alternatively, you could modify some other function in a similar manner. If you are not so sure about this, maybe wait for the more experienced folks around here to see your message. I am only getting started with hardware hacking. Regards Shreeyash On Sun, Aug 7, 2022 at 6:14 PM Rob via flashrom <flashrom(a)flashrom.org> wrote: I have used Flashrom to backup a memory image in a radio using the AT45DB081E spi flash memory. The read operation worked well using the Flashrom device set as AT45DB081D I bought some more used AT45DB081E chips to write the saved image and Flashrom objected by stating that the image was too big by 32767 bytes I edited image by removing the last 32767 bytes and Flashrom wrote the used chips and verified successfully using the device setting AT45DB081D While reading the datasheet I noticed that the AT45DB081D/E has two page sizes 256 and 264 bytes which explains the 32767 bytes difference in image sizes It seems FlashROM is aware of the page size setting! However I cannot see how read the status register to see the page size set or how to change it using the 0x3D 0x2A 0x80 0xA6 / A7 command as described in Chapter 11 of the AT45DB081E datasheet To summarise I want to change the page size of an AT45DB081E back to 264 to repair the radio and cannot see how to use Flashrom to do it Regards Rob _______________________________________________ flashrom mailing list -- flashrom(a)flashrom.org To unsubscribe send an email to flashrom-leave(a)flashrom.org

1 0

flashrom dev meeting notes 11.08.22
by Felix Singer 11 Aug '22

11 Aug '22

# 11th Aug 2022, 6:00 - 7:00 UTC+0 Attendees: Anastasia, Edward, Felix, Thomas, Nikolai, Evan ## Decisions Summary * Unassigned release-blocking bugs were assigned * We will have a brainstorming session to improve Development guidelines after the release (and probably to improve README too). * Development guidelines and Contact pages need to be added to side menu on wiki, so that these links are visible from any other page (TODO aklm) ## Agenda * Long discussion about the Meson build system and how other OSes than Linux can be integrated * Unit tests need to be fixed for non-Linux * [aklm] Bugs for release, which ones should go to our team (ChromeOS)? I want to check that we are not missing anything. [https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/… * All assigned! * How do we make sure people are reading our development guidelines? * Edward: [https://www.flashrom.org/Development_Guidelines#Adding/reviewing_a_new_flas… any thoughts about adding this to the top of the flashchip file? * Thomas: add to README ? * Thomas: README also needs improvement * Aklm: we need to re-write them * Some sections are out-of-order * Some info is outdated * Ask new people (who joined recently) what was confusing in the guidelines * A brainstorming session of new guidelines? * Thomas: Split into topics: history, how to send a patch, code style, code review guidelines etc * Thomas: let’s have a brainstorming session after the release * Aklm: can we add two pages to the side menu: development guidelines and Contact? [https://www.mediawiki.org/wiki/Manual:Interface/Sidebar](https://www.mediaw… TODO aklm

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom