Issue Tracker: Issueshttps://ticket.coreboot.org/https://ticket.coreboot.org/themes/PurpleMine2-2.16.0/favicon/favicon.ico?12024-02-05T03:40:27ZIssue Tracker
Redmine flashrom - Bug #525 (New): Potential clash when custom get_flash_region() called in erase_writehttps://ticket.coreboot.org/issues/5252024-02-05T03:40:27ZAnastasia Klimchuk
<p><code>erase_write</code> in erasure_layout.c makes a call to <code>get_flash_region()</code>. This call happens after erase layout is calculated, however <code>get_flash_region()</code> can potentially return smaller region.</p>
<p>Issue needs research (and fix if needed).</p>
<p>Originally reported by Vincent Fazio, copying the report below:</p>
<pre><code>As part of looking over #1 and #2, I developed some slight concerns about the loop on line 314 which is separate from
this patchset. I don't know if it warrants an issue and further discussion, and I haven't spelunked into the erase function
selection logic, but the concern I have there is we've already pre-calculated what erase functions we're using but
`get_flash_region` could return a region with a shorter end range, meaning the selected erase block fn could erase part
of the next region. So if we had a 32k erase block fn, it seems like if region.end forces the length of the erasable region
to 4k, we don't actually select a 4k erase function and instead continue to use a 32k function. If the next region is write
protected it seems like we'd have verification errors.
I think this currently only affects masters that have get_region defined, so `opaque_master_ich_hwseq` is at risk here.
This may have been less of a risk with the legacy path because, from what I remember, it always used the smallest working
erase block function, however the new path adjusts the function used based on the amount of changed data and coalesces blocks
when possible (I think).
</code></pre> flashrom - Bug #520 (New): Factor out verification from erase pathhttps://ticket.coreboot.org/issues/5202023-12-19T15:59:01ZVincent Fazio
<p>Currently, <code>flashrom_image_erase</code> differs from <code>flashrom_image_write</code> in how it performs its verification.</p>
<p>When writes are completed, verification occurs <u>afterwards</u> per the verify flags specified in the <code>flashctx</code> argument.</p>
<pre><code class="C syntaxhl" data-language="C"> <span class="cm">/* Verify only if we actually changed something. */</span>
<span class="k">if</span> <span class="p">(</span><span class="n">verify</span> <span class="o">&&</span> <span class="o">!</span><span class="n">all_skipped</span><span class="p">)</span> <span class="p">{</span>
<span class="n">msg_cinfo</span><span class="p">(</span><span class="s">"Verifying flash... "</span><span class="p">);</span>
<span class="cm">/* Work around chips which need some time to calm down. */</span>
<span class="n">programmer_delay</span><span class="p">(</span><span class="n">flashctx</span><span class="p">,</span> <span class="mi">1000</span><span class="o">*</span><span class="mi">1000</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">verify_all</span><span class="p">)</span>
<span class="n">combine_image_by_layout</span><span class="p">(</span><span class="n">flashctx</span><span class="p">,</span> <span class="n">newcontents</span><span class="p">,</span> <span class="n">oldcontents</span><span class="p">);</span>
<span class="n">ret</span> <span class="o">=</span> <span class="n">verify_by_layout</span><span class="p">(</span><span class="n">flashctx</span><span class="p">,</span> <span class="n">verify_layout</span><span class="p">,</span> <span class="n">curcontents</span><span class="p">,</span> <span class="n">newcontents</span><span class="p">);</span>
</code></pre>
<p>For the erase path, there is no post-operation verification. Instead, <code>check_erased_range</code> is called regardless of verify flags, performing verification even if the user doesn't request it and imposing a performance penalty.</p>
flashrom - Documentation #503 (In Progress): Feedback on "new" documentation website <www.flashr...https://ticket.coreboot.org/issues/5032023-08-07T14:45:04ZReal Onebajcsielias78@gmail.com
<p>This github issue is my personal feedback on flashrom's "new" documentation website.</p>
<p>TL;DR: The new website is horrible & lacks a lot of information and the "old" wiki is way more better.<br>
No download instructions</p>
<p>The new website doesn't have any download instructions, just building instructions. As a beginner, you can't tell where you should download the code. It just tells you how to build from the source where you are supposed to figure out how and where to download from.</p>
<p>On the other hand, the "old" wiki has a dedicated downloads page that is directly visible from the start page which tells you pretty much everything:</p>
<ul>
<li>Required dependencies;</li>
<li>How to get the source code with git;</li>
<li>Binary packages for various popular GNU/Linux distributions, BSD distributions and MS Windows;
Dedicated windows wiki page.</li>
</ul>
<p>It has a TON of missing resources that return 404</p>
<p>Trying to find a way to write a feedback to this project regarding this, I've noticed many webpages were missing, with the server returning me 404.<br>
Even harder to find what you need</p>
<p>There is no search feature, pages you'd expect to find your answer don't really work, etc.</p>
<p>For instance, I was trying to find the list of supported programmers. In return, the website hit me with this mess:</p>
<p>image</p>
<p>Like seriously, what is this mess?! Inserting man pages is not really helpful.</p>
<p>The old wiki on the other hand, has a dedicated page listing with images the supported programmers, which makes the difference.<br>
Ugly</p>
<p>I like the idea of minimalism, which is what a lot of websites should adopt, however this is way too simple and confusing.</p>
<p>The old wiki had more features like tables with images and colors indicating certain stuff, and I also really like the "Emergency help" red box (see below), which just gives the end user the idea that what they are doing could be potentially fatal and other important instructions.</p>
<p>image</p>
<p>The new website does not have these important features, which makes it hard to follow. It has this gray-on-white with few color indications (terminal output), which is very boring and makes me sleepy. Documentation shouldn't be boring, but be rather important.<br>
"Anon, you can't just leave your feedback here, this is the official flashrom github repository, not a place where you can leave your feedback"</p>
<p>I think that's true, but in the same time it was hard for me to really pick something from the Contact page.</p>
<p>First, there is no feedback section where I can really send this.</p>
<p>Second of all, I wanted to voice my oppinion to more people.</p>
<p>I could have easily just sent this to <a href="mailto:flashrom@flashrom.org">flashrom@flashrom.org</a>, but here are my answer scenarios:</p>
<pre><code>"We are sorry, but this is not the support channel, so if you want to send your feedback, send it to something@flashrom.org";
"Thank you for sending us your feedback. Your feedback is very important for us, and we'll keep that in mind" and then *the only person who read my feedback would forget about it, the feedback would be forever forgotten;
No answer and nothing would be achieved.
</code></pre>
<p>An apology message for being too harsh on the situation and thanking in advance</p>
<p>I don't really mean to be too harsh about the situation, but I've had really good anticipations about flashrom, praising it for a few months. Seeing how big of a downgrade got the documentation page made me really frustrated, which made me voice my criticism on the documentation website.</p>
<p>The program itself is quite good, can't complain about it. However, there were occasions where I had to troubleshoot the situation, and I would visit wiki.flashrom.org out of instinct. Today I visited it's domain - flashrom.org - just to see if something else is on this domain. I was very surpised to see how bad the documentation on that website was, and just assumed it was the old documentation, but the "Old wiki website" revealed that it is the otherwise.</p>
<p>In conclusion, I want to apologize on being too critic, I hope some people will really read this, I hope the developers will work on the documentation website, I want to apologize for any grammar & typo errors and I want to thank you in advance.</p>
<p>TheRealOne78</p>
flashrom - Bug #502 (New): Erase and Write problem with a SST25VF512.https://ticket.coreboot.org/issues/5022023-08-03T10:38:22ZGianni Lerro
<p>Hi<br>
I want to flash new firmware to a SST25VF512 but neither erase nor write works, reading current firmware works.</p>
<p>The programmer I used is this one CH341A Mini Programmer (<a href="https://www.onetransistor.eu/2017/08/ch341a-mini-programmer-schematic.html">https://www.onetransistor.eu/2017/08/ch341a-mini-programmer-schematic.html</a>), mine has a CH341B (<a href="https://www.wch-ic.com/products/CH341.html?">https://www.wch-ic.com/products/CH341.html?</a>) that can work without the external clock using the internal one.</p>
<p>With this, MIT Licensed, windows program AS Programmer (<a href="https://github.com/nofeletru/UsbAsp-flash">https://github.com/nofeletru/UsbAsp-flash</a>) everything works, reading, writing, deleting, enabling and disabling write protection.</p>
<p>My OS is Debian GNU/Linux Testing</p>
<p>Thanks</p>
flashrom - Bug #498 (New): DediProg SF600Plus unable to flash W25Q512JV chiphttps://ticket.coreboot.org/issues/4982023-06-29T12:32:53ZVojtech Vesely
<p>I am working on adding support for chip Winbond W25Q512JV-FIM, which should be quite similar to existing W25Q512JV. Writing to the chip is a problem, reading is fine.</p>
<pre><code>$ ./flashrom -p dediprog -w random.bin
flashrom 1.4.0-devel (git:v1.2-1310-g1ee04cd5) on Linux 6.3.9-arch1-1 (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).
Using dediprog id SF000000.
Found Generic flash chip "unknown SPI chip (REMS)" (0 kB, SPI) on dediprog.
===
This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE
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!
Error: Image size (67108864 B) doesn't match the expected size (0 B)!
</code></pre>
<p>This problem does not appear in <code>v1.3</code>, only in <code>master</code> branch.</p>
<p>Used hardware:</p>
<ul>
<li>Programmer: DediProg SF600Plus, Firmware version : 7.3.08, Hardware version : 2.3</li>
<li>Chip: W25Q512JV-FIM</li>
</ul>
flashrom - Feature #411 (In Progress): Fix unit tests to run on all supported environments (non-L...https://ticket.coreboot.org/issues/4112022-09-01T00:40:25ZAnastasia Klimchuk
<p>The list of issues to fix below (can be updated if new issues found).</p>
<p>1) DONE Mocks for <code>_fprintf_chk</code> are missing (needed for clang on Linux)<br>
2) DONE I/O mock functions need to be renamed so that they do not have name clash with standard I/O, because the latter are allowed to be macros<br>
Current idea is to add <code>iom_</code> prefix for all functions members of <code>struct io_mock</code><br>
3) DONE Refactor the code so that <code>linux/spidev.h</code> header is only included when building for Linux<br>
4) DONE Fix failing tests on FreeBSD (4 tests in chip.c: 2 write chip and 2 verify chip)<br>
5) DONE BSD family<br>
6) MacOS needs verifying</p>
flashrom - Refactoring #391 (In Progress): Refactor singleton states into reentrant patternhttps://ticket.coreboot.org/issues/3912022-06-17T02:57:57ZAlexander Goncharov
<p>Move global singleton states into a struct and store within the <code>spi_master</code> / <code>opaque_master</code> / <code>par_master</code> data field for the life-time of the driver.</p>
<p>This is one of the steps on the way to move <code>*_master</code> data memory management behind the initialisation API. </p>
<p>List of programmers which need to be refactored:</p>
<ul>
<li><del>atahpt</del> <a href="https://review.coreboot.org/c/flashrom/+/64963">https://review.coreboot.org/c/flashrom/+/64963</a></li>
<li><del>atapromise</del> <a href="https://review.coreboot.org/c/flashrom/+/65706">https://review.coreboot.org/c/flashrom/+/65706</a></li>
<li>atavia <code>*</code></li>
<li><del>buspirate_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/52958">https://review.coreboot.org/c/flashrom/+/52958</a></li>
<li>ch341a_spi <code>*</code></li>
<li><del>dediprog</del> <a href="https://review.coreboot.org/c/flashrom/+/56414">https://review.coreboot.org/c/flashrom/+/56414</a></li>
<li><del>developerbox_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54993">https://review.coreboot.org/c/flashrom/+/54993</a></li>
<li><del>digilent_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54012">https://review.coreboot.org/c/flashrom/+/54012</a></li>
<li><del>drkaiser</del> <a href="https://review.coreboot.org/c/flashrom/+/65194">https://review.coreboot.org/c/flashrom/+/65194</a></li>
<li>dummyflasher <code>*</code></li>
<li><del>ft2232_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/52256">https://review.coreboot.org/c/flashrom/+/52256</a></li>
<li><del>gfxnvidia</del> <a href="https://review.coreboot.org/c/flashrom/+/65342">https://review.coreboot.org/c/flashrom/+/65342</a></li>
<li>internal <code>*</code></li>
<li><del>it8212</del> <a href="https://review.coreboot.org/c/flashrom/+/65745">https://review.coreboot.org/c/flashrom/+/65745</a></li>
<li><del>jlink_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/52560">https://review.coreboot.org/c/flashrom/+/52560</a></li>
<li><del>linux_mtd</del> <a href="https://review.coreboot.org/c/flashrom/+/53947">https://review.coreboot.org/c/flashrom/+/53947</a> </li>
<li><del>linux_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/52285">https://review.coreboot.org/c/flashrom/+/52285</a></li>
<li><del>lspcon_i2c_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/56103">https://review.coreboot.org/c/flashrom/+/56103</a></li>
<li><del>mediatek_i2c_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/65746">https://review.coreboot.org/c/flashrom/+/65746</a></li>
<li><del>mstarddc_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54033">https://review.coreboot.org/c/flashrom/+/54033</a></li>
<li>ni845x_spi</li>
<li><del>nic3com</del> <a href="https://review.coreboot.org/c/flashrom/+/55107">https://review.coreboot.org/c/flashrom/+/55107</a></li>
<li><del>nicintel</del> <a href="https://review.coreboot.org/c/flashrom/+/65974">https://review.coreboot.org/c/flashrom/+/65974</a></li>
<li><del>nicintel_eeprom</del> <a href="https://review.coreboot.org/c/flashrom/+/66491">https://review.coreboot.org/c/flashrom/+/66491</a></li>
<li><del>nicintel_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54995">https://review.coreboot.org/c/flashrom/+/54995</a></li>
<li><del>nicnatsemi</del> <a href="https://review.coreboot.org/c/flashrom/+/65970">https://review.coreboot.org/c/flashrom/+/65970</a></li>
<li><del>nicrealtek</del> <a href="https://review.coreboot.org/c/flashrom/+/55108">https://review.coreboot.org/c/flashrom/+/55108</a></li>
<li><del>ogp_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54996">https://review.coreboot.org/c/flashrom/+/54996</a></li>
<li><del>pickit2_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/52774">https://review.coreboot.org/c/flashrom/+/52774</a></li>
<li><del>pony_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54997">https://review.coreboot.org/c/flashrom/+/54997</a></li>
<li><del>raiden_debug_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/56103">https://review.coreboot.org/c/flashrom/+/56103</a></li>
<li><del>rayer_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54998">https://review.coreboot.org/c/flashrom/+/54998</a></li>
<li><del>realtek_mst_i2c_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/56103">https://review.coreboot.org/c/flashrom/+/56103</a></li>
<li><del>satamv</del> <a href="https://review.coreboot.org/c/flashrom/+/65978">https://review.coreboot.org/c/flashrom/+/65978</a></li>
<li><del>satasii</del> <a href="https://review.coreboot.org/c/flashrom/+/66075">https://review.coreboot.org/c/flashrom/+/66075</a></li>
<li>serprog <code>*</code></li>
<li><del>stlinkv3_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54042">https://review.coreboot.org/c/flashrom/+/54042</a></li>
<li><del>usbblaster_spi</del> <a href="https://review.coreboot.org/c/flashrom/+/54044">https://review.coreboot.org/c/flashrom/+/54044</a></li>
</ul>
<p><code>*</code> - non-trivial case, this programmer requires some tricks</p>
flashrom - Bug #390 (New): Libflashrom progress goes backwards for erase and write operationshttps://ticket.coreboot.org/issues/3902022-06-16T22:52:11ZAnastasia Klimchuk
<p>When flashrom runs with <code>--progress</code> argument in the command line, it shows % progress for all operations. % is working nicely for read and verify operations. <br>
However for erase and write operations % starts with 0, goes up and then goes backwards to 0 again. By its nature, % progress should not go backwards.</p>
<p>Bug can be reproduced with dummyflasher.</p>
<p>Small repro case with just erase:</p>
<p>$ ./flashrom -p dummy:emulate=W25Q128FV -E --progress<br>
flashrom v1.2-759-gcba5de5 on Linux 5.16.18-1rodete2-amd64 (x86_64)<br>
flashrom is free software, get the source code at <a href="https://flashrom.org">https://flashrom.org</a></p>
<p>Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).<br>
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on dummy.</p>
<p>Erasing and writing flash chip... [READ] 100% complete... [READ] 0% complete... <br>
Erase/write done.</p>
<p>Longer repro case where you can see that read and verify works, but erase and write do not:</p>
<p>$ ./flashrom -p dummy:emulate=W25Q128FV,image=/tmp/rom -w /tmp/16m_rand.bin --progress<br>
flashrom v1.2-763-gb10d55049 on Linux 5.18.1-arch1-1 (x86_64)<br>
flashrom is free software, get the source code at <a href="https://flashrom.org">https://flashrom.org</a></p>
<p>Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).<br>
Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on dummy.</p>
<p>Reading old flash chip contents... [READ] 0% complete... [READ] 1% complete... [READ] 2% complete... [READ] 3% complete... [READ] 4% complete... [READ] 5% complete... [READ] 6% complete... [READ] 7% complete... [READ] 8% complete... [READ] 9% complete... [READ] 10% complete... [READ] 11% complete... [READ] 12% complete... [READ] 13% complete... [READ] 14% complete... [READ] 15% complete... [READ] 16% complete... [READ] 17% complete... [READ] 18% complete... [READ] 19% complete... [READ] 20% complete... [READ] 21% complete... [READ] 22% complete... [READ] 23% complete... [READ] 24% complete... [READ] 25% complete... [READ] 26% complete... [READ] 27% complete... [READ] 28% complete... [READ] 29% complete... [READ] 30% complete... [READ] 31% complete... [READ] 32% complete... [READ] 33% complete... [READ] 34% complete... [READ] 35% complete... [READ] 36% complete... [READ] 37% complete... [READ] 38% complete... [READ] 39% complete... [READ] 40% complete... [READ] 41% complete... [READ] 42% complete... [READ] 43% complete... [READ] 44% complete... [READ] 45% complete... [READ] 46% complete... [READ] 47% complete... [READ] 48% complete... [READ] 49% complete... [READ] 50% complete... [READ] 51% complete... [READ] 52% complete... [READ] 53% complete... [READ] 54% complete... [READ] 55% complete... [READ] 56% complete... [READ] 57% complete... [READ] 58% complete... [READ] 59% complete... [READ] 60% complete... [READ] 61% complete... [READ] 62% complete... [READ] 63% complete... [READ] 64% complete... [READ] 65% complete... [READ] 66% complete... [READ] 67% complete... [READ] 68% complete... [READ] 69% complete... [READ] 70% complete... [READ] 71% complete... [READ] 72% complete... [READ] 73% complete... [READ] 74% complete... [READ] 75% complete... [READ] 76% complete... [READ] 77% complete... [READ] 78% complete... [READ] 79% complete... [READ] 80% complete... [READ] 81% complete... [READ] 82% complete... [READ] 83% complete... [READ] 84% complete... [READ] 85% complete... [READ] 86% complete... [READ] 87% complete... [READ] 88% complete... [READ] 89% complete... [READ] 90% complete... [READ] 91% complete... [READ] 92% complete... [READ] 93% complete... [READ] 94% complete... [READ] 95% complete... [READ] 96% complete... [READ] 97% complete... [READ] 98% complete... [READ] 99% complete... [READ] 100% complete... done.<br>
Erasing and writing flash chip... [WRITE] 6% complete... [READ] 0% complete... [WRITE] 0% complete... Erase/write done.<br>
Verifying flash... [READ] 1% complete... [READ] 2% complete... [READ] 3% complete... [READ] 4% complete... [READ] 5% complete... [READ] 6% complete... [READ] 7% complete... [READ] 8% complete... [READ] 9% complete... [READ] 10% complete... [READ] 11% complete... [READ] 12% complete... [READ] 13% complete... [READ] 14% complete... [READ] 15% complete... [READ] 16% complete... [READ] 17% complete... [READ] 18% complete... [READ] 19% complete... [READ] 20% complete... [READ] 21% complete... [READ] 22% complete... [READ] 23% complete... [READ] 24% complete... [READ] 25% complete... [READ] 26% complete... [READ] 27% complete... [READ] 28% complete... [READ] 29% complete... [READ] 30% complete... [READ] 31% complete... [READ] 32% complete... [READ] 33% complete... [READ] 34% complete... [READ] 35% complete... [READ] 36% complete... [READ] 37% complete... [READ] 38% complete... [READ] 39% complete... [READ] 40% complete... [READ] 41% complete... [READ] 42% complete... [READ] 43% complete... [READ] 44% complete... [READ] 45% complete... [READ] 46% complete... [READ] 47% complete... [READ] 48% complete... [READ] 49% complete... [READ] 50% complete... [READ] 51% complete... [READ] 52% complete... [READ] 53% complete... [READ] 54% complete... [READ] 55% complete... [READ] 56% complete... [READ] 57% complete... [READ] 58% complete... [READ] 59% complete... [READ] 60% complete... [READ] 61% complete... [READ] 62% complete... [READ] 63% complete... [READ] 64% complete... [READ] 65% complete... [READ] 66% complete... [READ] 67% complete... [READ] 68% complete... [READ] 69% complete... [READ] 70% complete... [READ] 71% complete... [READ] 72% complete... [READ] 73% complete... [READ] 74% complete... [READ] 75% complete... [READ] 76% complete... [READ] 77% complete... [READ] 78% complete... [READ] 79% complete... [READ] 80% complete... [READ] 81% complete... [READ] 82% complete... [READ] 83% complete... [READ] 84% complete... [READ] 85% complete... [READ] 86% complete... [READ] 87% complete... [READ] 88% complete... [READ] 89% complete... [READ] 90% complete... [READ] 91% complete... [READ] 92% complete... [READ] 93% complete... [READ] 94% complete... [READ] 95% complete... [READ] 96% complete... [READ] 97% complete... [READ] 98% complete... [READ] 99% complete... [READ] 100% complete... VERIFIED.</p>
flashrom - Bug #374 (Response Needed): -x option filters only spaces when converting region names...https://ticket.coreboot.org/issues/3742022-04-28T01:27:32ZAnastasia Klimchuk
<p>Also check that manpage is updated</p>
<p>Relevant patch:<br>
<a href="https://review.coreboot.org/c/flashrom/+/52450">https://review.coreboot.org/c/flashrom/+/52450</a><br>
Manpage update here <a href="https://review.coreboot.org/c/flashrom/+/52892">https://review.coreboot.org/c/flashrom/+/52892</a></p>
coreboot - Feature #295 (New): Documentation: include common partshttps://ticket.coreboot.org/issues/2952021-02-27T13:15:19ZAlexey Vazhnov
<p>In user-level how-tos, some parts are common for every motherboard, for example:</p>
<ul>
<li>get coreboot sources</li>
<li>install dependencies</li>
</ul>
<p>Possible solutions:</p>
<a name="Repeat-these-steps-in-every-user-level-how-to"></a>
<h3 >Repeat these steps in every user-level how-to<a href="#Repeat-these-steps-in-every-user-level-how-to" class="wiki-anchor">¶</a></h3>
<p>Cons:</p>
<ul>
<li>Somebody have to keep them up to date</li>
</ul>
<a name="Give-a-links-to-separate-pages"></a>
<h3 >Give a links to separate pages<a href="#Give-a-links-to-separate-pages" class="wiki-anchor">¶</a></h3>
<p>Cons:</p>
<ul>
<li>I don't like to jump to different pages when whole documentation can fit into one page</li>
</ul>
<a name="Include-from-special-pages-which-are-not-rendered-by-self"></a>
<h3 >Include from special pages, which are not rendered by self<a href="#Include-from-special-pages-which-are-not-rendered-by-self" class="wiki-anchor">¶</a></h3>
<p>Here I will try to find a way to <strong>include</strong> common parts.</p>
coreboot - Bug #251 (New): Add SD card detect GPIO in jslrvp devicetreehttps://ticket.coreboot.org/issues/2512020-01-09T06:05:32ZAamir Bohraaamir.bohra@intel.com
<p>The SD card detect GPIO currently needs to be added once the jsl gpio driver code is merged.<br>
This bug tracks its implementation.</p>
coreboot - Support #222 (New): Include FSP stack and heap allocation requirement in FSP intergrat...https://ticket.coreboot.org/issues/2222019-07-26T07:38:57ZAamir Bohraaamir.bohra@intel.com
<p>Newer CML FSP releases enable support for using the same stack as the bootloader.<br>
And do not relocate the stack pointer. The FSP integration guide needs to capture<br>
stack and heap allocation requirement, along with guide on the UPDs involved.</p>
coreboot - Feature #108 (Response Needed): thinkpad x1 carbon gen 1 remaining taskshttps://ticket.coreboot.org/issues/1082017-04-25T15:29:01Zlx r
<ul>
<li><del>SPD based on inteltool for elpida</del>
<ul>
<li><del>missing samsung memory (missing a model or find spd data in uefi)</del></li>
<li><del>missing hynix memory (missing a model or find spd data in uefi)</del></li>
</ul></li>
<li>test msata port if soldered (missing msata disk)</li>
<li><del>use pins to differ 4gb and 8gb (prepare, but missing a model to verify)</del></li>
<li>check why device consumes more power (+ 3W while idle)
<ul>
<li>do another test run how much is the difference, see if <code>powertop --auto-tune</code> works</li>
<li>check if thermal/power/freq MSR are different</li>
<li>check if it's display backlight</li>
<li>check how big is the consumption when turning display off</li>
</ul></li>
<li>enable pci/sata link power save</li>
</ul>
coreboot - Bug #66 (New): rmodule_copy_payload() does not initialize unused memoryhttps://ticket.coreboot.org/issues/662016-08-16T16:38:33ZTrammell Hudsonhudson@trmm.net
<p>If module->payload_size != rmodule_memory_size(module), the excess memory remains uninitialized in rmodule_copy_payload(). This prevents reproducible TPM measurements of the unpacked modules and could possibly lead to runtime bugs or security vulnerabilities.</p>
coreboot - Feature #38 (New): tp_smapi support on ThinkPadshttps://ticket.coreboot.org/issues/382016-03-15T00:32:03ZIru Caimytbk920423@gmail.com
<p>tp_smapi kernel module: <a href="https://github.com/evgeni/tp_smapi">https://github.com/evgeni/tp_smapi</a></p>
<p>SMAPI a useful feature for setting the battery charge threshold. The firmware part of SMAPI is implemented in the boot firmware (IMO the SMM part). Maybe we have to reverse engineer the factory firmware to know how the firmware code talk to the EC. We also need to change the cmos.layout of the supported laptops.</p>