Easy projects: Difference between revisions

From flashrom
Jump to navigation Jump to search
m (→‎AMD 740G information gathering: We also want -V for superiotool in case an unknown chip is used.)
(Done: Add support for multiple slaves to the ft2232_spi programmer)
(30 intermediate revisions by 6 users not shown)
Line 1: Line 1:
You probably came here trying to find a small (minutes to hours) and easy task where you can get your hands dirty and get results immediately.
You probably came here trying to find a small (minutes to hours) and easy task where you can get your hands dirty and get results immediately.


If you're a coreboot or flashrom newbie, this page is for you.
If you're a flashrom newbie, this page is for you.


= flashrom =
= Open tasks =


The [[flashrom]] tool can read/write coreboot/BIOS images from/to flash chips.
== Fix issues found by scan-build ==
Run scan-build in the tree:


== Add timing info to flash chip definitions ==
<tt>make clean && CFLAGS='-fsanitize=leak' scan-build make</tt>


Go through the list of flash chips in flashchips.c inside the flashrom source. For each chip (except SPI chips), read through the data sheets and add a comment to the flash chip definition which contains the timing information in microseconds(!) for the probe sequence.
At the moment of writing this, it produces around 30 issues, which means there are plenty of easy projects.


This will make probing a lot more reliable.
In general, one issue == one Easy project. However, you can fix more than one issue in the same patch if there are multiple occurrences of the same issue in the same file.


Every annotated chip helps.
You need to install clang-tools for this project.


== Add the bus type to flash chip definitions ==
== Find chips without voltage data ==
We have added allowed supply voltage ranges (usually denoted VCC in datasheets) to the chip definitions in flashchips.c, but not all of them.
Complete the list by looking for the right datasheet and editing flashchips.c accordingly.


Go through the list of flash chips in flashchips.c inside the flashrom source. Look for chip definitions which have .bustype = CHIP_BUSTYPE_NONSPI and look at their data sheets. Read the data sheets and try to figure out the flash bus they use (Parallel/LPC/FWH/SPI). Change the bustype field to CHIP_BUSTYPE_PARALLEL etc. and post a patch to the list.
== Find boards that have a board enable but are not mentioned in print.c ==
There may be a few boards that had a [[Board Enable]] added (in board_enable.c) but which were not added to the array named boards_known in print.c (usually by mistake).


This will make probing faster and more reliable.
Find those and send a list or even a patch for print.c to the mailing list.


Even a single updated chip helps.
Even better would be an automatic detection of such mistakes.
We already do some sanity checks on startup (cf. <tt>selfcheck()</tt> in <tt>flashrom.c</tt>).


