Issue Tracker: Issueshttps://ticket.coreboot.org/https://ticket.coreboot.org/themes/PurpleMine2-2.16.2/favicon/favicon.ico?12016-07-29T04:41:47ZIssue Tracker
Redmine coreboot - Bug #61 (Response Needed): Bluetooth light on X200https://ticket.coreboot.org/issues/612016-07-29T04:41:47ZJean Lucasjean@4ray.co
<p>On a ThinkPad X200, with coreboot revision 4.4-910-g168eb6a, the Bluetooth light has never turned on, despite active Bluetooth usage. Which are the files that handle the Bluetooth (and possibly WiFi and WAN) light(s)?</p>
coreboot - Feature #57 (Feedback): Create build rule for ASUS E35M1-I Deluxehttps://ticket.coreboot.org/issues/572016-06-04T16:31:21ZJohannes Obermayrjohannesobermayr@gmx.de
<p>Please create a build rule for ASUS E35M1-I Deluxe board.</p>
<p>info_dump difference between similiar ASRock E350M1 is shown in attached file.</p>
coreboot - Feature #56 (New): 16GB DIMM support on Sandy/Ivy Bridgehttps://ticket.coreboot.org/issues/562016-05-31T10:39:03ZIru Caimytbk920423@gmail.com
<p>The first 16GB DDR3L was released last year, and for Intel platforms, only Broadwell and some Atom SoCs support it. However, in the compatibility list[2], it is said that many existing boards that supports DDR3 support 16GB DDR3L, and CPUs on X79 boards can support it with a modified MRC. So I think it's possible to be supported on a Sandy/Ivy Bridge machine.</p>
<p>The raminit logs show that coreboot does the memory init, and the code in romstage that should be run in memory works fine, but it crashes on payload stage.</p>
<p>(The following is what I wrote on the mailing list)</p>
<p>Hi,</p>
<p>I'm tesing to see if the coreboot Sandy/Ivy MRC supports 16GB DIMMs. Here's my result.</p>
<p>I'm using a MT16KTF2G64HZ-1G6A1[1]. My machine is Lenovo T420 with i7-3630QM. With this module inserted (I've tested 16G+0 and 16G+8G), the system can light up, but it'll then get crashed.</p>
<ul>
<li>with GRUB2 payload, it'll crash after the payload loads</li>
<li>with SeaBIOS payload with proprietary VGABIOS, I can see the prompt, and can boot to a GRUB or syslinux loader on my USB stick, but when I try to boot a system, it get crashed. If I boot to Memtest86+ on my USB stick, the system will crash when memtest starts to test the memory.</li>
</ul>
<p>And another thing I can see is, the first boot can boot to payload, but the second boot will fail. I think it's caused by the MRC cache.</p>
<p>I'm still wondering if Sandy/Ivy northbridge can support 16GB DIMMs. I'll give a more detailed EHCI debug output later. According to [2], I think the incompatibility is an MRC issue instead of hardware incompatibility.</p>
<p>[1] <a href="https://www.micron.com/parts/modules/ddr3-sdram/mt16ktf2g64hz-1g6?pc={E1D8F1A9-3DFC-4BD2-8A1E-C26ED261EB0A}" class="external">https://www.micron.com/parts/modules/ddr3-sdram/mt16ktf2g64hz-1g6?pc={E1D8F1A9-3DFC-4BD2-8A1E-C26ED261EB0A}</a><br>
[2] <a href="http://www.intelligentmemory.com/fileadmin/download/compatibilitylist.pdf" class="external">http://www.intelligentmemory.com/fileadmin/download/compatibilitylist.pdf</a></p>
coreboot - Bug #55 (New): copy lzint decompress from phnxsplit into python phonix_extracthttps://ticket.coreboot.org/issues/552016-05-18T20:59:36ZAlexander Couzenslynxislazus@gmail.com
<p>phoniex_extract lacks support for decompression lzint compressed images.<br>
it can detect compressed images, but tries to use the unknown tool unlzint.</p>
<p>phnxsplit can do the same job, but can decompress.</p>
coreboot - Bug #49 (New): board_status.sh does not check git identityhttps://ticket.coreboot.org/issues/492016-04-30T18:19:14ZDaniel Kuleszdaniel.ina1@googlemail.com
<p>Running board_status.sh from live environments seems like a good idea at first sight.</p>
<p>However, board_status.sh does not check git identities beforehand and only prints warnings during uploading process. In fact, it fails (more or less silently) to commit the changes due to not configured git identity. Now, even if you set the git identity afterwards and re-run it, it refuses to file the board_status because it says that it's a duplicate, while in fact the previous report was not uploaded at all.</p>
<p>So imho we have two problems here:</p>
<ul>
<li>board_status.sh does not check git identities beforehand</li>
<li>board_status reports false positives regarding duplicate status</li>
</ul>
coreboot - Bug #46 (New): F2A85-M reports false temperatureshttps://ticket.coreboot.org/issues/462016-04-25T17:10:10ZDaniel Kuleszdaniel.ina1@googlemail.com
<p>Running lm-sensors on my F2A85-M with Coreboot 4.3-Release, I get the following temperature readings which are obviously wrong:</p>
<pre><code>sensors
k10temp-pci-00c3
Adapter: PCI adapter
temp1: +0.0 C (high = +70.0 C)
(crit = +70.0 C, hyst = +69.0 C)
radeon-pci-0008
Adapter: PCI adapter
temp1: -9.0 C (crit = +120.0 C, hyst = +90.0 C)
</code></pre> coreboot - Feature #39 (New): Enable OS-level flashing of coreboot for ThinkPad T410/X201https://ticket.coreboot.org/issues/392016-03-24T04:00:07ZRodrigo Toste Gomesrgomes_ticket.coreboot.org@codeblurb.com
<p>I have a use case where I need to be able to flash coreboot on a T410 from the OS-level.<br>
I have successfully flashed coreboot on a T410 via external flashing (using a Ponoma clip on the SOIC-8 flash chip that's exposed only when the motherboard is removed). I managed to get an older version of coreboot to work (the same one that's suggested in the x201 page), using the x201 chipset option. I had to struggle a bit to extract the vga bios, but once I had it, everything seems to run smoothly.<br>
I am planning to investigate further with newer versions of coreboot, but that is not my first priority. They seem to make it impossible to boot Linux, and my priority is getting some version of coreboot on these machines, and doing it via OS-level flashing.<br>
The X201 wiki page hints that we should be able to edit the Lenovo BIOS installer, modifying the bootblock part so that the flash is writeable, and then should be able to write coreboot. I have a good testbench that allows me to quickly recover if I brick a motherboard, and have the freedom to irreversibly brick a couple of motherboards without consequence (although I find it hard to believe I could achieve that, and would be less than ideal if I did). I don't, however, have a lot of experience with BIOS editing, and am cooperating with Alexander in that aspect. This tickets serves to record progress and simplify discussion.</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" class="external">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>
coreboot - Bug #30 (New): board-status allows invalid uploadshttps://ticket.coreboot.org/issues/302016-02-04T20:52:49ZTimothy Pearsontpearson@raptorengineeringinc.com
<p>board-status uses the GIT hash of the parent coreboot tree in its commits, but does not check to make sure that the user actually booted the same GIT hash before merrily uploading an invalid status report.</p>
<p>board-status should verify (via the coreboot tables) that the user has actually booted from a build of the GIT hash in the parent coreboot tree before allowing upload.</p>
coreboot - Feature #29 (New): board-status should reject uploads with incorrect DMI stringhttps://ticket.coreboot.org/issues/292016-02-03T20:24:32ZTimothy Pearsontpearson@raptorengineeringinc.com
<p>There have been a number of cases where people have forgotten to change their DMI mainboard make/model strings to match the physical board and/or coreboot's settings.</p>
<p>board-status should compare the advertised DMI strings against the coreboot configuration file, and reject upload if make/model do not match.</p>
coreboot - Feature #28 (New): board-status should reject duplicate uploadshttps://ticket.coreboot.org/issues/282016-02-02T23:20:02ZTimothy Pearsontpearson@raptorengineeringinc.com
<p>When a board has already been tested and test results for the same non-dirty GIT hash would be uploaded for the same hardware, board-status should abort to prevent multiple duplicate test results.</p>
coreboot - Bug #21 (New): If a PCI device requests more memory space than is available, coreboot ...https://ticket.coreboot.org/issues/212015-12-30T17:34:09ZMartin Rothgaumless@gmail.com
<p>Here are the issues and their locations:</p>
<p>Current code:<br>
device.c: avoid_fixed_resources()</p>
<pre><code> if (res->flags & IORESOURCE_MEM)
res->base = resource_max(res);
</code></pre>
<p>res->base isn't checked to make sure that it's valid.</p>
<p>device_util.c: resource_max()</p>
<pre><code> resource_t max;
max = align_down(resource->limit - resource->size + 1, resource->align);
return max;
</code></pre>
<p>The max value also isn't checked for validity here.</p>
<p>Currently if a device requests 2GB of memory, it's assigned memory at address 0x00.</p>
<p>I don't believe that this is as simple as just not assigning memory to the offending BAR, as that will leave the device in a very odd state with some BARs enabled, and others not enabled.</p>
<p>An initial attempt to fix this problem was proposed in <a href="https://review.coreboot.org/#/c/12575" class="external">https://review.coreboot.org/#/c/12575</a></p>
coreboot - Feature #20 (In Progress): Add make target to check if toolchain is up to datehttps://ticket.coreboot.org/issues/202015-12-30T17:07:23ZTimothy Pearsontpearson@raptorengineeringinc.com
<p>Various automated build/test services use a specific toolchain build for all tests, and have no way to know if the toolchain has been updated and requires a rebuild. This, in turn, means manual intervention is needed for these services every time the toolchain version changes. (unless various hacks involving searching the output text are used, but these are highly suboptimal).</p>
<p>A new make target to check if the built toolchain is completely up to date with the current coreboot versions would be very useful.</p>
coreboot - Bug #19 (New): Violations of Coding guidelines: All objects should have fully qualifie...https://ticket.coreboot.org/issues/192015-12-30T16:28:11ZMartin Rothgaumless@gmail.com
<p>Some (most?) of these can be seen using the following command:<br>
grep -Grin 'unsigned' | grep -v 'unsigned<a class="wiki-page new" href="https://ticket.coreboot.org/projects/coreboot/wiki/Space">:space:</a>*int|unsigned<a class="wiki-page new" href="https://ticket.coreboot.org/projects/coreboot/wiki/Space">:space:</a>*long|unsigned<a class="wiki-page new" href="https://ticket.coreboot.org/projects/coreboot/wiki/Space">:space:</a>*char|unsigned<a class="wiki-page new" href="https://ticket.coreboot.org/projects/coreboot/wiki/Space">:space:</a>*short'</p>
coreboot - Bug #15 (In Progress): board-status uploads incorrect reports if config not foundhttps://ticket.coreboot.org/issues/152015-12-01T15:29:56ZTimothy Pearsontpearson@raptorengineeringinc.com
<p>The board-status script uploads reports for a nonexistent mainboard if the coreboot configuration file is not found in CBFS. It should abort the upload if the CBFS configuration file access fails.</p>
<p>Script output during failure:</p>
<pre><code>E: File not found: config
mv: cannot stat ‘/tmp/coreboot_board_status.i4CRMqXl/config.txt’: No such file or directory
cp: cannot stat ‘/tmp/coreboot_board_status.i4CRMqXl/config.short.txt’: No such file or directory
</code></pre>
<p>Example of failed/incorrect board-status commit:<br>
<a href="https://review.coreboot.org/gitweb?p=board-status.git;a=commit;h=d4370d70b721b964ed47df422935c01e6c887bff" class="external">https://review.coreboot.org/gitweb?p=board-status.git;a=commit;h=d4370d70b721b964ed47df422935c01e6c887bff</a></p>
<p>Example of correct board-status commit:<br>
<a href="https://review.coreboot.org/gitweb?p=board-status.git;a=commit;h=a633af9397e42af0b436e2f75417aca71b056c4a" class="external">https://review.coreboot.org/gitweb?p=board-status.git;a=commit;h=a633af9397e42af0b436e2f75417aca71b056c4a</a></p>
<p>CBFS contents causing the problem:<br>
<a href="https://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=emulation/qemu-armv7/4.2-441-g1a38374/2015-12-01T15:59:41Z/cbfs.txt;h=0839a112bc295e16a4624acb33c73bf3fa9ba9d0;hb=d4370d70b721b964ed47df422935c01e6c887bff" class="external">https://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=emulation/qemu-armv7/4.2-441-g1a38374/2015-12-01T15:59:41Z/cbfs.txt;h=0839a112bc295e16a4624acb33c73bf3fa9ba9d0;hb=d4370d70b721b964ed47df422935c01e6c887bff</a></p>
<p>Correct CBFS contents:<br>
<a href="https://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asus/kfsn4-dre/4.2-413-g8528e39/2015-11-28T18:21:18Z/cbfs.txt;h=a633af9397e42af0b436e2f75417aca71b056c4a;hb=2b0d3777959841375d6ca1cf5164ec9d3f8a235d" class="external">https://review.coreboot.org/gitweb?p=board-status.git;a=blob;f=asus/kfsn4-dre/4.2-413-g8528e39/2015-11-28T18:21:18Z/cbfs.txt;h=a633af9397e42af0b436e2f75417aca71b056c4a;hb=2b0d3777959841375d6ca1cf5164ec9d3f8a235d</a></p>