Issue Tracker: Issueshttps://ticket.coreboot.org/https://ticket.coreboot.org/themes/PurpleMine2-2.16.2/favicon/favicon.ico?12023-08-07T14:45:04ZIssue Tracker
Redmine 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>
coreboot - Other #492 (New): Evaluate changes which need to be made to support Intel's X86S ISA c...https://ticket.coreboot.org/issues/4922023-05-28T15:25:56ZMartin Rothgaumless@gmail.com
<p>This past week, Intel announced a plan to boot directly to 64-bit mode[1].<br>
While the timeline released with the announcement does't have any dates for the implementation, due to the huge impact this will have on coreboot, it seems appropriate to start looking at what changes will need to be made to support these changes to the ISA.</p>
<p>Changes currently listed:<br>
Changes in X86-S ISA consist of:</p>
<ul>
<li>restricting the CPU to be always in paged mode</li>
<li>removing 32-bit ring 0, as well as vm86 mode.</li>
<li>removing ring 1 and ring 2</li>
<li>removing 16-bit real and protected modes</li>
<li>removing 16-bit addressing</li>
<li>removing fixed MTRRs</li>
<li>removing user-level I/O and string I/O</li>
<li>removing CR0 Write-Through mode</li>
<li>removing legacy FPU control bits in CR0</li>
<li>removing ring 3 interrupt flag control</li>
<li>removing obsolete CR access instruction</li>
<li>rearchitecting INIT/SIPI</li>
<li>adding a new mechanism to switch between 4- and 5-level page tables</li>
<li>removing XAPIC and only supporting x2APIC</li>
<li>removing APIC support for 8529</li>
<li>removing the disabling of NX or SYSCALL or long mode in the EFER MSR</li>
<li>removing the #SS and #NP exceptions</li>
<li>supporting a subset of segmentation architecture, with the following conditions:
o restricted to a subset of IDT event delivery
o base only for FS, GS
o base and limit for GDT, IDT, and TSS
o no limit on data or code fetches in 32-bit mode (similar to 64-bit)
o no AR or unusable selector checking on CS, DS, ES, FS, and GS on data or code
fetches in any mode
o restricted support for far call, far return, far jump, and IRET (like FRED).</li>
</ul>
<p>1: <a href="https://web.archive.org/web/20230526070811/https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html#articleparagraph_462828643" class="external">https://web.archive.org/web/20230526070811/https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html#articleparagraph_462828643</a></p>
coreboot - Cleanup #490 (New): Verify copyrights on files with BSD, X11, MIT, HPND, and ISC licenseshttps://ticket.coreboot.org/issues/4902023-05-20T20:37:49ZMartin Rothgaumless@gmail.com
<p>Files with these licenses contain a phrase similar to "provided that the above copyright notice appears in all copies".</p>
<p>This requires that the copyrights be left in these files when they are brought into coreboot from other projects, and that they should not have been removed in the copyright cleanup.</p>
<p>The coreboot project does not want new copyright notices added to these files going forward, similar to the position on GPL files, however the existing copyright notices need to be grandfathered in for these files.</p>
coreboot - Cleanup #480 (New): amd/common/acpi/gpio_bank_lib.asl: IASL remarks: Creation of named...https://ticket.coreboot.org/issues/4802023-04-10T19:26:05ZPaul Menzelpmenzel+ticket.coreboot@molgen.mpg.de
<p>Building AMD boards using AMD common code like <em>google/kahlee (Careena)</em> or <em>google/myst</em>, IASL show the remarks below:</p>
<pre><code>$ git log --oneline --no-decorate -1
f2e8865d76 soc/amd/common/blk/pcie: Program LTR max latencies
$ make menuconfig
[…]
$ make -j4
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20200925
Copyright (c) 2000 - 2020 Intel Corporation
dsdt.asl 49: Name(BUFF, Buffer(Local0) {})
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.S2BF)
dsdt.asl 117: OperationRegion (GPDW, SystemMemory, Local0, 4)
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GPRD)
dsdt.asl 126: OperationRegion (GPDW, SystemMemory, Local0, 4)
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GPWR)
dsdt.asl 134: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4)
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.STXS)
dsdt.asl 143: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4)
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.CTXS)
dsdt.asl 152: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4)
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GRXS)
dsdt.asl 162: OperationRegion (GPDW, SystemMemory, GPAD (Arg0), 4)
Remark 2173 - ^ Creation of named objects within a method is highly inefficient, use globals or method local variables instead (\_SB.GTXS)
ASL Input: dsdt.asl - 33891 bytes 1278 keywords 901 source lines
AML Output: dsdt.aml - 13412 bytes 909 opcodes 369 named objects
Compilation successful. 0 Errors, 0 Warnings, 7 Remarks, 295 Optimizations, 46 Constants Folded
IASL 3150 warning types were ignored!
IASL build/dsdt.aml disassembled correctly.
</code></pre>
<p>Moved to common in <a href="https://review.coreboot.org/c/coreboot/+/32651" class="external">commit 251d305e73f7 (soc/amd/stoneyridge: Move GPIO support to common)</a>.</p>
flashrom - Cleanup #452 (New): flashrom - meson.build file - update meson_version to >=0.57.0https://ticket.coreboot.org/issues/4522023-02-02T16:03:59ZJames Feeneyjames@nurealm.net
<p>meson.build:4</p>
<pre><code>meson_version : '>=0.53.0',
</code></pre><pre><code>$ meson setup ...
...
WARNING: Project specifies a minimum meson_version '>=0.53.0' but uses features which were added in newer versions:
* 0.57.0: {'test() timeout <= 0'}
...
</code></pre> coreboot - Project ideas #451 (New): Fix POST code handlinghttps://ticket.coreboot.org/issues/4512023-01-29T00:48:12ZFelix Singer
<p>coreboot supports writing POST codes to I/O port 80. There are various Kconfigs that deal with POST codes, which don’t have effect on most platforms. The code to send POST codes is scattered in C and Assembly, some use functions, some use macros and others simply use the <code>outb</code> instruction. The POST codes are duplicated between stages and aren’t documented properly.</p>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ul>
<li>Guard Kconfigs with a depends on to only show on supported platforms</li>
<li>Remove duplicated Kconfigs</li>
<li>Replace <code>outb(0x80, ...)</code> with calls to <code>post_code(...)</code></li>
<li>Update Documentation/POSTCODES</li>
<li>Use defines from console/post_codes.h where possible</li>
<li>Drop duplicated POST codes</li>
<li>Make use of all possible 255 values</li>
</ul>
<a name="Requirements"></a>
<h2 >Requirements<a href="#Requirements" class="wiki-anchor">¶</a></h2>
<ul>
<li>Knowledge in the coreboot build system and the concept of stages</li>
<li>Other knowledge: Little experience with C and x86 Assembly</li>
<li>Hardware requirements: Nothing special</li>
</ul>
<a name="Mentors"></a>
<h2 >Mentors<a href="#Mentors" class="wiki-anchor">¶</a></h2>
<ul>
<li>Patrick Rudolph <a href="mailto:patrick.rudolph@9elements.com">patrick.rudolph@9elements.com</a></li>
<li>Christian Walter <a href="mailto:christian.walter@9elements.com">christian.walter@9elements.com</a></li>
</ul>
coreboot - Documentation #450 (New): Port over wiki pages to the new documentationhttps://ticket.coreboot.org/issues/4502023-01-20T13:25:12ZFelix Singer
<p>The <a href="https://www.coreboot.org/Welcome_to_coreboot" class="external">old coreboot wiki</a> is being retired and it's replaced by <a href="https://doc.coreboot.org" class="external">https://doc.coreboot.org</a> created with Sphinx. There are several wiki pages which are still not ported over.</p>
<p>This ticket is meant as a tracking ticket. Please create a separate ticket for each wiki page which needs a port and set this ticket as your parent ticket.</p>
<p><strong>Be aware that some wiki pages have content but for some reason the software doesn't render it. In that case, check the source page of it to see if it has content.</strong></p>
coreboot - Cleanup #421 (New): Change API of functions taking hash as an argumenthttps://ticket.coreboot.org/issues/4212022-10-12T10:42:03ZKrystian Hebel
<p>All existing functions that take a digest as an input assume that only one hashing algorithm is used at a time. Crypto agile format entry can (and should) log every used PCR bank in one entry for a given measurement. To make it work, some of the arguments must be changed, e.g.:</p>
<ul>
<li>pass number of algorithms used;</li>
<li>instead of algorithm ID, pass a pointer to array of such IDs, with size equal to above;</li>
<li>instead of hash, pass a pointer to array of hashes, with size and order as above.</li>
</ul>
flashrom - Other #419 (New): Add automatic spell checking to build bothttps://ticket.coreboot.org/issues/4192022-10-11T08:53:48ZAngel Pons
<p>Having the build bot automatically spell-check changes like coreboot's does would be very useful, especially for people with dyslexia. How can we do it?</p>
flashrom - Other #402 (New): Testing of FM25Q chip serieshttps://ticket.coreboot.org/issues/4022022-07-11T20:34:43ZSamantaz Fox
<a name="Problem-encountered"></a>
<h2 >Problem encountered<a href="#Problem-encountered" class="wiki-anchor">¶</a></h2>
<p>I had to reprogram an FM25Q08B, and ran in a somewhat weird issue:</p>
<ul>
<li>the chip was detected</li>
<li>the registers were properly read,</li>
<li>the memory reading operation was hanging (I let it run for 20 minutes, with no result).</li>
</ul>
<p>I added some debugging code across the function path that leads to <a href="https://review.coreboot.org/plugins/gitiles/flashrom/+/edcea80d68e0f029b79bc273ba622dc4a3e6cb2b/spi25.c#691" class="external"><code>spi_read_chunked</code></a>, and discovered that only the first 2048 bytes could be read, then the chip stopped responding.</p>
<a name="Solution"></a>
<h2 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>After some more digging, I found out that this chip requires paged reading (chunks of 256 bits, similarly to the write process). Note that I've only tried one sample so far (more will come later this week), so I'm currently unable to say if this is a hardware issue or intended.</p>
<p>In the end, my workaround was to override <code>chunksize</code> in <code>spi_read_chunked</code>. After that, everything went fine: I was able to dump the existing content, erase the chip, write new content, and verify it back.</p>
<p>I'm sorry for not being able to provide a patch. I'm not familiar enough with the codebase & coding style.</p>
<a name="Maybe-Useful-details"></a>
<h2 >(Maybe) Useful details<a href="#Maybe-Useful-details" class="wiki-anchor">¶</a></h2>
<ul>
<li>A BusPirate was used as the SPI interface</li>
<li>Flashrom was running on Fedora 35, built from <a href="https://review.coreboot.org/plugins/gitiles/flashrom/+/edcea80d68e0f029b79bc273ba622dc4a3e6cb2b" class="external">edcea80</a> (latest master at the time of writing)</li>
<li>The chip was <a href="https://www.flashrom.org/Bus_Pirate" class="external">wired as shown on the wiki page</a> with 6.8k resistors for 3.3V pull-up</li>
</ul>
<p><strong>Logs:</strong> I've run all my tests in verbose mode, so I'll send those later on (I have to transfer them across PCs).</p>
flashrom - Documentation #382 (New): Update Downloads page on the websitehttps://ticket.coreboot.org/issues/3822022-05-19T22:29:36ZAnastasia Klimchuk
<p>Downloads page is out-of-date.</p>
<p>Suggestion: for linux systems use packaged binary, if you need latest, build off master<br>
List of versions in each distro: <a href="https://repology.org/badge/vertical-allrepos/flashrom.svg" class="external">https://repology.org/badge/vertical-allrepos/flashrom.svg</a> </p>
flashrom - Cleanup #368 (New): Code style review for s25f chips infrastructurehttps://ticket.coreboot.org/issues/3682022-04-28T01:01:53ZAnastasia Klimchukflashrom - Documentation #359 (Response Needed): Document how spireadmode param works in sb600spihttps://ticket.coreboot.org/issues/3592022-04-27T23:08:14ZAnastasia Klimchuk
<p>Some man page info was added in <br>
Check is that's sufficient, if any more info needed?</p>
coreboot - Cleanup #308 (New): Deal with walkcbfs_asmhttps://ticket.coreboot.org/issues/3082021-04-28T07:02:02ZPatrick Georgipgeorgi@google.com
<p>To remove the CBFS master header, walkcbfs_asm needs to either be made aware of fmap or removed.</p>
<p>Current users (as determined by Arthur):</p>
<ul>
<li>Updating microcode before CAR on systems that don't do µcode updates through FIT</li>
<li>Finding FSP-T on builds that use it (which is a bad idea anyway for root of trust concerns)</li>
</ul>
coreboot - Cleanup #306 (New): Get rid of CBFS master headerhttps://ticket.coreboot.org/issues/3062021-04-28T06:58:48ZPatrick Georgipgeorgi@google.com
<p>The CBFS master header has been used for some basic partitioning of the flash before we established the use of FMAP. Now that FMAP is the default mechanism across the tree, we should get rid of the master header.</p>
<p>This is a tracking issue to collect what needs to be done before we can retire the master header for good.</p>