[[Flashrom#Communication_bus_protocol]] has a writeup on how to figure out the bus type.
== Add timing info to flash chip definitions (mostly done) ==


== Add new flash chip definitions ==
Go through the list of flash chips in flashchips.c inside the flashrom source. For each chip (except SPI chips), read through the data sheets and add a comment to the flash chip definition which contains the timing information in microseconds(!) for the probe sequence.


We have a few dozen chip IDs listed in flash.h, but not in flashchips.c. Find them, dig up the data sheets and add chip definitions for them to flashchips.c. You can use similar flash chips as a guideline.
This will make probing a lot more reliable.


This will reduce the number of undetected chips.
Every annotated chip helps.


Every added chip broadens flashrom support.
== Add new flash chip definitions ==


== Test flashrom ==
We have a few dozen chip IDs listed in flash.h, but not in flashchips.c. You can find them by running '''util/list_yet_unsupported_chips.sh'''. Then dig up the data sheets and add chip definitions for them to flashchips.c. You can use similar flash chips as a guideline. Check our list of pending patches (http://patchwork.coreboot.org/project/flashrom/list/) to not duplicate someone's work. Reviewing any pending patches by verifying the values in the patches is of course also very welcomed too! The process of adding a chip and the needed data structures are explained [[Development_Guidelines#Adding.2Freviewing_a_new_flash_chip|here]].


If you have a desktop (no laptops/notebooks/netbooks), please run
This will reduce the number of undetected chips and every added chip broadens flashrom support.
flashrom
and check if it finds your flash chip. If it does and any of the operations are listed as unsupported, we'd like to hear about it. If your flash chip is not found, we'd like to hear about it as well.


In both cases, please send the output of
== Add (ferroelectric, F-RAM) SPI chips made by Cypress / Ramtron ==
flashrom -V
to the coreboot [[Mailinglist|mailing list]] (preferred) or to [mailto:flashrom@coreboot.org flashrom@coreboot.org]


= coreboot =
http://www.cypress.com/products/f-ram-serial


I'll skip explaining what coreboot is. The whole wiki is about this topic and I can't summarize it in one sentence.
Example datasheet: http://www.cypress.com/file/41676/download


== coreboot v2 ==
These work mostly like SPI flashes, except for (these are just the biggest points):
* No erase command (or erasing necessary)
* 2-byte addresses (atleast for smaller/older devices)


The workhorse version of coreboot. Lots of supported boards, but difficult to work with.
== Test flashrom ==
 
===AMD 740G information gathering===
(This project description is not finished yet)


If you have a board with AMD 740G chipset, please run (as root)
Please see the [[Board Testing HOWTO]].
flashrom -V
lspci -nnvvvxxxx
superiotool -edV
dmidecode
and mail the output to FIXME together with the exact model number/name of your board.


This helps us evaluate which boards are good targets for coreboot.
== Replace programmer_delay() with internal_sleep() where appropriate ==


== coreboot v3 ==
If a delay call does not depend on precise timing and if the '''programmer''' in question '''does not offer its own delay function''', programmer_delay() can be replaced with internal_sleep().
If a delay call does not depend on precise timing and if the delay '''should run on the host''', programmer_delay() can be replaced with internal_sleep().


The next generation version of coreboot. Few supported boards, still in the design testing phase, easy to work with.
= Done =


TODO: Add easy tasks here.
== Add automatic uploading of log files ==
We have a pastebin at http://paste.flashrom.org. Create a patch that (if enabled) automatically uploads the output of a flashrom run to it using [http://curl.haxx.se/libcurl/ libcurl] or a similar library (free license, cross-platform).


= Payloads =
''PoC sent by Michael Coppola, but so far rejected by Carl-Daniel.''


coreboot can use a number of different [[Payloads|payloads]].
== Tag SPI chips in flashchips.c with the status register write command according to their datasheets ==


== Add/test new supported payloads ==
Usually the status register of SPI chips is write protected and has to be made accessible by one of two possible commands (or by either one). We indicate this by setting 2 bits in the feature flags of the chip definition in flashchips.c.
The default is EWSR (see spi_write_status_register in spi25.c) and so no chips needing this have been tagged correctly (yet!).
The task is to look at all chip definitions with '''bustype = BUS_SPI''' and check the '''feature_bits''' field if it contains the correct '''FEATURE_WRSR_*''' flag and add/change it after looking it up in the datasheet. In case either works use FEATURE_WRSR_EITHER.
Please send a list of chips to change together with the correct flag or (preferably) a patch to the mailing list.


* Test syslinux (probably requires [[SeaBIOS]] in addition, needs to be checked).
''Patch created by Steven Zakulec, committed in r1527.''
* Port [[GPXE]] to "native" coreboot (it works fine together with [[SeaBIOS]] though).


= Other =
== Add support for multiple slaves to the ft2232_spi programmer ==


* Add support for using coreboot in VirtualBox.
The FT232H for example has 4 generic GPIO pins that could be used as additional CS pins. Think about useful command line arguments (what about other programmers that support similar functionality, e.g. by supporting multiple CS pins natively?) before you start.
An example how this could look like [http://patchwork.coreboot.org/patch/3660/ exists] already.

Revision as of 04:22, 9 March 2022

You probably came here trying to find a small (minutes to hours) and easy task where you can get your hands dirty and get results immediately.

If you're a flashrom newbie, this page is for you.

Open tasks

Fix issues found by scan-build

Run scan-build in the tree:

make clean && CFLAGS='-fsanitize=leak' scan-build make

At the moment of writing this, it produces around 30 issues, which means there are plenty of easy projects.

In general, one issue == one Easy project. However, you can fix more than one issue in the same patch if there are multiple occurrences of the same issue in the same file.

You need to install clang-tools for this project.

Find chips without voltage data

We have added allowed supply voltage ranges (usually denoted VCC in datasheets) to the chip definitions in flashchips.c, but not all of them. Complete the list by looking for the right datasheet and editing flashchips.c accordingly.

Find boards that have a board enable but are not mentioned in print.c

There may be a few boards that had a Board Enable added (in board_enable.c) but which were not added to the array named boards_known in print.c (usually by mistake).

Find those and send a list or even a patch for print.c to the mailing list.

Even better would be an automatic detection of such mistakes. We already do some sanity checks on startup (cf. selfcheck() in flashrom.c).

Add timing info to flash chip definitions (mostly done)

Go through the list of flash chips in flashchips.c inside the flashrom source. For each chip (except SPI chips), read through the data sheets and add a comment to the flash chip definition which contains the timing information in microseconds(!) for the probe sequence.

This will make probing a lot more reliable.

Every annotated chip helps.

Add new flash chip definitions

We have a few dozen chip IDs listed in flash.h, but not in flashchips.c. You can find them by running util/list_yet_unsupported_chips.sh. Then dig up the data sheets and add chip definitions for them to flashchips.c. You can use similar flash chips as a guideline. Check our list of pending patches (http://patchwork.coreboot.org/project/flashrom/list/) to not duplicate someone's work. Reviewing any pending patches by verifying the values in the patches is of course also very welcomed too! The process of adding a chip and the needed data structures are explained here.

This will reduce the number of undetected chips and every added chip broadens flashrom support.

Add (ferroelectric, F-RAM) SPI chips made by Cypress / Ramtron

http://www.cypress.com/products/f-ram-serial

Example datasheet: http://www.cypress.com/file/41676/download

These work mostly like SPI flashes, except for (these are just the biggest points):

  • No erase command (or erasing necessary)
  • 2-byte addresses (atleast for smaller/older devices)

Test flashrom

Please see the Board Testing HOWTO.

Replace programmer_delay() with internal_sleep() where appropriate

If a delay call does not depend on precise timing and if the programmer in question does not offer its own delay function, programmer_delay() can be replaced with internal_sleep(). If a delay call does not depend on precise timing and if the delay should run on the host, programmer_delay() can be replaced with internal_sleep().

Done

Add automatic uploading of log files

We have a pastebin at http://paste.flashrom.org. Create a patch that (if enabled) automatically uploads the output of a flashrom run to it using libcurl or a similar library (free license, cross-platform).

PoC sent by Michael Coppola, but so far rejected by Carl-Daniel.

Tag SPI chips in flashchips.c with the status register write command according to their datasheets

Usually the status register of SPI chips is write protected and has to be made accessible by one of two possible commands (or by either one). We indicate this by setting 2 bits in the feature flags of the chip definition in flashchips.c. The default is EWSR (see spi_write_status_register in spi25.c) and so no chips needing this have been tagged correctly (yet!). The task is to look at all chip definitions with bustype = BUS_SPI and check the feature_bits field if it contains the correct FEATURE_WRSR_* flag and add/change it after looking it up in the datasheet. In case either works use FEATURE_WRSR_EITHER. Please send a list of chips to change together with the correct flag or (preferably) a patch to the mailing list.

Patch created by Steven Zakulec, committed in r1527.

Add support for multiple slaves to the ft2232_spi programmer

The FT232H for example has 4 generic GPIO pins that could be used as additional CS pins. Think about useful command line arguments (what about other programmers that support similar functionality, e.g. by supporting multiple CS pins natively?) before you start. An example how this could look like exists already.