[coreboot] T430: Flashing using plug contacts instead of fully disassembling the laptop

[Daniel Kulesz via coreboot]

Hi,

I plan to flash a Thinkpad T430. According to an article in the german 
"golem.de" magazine [1] accessing the flash via SPI is possible by connecting 
the wires from the SPI flasher to plug contacts on the upper side of the board 
- without disassembling the whole device. Unfortunately, I was unable to find 
the details regarding these contacts neither in the coreboot docs nor anywhere 
else. Did I look in the wrong places or is this simply not publically 
documented?

Cheers, Daniel


[1] 
https://www.golem.de/news/coreboot-und-nitrokey-mein-acht-jahre-alter-laptop-wird-zur-festung-2012-152931.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: RFC: On testing and reporting how well coreboot does on real hardware

[Daniel Kulesz via coreboot]

Hi Patrick,

> Looking at the software you described it seems a wonderful tool for humans
> to create, execute test steps and analyse test results entered manually by
> a human.

Actually, this was the primary goal - we wanted to support testing of systems 
that are close to hardware (such as coreboot). Especially with coreboot, 
personally, I found too often that I bought a board that was officially 
"supported" just to find out that some things were actually broken while they 
seemed to have been working in past versions well (happened to me lately with a 
Thinkpad T410, see my previous postings to the list about this). The idea in 
SystemTestPortal is to support testing for such regressions - but this of 
course requires the availability of humans that execute these tests.

> What we are looking for is only the "data store" and visual representation
> of such, where automated tests are run by robots. Those (self-hosted or
> propietary) robots need to publish their test results somewhere using a web
> API.

I see. Well, there is a different project named "ReportPortal.io" that (imho) 
does exactly that. We had a joint stand at FOSDEM 2019 together with them and 
KiwiTCMS. It might be worth looking into that.

> Does SystemTestPortal support input from robots over for example REST API?

Not at the moment but it is a feature request we received multiple times so we 
will eventually add this in the future.

> Does it support the idea of different products/configurations?

Yes, it does. We have a two-dimensional concept of a products and variants, but 
I think coreboot would need three dimensions or even more, right? So for 
example you could have:

- coreboot 4.14 ("clean" without patches)
- on a Thinkpad T410
- built with config options X and Y enabled but Z disabled

In addition, there could be also different configurations of the target 
machine, different OSs on which you would test etc. - the key challenge here is 
to decide what to put into the test cases themselves and what to put in the 
products/variants/configuration metadata. Maybe you could try to describe a 
data model that would be ideal from the coreboot perspective?

Cheers, Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: RFC: On testing and reporting how well coreboot does on real hardware

[Daniel Kulesz via coreboot]

Hi Piotr, Patrick et al.,

actually, there is dedicated software to achieve exactly what you are talking 
about. I initiated the SystemTestPortal project [1] a while ago to provide an 
open source solution that focuses on simplicity and low entry barriers - you 
can watch my 2019 talk at FrOsCon [2] to get a first overview.

Currently, the project is stalled and, thus, the software is ready for 
production due to the lack of maintenance. However I plan tp resume the project 
soon. There are also other open source projects that provide similar solutions 
in this space. Yet, I must confess that to date I had a really hard time 
convincing developers to give our tool a serious try. While this might be due 
to bugs in the tool itself, I think it is mainly because many developers and 
project leaders don't buy into such a "community testing" approach as they 
think that the only right way to test software is through test automation.

I think that coreboot is a perfect example of a project that could benefit from 
such a tool (not necessarily our tool, but one from this category).

Cheers, Daniel


[1] https://www.systemtestportal.org/
[2] https://media.ccc.de/v/froscon2019-2359-testing_software_yes_please
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Lenovo T410: Regression in coreboot 4.13?

[Daniel Kulesz via coreboot]

Yes, definitely - however I didn't really have the time to do that 
(unfortunately) and had to return the T410. Luckily, I have a second T410, so 
if I find the time to disassemble it I will try to find the offending commit. 
If someone has one that is already disassembled this would make the process 
much easier as it is so much hassle with this model...

Nevertheless I wanted to issue a warning to other people who might try to flash 
their T410 with the current version.

Cheers, Daniel


On Tue, 2 Mar 2021 17:57:36 +0300
Mike Banon  wrote:

> Know it may be late, but you should've done a commit dichotomy to find
> some bad commit which maybe happened between 4.12/4.13 and could've
> been a real cause of your problem.
> 
> On Sat, Feb 20, 2021 at 11:45 PM Daniel Kulesz via coreboot
>  wrote:
> >
> > Hi folks,
> >
> > I spent a long time trying to get coreboot 4.13 to work on a Lenovo T410, 
> > trying various configuration options etc. but it never worked (fan, 
> > keyboard LED and thinklight went on, screen stayed dark). I tried even the 
> > most basic config, but no luck.
> >
> > I tried the same with coreboot 4.12 and this seems to work fine.
> >
> > Unfortunately, this is not my laptop and the owner needs his laptop back 
> > asap, so I don't have the time to further debug this issue. Yet, I wanted 
> > to report this regression as I I am wondering if anyone else is running 
> > 4.13 on a T410 with success?
> >
> > Cheers, Daniel
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
> 
> 
> 
> -- 
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Lenovo T410: Regression in coreboot 4.13?

[Daniel Kulesz via coreboot]

Hi folks,

I spent a long time trying to get coreboot 4.13 to work on a Lenovo T410, 
trying various configuration options etc. but it never worked (fan, keyboard 
LED and thinklight went on, screen stayed dark). I tried even the most basic 
config, but no luck.

I tried the same with coreboot 4.12 and this seems to work fine.

Unfortunately, this is not my laptop and the owner needs his laptop back asap, 
so I don't have the time to further debug this issue. Yet, I wanted to report 
this regression as I I am wondering if anyone else is running 4.13 on a T410 
with success?

Cheers, Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Flashing coreboot on T440p by just flashing the 4MB chip - how?

[Daniel Kulesz via coreboot]

Hi Nico,

thank you, this helped me a lot and I got coreboot running by just flashing the 
top 4MB to the smaller chip. Yet there are a few things I still don't 
understand:

- as the bios region spans both chips, how does this work when I only flash the 
bios region into one part of this region? I assumed some of the original bios 
would be missing, resulting in a brick.
- where is the firmware of the EC controller actually located? It's not 
mentioned in the ROM layout map.
- to my understanding, applying me_cleaner would mean I need to flash the 8MB 
chip as well. Can this be done internally once I have coreboot running or will 
the ifd lock in the descriptor (that was left untouched) block this access, so 
in the end I will need to disassemble the T440p to get physical access to the 
8MB chip?
- to take advantage of the space gained by applying me_cleaner, the descriptor 
would need to be reflashed as well, right? Can this be done internally as well?
- I tried to compile GRUB as payload first, but it didn't fit in the space so I 
had to go for SeaBIOS. Is there a way to get GRUB working without touching the 
8MB chip? I wonder why it doesn't fit into the 4 MB space of the smaller ... is 
the size of the CBFS region set correctly to the available maximum by default?

Again, thanks a lot! I will try to submit a merge request for the doc article 
about the T440p once I get a better understanding of this.

Cheers, Daniel




On Tue, 13 Oct 2020 22:18:23 +0200
Nico Huber  wrote:

> Hi Daniel,
> 
> On 13.10.20 21:59, Daniel Kulesz via coreboot wrote:
> > The build fails because I don't have the other proprietary parts 
> > (descriptor.bin, me.bin, gbe.bin).
> 
> you can simply omit them. If you don't tell that you have them (in your
> config), coreboot won't miss them.
> 
> > Or is this process meant the way that I should build coreboot without these 
> > parts and only flash the BIOS region, not touching them?
> 
> That's it. Generally, for any retrofit coreboot, they are already on
> the machine, so you never have to extract them. In case of the T440p,
> the BIOS region spans the end of the 8MiB and the whole 4MiB chip[1].
> Hence, you never need to deal with descriptor/gbe/me if you only flash
> the latter.
> 
> Remember to build coreboot for 12MiB and take the last 4MiB of the
> resulting `coreboot.rom` and always keep a backup ;)
> 
> Nico
> 
> [1] https://doc.coreboot.org/_images/flashlayout_Ivy_Bridge.svg
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Flashing coreboot on T440p by just flashing the 4MB chip - how?

[Daniel Kulesz via coreboot]

Hi folks,

I am trying to put coreboot on a T440p that runs the latest OEM Firmware from 
April 2020. According to the official coreboot documentation, it should be 
doable by just flashing the (easily accessible) 4MB chip. While I successfully 
extracted the OEM ROM from this 4 MB chip using an external programmer and 
obtained the mrc.bin as explained in coreboot's docs, I failed to build 
coreboot itself. The build fails because I don't have the other proprietary 
parts (descriptor.bin, me.bin, gbe.bin).

All reports I found extract the ROM from both the 4 MB and 8 MB chips, put them 
together, and then run ifdtool on it to obtain these parts. If I try running 
ifdtool on just the 4MB dump, I get the following:

~/coreboot/util/ifdtool$ ./ifdtool -x t440p_4mb.rom 
File t440p_4mb.rom is 4194304 bytes
Unknown descriptor version: 1

Also, I can't extract them using me_cleaner.

Are these parts supposed to be contained in coreboot's 3rdparty repos (where I 
can't find them)? Or do I need to disassemble the whole device to extract the 
ROM from the 8MB chip as well in order to obtain these parts using ifdtool? Or 
is this process meant the way that I should build coreboot without these parts 
and only flash the BIOS region, not touching them?

Thanks a lot in advance.

Cheers, Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Issue-Tracker: Unable to reply

[Daniel Kulesz via coreboot]

Hi,

I wanted to reply in the Redmine issue tracker to a comment posted by Patrick 
Georgi [1], however, it seems like I can only open new issues and edit my own 
issue as well but not comment or reply to comments. At least I don't see any 
button for that. Is this a general permission issue (regarding roles) or is 
this specific to my account (kuleszdl) there?

Cheers, Daniel


[1] https://ticket.coreboot.org/issues/49
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Need help with getting KGPE-D16 working.

[Daniel Kulesz via coreboot]

Hi Ragnaros,

to solve (some of) the hangs I highly recommend disabling the serial console 
completely as discussed here:

https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/GA3WYOUJYCJQ6M2RSRU5QRZH5XAEM623/#YYE4UUFDXGVXNBT27GXJW75ZCA25XUBF

Using 16 GB sticks did not work for me either, but I found a configuration that 
works if you use only some of them together with 8 GB slots resulting in at 
least 96 GB of fully working memory in a single-cpu configuration. This might 
also work with 192 GB in a dual-cpu configuration. See my posting here for 
details:

https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/A63PJCMN6AWXKQZWV4HGMFQSQXQAHHM5/

If you have only 16 GB sticks available, use the orange slots only or just a 
single DIMM in the first orange slot before going any further. It doesn't make 
sense to diagnose issues such a graphics output or non-booting payloads when 
you don't rule out inproperly working memory first.

Gfx initialization with a dedicated nvidia GPU and booting from NVMe works fine 
for me, although I'm not using 4.11 but an older version (master somewhere 
between 4.8 and 4.9). I just use a text-based ("legacy") graphics without 
splash and boot the kernel from there which then initializes the graphics 
properly and switches them to graphics mode. No issues with this so far.

Regarding the fans: If you run linux, you can control them in userland using a 
tool such as "fancontrol" if you don't want to control them by the BMC or don't 
have it installed. The fancontrole profile I created for this (attached) 
results in the following RPM and temperature levels at the moment in my 
(computer) case:

GPU core: +0.90 V  (min =  +0.90 V, max =  +0.90 V)
temp1:+60.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +105.0°C, hyst =  +5.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)

fam15h_power-pci-00c4
Adapter: PCI adapter
power1:   51.28 W  (crit = 114.49 W)

...

fan1: 596 RPM  (min =  329 RPM)
fan2: 584 RPM  (min =  329 RPM)
fan3:   0 RPM  (min =  329 RPM)  ALARM
fan4:   0 RPM  (min =  329 RPM)  ALARM
fan5: 585 RPM  (min =  329 RPM)
fan6: 696 RPM  (min =  329 RPM)
fan7:   0 RPM  (min =  329 RPM)  ALARM
fan8:   0 RPM  (min =  329 RPM)  ALARM
temp1:+68.2°C  (high = +70.0°C, hyst = +65.0°C)
   (crit = +85.0°C, hyst = +80.0°C)  sensor = thermal diode
temp7:+25.8°C  (high = +70.0°C, hyst = +65.0°C)
   (crit = +85.0°C, hyst = +80.0°C)  sensor = AMD AMDSI
temp8: +0.0°C  (high = +70.0°C, hyst = +65.0°C)
   (crit = +85.0°C, hyst = +80.0°C)  sensor = AMD AMDSI

...

k10temp-pci-00cb
Adapter: PCI adapter
temp1:+22.9°C  (high = +70.0°C)

Normally, my fans run at around 350-400 RPM in idle and are hardly hearable. 
The increased rotation levels are probably due to the fact that I didn't clean 
the dust filters for a while. If you use the profile you might need to adjust 
the devpath probably, but you can try to create your own with pwmconfig and 
then tweak the values. 

Cheers, Daniel


fancontrol
Description: Binary data
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] KGPE-D16: Working single-CPU configuration with 96 GB of RAM

[Daniel Kulesz via coreboot]

Hi folks,

albeit the board has been deprecated in coreboot 4.11, I wanted to contribute a 
working RAM setup for all who still use it. I managed to run a KGPE-D16 with a 
single CPU (Opteron 6380) and 96 GB of RAM and the following LRDIMMs:

orange slots: 4x Samsung 16 GB DDR3L reg ECC (M393B2G70BH0-YK0)
black slots: 4x Samsung 8 GB DDR3L reg ECC (M393B1K70DH0-YK0)

Using full 128 GB with the 16 GB modules resulted in ECC errors during 
memtester runs (and under heavy load). Also, I was not able to get a 
configuration with 96 GB using only 16 GB modules running - neither by the 
configuration described as problematic in the Wiki (leaving the slots next to 
the CPU empty) nor using the configuration desribed in the user manual (leaving 
the slots B1 and D1 empty.

I tested the "working so far" configuration with memtester (running aprox 10 
minutes) and by compiling AOSP for about one hour with 80 GB allocated to the 
VM where the compilation is running. No entries about ECC-recovered hardware 
errors and such in syslog so far (unline the previous run when I had 128 GB in 
the machine).

Btw.: For me, it would make sense to have a section in the documentation about 
boards that were previously supported in coreboot such as the KGPE-D16 that is 
currently missing there.

Cheers, Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Testing modernizing patches on ASUS KGPE-D16. (was Re: Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?)

[Daniel Kulesz via coreboot]

Hi folks,

is there a branch that has all the outstanding KGPE-D16 changes merged? I will 
be happy to test, but I feat I won't find the time to test all those fixes each 
in a separate branch. Also some specification of what tests need to be 
conducted would help.

The outstanding KGPE-D16 bugs on my personal list are boot failures that 
require to turn off/on AC and the power consumption issues in idle that forced 
me to pull out one of the CPU packages and its RAM. But as far as I understood 
these were not targeted in the recent changes but could be "accidentially" 
fixed (e.g. by removal of some old buggy code) - correct?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] lower memory performance with coreboot on KGPE-D16

[Daniel Kulesz via coreboot]

Hi Iru,

> I just found the memory performance on KGPE-D16 is lower when running with
> coreboot. I have two Opteron 6276 and 8 16GB DDR3-1600 RDIMM on all orange
> slots. I tested it with `hdparm -tT /dev/sda` and see the `Timing cached
> reads` result. With coreboot, this value is around 3000 MB/s, but with OEM
> firmware it can go to around 3600 MB/s. I think the disk cached read speed
> is related to memory performance.

Are you using DDR3L-RDIMMs? And did you check whether your memory really runs 
at 800 MHz? My experience is that coreboot sets the clock down to 667 MHz when 
running on 1.35V (low voltage), while the vendor bios seems to run modules at 
800 MHz in low voltage mode,  resulting in higher performance. According to 
Timothy, this is  "over the spec" and thus not set in coreboot by default (you 
can choose between 1.5V 800 MHz or 1.35V at 667 MHz - but may depend on the 
used modules).

You can check e.g. in dmidecode. Below is an example (serial number x'd out):

Handle 0x000E, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0006
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_D2
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 800 MHz
Manufacturer: Samsung
Serial Number: x
Asset Tag: Not Specified
Part Number: M393B1K70DH0-YK0  
Rank: 2
Configured Clock Speed: 800 MHz
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.5 V

Btw.: I am getting around 3700 MB/sec with hdparm -Tt on my /dev/sda 
(mechanical disk) and around 3840 MB/sec on /dev/nvme0n1 (PCIe M.2 SSD).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Daniel Kulesz via coreboot]

Thank you for your answers, Jason and Alberto.

While it's true that the hypercard is a PCIe 3.0 device, I did not see the 
reason yet why it would not operate in a PCIe 2.0 slot with lower throughput. 
And I am not sure but - is Intel VROC required to use all four M.2 slots?

Anyways, I am happy to report that I "resolved" the issue partially by getting 
rid of the GPU that occupies two slots, replacing it by one that occupies just 
1 slot. Then I installed the USB3 controller card next to it, resulting in the 
following setup:

1. (MIO): empty
2. GPU
3. USB3 controller card
4. Hypercard
5. Empty

This way, I have graphics, USB 3.0 and two M.2 slots working. In addition, I 
noticed that the system (without usb3) takes around 7-8W less in idle than with 
the previous gpu installed. That's a bit surprising as the old gpu was 
advertised to use only ~5.5W total while idle (but I wondered while it gets so 
hot, I thought this was due to it being installed so close to CPU0's huge 
heatsink). As I don't need that much GPU power anyways, the swap had at least a 
nice (unexpected) side-effect for me.

However, the fact that I still can use only two M.2 cards is somewhat 
disappointing. Since there are also other vendors of comparable PCIe quad-M.2 
cards, I welcome any reports (both positive and negative) from people who tried 
different m.2 quad card models in a KGPE-D16.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Daniel Kulesz via coreboot]

Hi folks,

maybe this is not really coreboot-related, but I am experiencing an issue with 
the KGPE-D16 that there seems to be no working constellation how the following 
three cards can be put into service:

- nvidia GPU (PCIe 3 x16, takes 1 slot but occupies two)
- ASUS hypercard (PCIe 3 x16, takes 1 slot, has four M.2 slot with PCIe x4 
each), see [1]
- USB3 controller card (PCIe x4, takes 1 slot)

No matter what I try, the hypercard is unable to detect more than two M.2 ssds. 
And only in the following config:

1 (MIO): empty
2: GPU
3: (GPU)
4: Hypercard
5: empty

When I put the USB3 card in 5, only one of the M.2 ssds on the hypercard is 
recognized. Therefore, I also tried swapping stuff in many combinations such as 
the following:

1: empty
2: Hypercard
3: empty
4: USB3
5: GPU

But no matter what I do, there seems to be now way to get all three cards 
working simulaneously. Even with JUST the hypercard and nothing else it will 
only detect two of the three M.2 cards inserted. :/

Seems like the vendor bios has the same issue. My plan now is to get a GPU that 
occupies only 1 slot and put the USB3 card next to it.

Any help and clarifying explanations on this topic are warmly welcome.

Cheers, Daniel


[1] https://www.asus.com/Motherboard-Accessory/HYPER-M-2-X16-CARD/

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] (libre) Add-on cards for getting higher SSD throughput on the KGPE-D16?

[Daniel Kulesz via coreboot]

On Fri, 2 Mar 2018 17:40:56 -0500
"taii...@gmx.com"  wrote:

> I concur with what tim said and I too recommend getting the much faster 
> TALOS 2 - the current board/cpu combo price is quite reasonable (only $2.5K)
> 

Yes, but KGPE-D16's PCIe v2 x4 should be enough for 2 GB/s which is more than 
current entry-level M.2 NVMe SSDs need. Since I have the KGPE-D16 already (and 
DDR4 reg ecc prices are very high), I'd like to max it out before upgrading.

> You might also be interested in this.
> http://www.openssd-project.org/wiki/The_OpenSSD_Project

Yes, I've heard of that but it does not seem to be anywhere near a 
production-ready state with available hardware, yet. For the meantime, I am 
okay with using closed-source drive firmware as it's sandboxed and its 
capabilities are controlled by open software/firmware. As far as I understood 
this is true for SATA drives, but I am not sure if the same accounts for NVMe 
drives as well. What kind of firmware does actually run on the NVMe controller 
and to which data/registers does it have access? Is there a substantial 
difference to SATA via AHCI?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] (libre) Add-on cards for getting higher SSD throughput on the KGPE-D16?

[Daniel Kulesz via coreboot]

Thank you, Timothy.

> > (2) get the PIKE 2008 card => will SATA3 work without non-free firmware?
> 
> No.
> 

Ok, too bad. I thought the non-free firmware would only be needed for the SAS 
part, but I assume the LSI controller handles both SAS and SATA.

> > (3) put in some PCIe SATA3 card => any recommended chips that respect 
> > freedom?
> 
> There are very few.  You can try some of the Marvell devices but you
> will still be limited by the host side bus as these old Opterons only
> support PCIe v2.
> 

Yes, I was aware of the limitation. As far as I understand, the PCIe v2 x16 
slot would allow for 8 GB/s - but that should be enough, even for a modern m.2 
SSD. I just ordered a PCIe v2 x16 device with an Asmedia chipset to give it a 
try - seems to be supported in Linux and costs just 7€ incl. shipping.

> > (4) get a m.2 SSD instead together with some PCIe adapter => the cards 
> > don't have a co-processor, right?
> 
> Yes, they do.  NVMe devices have an integrated proprietary controller to
> manage data storage / wear levelling.

> > (5) stay with SATA2 and live with the limited speed
> >
> > Any recommendations for a freedom-respecting choice?
> 
> To be blunt, even your hard disks have an integrated (and hackable!)
> proprietary controller.  I'd suggest going with m.2 and:
> 

Yes, but you could say this about any 2.5" SATA SSD/HDD as well. Important for 
me is that the firmware runs isolated (on the drive) and does not have access 
to the host. As far as I understood this is the actual concern regarding the 
PIKE cards, right?

I haven't made up my mind to go with the m.2 option yet, because (1) the ssd 
cards are way more expensive than 2,5" sata drives and (2)  was not sure what 
speed they can actually achieve with an adapter plugged to PCIe v2. Please 
correct me if I'm wrong, but, as far as I understood the firmware of the m.2 
cards has direct pcie bus access because there is no controller (such as the 
marvell or asmedia) inbetween - right? If so, that would be a third reason to 
go for the sata3 pcie card for me.

> Also, mandatory plug for Talos II here: these bottlenecks disappear on
> newer hardware and you don't have to accept the ME/PSP to get access to
> modern speeds.  The KGPE-D16 is the last and most powerful
> owner-controllable x86 machine, but it is definitely showing its age in
> some areas.
> 

I agree, SATA 2 and PCIe v2 are really getting old these days. Even if the G34 
CPUs are somewhat powerful, that doesn't help much if the peripherials slow 
down the system.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] (libre) Add-on cards for getting higher SSD throughput on the KGPE-D16?

[Daniel Kulesz via coreboot]

Hi,

after plugging a rather newish 2,5 SATA SSD to my KGPE-D16, I realized that the 
regular SATA ports connected to the SP5100 on this board can only handle SATA2, 
limiting transfer speeds to max. 300 MB/s. I thought about various options what 
I could do now:

(1) try to get the PIKE 9230 card => but does come with a co-processor and 
non-free firmware like the SAS Pike cards? Seems almost impossible to get one 
though
(2) get the PIKE 2008 card => will SATA3 work without non-free firmware?
(3) put in some PCIe SATA3 card => any recommended chips that respect freedom?
(4) get a m.2 SSD instead together with some PCIe adapter => the cards don't 
have a co-processor, right?
(5) stay with SATA2 and live with the limited speed

Any recommendations for a freedom-respecting choice?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [off topic] Opteron CPU missing chips on the bottom

[Daniel Kulesz via coreboot]

Hi Taiidan,

> I purchased a used g34 opteron off of fleabay (sold as working with no 
> mention of this) and I noticed that it is missing some of the bits on 
> the bottom and that most of them are crooked, I haven't tried it in my 
> system yet and I am wondering should return it? or if there isn't any 
> much risk of it damaging my (expensive kgpe-d16) motherboard and I 
> should see if it works?
> I got it for half the usual priceguess I should have asked for photos.
> 
> I noticed many CPU's sold on ebay have this issue (in those cases they 
> mentioned it) but I can't understand how it happens, for instance I 
> noticed a 6386 for sale where they mentioned that it was missing a few 
> and because of that it doesn't work in a dual socket configuration.

I have a few Opterons which have this issue and it seems to pretty common. I 
assume that some "expert" put the CPU on a table before mounting it, and they 
move it one the table - can't imaging how people manage to chop off the chips 
otherwise. While some of these damaged CPUs seem to work just fine, I had 
several which do not recognize more than 1-2 pcs of memory and, thus, would not 
recommend buying one of these.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] FOSDEM 2018 beverage round?

[Daniel Kulesz via coreboot]

Hi folks,

I've read about the "discussion over beers or another prefered beverage" at 
FOSDEM 2018 a couple of days ago here on this list. Since I definitely plan to 
attend FOSDEM this year again (I got my talk in the testing and automation 
devroom accepted), I was wondering what the requirements for joining this 
bevereage round are and if there are already any concrete plans for that.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Daniel Kulesz via coreboot]

Hi,

afaik, Intel did not publish any info about the affectedness of the Core2Duo 
generation to date. I tried the Spectre-Demos for variant 1 on the X200 [1], 
and it seems unaffected while e.g. the Opterons on the KGPE-D16 are just as 
affected as all those Intel CPUs. Nevertheless, this should be fixable by OS 
updates only so nothing to worry about. It's only that ATM afaik only 
CentOS/RHEL ships updates for v1, as they have not been integrated into the 
Linux kernel yet. Regarding v3, there is not much to worry about either since 
it's also fixable by the KPTI-Kernel patch most distros should already have 
included by now (the one that is known to cause performance impact).

The remaining and most important question is regarding v2, where the situation 
is unclear. And no, Qubes will not protect you from v2 because it allows the 
"isolated" stuff you run in your VM to escape this isolation and e.g. read the 
Host's memory - i.e. Dom0 in Qubes-speak.

Regarding the 2nd and 3rd core-i-gen: Since Lenovo announced to release updates 
for the T530, and taking into account that some early "low-end" versions of the 
T530 had a 2nd-gen core-i CPU, there is (very) slight hope Intel will provide 
microcode updates for this generation. However, I haven't seen any other vendor 
than Lenovo making announcements about devices from these generations, so I 
have some doubt that Lenovo will provide updates at all.

Regarding the impact: Not having fixes for v2 does not render the machine 
completely insecure, but you basically know for sure that you can't expect 
getting any secure isolation by running untrusted code in VMs. However, since 
the X200 has no IOMMU, I am not sure to which degree the level of isolation 
provided before was secure anyways.

Cheers, Daniel

[1] https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [KGPE-D16] No video output with Ati x600se GPU

[Daniel Kulesz via coreboot]

Hi,

> I'm having issues to use an Ati x600se 128mb GPU (OEM DELL) with my KGPE-D16.
> With ASUS BIOS, the card works fine (either in first or second pcie-x16 slot)
> With coreboot, no video output. The board still boots but the card isn't 
> detected at all. (either in first or second pcie-x16 slot)
> I don't know what is the issue since I was using a GTX660 before without 
> issue.

It seems like you are not using SeaBIOS. Normally, Seabios initializes PCI 
devices. Are you sure you are using the same coreboot configuration that worked 
fine for your GTX660 with this ATI card or did you rebuild/reflash coreboot 
inbetween?

> Do I need to embed the VGA rom in cbfs for this card ?

No, afaik the VGA rom is only needed for native gfx init on (some) devices with 
embedded graphics but not for add-on pci(e) cards.


Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: More power drain experiments with coreboot vs. vendor bios

[Daniel Kulesz via coreboot]

Hi all,

I did some more testing with the Opteron CPUs, and it seems there is some 
defect in coreboot as it does not report the state P5. I attached the output of 
"cpupower frequency-info" which I obtained on a 1x6220/64G configuration 
running coreboot and running the vendor bios.

I also did some wattage measures using a new Brennenstuhl PM 231 watt meter for 
my whole system. It seems like coreboot still has some flaw in this regards, as 
I was able to reproduce the high power drain in idle with the 6220 processor as 
well.

With the vendor bios:

2x6276, 128G => 90W idle, ~350W load
1x6276, 64G => 66W idle, 165W load
1x6220, 64G => 70W idle, 157W

With coreboot:

1x6220, 64G => 101W idle, 165W load

One thing I noticed is that when running coreboot the power state P5 seems 
absent, while it's present when running the vendor bios. Could this be the 
cause for the high power drain in idle? (even if I am not sure if the system 
enters these states at all). Please see the logs attached.

If you compare the config of 1x6276 vs. 2x6276 it seems like there is just a 
difference of 24W in idle and I am sure the memory also draws some power. 
Therefore, I wonder how big the improvement could be by replacing the 
6200-series CPUs by one of the power-optimized "warsaw" modules (6338P or 
6370P). I could not find any figures about idle power consumption with these 
CPUs so I welcome any reports from others. I don't really need all that CPU 
power but I would really like to use all of my 128G memory - which is why I am 
looking for the most power efficient CPU for the KGPE-D16.

Cheers, Daniel
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 5.0 us
  hardware limits: 1.40 GHz - 3.00 GHz
  available frequency steps:  3.00 GHz, 2.60 GHz, 2.20 GHz, 1.80 GHz, 1.40 GHz
  available cpufreq governors: userspace powersave conservative ondemand 
performance schedutil
  current policy: frequency should be within 1.40 GHz and 3.00 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency: 1.40 GHz (asserted by call to hardware)
  boost state support:
Supported: yes
Active: yes
Boost States: 2
Total States: 7
Pstate-Pb0: 3600MHz (boost state)
Pstate-Pb1: 3300MHz (boost state)
Pstate-P0:  3000MHz
Pstate-P1:  2600MHz
Pstate-P2:  2200MHz
Pstate-P3:  1800MHz
Pstate-P4:  1400MHz

analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 5.0 us
  hardware limits: 1.40 GHz - 3.00 GHz
  available frequency steps:  3.00 GHz, 2.60 GHz, 2.20 GHz, 1.80 GHz, 1.40 GHz
  available cpufreq governors: userspace powersave conservative ondemand 
performance schedutil
  current policy: frequency should be within 1.40 GHz and 3.00 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency: 1.40 GHz (asserted by call to hardware)
  boost state support:
Supported: yes
Active: yes
Boost States: 2
Total States: 8
Pstate-Pb0: 3600MHz (boost state)
Pstate-Pb1: 3300MHz (boost state)
Pstate-P0:  3000MHz
Pstate-P1:  2600MHz
Pstate-P2:  2200MHz
Pstate-P3:  1800MHz
Pstate-P4:  1400MHz
Pstate-P5:  500MHz

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] X200s: Are the WXGA+ (1440x900) screens supported?

[Daniel Kulesz via coreboot]

Hi Persmule,

sounds great, thank you!

Cheers, Daniel

On Sun, 21 May 2017 18:44:34 +0800
Persmule <persm...@gmail.com> wrote:

> Hi Daniel,
> 
> Briefly saying, yes. This is a log generated on an x200s with wxga+
> screen, and native graphic init works with no problem:
> https://review.coreboot.org/cgit/board-status.git/tree/lenovo/x200/4.6-122-ga7092750b2/2017-05-14T03_08_55Z
> 
> Persmule
> 
> 在 2017年05月21日 18:20, Daniel Kulesz via coreboot 写道:
> > Hi,
> >
> > is someone running a (recent) version of coreboot on a X200s with the 
> > 1440x900 screen? If yes: Does native graphics init work?
> >
> > Cheers, Daniel
> >
> 
> 

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] X200s: Are the WXGA+ (1440x900) screens supported?

[Daniel Kulesz via coreboot]

Hi,

is someone running a (recent) version of coreboot on a X200s with the 1440x900 
screen? If yes: Does native graphics init work?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16

[Daniel Kulesz via coreboot]

Hi BogDan,

> Run *dmidecode* and search for "Interleaved Data Depth" to check if
> the ram is running in quadchnnel mode you (check
> https://unix.stackexchange.com/questions/215206/detect-number-of-ram-channels
> for more info on this matter). In your case you should have two
> "Interleaved Data Depth: 4"

Unfortunately, it seems like coreboot does not supply this in dmidecode (I X'd 
out the serial numbers):

Handle 0x0006, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 256 GB
Error Information Handle: Not Provided
Number Of Devices: 16

Handle 0x0007, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0006
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_A1
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 667 MHz
Manufacturer: Samsung
Serial Number: 
Asset Tag: Not Specified
Part Number: M393B1K70DH0-YK0  
Rank: 2
Configured Clock Speed: 667 MHz
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.35 V

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Recommended memory for coreboot + ASUS KGPE-D16

[Daniel Kulesz via coreboot]

Hi Bogdan,

I am running my KGPE-D16 with 2x6276 and 16 of these 8GB Samsung RDIMMs:

M393B1K70DH0-YK0

They work fine in coreboot. If you want to run them at 1600MHz, you need to 
raise the voltage to 1.5V even if the vendor bios clocks them at 1600MHz with 
1.35V. They work fine in this setting as well, although this is out-of-spec 
according to Timothy Pearson. I have no idea how to check if they run in 
quadchannel but appreciate any hints. You can find more info on this thread:

https://mail.coreboot.org/pipermail/coreboot/2017-February/083151.html

Please be aware that power consumption in idle on the KGPE-D16 is still a major 
issue with coreboot (~150W with coreboot while ~80W with vendor bios in 
dual-cpu config):

https://mail.coreboot.org/pipermail/coreboot/2017-February/083195.html

Also, if running the board populated with DIMMs in all slots the best bootup 
time for coreboot I could get was around 30s:

https://mail.coreboot.org/pipermail/coreboot/2017-March/083595.html

On the contrary, with just 2 UDIMMs, it booted up almost instantly. Please 
consider this as well when making the decision. 

Yet, I am happy to welcome more KGPE-D16 users and share experience.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Trouble initializing gfx on X200(s)

[Daniel Kulesz via coreboot]

Hi folks,

using the latest coreboot master, I tried several combinations and various 
config options but I did not succeed to initialize gfx on a X200s so that 
typical graphical boots work such as:

- Ubuntu CD Installer Splashscreen
- Windows 7 Installer
- Windows 10 Installer
- ...

I tried with both native gfx init and the vga blob using various resolutions, 
fb options etc. but no success so far. :/ Of course, graphics initialization 
works fine in Linux.

One thing I noticed: When using the vga blob, Seabios gives only a blinking 
cursor while GRUB works fine. When loading Seabios as a payload from GRUB (was 
hard to get that done!), the blinking cursor issue does not occur. However, the 
above mentioned operating system installers still fail to boot

Any ideas? Or did someone ever get one of those graphical things booted on a 
X200 with Coreboot?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

On Thu, 13 Apr 2017 17:17:03 -0500
Timothy Pearson  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> > 
> > Unfortunately, I had the option already enabled when using the 
> > "config-unreliable" in my initial posting. So it looks like this setting is 
> > not effective in stopping the hangs.
> > 
> > Cheers, Daniel
> 
> After further external analysis once the KGPE-D16 was placed on our test
> stand for OpenBMC development, the intermittent hang resulting in hard
> system lockup (requiring a full standby power cycle) appears to be fixed
> in this patch series on Gerrit:
> 
> https://review.coreboot.org/#/c/19280/
> 
> Can you please test and confirm?
> 
> Thanks!
> 

Sure thing: I applied the patch on top of current coreboot-master and compiled 
the ROM using the "config-unreliable" from my initial posting.  Then I did a 
series of five warm reboots and watched the output on the serial console. 
Result: No more hangs! (Previously, it took like 20 attempts to get even one 
successful boot)

Great job, and many thanks!

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Where to buy the KCMA-D8? *brand new*

[Daniel Kulesz via coreboot]

>Does anyone know? I have checked everywhere
>I can't find the accessories for the board family either (TPM etc)

There is shop in Germany that sells it (according to the website, they have 6 
pcs left in stock):

https://direkt.jacob.de/Mainboards/divers/ASUS-KCMA-D8-90-MSVD91-G0UAY00Z-artnr-851627.html?ref=103

It was easy to find using a price comparison machine:

https://geizhals.de/asus-kcma-d8-90-msvd91-g0uay00z-a592717.html

If you are looking for a cheap board for a "high-end" router without the need 
for IOMMU I would recommend trying the Supermicro H8DME (it doesn't have a 
recent board_status though). You can find them pretty cheap on Ebay (used as 
well as new), however, you need to get DDR2 memory for them (which is even 
cheaper than DDR2 nowadays).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

Hi Timothy,

On Tue, 21 Mar 2017 10:32:46 -0500
Timothy Pearson <tpear...@raptorengineering.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 03/12/2017 07:58 PM, Daniel Kulesz via coreboot wrote:
> > Hi folks,
> > 
> > as reported, the KGPE-D16 was mostly unusable for me in my 2x Opteron 6276 
> > + 128 GB RAM configuration as it simply did not boot reliably - even with 
> > serial console debugging disabled completely. After experimenting with 
> > various config options and comparing my best "known half-working" config 
> > from earlier attempts, I finally found out that the hangs were related to 
> > the configuration and not to a specific coreboot version.
> > 
> > I attached the configs showing my current "reliable" setup (that survived 
> > 10 cold and 10 warm reboots without a single hangup!) and one of the 
> > previous "unreliable" setups which often needed several cold boots to 
> > successfully boot up once. There are several options which might be 
> > reposible for these hangs. Personally, I believe what helps is to 
> > completely disable the serial console and not just disable debugging to 
> > serial console.
> > 
> > As asked for previously, I also took some boot time measures from pressing 
> > the power button to "grub beep" in my 128 GB RAM configuration. Here they 
> > are:
> > 
> > vendor bios, unoptimized with iPXE setup: 59s
> > coreboot, current with the "reliable" config: 73s
> > coreboot, Jan 17 2017, with the "reliable" config: 91s
> > coreboot, current with the "unreliable" config: 131s
> > 
> > I assume that further investigation of the root cause could help to locate 
> > the real bug (like e.g. the setup of the serial console). Yet, I hope that 
> > having a "working-good" config will be useful for people suffering from the 
> > same issue as I did. For me, this setup is still far from being what I 
> > expected (memory is clocked too low and idle power consumption is 170W 
> > instead of 90W), but at least the machine boots up reliably every time now.
> > 
> > Cheers, Daniel
> > 
> 
> Could you verify something for me?  In internal tests it looks like
> setting CONFIG_SQUELCH_EARLY_SMP resolves the hang with the serial
> console enabled, but I need secondary verification of this due to the
> intermittent nature of the problem.  You seem to be hardest hit by the
> bug so your system should make a good test case.
> 
> Thanks!
> 

Unfortunately, I had the option already enabled when using the 
"config-unreliable" in my initial posting. So it looks like this setting is not 
effective in stopping the hangs.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Daniel Kulesz via coreboot]

On Wed, 15 Mar 2017 16:17:31 -0500
Timothy Pearson <tpear...@raptorengineering.com> wrote:

> On 03/15/2017 04:09 PM, Daniel Kulesz via coreboot wrote:
> > Hi,
> > 
> > I wanted to try caching of the MRC training data. As described in Timothy's 
> > post, I commented the following line:
> > 
> >> allow_config_restore = 0;
> > 
> > However, I was not able to measure any effects regarding boot time. Does 
> > this setting only work with cbfs enabled? And if so, is it necessary to set 
> > additionally any cbfs variables?
> > 
> > Cheers, Daniel
> 
> You will need NVRAM enabled for this setting to work.  Additionally,
> there is some instability when this line is uncommented; when I have
> some free time available I'll take another look at why.

Many thanks - this did the trick! Boot time decreased from 71s to 30s now. 
Finally, coreboot boots up twice as fast as the vendor bios on the KGPE-D16!

@Timothy: Regarding the mentioned instability: Have you tested for its presence 
after we applied this "revert fix" for the MCT failures? I've been running 
"memtester 10G" + "stress-ng --cpu 0" for around 20 minutes now but could not 
observe any failures, instabilities or dmesg entries so far.

@Paul: Have you tried this setting as well? If yes - would you like to share 
your experience?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Daniel Kulesz via coreboot]

Hi,

I wanted to try caching of the MRC training data. As described in Timothy's 
post, I commented the following line:

> allow_config_restore = 0;

However, I was not able to measure any effects regarding boot time. Does this 
setting only work with cbfs enabled? And if so, is it necessary to set 
additionally any cbfs variables?

Cheers, Daniel

P.S.
Hope this time I've set the Reply-To header correctly.




> On 03/02/2017 02:17 PM, Paul Menzel wrote:
> > Dear Arthur, dear Timothy,
> > 
> > 
> > Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson:
> >> On 03/02/2017 01:30 PM, Arthur Heymans wrote:
> >>> Paul Menzel writes:
> >>>
>  I think most of the time is spent in RAM initialization.
> 
> 1. Do board owners with similar amount of memory (independent of the
>    board) have similar numbers?
> 2. What are the ways to improve that? Is it possible? For example, can
>    the modules be probed in parallel (if that isn?t done already)?
> 
> >>>
> >>> I'm not the right person to answer this since I don't know this
> >>> code/hardware that well, but on modern Intel hardware native code uses
> >>> the MRC cache to store dram training results and restore those on
> >>> next boots (and resume from suspend) if no change in dimm configuration
> >>> was detected.
> >>>
> >>> Maybe something like this could also be applied here (or maybe it's 
> >>> already
> >>> the case since it includes code to access spi flash)?
> >>
> >> Yes, this is already implemented as an option, and it does a fairly
> >> decent job of reducing training overhead to almost nothing,
> > 
> > Interesting. What option is that?
> > 
> > Also, besides the file `s3nv` I don?t see anything else in CBFS. Where
> > is the training data cached?
> 
> That's it.  The cache is mandatory for S3 resume, and optional at boot.
> 
> That being said, the pathways are present but are deactivated due to
> historical instability and are not tied in to an nvram variable at this
> time.  If you want to test, you'll need to edit the source file
> "src/northbridge/amd/amdmct/mct_ddr3/mct_d.c"; near line 2730 you'll see
> a FIXME comment and this line:
> 
> allow_config_restore = 0;
> 
> Comment that line out and recompile to test.  I strongly suggest running
> memtest across multiple warm and cold boots (and reboots) before
> determining the functionality is stable enough for use.



-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: Most severe hang failure sorted out + boot time measures

[Daniel Kulesz via coreboot]

Hi folks,

as reported, the KGPE-D16 was mostly unusable for me in my 2x Opteron 6276 + 
128 GB RAM configuration as it simply did not boot reliably - even with serial 
console debugging disabled completely. After experimenting with various config 
options and comparing my best "known half-working" config from earlier 
attempts, I finally found out that the hangs were related to the configuration 
and not to a specific coreboot version.

I attached the configs showing my current "reliable" setup (that survived 10 
cold and 10 warm reboots without a single hangup!) and one of the previous 
"unreliable" setups which often needed several cold boots to successfully boot 
up once. There are several options which might be reposible for these hangs. 
Personally, I believe what helps is to completely disable the serial console 
and not just disable debugging to serial console.

As asked for previously, I also took some boot time measures from pressing the 
power button to "grub beep" in my 128 GB RAM configuration. Here they are:

vendor bios, unoptimized with iPXE setup: 59s
coreboot, current with the "reliable" config: 73s
coreboot, Jan 17 2017, with the "reliable" config: 91s
coreboot, current with the "unreliable" config: 131s

I assume that further investigation of the root cause could help to locate the 
real bug (like e.g. the setup of the serial console). Yet, I hope that having a 
"working-good" config will be useful for people suffering from the same issue 
as I did. For me, this setup is still far from being what I expected (memory is 
clocked too low and idle power consumption is 170W instead of 90W), but at 
least the machine boots up reliably every time now.

Cheers, Daniel


config-reliable
Description: Binary data


config-unreliable
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] kfsn4-dre: Tested RAM configurations?

[Daniel Kulesz via coreboot]

Hi all,

the Wiki page for the kfsn4-dre is somewhat incomplete. It mentions that

"K8 processors currently require specific RAM configurations to work correctly. 
"

However, it is not stated which specific RAM configurations have been tested 
successfully so far.

Furthermore, vendor manual and HCL mention that the board supports only RAM 
modules of maximum 4 GB each. Is this a chipset limitation? If no, is someone 
running this board successfully with 8GB sticks? I would welcome a HCL list of 
tested configurations like the one for the KGPE-D16.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to improve the boot time of the Asus KGPE-D16?

[Daniel Kulesz via coreboot]

Hi Paul,

> 
> I think most of the time is spent in RAM initialization.
> 
>1. Do board owners with similar amount of memory (independent of the
>   board) have similar numbers?
>2. What are the ways to improve that? Is it possible? For example, can
>   the modules be probed in parallel (if that isn?t done already)?
> 

Regarding 1: I am running 128GB in 8GB modules (LRDIMMs) and experiencing a 
similar issue. With just two UDIMMs, the boot times are *much* faster. Also, 
the vendor BIOS is faster from the time you press the poweron button to the 
time the monitor gets a signal.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: More insights on the PCI hang failure

[Daniel Kulesz via coreboot]

Hi folks,

as we know, the KGPE-D16 is likely to hang during PCI init, especially if the 
serial console is enabled (Timothy mentioned that he did not observe failures 
with the debug level of the console lowered - however, for me this did not 
work). Typical symptoms look like the following:

ERROR: PNP: 002e.b 70 irq size: 0x01 not assigned

After discussing the issue with Timothy and doing a (huge) number of 
experiments in different settings I am of the opinion that the issue *does* 
seem to be memory/clock related. I tried various memory configurations and 
found some interesting correlations between memory configuration and the rate 
of failures. Also, I found another trigger which makes the hang *much* more 
likely.

For testing, I used the current coreboot master with the proposed revert which 
made the MC4 errors go away. After some experimenting, I found two settings 
which made the PCI-hangs go away:

1. Setting minimum memory voltage to 1.5V (probably unrelated)
2. Setting maximum memory clock down to 400 MHz (DDR3-800 instead of DDR3-1600)

With this setting, the number of PCI hangs went considerably down on a number 
of different configurations (all using two Opteron 6276 CPUs). The numbers are 
(#hangs / #boot attempts):

1xCK0 (in slot A2): warm (0/8), cold (0/3) => no failures!
1xYK0 (in slot A2): warm (0/6), cold (0/3) => no failures!
8xYK0 (in all orange slots): warm (1/8), cold (1/5) => rare
16xYK0 (in all slots): warm (3/8), cold (1/5) => more likely

Specs of the memory modules (all from Samsung):

CK0: 8GB DDR3-1600, 1.5V
YK0: 8GB DDR3L-1600, 1.35V

However, there is one more and quite severe issue: If I set the following 
option, I am get a hang in like 70% of the boot attempts:

Chipset => Enable PCI-E MMCONFIG Support

I wouldn't care too much about leaving this disabled. Unfortunately, I am 
getting a "force reboot" of the Kernel each time it tries to initialize the 
nouveau driver. Not sure if this is really related to this option or the fact 
that I'm running the RDIMMs at such low settings, but we'll have to find out.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi,

> > after a lengthy bisection run I was able to nail down the commit which is 
> > causing the MC4 errors in the configurations I tested. I reverted the 
> > commit on top of current master, and now my KGPE-D16 fully works without 
> > MC4 errors in both 1-CPU-package und 2-CPU-package configurations - that 
> > is, with all 16 memory slots populated with the 8GB DDR3L Samsung RDIMMs 
> > (PC12800 variant) mentioned in my initial post.
> 
> Thank you for working on that bisect, and for isolating the exact commit
> causing the problem!
> 
> However, we are going to need additional input from other owners of the
> KGPE-D16 to verify that a simple revert does not break support for the
> DIMMs installed in their machines.  In particular, I am interested in
> test reports from those with Kingston RDIMMs since they seemed to be
> among the most finicky.
> 

I have some more DIMMs I could test with if this would help:

- 2x Samsung 2GB 8500R
- 6x Crucial Ballistix Sport (non-RDIMMs, 4 of them have issues in another 
vendor bios running at the clock specified in the SPD)

> > However, the issue with memory clock (being reported at) 667MHz in 
> > dmidecode still remains.
> 
> Can you please send over a debug log at SPEW level showing the romstage
> boot process for 4 DIMMs?  The only log I have right now is for 8.
> 

Yep, will do so!

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

after a lengthy bisection run I was able to nail down the commit which is 
causing the MC4 errors in the configurations I tested. I reverted the commit on 
top of current master, and now my KGPE-D16 fully works without MC4 errors in 
both 1-CPU-package und 2-CPU-package configurations - that is, with all 16 
memory slots populated with the 8GB DDR3L Samsung RDIMMs (PC12800 variant) 
mentioned in my initial post.

However, the issue with memory clock (being reported at) 667MHz in dmidecode 
still remains.

I submitted a request for reverting the causing commit [1].

Cheers, Daniel

[1] https://review.coreboot.org/#/c/18369/

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

here's a short update regarding the beforementioned DDR3L Samsung memory sticks 
on the KGPE-D16 running coreboot.

Thanks to help and hints from Timothy, I experimented with different cpu/memory 
configurations and have done some stress and memory testing. So far, I have a 
few interesting findings to report for a 1-CPU-package configuration (using 
Opteron 6276):

(1) When running coreboot master with 4 DIMMs (in orange slots), the DIMMs are 
reported in dmidecode to be running at 800MHz and no ECC errors show up in 
dmesg during memtester runs. Same goes for the vendor bios.
(2) When running coreboot master with 8 DIMMs, the DIMMs are reported in 
demidecode to be running at 667 MHz and MC4 errors show up in dmesg during 
memtester runs.
(3) When running the same as in (2) but with the *vendor BIOS*, dmidecode 
reports 800MHz and memtester runs without MC4 errors.
(4) When running the same as in (2) but with *Coreboot 4.3*, dmidecode reports 
667MHz but memtester runs *without* MC4 errors as well.

It is still on my list to validate (using benchmarks) whether dmidecode just 
reports non-sense or if the DIMMs really run at only 667MHz. However, the issue 
with the MC4 errors is much more severe and likely to be a regression between 
Coreboot 4.3 and the current master version. It will require further bisecting 
to identify the cause.

@Other KGPE-D16 users: Does dmidecode in coreboot report your memory sticks to 
be running at 800MHz (provided you have PC12800 ones)? And are seeing MC4 
failures when running memtester? (For me, it happens at stage 2 with the 
"random testing" - usually after less than 7 minutes after starting the test 
and even if I just use 10G of memory for testing).

I also tested using two cpu packages and other memory populations, but as 
Timothy has obligations regarding the proper dimension of my PSU, it makes more 
sense for me to test in 1-CPU-configuration first to find the cause of these 
MC4 errors in coreboot before proceeding further.

Cheers, Daniel



Btw.: I had some "false negative" kernel oopses when running stress-ng with all 
tests enabled on both vendor bios and coreboot. Seems to be a known software 
issue (Ubuntu bug 1654073).

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] KGPE-D16: Excessive power consumption in idle

[Daniel Kulesz via coreboot]

On Fri, 10 Feb 2017 00:37:57 -0500
"taii...@gmx.com" <taii...@gmx.com> wrote:

> On 02/09/2017 06:46 PM, Daniel Kulesz via coreboot wrote:
> 
> > Hi,
> >
> > I just compiled and flashed the lastest master on my KGPE-D16 with pretty 
> > much the default config. My board has only one of the CPU sockets populated 
> > with an Opteron 6276. Things seem to work fine so far, except the power 
> > consumption. The "sensors" command reports a CPU power consumption of about 
> > ~85W (!) in idle:
> >
> > ---
> > k10temp-pci-00cb
> > Adapter: PCI adapter
> > temp1:+21.2°C  (high = +70.0°C)
> >
> > fam15h_power-pci-00c4
> > Adapter: PCI adapter
> > power1:   85.13 W  (crit = 115.11 W)
> >
> > nouveau-pci-0500
> > Adapter: PCI adapter
> > GPU core: +1.01 V  (min =  +0.60 V, max =  +1.20 V)
> > fan1:   0 RPM
> > temp1:+37.0°C  (high = +95.0°C, hyst =  +3.0°C)
> > (crit = +105.0°C, hyst =  +5.0°C)
> > (emerg = +135.0°C, hyst =  +5.0°C)
> >
> > k10temp-pci-00c3
> > Adapter: PCI adapter
> > temp1:+24.1°C  (high = +70.0°C)
> > ---
> >
> > With the vendor bios, the power consumption reported by "sensors" was just 
> > about the half - around 43W. I measured the consumption also on the power 
> > socket, and the whole systems seems to draw around 91W in idle (which is 
> > strange, since the GPU + hard drives + fans certainly don't take only 6W, 
> > but yeah...). Anyways, with the vendor bios, the power consumption of the 
> > whole system was around 60W (tested with a different power supply, but as a 
> > rough measure I guess this is representative).
> >
> > In coreboot's menuconfig, I can't select any power saving options or such 
> > as it was possible for other boards, which leaves me a bit puzzled.
> >
> > Anyone having simular issues?
> >
> > Cheers, Daniel
> >
> I am not.

Thanks. May I ask which CPU you are using?

> What does "cpufrequency monitor" report?

Here's the output of "cpufreq-info":

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpuf...@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:0.80%, 2.10 GHz:0.46%, 1.80 GHz:0.70%, 1.60 
GHz:1.68%, 1.40 GHz:96.37%  (736)
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:0.54%, 2.10 GHz:0.08%, 1.80 GHz:0.29%, 1.60 
GHz:3.19%, 1.40 GHz:95.91%  (223)
analyzing CPU 2:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 GHz, 1.60 GHz, 1.40 GHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, 
performance, schedutil
  current policy: frequency should be within 1.40 GHz and 2.30 GHz.
  The governor "ondemand" may decide which speed to use
  within this range.
  current CPU frequency is 1.40 GHz.
  cpufreq stats: 2.30 GHz:0.45%, 2.10 GHz:0.18%, 1.80 GHz:1.01%, 1.60 
GHz:2.10%, 1.40 GHz:96.25%  (445)
analyzing CPU 3:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 5.0 us.
  hardware limits: 1.40 GHz - 2.30 GHz
  available frequency steps: 2.30 GHz, 2.10 GHz, 1.80 G

Re: [coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

To answer my question myself: It works partially.

> 1.) Samsung M393B1K70DH0-YK0
> 
> Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank, x4 • Modules: 1x 
> 8GB • JEDEC: PC3L-12800R • Voltage: 1.35V
> 

I got 8 of these working with one CPU package on the KGPE-D16 with one of the 
latest Coreboot master versions:

Version: 4.5-963-gf57a768

However, the experience was not very good because I did not fit all of them at 
once and started with testing "partical" configurations with just two or four 
modules inserted. In these cases, raminit succeeded but when detecting the PCI 
devices the system hang up - especially when placing 4 modules in the orange 
slots. Also, with coreboot-4.5, I only managed to get four modules working when 
placing them in the slots most far away from CPU0 (two orange, two black).

Apart from that, the configured clock speed seems too low to me (the vendor 
bios runs the modules at 800 MHz instead of 667 MHz):

Handle 0x0007, DMI type 17, 40 bytes
Memory Device
Array Handle: 0x0006
Error Information Handle: Not Provided
Total Width: 72 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: None
Locator: NODE 0 DIMM_A1
Bank Locator: Not Specified
Type: DDR3
Type Detail: Synchronous Registered (Buffered)
Speed: 667 MHz
Manufacturer: Samsung
Serial Number: xxx
Asset Tag: Not Specified
Part Number: M393B1K70DH0-YK0  
Rank: 2
Configured Clock Speed: 667 MHz
Minimum Voltage: 1.35 V
Maximum Voltage: 1.5 V
Configured Voltage: 1.35 V

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16: Excessive power consumption in idle

[Daniel Kulesz via coreboot]

Hi,

I just compiled and flashed the lastest master on my KGPE-D16 with pretty much 
the default config. My board has only one of the CPU sockets populated with an 
Opteron 6276. Things seem to work fine so far, except the power consumption. 
The "sensors" command reports a CPU power consumption of about ~85W (!) in idle:

---
k10temp-pci-00cb
Adapter: PCI adapter
temp1:+21.2°C  (high = +70.0°C)

fam15h_power-pci-00c4
Adapter: PCI adapter
power1:   85.13 W  (crit = 115.11 W)

nouveau-pci-0500
Adapter: PCI adapter
GPU core: +1.01 V  (min =  +0.60 V, max =  +1.20 V)
fan1:   0 RPM
temp1:+37.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +105.0°C, hyst =  +5.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1:+24.1°C  (high = +70.0°C)
---

With the vendor bios, the power consumption reported by "sensors" was just 
about the half - around 43W. I measured the consumption also on the power 
socket, and the whole systems seems to draw around 91W in idle (which is 
strange, since the GPU + hard drives + fans certainly don't take only 6W, but 
yeah...). Anyways, with the vendor bios, the power consumption of the whole 
system was around 60W (tested with a different power supply, but as a rough 
measure I guess this is representative).

In coreboot's menuconfig, I can't select any power saving options or such as it 
was possible for other boards, which leaves me a bit puzzled.

Anyone having simular issues?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: "Freedom level" field for boards

[Daniel Kulesz via coreboot]

 supported by coreboot
Message-Id: <20170206030901.a2ac00bcd93e316782a3e...@googlemail.com>
X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Timothy,

> I have taken much of the feedback received into account, and revised the
> freedom level categories at
> https://www.coreboot.org/Board_freedom_levels somewhat.  Specifically,
> the "Pwned" category is now factually stated as "Vendor Controlled", and
> the EC exception in the Silver category was removed, among other minor
> tweaks.
> 
> These changes had the effect of demoting all Lenovo laptops to Bronze,
> and promoting the ASUS C201 (Google Veyron) to Gold.  I am still not
> 100% sure that I like the Veyron at Gold status due to the WiFi
> controller, but I will accept it for now pending introduction of
> libre-friendly (firmware-free or HW enforced radio limits with libre
> firmware) WiFi chipsets.
> 
> Comments welcome!

Generally, I like this revised version. Some minor suggestions:

- if you stress the word "require" in the "vendor controlled" section, I would 
suggest to stress the words "require absolutely no" and "require some" in the 
above sections.
- the forecast "No amount of reverse engineering or hacking will ever allow a 
fully libre firmware to execute on these boards." sounds too much like a fact 
and too pesimistic to me to. Although it reflects the current state of what we 
know, I would be careful with making such "absolute" forecasts.
- the term "pwned" is still in the introduction.
- I would mention in the introduction that  this is a classification for 
Coreboot-supported boards, not one for boards in general. This is not really 
clear from the introduction. Therefore, I would also state "All 
coreboot-supported AMD hardware" and so on in the vendor-controlled section.
- the term "libre software operating system" is sort of fuzzy, especially as 
you take into account operating systems which ship kernels that contain 
non-free components (at least the FSF claims that).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] KGPE-D16 and Samsung DDR3L memory sticks

[Daniel Kulesz via coreboot]

Hi folks,

I spent some time checking the available RAM options for the KGPE-D16. The 
current list in the wiki is not very comprehensive and the models listed there 
are not easy to find on the market. After some research, I identified two 
"promising" candidates:

1.) Samsung M393B1K70DH0-YK0

Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank, x4 • Modules: 1x 
8GB • JEDEC: PC3L-12800R • Voltage: 1.35V

2.) Samsung M393B1K70DH0-YH9

Type: DDR3 DIMM 240-Pin, reg ECC • Ranks/​Banks: dual rank • Modules: 1x 8GB • 
JEDEC: PC3L-10667R • Voltage: 1.35V

Does one of you have experience with any of these (especially on this board)?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Quad core CPU overheat?

[Daniel Kulesz via coreboot]

Hi Pok,

what I would suggest is to actually read out the temperatures (e.g. using 
"lm-sensors" in Linux) and use something even more stressing than crossgcc 
(like "stress-ng" in Linux). Normally, when the CPU gets hot it should "just" 
clock down and only issue this emergency powerdown in case when the 
temperatures exceed "extreme" limits (like 100 or 105°C, but depends on the 
CPU).

Once you know what temperatures your T420 gets, you should be able to find out 
if this is a thermal issue (defective fan, defective heatsink, wrong 
installation, bad thermal paste...) or actually something Corebook-related.

Another indicator could be the readout of temperatures and fan speeds while the 
system is idle. According to some people in the german thinkpad-forum.de, 
temperatures in idle should be around 44°C with the fan being off and around 
87°C when stressing the system for 30 minutes with prime95:

https://thinkpad-forum.de/threads/170582-Erfahrungsberichte-Quadcore-im-T420-Mod-Bios-inside

Please compare these measures with your system. It seems like it's possible to 
mod the fan of the T430 to work in the T420 in order to get even better 
temperatures.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot binary for ASUS F2A85-M

[Daniel Kulesz via coreboot]

On Mon, 23 Jan 2017 15:51:16 +0200
Kyösti Mälkki  wrote:

> On Mon, Jan 23, 2017 at 2:41 PM, Maxim Gusev via coreboot <
> coreboot@coreboot.org> wrote:
> 
> > Hi Daniel,
> >
> > Now I have compiled coreboot 4.5 with the SeaBIOS 1.9.3 as a payload and
> > the VGAbios:
> > I am using the Asus EN8600GT as a videocard (PCIe) and I took out the
> > binary here:
> > https://www.techpowerup.com/vgabios/?architecture=;
> > manufacturer=Asus=8600+GT=PCI-E=&
> > memSize=256=
> >

To my understanding, when using an external graphics card you don't need to 
extract or put any VGA blobs in. But you need to initialize the PCIe video. Can 
you provide us with the full config you are using, please? Or did you try my 
config which I linked in my initial answer? (There, it should be already 
enabled as far as I remember)

> > Also I have turned on  in console settings "Show POST codes...", but there
> > is nothing works:(
> >
> 
> You probably also need POST_DEVICE_PCI_PCIE set in your .config. In
> menuconfig: "Device to send POST codes to" -> "PCI/PCIe".
> 
> As for the serial port: I think this mainboard is not a retail version, but
> came from ASUS Essentio Desktop PC CM1745.
> http://www.ascendtech.us/asus-f2a85-m-cm1745-dp-motherboard_i_mb90mibiw5g0xbn.aspx
> 
> Looks like RS232 level translator ICs are also missing and some other
> differences on BOM too.
> 

Indeed, there seem to be different versions of the board then. I have the 
retail version, and mine has the connectors soldered. Can someone update the 
wiki, please?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot binary for ASUS F2A85-M

[Daniel Kulesz via coreboot]

Hi Maxim,

no it normally does not make any sounds, unless you have set e. g. grub to beep 
once its loaded. But you *need* to have a payload, otherwise nothing will boot. 
I suggest you try to SeaBIOS in the first instance. Also, you need to have 
either an external graphics cards (PCIe) or the vga bios, otherwise you also 
won't see anything on the screen until the point when you boot an operating 
system like linux which initializes the graphics.

The F2A-85M *does* have a serial port soldered on the board, but there is no 
connector for it. You need to get a simple cable like this one and connect it 
to your board:

https://www.quietpc.com/images/products/serial-port-pci-brackets-1-large.jpg

Cheers, Daniel


On Sun, 22 Jan 2017 15:33:00 -0500
Maxim Gusev  wrote:

> Hi!
> I'm using Athlon x2 340.
> The post card shows only . Can it show something while loading? Or not...
> I dont use any payloads now and no vga bios.
> Also my mainboard dont have soldered serial port.
> 
> Should the mainboard make sounds during the boot process?
> Thanks!
> 
> 
> 
>  Original Message 
> Subject: Re: Coreboot binary for ASUS F2A85-M
> Local Time: 20 Января 2017 г. 3:16 ночи
> UTC Time: 20 Января 2017 г. 00:16
> From: daniel.i...@googlemail.com
> To: Maxim Gusev 
> coreboot@coreboot.org 
> 
> Hi Max,
> 
> I had my F2A-85M working with an A10-6700 which needed some additional 
> tweaking because the Quadcore-CPU was causing timing issues in SeaBIOS. On my 
> previous cpu (A4-5300) everything was fine so I suppose the same should work 
> on your dualcore as well.
> 
> You can find my config files (for the A10-6700) together with some logs in 
> this commit:
> 
> https://review.coreboot.org/cgit/board-status.git/commit/?id=947fdae2518172e305a96b9de5684dba0bbbabbc
> 
> However, I also had the issue that I didn't receive any video output unless 
> the Linux kernel initialized the video or I plugged an PCIe GPU. I tried 
> including the VBIOS, but were out of luck for both CPUs/APUs.
> 
> Did you try hooking up a serial cable to see what is going on (provided you 
> have debug instructions compiled in).
> 
> Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot binary for ASUS F2A85-M

[Daniel Kulesz via coreboot]

Hi Max,

I had my F2A-85M working with an A10-6700 which needed some additional tweaking 
because the Quadcore-CPU was causing timing issues in SeaBIOS. On my previous 
cpu (A4-5300) everything was fine so I suppose the same should work on your 
dualcore as well. 

You can find my config files (for the A10-6700) together with some logs in this 
commit:

https://review.coreboot.org/cgit/board-status.git/commit/?id=947fdae2518172e305a96b9de5684dba0bbbabbc

However, I also had the issue that I didn't receive any video output unless the 
Linux kernel initialized the video or I plugged an PCIe GPU. I tried including 
the VBIOS, but were out of luck for both CPUs/APUs. 

Did you try hooking up a serial cable to see what is going on (provided you 
have debug instructions compiled in).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does the Core2Quad Mobile Q9100 require microcode updates?

[Daniel Kulesz via coreboot]

Hi,

thank you for the hints. Actually, I am a bit puzzled why some of you 
misinterpreted my message as a claim or even a "proof". Since I haven't seen 
(m)any reports about running Coreboot with a Core2Quad Mobile w/o microcode 
updates (The Libreboot docs even state that these CPUs are incompatible), I 
only wanted to report that for me it seems not to crash badly on booting or 
compiling. No more than that.

Cheers, Daniel


[1] https://libreboot.org/docs/install/t500_external.html#cpu_compatibility


On Mon, 09 Jan 2017 11:40:33 -0600
Timothy Pearson <tpear...@raptorengineering.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 01/09/2017 11:36 AM, ron minnich wrote:
> > 
> > 
> > On Mon, Jan 9, 2017 at 8:23 AM taii...@gmx.com <mailto:taii...@gmx.com>
> > <taii...@gmx.com <mailto:taii...@gmx.com>> wrote:
> > 
> > On 01/08/2017 06:50 PM, Daniel Kulesz via coreboot wrote:
> > 
> > > Hi,
> > >
> > > for the record: I had the Q9000 (not Q9100) running in my Thinkpad
> > T500 for a few weeks now without microcode updates and did not
> > encounter any issues so far.
> > 
> > 
> > absence of proof is not proof of absence. 
> > 
> 
> I would personally be very wary of running Intel CPUs without microcode
> updates.  Intel relies heavily on that "patch after ship" feature to
> iron out serious bugs (i.e. privilege escalation) in their hardware.
> 
> - -- 
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> https://www.raptorengineering.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJYc8sOAAoJEK+E3vEXDOFb/YwH/AqhMYlwtUsEAOVAg1dRmGss
> wld98lITvh9gRv2vDPUxNrA8S2rhV8gE6OyQLn8EskyTRMNl8Wts9HR9gVBgPDO2
> +mk6CQTVbWy7CBT4MZmGsJfx61KT+5valJCvH63RVciLPIY4v97w2KVPn1FE7IqN
> AlCPBZDuxvVvBbRFKepygb9v75Nse6yGt1f7DHdwasAOnKGxEr+kSqMDjCNIM7D7
> p4Sh5u8WzBT/3+fYm4jViskZrPhKdlo6LLQcggrlurPeAItvccm3acULGkE2FeRD
> +R/Y984vIaS+qlGfkh+Es8Xo4xbeXDJQzIruifN4unOD295txwsFdJ/muSXYpsk=
> =eXl1
> -END PGP SIGNATURE-



-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Does the Core2Quad Mobile Q9100 require microcode updates?

[Daniel Kulesz via coreboot]

Hi,

for the record: I had the Q9000 (not Q9100) running in my Thinkpad T500 for a 
few weeks now without microcode updates and did not encounter any issues so far.

Cheers, Daniel


On Sat, 12 Nov 2016 12:25:18 -0500
"taii...@gmx.com" <taii...@gmx.com> wrote:

> It varies as per CPU revision, some have newer/older onboard microcode 
> than others.
> 
> You won't know until you try it, or someone else with the exact same cpu 
> model/revision posts back (might take a long time)
> 
> I would check the errata spec sheet to see if there is anything bad that 
> is addressed by later microcode updates post-your cpus onboard version.
> On 11/12/2016 07:12 AM, Daniel Kulesz via coreboot wrote:
> > Hi,
> >
> > I am considering upgrading my Coreboot'ing Thinkpad T500 with a Core2Quad 
> > Mobile Q9100 [1] (which requires some hardware modifications but is 
> > doable). My question is: Does this CPU require the microcode updates or 
> > will it run without? Practical experience from someone running this or a 
> > simular CPU from the same family (Q9000, Q9300) would be appreciated!
> >
> > Cheers, Daniel
> >
> > [1] 
> > http://ark.intel.com/products/37033/Intel-Core2-Quad-Processor-Q9100-12M-Cache-2_26-GHz-1066-MHz-FSB
> >
> 

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] F2A-85M: Different VGA BIOS needed after CPU Upgrade?

[Daniel Kulesz via coreboot]

Hi,

to answer this question to myself: It seems like my VGA BIOS was neither 
working with the A4-5300 APU nor the A10-6700 APU. After debugging the problem 
over the serial port it turned out that SeaBIOS had multithreading issues and 
recognized the disks only partially and incorrectly --- which then lead to a 
boot failure.

To solve this issue, I got the hint on IRC (many thanks!) to apply the 
following patch (also raises the debug level):


diff --git a/payloads/external/SeaBIOS/Makefile 
b/payloads/external/SeaBIOS/Makefile
index 4b108d5..10e5aea 100644
--- a/payloads/external/SeaBIOS/Makefile
+++ b/payloads/external/SeaBIOS/Makefile
@@ -37,6 +37,8 @@ checkout: fetch
cd seabios; git checkout master; git branch -D coreboot 2>/dev/null; 
git checkout -b coreboot $(TAG-y)
 
 config: checkout
+   echo "CONFIG_DEBUG_LEVEL=5" >> seabios/.config
+   echo "CONFIG_THREADS=n" >> seabios/.config
echo "CONFIG SeaBIOS $(TAG-y)"
echo "CONFIG_COREBOOT=y" > seabios/.config
 ifeq ($(CONFIG_CONSOLE_SERIAL)$(CONFIG_DRIVERS_UART_8250IO),yy)


After that, my A10-6700 (Richland) worked with Coreboot. I had some stalls on 
CPU #3 which have gone after applying microcode updates (via the OS). I had the 
same issue with an older (but not a newer) version of the vendor BIOS, so I 
assume the CPU really has a bug which prevents reliable multi-core operations. 
It could be that the SeaBIOS trouble also originate from that, but I haven't 
tried compiling the microcode in, yet.

Cheers, Daniel



On Tue, 28 Jun 2016 12:23:23 +0200
Daniel Kulesz <daniel.i...@googlemail.com> wrote:

> Hi John,
> 
> > It sounds to me as though the PCI id's of the graphics card for the 
> > upgraded CPU may be different (I could be totally wrong about that, so I 
> > defer to others on the list if I'm barking up the wrong tree) and your 
> > coreboot image may need to be updated accordingly. Of course, it could 
> > also be the video BIOS that's the problem as you've suggested.
> 
> Thank you for the hint. I inspected that, but the PCI-IDs actually look the 
> same:
> 
> 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
> [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993]
> (A4-5300)
> 
> and
> 
> 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
> Richland [Radeon HD 8670D] (prog-if 00 [VGA controller])
> (A10-6700)
> 
> Looks like the VGA BIOS is really different:
> 
> # diff vgabios_a4-5300.bin vgabios_a10_6700.bin 
> Binary files vgabios_a4-5300.bin and vgabios_a10_6700.bin differ
> 
> Guess I will have to to "update" the VGA BIOS then.
> 
> Cheers, Daniel
> 
> 
> > 
> > Hi Daniel,
> > 
> > 
> > Kind Regards,
> > 
> > John.
> > 
> > 
> > On 28/06/16 09:24, Daniel Kulesz via coreboot wrote:
> > > Hi folks,
> > >
> > > I upgraded the CPU in my F2A-85M from a A4-5300 (Trinity) to a A10-6700 
> > > (Richland). The board had Coreboot installed before with the VGA BIOS 
> > > extracted from the A4-5300. However, I did not get any video output when 
> > > trying to boot after the upgrade, so I replaced the flash chip with a 
> > > backup with the vendor BIOS that works.
> > >
> > > Is it likely that the A10-6700 needs a different VGA BIOS or does this 
> > > this rather look like a different issue? I don't want to experiment too 
> > > much because the BIOS chips are hardware-wise pretty fragile (even when 
> > > using the extractor tool).
> > >
> > > Cheers, Daniel
> > >

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Success: Native gfx init on T500 with 1680x1050 display working w/o VGA blob

[Daniel Kulesz via coreboot]

Hi folks,

already since a while, there exists a hardware mod for the Thinkpad T500 which 
allows to run a quadcore CPU from from the Q9000-QX9300 series using Coreboot 
[1]. After trying various Coreboot configurations, I managed to make the 
current coreboot-master (e39a8a9c092ed66686632d591ec84ed7a6165a50) work on such 
a Quadcore-modded T500 with the Q9000 CPU [2]. What is really stunning: 
Although this T500 has one of the "believed-unsupported" 1680x1050 screen, even 
without the VGA blob and without microcode updates I get Seabios output using 
native gfx init!

However, there are some small issues:
- sometimes the screen is a little garbled, similar to the bug I reported for 
my X60s in [3]. It's not that bad, however and only affects booting.
- the memtest86+ payload does not boot (or it boots but shows no image, I don't 
know. Is it possible to make memtest86+ use the  1680x1050 resolution?).
- when booting the Debian Jessie installer, selecting the default VGA mode does 
not work. However, selecting mode 7 (1680x1050 VESA) works fine.
- when booting into an installed Debian Jessie base system, the grub screen 
(from Debian, not a coreboot payload) is not visible unless you set 
GRUB_GFXMODE=1680x1050 in grub.cfg and rewrite it.

Since I haven't reassembled the machine yet, I haven't done any extensive 
testing, didn't try virtualization etc. However, installing Debian Jessie 
worked fine. Power consumption in idle is very good as for this CPU (13,5-19W, 
depending on screen brightness).

I am attaching my config to this post and will try to run board-status script 
as soon. Very happy with my T500 so far - huge thanks to the Coreboot 
developers!

Cheers, Daniel


[1] 
https://thinkpad-forum.de/threads/199129-Core2-Quad-mit-Coreboot-Libreboot-auf-T500-%28-wahrsch-auch-T400%29-benutzen-BETA
[2] 
http://ark.intel.com/products/40480/Intel-Core2-Quad-Processor-Q9000-6M-Cache-2_00-GHz-1066-MHz-FSB
[3] https://ticket.coreboot.org/issues/80
#
# Automatically generated file; DO NOT EDIT.
# coreboot configuration
#

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
CONFIG_COMPILER_GCC=y
# CONFIG_COMPILER_LLVM_CLANG is not set
# CONFIG_ANY_TOOLCHAIN is not set
# CONFIG_CCACHE is not set
# CONFIG_FMD_GENPARSER is not set
# CONFIG_SCONFIG_GENPARSER is not set
CONFIG_USE_OPTION_TABLE=y
# CONFIG_STATIC_OPTION_TABLE is not set
# CONFIG_UNCOMPRESSED_RAMSTAGE is not set
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
# CONFIG_NO_XIP_EARLY_STAGES is not set
CONFIG_EARLY_CBMEM_INIT=y
# CONFIG_EARLY_CBMEM_LIST is not set
# CONFIG_COLLECT_TIMESTAMPS is not set
# CONFIG_USE_BLOBS is not set
# CONFIG_COVERAGE is not set
# CONFIG_RELOCATABLE_MODULES is not set
# CONFIG_RELOCATABLE_RAMSTAGE is not set
# CONFIG_NO_STAGE_CACHE is not set
CONFIG_BOOTBLOCK_SIMPLE=y
# CONFIG_BOOTBLOCK_NORMAL is not set
CONFIG_BOOTBLOCK_CUSTOM=y
CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c"
# CONFIG_C_ENVIRONMENT_BOOTBLOCK is not set
# CONFIG_UPDATE_IMAGE is not set
# CONFIG_GENERIC_GPIO_LIB is not set
# CONFIG_BOARD_ID_AUTO is not set
# CONFIG_BOARD_ID_MANUAL is not set
# CONFIG_RAM_CODE_SUPPORT is not set
# CONFIG_BOOTSPLASH_IMAGE is not set

#
# Mainboard
#
# CONFIG_VENDOR_A_TREND is not set
# CONFIG_VENDOR_AAEON is not set
# CONFIG_VENDOR_ABIT is not set
# CONFIG_VENDOR_ADI is not set
# CONFIG_VENDOR_ADLINK is not set
# CONFIG_VENDOR_ADVANSUS is not set
# CONFIG_VENDOR_AMD is not set
# CONFIG_VENDOR_AOPEN is not set
# CONFIG_VENDOR_APPLE is not set
# CONFIG_VENDOR_ARTECGROUP is not set
# CONFIG_VENDOR_ASROCK is not set
# CONFIG_VENDOR_ASUS is not set
# CONFIG_VENDOR_AVALUE is not set
# CONFIG_VENDOR_AZZA is not set
# CONFIG_VENDOR_BACHMANN is not set
# CONFIG_VENDOR_BAP is not set
# CONFIG_VENDOR_BCOM is not set
# CONFIG_VENDOR_BIFFEROS is not set
# CONFIG_VENDOR_BIOSTAR is not set
# CONFIG_VENDOR_BROADCOM is not set
# CONFIG_VENDOR_COMPAQ is not set
# CONFIG_VENDOR_CUBIETECH is not set
# CONFIG_VENDOR_DIGITALLOGIC is not set
# CONFIG_VENDOR_DMP is not set
# CONFIG_VENDOR_ECS is not set
# CONFIG_VENDOR_ELMEX is not set
# CONFIG_VENDOR_EMULATION is not set
# CONFIG_VENDOR_ESD is not set
# CONFIG_VENDOR_GETAC is not set
# CONFIG_VENDOR_GIGABYTE is not set
# CONFIG_VENDOR_GIZMOSPHERE is not set
# CONFIG_VENDOR_GOOGLE is not set
# CONFIG_VENDOR_HP is not set
# CONFIG_VENDOR_IBASE is not set
# CONFIG_VENDOR_IEI is not set
# CONFIG_VENDOR_INTEL is not set
# CONFIG_VENDOR_IWAVE is not set
# CONFIG_VENDOR_IWILL is not set
# CONFIG_VENDOR_JETWAY is not set
# CONFIG_VENDOR_KONTRON is not set
# CONFIG_VENDOR_LANNER is not set
CONFIG_VENDOR_LENOVO=y
# CONFIG_VENDOR_LINUTOP is not set
# CONFIG_VENDOR_LIPPERT is not set
# CONFIG_VENDOR_LOWRISC is not set
# CONFIG_VENDOR_MITAC is not set
# CONFIG_VENDOR_MSI is not set
# CONFIG_VENDOR_NEC is not set
# CONFIG_VENDOR_NOKIA is not set
# CONFIG_VENDOR_NVIDIA is not set
# CONFIG_VENDOR_PACKARDBELL is not set
# CONFIG_VENDOR_PCENGINES is not set
# CONFIG_VENDOR_PURISM is not set

Re: [coreboot] Bug?: Value in .config overwritten during make (Thinkpad T400/T500)

[Daniel Kulesz via coreboot]

Hi Nico and Martin,

thank you for your clarifications and the pointer to the documentation.

On Sun, 13 Nov 2016 22:46:48 +0100
Nico Huber  wrote:

> what do you mean by `actual config`? how did you set it? If you edi-
> ted .config manually, it's intended behavior. MAX_CPUS doesn't have
> a prompt so it's not user visible / settable.

Indeed, I meant the .config file which I edited manually to set the number of 
CPUs. So I see, to make the T400/T500 systems support both Dual- and Quadcore 
CPUs I would need to make this setting get a prompt/select then (if not using 
Kconfig hardcoding of course).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Bug?: Value in .config overwritten during make (Thinkpad T400/T500)

[Daniel Kulesz via coreboot]

Hi folks,

after several hours of trial & error I finally realized why the quadcore CPU in 
my T500 does not get recognized: No matter what you set for MAX_CPUS in 
.config, it gets overwritten during the build with a value coming from

src/mainboard/lenovo/t400

where the following is defined:

config MAX_CPUS
int
default 2

Well, at least for me default means that it's a default, not that it overwrites 
the actual config. Is this behavior really intended?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Does the Core2Quad Mobile Q9100 require microcode updates?

[Daniel Kulesz via coreboot]

Hi,

I am considering upgrading my Coreboot'ing Thinkpad T500 with a Core2Quad 
Mobile Q9100 [1] (which requires some hardware modifications but is doable). My 
question is: Does this CPU require the microcode updates or will it run 
without? Practical experience from someone running this or a simular CPU from 
the same family (Q9000, Q9300) would be appreciated!

Cheers, Daniel

[1] 
http://ark.intel.com/products/37033/Intel-Core2-Quad-Processor-Q9100-12M-Cache-2_26-GHz-1066-MHz-FSB

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Cable issue? Flashrom doesn't detect F2A-85M's flash chip (25Q64F)

[Daniel Kulesz via coreboot]

Hi folks,

for backup purposes, I am trying to do some flashing of the BIOS chip from my 
Asus F2A-85M (Winbond 25Q64F) by connecting it to a RPi2. In the past, I used 
the RPi2 setup successfully to flash the Macronix chip in the X200 using a 3M 
test clip and 15cm jumper cables, but I don't have a clip for Winbond chip on 
the F2A-85M so I am using the connectors which came bundled with a Buspirate 
(making the wires a little longer in total).

Unfortunately, Flashrom does not detect the chip even when supplying the -c 
parameter. Here are some pictures of my setup:

https://abload.de/img/dscn6511d8jh4.jpg
https://abload.de/img/dscn6515vekdc.jpg
https://abload.de/img/dscn6516n7j3f.jpg

I tried several times, checked the pinout and tried attaching the connectors to 
different areas of the flash chip's heads. Is there anything I am doing 
obviously wrong?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] F2A-85M: Different VGA BIOS needed after CPU Upgrade?

[Daniel Kulesz via coreboot]

Hi John,

> It sounds to me as though the PCI id's of the graphics card for the 
> upgraded CPU may be different (I could be totally wrong about that, so I 
> defer to others on the list if I'm barking up the wrong tree) and your 
> coreboot image may need to be updated accordingly. Of course, it could 
> also be the video BIOS that's the problem as you've suggested.

Thank you for the hint. I inspected that, but the PCI-IDs actually look the 
same:

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993]
(A4-5300)

and

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Richland [Radeon HD 8670D] (prog-if 00 [VGA controller])
(A10-6700)

Looks like the VGA BIOS is really different:

# diff vgabios_a4-5300.bin vgabios_a10_6700.bin 
Binary files vgabios_a4-5300.bin and vgabios_a10_6700.bin differ

Guess I will have to to "update" the VGA BIOS then.

Cheers, Daniel


> 
> Hi Daniel,
> 
> 
> Kind Regards,
> 
> John.
> 
> 
> On 28/06/16 09:24, Daniel Kulesz via coreboot wrote:
> > Hi folks,
> >
> > I upgraded the CPU in my F2A-85M from a A4-5300 (Trinity) to a A10-6700 
> > (Richland). The board had Coreboot installed before with the VGA BIOS 
> > extracted from the A4-5300. However, I did not get any video output when 
> > trying to boot after the upgrade, so I replaced the flash chip with a 
> > backup with the vendor BIOS that works.
> >
> > Is it likely that the A10-6700 needs a different VGA BIOS or does this this 
> > rather look like a different issue? I don't want to experiment too much 
> > because the BIOS chips are hardware-wise pretty fragile (even when using 
> > the extractor tool).
> >
> > Cheers, Daniel
> >

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] F2A-85M: Different VGA BIOS needed after CPU Upgrade?

[Daniel Kulesz via coreboot]

Hi folks,

I upgraded the CPU in my F2A-85M from a A4-5300 (Trinity) to a A10-6700 
(Richland). The board had Coreboot installed before with the VGA BIOS extracted 
from the A4-5300. However, I did not get any video output when trying to boot 
after the upgrade, so I replaced the flash chip with a backup with the vendor 
BIOS that works.

Is it likely that the A10-6700 needs a different VGA BIOS or does this this 
rather look like a different issue? I don't want to experiment too much because 
the BIOS chips are hardware-wise pretty fragile (even when using the extractor 
tool).

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Target Evaluation: Gigabyte GA-EG45M-DS2H

[Daniel Kulesz via coreboot]

Hi,

since I switched to an F2A-85M I have a spare gigabyte desktop board with the 
Intel X4500 onboard graphics (quite rare) which has afaik no coreboot so far. 
In general, it seems like only one other socket 775 board is supported. I was 
wondering if this could be an interesting target or if any major showstoppers 
are to be expected. Here's are the specs:

http://www.gigabyte.com/products/product-page.aspx?pid=2877#sp

Although the board just supports DDR2 memory (4 slots), with the Socket 771 
pinmod it should be able to run quite decent and cheap Xeon quadcores.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

On Sat, 7 May 2016 15:53:47 +0200
Zoran Stojsavljevic  wrote:

> > @Zoran: I also have an X220 (2nd gen Core I5) on which I did not
> undertake any Coreboot experiments yet. But I
> > suppose you are rather asking for much newer CPUs from the 6th and 7th
> generation?
> >
> > Cheers, Daniel
> 
> Hello Daniel,
> 
> Second generation CORE is SNB. CPUID something like 0x20xyz. CORE 2nd gen.
> was released Y2011.
> Third generation CORE is IVB. CPUID something like 0x30xyz. Core 3rd gen.
> was released Y2012.
> 
> What I am talking/pointing ot about is the following:
> *Fourth generation CORE is HSW. CPUID something like 0x40651 (i5 4300U) -
> HP 840 G1 - one of my laptops. Released Y2013.*
> *Sixth generation CORE is SKL. CPUID something like 0x606E3 (i5 6200U) - HP
> 450 G3 - another of my laptops. Released Y2015.*
> 
> 4th (HSW-U) and 6th (SKL-U) generations of CPUs in laptops: these are ones
> I am talking about/pointing to (don't think CORE 5th gen. is important).
> 
> Sorry I am late with Re:.

Hi Zoran,

You are welcome! But I don't have any of these newer laptops and afaik Coreboot 
does not support many of them, either. Especially the newer Thinkpads (T/X240+) 
are not supported. But sure, if anybody has one of these machines doing similar 
experiments would really make sense. I still wonder why I didn't read or hear 
about any complaints about running Libreboot/Coreboot on a X200 since the 
difference of the missing C4 mode (by default at least) is so striking.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

> > Sounds stupid, but I'm really impressed now! But... is there a reason
> > C4 is not enabled by default then? I mean, if it makes trouble, you
> > can always disable it (at least on Linux) with the command line
> > parameters as discussed previously. Imho, it should be at least
> > configurable using the regular config mechanism.
> > 
> I guess, just nobody tried it before on a ThinkPad. The entries for
> C1/C2 are most probably copy-pasted from Roda/RK9. Thanks for testing
> this through! If you don't want to go further (https://coreboot.org/Git)
> somebody else will likely write a patch ;)

Okay, but that's strange, because e.g. my X60 supports C4 although it also 
seems to consume way too much power. Will have to investigate that as well. I 
also have this other X200 with P8600 and CCFL backlight, but one can assume 
that the patch will work there as well. But if I find the time I can test it 
there as well if nobody else wants to do that. I assume once it gets in git, we 
will automatically get more testers anyways. ;-)

And yes, I can submit the patch but not today, it's already 1:40am over here.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

Hi all,

On Mon, 2 May 2016 13:16:15 +0200
Nico Huber  wrote:

> On 02.05.2016 01:06, Daniel Kulesz wrote:
> >>> - disabling "cpu power management" makes the idle consumption raise to 
> >>> 12,8W
> >> Is this 12.8W compared to 7.5W (i.e. with lowest backlight)?
> >>
> > 
> > Nope, I am only comparing with highest backlight now, so it is 12.8W versus 
> > 10.0W here.
> Hmmm, 2.8W... whatever that option does it confuses me.
> 
Well, I assume it disables C3 and C4.

> >>> Any ideas which could solve this mystery?
> >>>
> >> One more thing you can test, in case your Linux uses the intel_idle
> >> driver: There is a kernel parameter intel_idle.max_cstate, if you boot
> >> the vendor BIOS with defaults and Linux with intel_idle.max_cstate=2 it
> >> should use C1/C2 but not C3/C4 and thus behave more like coreboot.
> >>
> > Okay. I was just aware of the generic "processor.max_cstate=2"
> > parameter. I tried with both parameters using the vendor BIOS and here
> > are the results:
> > 
> > intel_idle.max_cstate=2: 10W in idle at full brightness (no effect)
> > processor.max_cstate=2: 12.6W in idle at full brightness
> > 
> > So it seems plausible that this issue is related to Coreboot not
> > (properly?) supporting C3/C4. So this is a known issue then? If yes,
> > imho it should be *definitely* documented on the wiki page since it
> > could be a "showstopper" for many adopters who need the maximum battery
> > life the X200 is able to deliver only with the vendor BIOS at this point
> > in time ...
> Well, let's see what we got:
>   o 10.0W with "cpu power management"
>   o 12.6W with "cpu power management" but max_cstate=2
>   o 12.8W without "cpu power management"
> FWIW, C2 usually saves more power. So I wonder how good your measuring
> at the wall plug works. Another easy option to measure the power
> consumption is looking at what the battery reports (usually
> /sys/class/power_supply/BAT0/power_now).
> 

Well sure, the power consumption is not always 100% steady so sometimes it 
"flakes" around 0.1 - 0.2W, depending on e.g. whether the fan is running or not 
or what some background processes do. So I just took the values that were 
reported by my external meter most of the time, and these could be slightly 
off. 

Of course, using "power_now" would be more accurate, but I would have to take 
like 100 measurements and then take the median or something like that. Imho a 
bit too much in this case since the difference is so big that it's visible at 
first sight.


> Regarding C3/C4 support, AFAIK, we implemented it fully but it just
> didn't work on the system we originally ported coreboot for (Roda/RK9).
> The system kept resetting whenever it should enter (or maybe exit) C3,
> IIRC.  You could give it a try on your X200 though. Whatever the issue
> on the RK9 was, it might be board specific.
> 
> If you want to try it, in src/mainboard/lenovo/x200/cstates.c add:
> {
> /* acpi C3 / cpu C3 */
> 3, 0x02,  300,
> { ACPI_ADDRESS_SPACE_FIXED, 1, 2, { 1 }, 0x20, 0 }
> },
> for C3 or
> {
> /* acpi C3 / cpu C4 */
> 3, 0x02,  300,
> { ACPI_ADDRESS_SPACE_FIXED, 1, 2, { 1 }, 0x30, 0 }
> },
> for C4. You can not have all of them, as ACPI only supports three
> C-states.

Indeed this was a *VERY GOOD* hint! I added the line with the C4 states and 
idle power consumption dropped to about 11.5W running my regular OS and with 
Wifi on. So I again disassembled the keyboard/palmrest, removed the wifi card 
and did exactly the same measurements as before. And here are the results:

Benchmark results: almost like before (not crappy like with vendor BIOS!), a 
little worse because it probably takes a few ms for the CPU to wake up from C4 
first.
Stress test: >37.2W (as before)

Idle, max brightness: 10.8W (!!)
Idle, lowest brightness: 7.8W (!!)

...and after running "powertop --auto-tune":
Idle, max brightness: 9.9W
Idle, lowest brightness: 6.9W
Screen off:6.4W

Sounds stupid, but I'm really impressed now! But... is there a reason C4 is not 
enabled by default then? I mean, if it makes trouble, you can always disable it 
(at least on Linux) with the command line parameters as discussed previously. 
Imho, it should be at least configurable using the regular config mechanism.

@Zoran: I also have an X220 (2nd gen Core I5) on which I did not undertake any 
Coreboot experiments yet. But I suppose you are rather asking for much newer 
CPUs from the 6th and 7th generation?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

> > Okay. I was just aware of the generic "processor.max_cstate=2"
> > parameter. I tried with both parameters using the vendor BIOS and
> > here are the results:
> 
> Can you do a test run with closed devices? This would ensure, you're
> not measurring a brightness difference.

Okay, you mean with the display turned off? I did this now using xrandr and 
here are the results:

Coreboot: 9.0W
vendor BIOS: 6.9W

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

> > - disabling "cpu power management" makes the idle consumption raise to 12,8W
> Is this 12.8W compared to 7.5W (i.e. with lowest backlight)?
> 

Nope, I am only comparing with highest backlight now, so it is 12.8W versus 
10.0W here.

> > - disabling "PCI Bus power management" and "PCI express power management" 
> > makes the idle consumption raise to 13,3W
> > - disabling the AMT firmware had no effect
> > - running the stress test still drains only 24,2W
> > - performance is the same as before
> >
> > I still don't understand the whole performance issue. Therefore, I took
> > another X200 with a P8600, CCFL screen and an older vendor BIOS and
> > re-ran the benchmark there --- with almost identical results.
> > 
> > So in the end I'm just confused. This would mean that running Coreboot
> > makes the X200 *much* faster at the expense of battery life, both in
> > idle and under stress conditions.
> > 
> Maybe Lenovo limited the processor clock on purpose to get a better
> battery life. Maybe it's just an unexpected side effect of running
> Linux (not Windows, what Lenovo tested against). Anyway, I wouldn't care
> about the power consumption under load, it might even result in a longer
> battery life: Being faster means shorter periods in higher performance
> states. The idle power consumption is what really matters.
> 
Yes I agree, I am almost never putting high load on the machine anyways, so 
even if it would make an impact I would not care too much. And then you can 
still limit the max. frequency or something and be performance-wise probably 
still comparable to the vendor BIOS.

> > Any ideas which could solve this mystery?
> >
> One more thing you can test, in case your Linux uses the intel_idle
> driver: There is a kernel parameter intel_idle.max_cstate, if you boot
> the vendor BIOS with defaults and Linux with
>   intel_idle.max_cstate=2
> it should use C1/C2 but not C3/C4 and thus behave more like coreboot.
> 
Okay. I was just aware of the generic "processor.max_cstate=2" parameter. I 
tried with both parameters using the vendor BIOS and here are the results:

intel_idle.max_cstate=2: 10W in idle at full brightness (no effect)
processor.max_cstate=2: 12.6W in idle at full brightness

So it seems plausible that this issue is related to Coreboot not (properly?) 
supporting C3/C4. So this is a known issue then? If yes, imho it should be 
*definitely* documented on the wiki page since it could be a "showstopper" for 
many adopters who need the maximum battery life the X200 is able to deliver 
only with the vendor BIOS at this point in time ...

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

Hi again,

I did some more experiments with the vendor BIOS and made the following 
observations:

- disabling "cpu power management" makes the idle consumption raise to 12,8W
- disabling "PCI Bus power management" and "PCI express power management" makes 
the idle consumption raise to 13,3W
- disabling the AMT firmware had no effect
- running the stress test still drains only 24,2W
- performance is the same as before

I still don't understand the whole performance issue. Therefore, I took another 
X200 with a P8600, CCFL screen and an older vendor BIOS and re-ran the 
benchmark there --- with almost identical results.

So in the end I'm just confused. This would mean that running Coreboot makes 
the X200 *much* faster at the expense of battery life, both in idle and under 
stress conditions.

Any ideas which could solve this mystery?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

Hi Nico,

> On 01.05.2016 12:26, Daniel Kulesz via coreboot wrote:
> > Coreboot with idle=poll: 15,8W
> > Coreboot running "stress": 37,2W
> well, this is what I would expect from the specs.
> 
> > Vendor BIOS with idle=poll: 15W
> > Vendor BIOS with intel_pstate=disabled: 10W
> > Vendor BIOS running "stress": 24,3W (!!)
> This looks suspicious. Doing some calculation:
> You are measuring at the wall plug, efficiency could be around 83%,
> which would leave 20W. Chipset, backlight and other stuff needs power as
> well, say around 8W, leaving 12W for your 25W TDP CPU???
> 
Well, I could imagine that the PSU's efficiency is better than 83%, and maybe 
the CPU is just rated at 25W TDP while in fact it consumes less. Please note 
that the whole family of CPUs is rated at this wattage and so is the P9600 
which runs at 2,66GHz and not just 2,53GHz and at a slightly higher min. 
voltage (but slightly lower max. voltage).

> So, before bothering yourself with the power consumption difference
> under load, I would also check the performance of coreboot vs. vendor
> BIOS.
> 
That's a good point and I was also thinking about this. So I just did a few 
measurements using "cryptsetup benchmark" (results attached). As you can see, 
indeed performance with the vendor BIOS is significantly lower. But why?

As I don't really need so much performance and rather would prefer better 
battery lifetime, the vendor BIOS' behavior would suit me better. I will try to 
tweak its settings a bit and see how this impacts performance and power 
consumption so we can get a better idea what could be causing the impact.

> > And I didn't find any documentation about how to actually extract the
> > VGA Bios part, so any hints are welcome.
> Um, if you find a way, please document ;)
> 
As I posted, it is there, but a bit hidden in the Wiki.

I also ran a test series with the microcode updates included => no difference.

Cheers, Daniel
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1   409600 iterations per second
PBKDF2-sha256 264258 iterations per second
PBKDF2-sha512 190511 iterations per second
PBKDF2-ripemd160  273066 iterations per second
PBKDF2-whirlpool   83591 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
 aes-cbc   128b95.1 MiB/s98.3 MiB/s
 serpent-cbc   128b32.8 MiB/s   123.5 MiB/s
 twofish-cbc   128b82.6 MiB/s   108.7 MiB/s
 aes-cbc   256b72.7 MiB/s74.4 MiB/s
 serpent-cbc   256b32.8 MiB/s   123.4 MiB/s
 twofish-cbc   256b82.6 MiB/s   108.7 MiB/s
 aes-xts   256b98.0 MiB/s97.9 MiB/s
 serpent-xts   256b   111.9 MiB/s   115.9 MiB/s
 twofish-xts   256b   100.3 MiB/s   101.1 MiB/s
 aes-xts   512b74.0 MiB/s73.8 MiB/s
 serpent-xts   512b   112.1 MiB/s   115.9 MiB/s
 twofish-xts   512b   100.2 MiB/s   101.0 MiB/s
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1   665340 iterations per second
PBKDF2-sha256 420102 iterations per second
PBKDF2-sha512 303407 iterations per second
PBKDF2-ripemd160  428339 iterations per second
PBKDF2-whirlpool  132129 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
 aes-cbc   128b   131.5 MiB/s   155.5 MiB/s
 serpent-cbc   128b51.5 MiB/s   195.2 MiB/s
 twofish-cbc   128b   130.7 MiB/s   171.6 MiB/s
 aes-cbc   256b   104.1 MiB/s   117.5 MiB/s
 serpent-cbc   256b51.5 MiB/s   195.2 MiB/s
 twofish-cbc   256b   130.7 MiB/s   171.6 MiB/s
 aes-xts   256b   155.0 MiB/s   154.8 MiB/s
 serpent-xts   256b   176.1 MiB/s   182.3 MiB/s
 twofish-xts   256b   158.7 MiB/s   159.7 MiB/s
 aes-xts   512b   116.9 MiB/s   116.5 MiB/s
 serpent-xts   512b   176.1 MiB/s   182.3 MiB/s
 twofish-xts   512b   158.7 MiB/s   159.5 MiB/s
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

Hi all,

thank you again for the suggestions!

First thing: VGABIOS. I was able to extract the blob (the hint in the wiki is a 
bit hidden and the introduction of the section is a bit misleading btw) and 
re-ran the measurements using the proprietary VGA BIOS:

Idle: 13,4W
Stress: 37,2W

So they values are exactly the same as with native graphics init. 

Second thing: Powertop. I did the suggested powertop --autotune experiments in 
idle and obtained the following results:

vendor BIOS: 8,8W
Coreboot: 12,2W

So in both cases a decrease of around 1,2W.

But still something else drains these extra 3,5W. Not running in C3/C4 would 
explain that difference maybe. How can I check that? I am now doing another 
attempt to include the microcode updates, but I doubt this will make such a big 
difference.

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

Hi Andrey and lynxis,

thank you for the quick reply and your suggestions. I followed Andrey's advice 
and here are the results (only with full screen brightness):

Coreboot with idle=poll: 15,8W
Coreboot running "stress": 37,2W

Vendor BIOS with idle=poll: 15W
Vendor BIOS with intel_pstate=disabled: 10W
Vendor BIOS running "stress": 24,3W (!!)

Remember, the idle values without additional kernel parameters were:
Vendor BIOS: 10W
Coreboot: 13,4W

I didn't expect the power consumption in the "stress" scenario to rise up that 
high with coreboot, I just supposed to power consumption in idle to be 
affected! :-(

Unfortunately, I was not able to extract the VGA BIOS and use it instead of 
native gfx init, as I didn't succeed to apply bios_extract:

daniel@compilehost:~/extract_x200_vga$ dd bs=1k skip=6144 if=x200_factory.rom 
of=x200_biospart.img
2048+0 records in
2048+0 records out
2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.00409209 s, 512 MB/s
daniel@compilehost:~/extract_x200_vga$ ../bios_extract/bios_extract 
x200_biospart.img 
Using file "x200_biospart.img" (2048kB)
Error: Unable to detect BIOS Image type.

And I didn't find any documentation about how to actually extract the VGA Bios 
part, so any hints are welcome.

By the way: All settings in the vendor BIOS are default/unchanged. And I 
activated all these PCI power management and ASPM settings in coreboot (see my 
attached config) and even disabled all debugging to serial console etc. but 
this didn't help so far.

Cheers, Daniel
#
# Automatically generated file; DO NOT EDIT.
# coreboot configuration
#

#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_CBFS_PREFIX="fallback"
# CONFIG_MULTIPLE_CBFS_INSTANCES is not set
CONFIG_COMPILER_GCC=y
# CONFIG_COMPILER_LLVM_CLANG is not set
# CONFIG_ANY_TOOLCHAIN is not set
# CONFIG_CCACHE is not set
# CONFIG_FMD_GENPARSER is not set
# CONFIG_SCONFIG_GENPARSER is not set
# CONFIG_USE_OPTION_TABLE is not set
# CONFIG_UNCOMPRESSED_RAMSTAGE is not set
CONFIG_COMPRESS_RAMSTAGE=y
CONFIG_INCLUDE_CONFIG_FILE=y
CONFIG_EARLY_CBMEM_INIT=y
CONFIG_COLLECT_TIMESTAMPS=y
# CONFIG_USE_BLOBS is not set
# CONFIG_COVERAGE is not set
# CONFIG_RELOCATABLE_MODULES is not set
# CONFIG_RELOCATABLE_RAMSTAGE is not set
CONFIG_FLASHMAP_OFFSET=0x0
CONFIG_BOOTBLOCK_SIMPLE=y
# CONFIG_BOOTBLOCK_NORMAL is not set
CONFIG_BOOTBLOCK_CUSTOM=y
CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c"
# CONFIG_C_ENVIRONMENT_BOOTBLOCK is not set
# CONFIG_UPDATE_IMAGE is not set
# CONFIG_GENERIC_GPIO_LIB is not set
# CONFIG_BOARD_ID_AUTO is not set
# CONFIG_BOARD_ID_MANUAL is not set
# CONFIG_RAM_CODE_SUPPORT is not set
# CONFIG_BOOTSPLASH_IMAGE is not set
# CONFIG_ACPI_SATA_GENERATOR is not set

#
# Mainboard
#
# CONFIG_VENDOR_A_TREND is not set
# CONFIG_VENDOR_AAEON is not set
# CONFIG_VENDOR_ABIT is not set
# CONFIG_VENDOR_ADLINK is not set
# CONFIG_VENDOR_ADVANSUS is not set
# CONFIG_VENDOR_AMD is not set
# CONFIG_VENDOR_AOPEN is not set
# CONFIG_VENDOR_APPLE is not set
# CONFIG_VENDOR_ARTECGROUP is not set
# CONFIG_VENDOR_ASROCK is not set
# CONFIG_VENDOR_ASUS is not set
# CONFIG_VENDOR_AVALUE is not set
# CONFIG_VENDOR_AZZA is not set
# CONFIG_VENDOR_BACHMANN is not set
# CONFIG_VENDOR_BAP is not set
# CONFIG_VENDOR_BCOM is not set
# CONFIG_VENDOR_BIFFEROS is not set
# CONFIG_VENDOR_BIOSTAR is not set
# CONFIG_VENDOR_BROADCOM is not set
# CONFIG_VENDOR_COMPAQ is not set
# CONFIG_VENDOR_CUBIETECH is not set
# CONFIG_VENDOR_DIGITALLOGIC is not set
# CONFIG_VENDOR_DMP is not set
# CONFIG_VENDOR_ECS is not set
# CONFIG_VENDOR_EMULATION is not set
# CONFIG_VENDOR_ESD is not set
# CONFIG_VENDOR_GETAC is not set
# CONFIG_VENDOR_GIGABYTE is not set
# CONFIG_VENDOR_GIZMOSPHERE is not set
# CONFIG_VENDOR_GOOGLE is not set
# CONFIG_VENDOR_HP is not set
# CONFIG_VENDOR_IBASE is not set
# CONFIG_VENDOR_IEI is not set
# CONFIG_VENDOR_INTEL is not set
# CONFIG_VENDOR_IWAVE is not set
# CONFIG_VENDOR_IWILL is not set
# CONFIG_VENDOR_JETWAY is not set
# CONFIG_VENDOR_KONTRON is not set
# CONFIG_VENDOR_LANNER is not set
CONFIG_VENDOR_LENOVO=y
# CONFIG_VENDOR_LINUTOP is not set
# CONFIG_VENDOR_LIPPERT is not set
# CONFIG_VENDOR_MITAC is not set
# CONFIG_VENDOR_MSI is not set
# CONFIG_VENDOR_NEC is not set
# CONFIG_VENDOR_NOKIA is not set
# CONFIG_VENDOR_NVIDIA is not set
# CONFIG_VENDOR_PACKARDBELL is not set
# CONFIG_VENDOR_PCENGINES is not set
# CONFIG_VENDOR_PURISM is not set
# CONFIG_VENDOR_RCA is not set
# CONFIG_VENDOR_RODA is not set
# CONFIG_VENDOR_SAMSUNG is not set
# CONFIG_VENDOR_SIEMENS is not set
# CONFIG_VENDOR_SOYO is not set
# CONFIG_VENDOR_SUNW is not set
# CONFIG_VENDOR_SUPERMICRO is not set
# CONFIG_VENDOR_TECHNEXION is not set
# CONFIG_VENDOR_THOMSON is not set
# CONFIG_VENDOR_TI is not set
# CONFIG_VENDOR_TRAVERSE is not set
# CONFIG_VENDOR_TYAN is not set
# CONFIG_VENDOR_VIA is not set
# CONFIG_VENDOR_WINENT is not set
# CONFIG_VENDOR_WYSE is not set
CONFIG_BOARD_SPECIFIC_OPTIONS=y
CONFIG_MAINBOARD_DIR="lenovo/x200"
CONFIG_MAINBOARD_PART_NUMBER="ThinkPad 

[coreboot] Lenovo X200 running Coreboot drains 3-4W more power than with Vendor BIOS

[Daniel Kulesz via coreboot]

Hi,

I was wondering why my Lenovo X200 had such a short battery lifetime when 
running Libreboot/Coreboot, so I did a few measurements using the following 
hardware configuration:

X200 with P8700 CPU
8GB RAM
LED Display (yes, one of the rare ones)
OCZ Trion SSD (unused, just idling)
Wifi and WWAN removed
Battery removed
Ubuntu MATE 16.04 Live running from an USB thumb drive
No tweaking with powertop or such

I kept this configuration unchanged except for the BIOS and waited 5 minutes 
after booting, so the system could settle. Then I measured power consumption 
both at full brightness and at minimum brightness using a conventional power 
meter (EKM 365) which was plugged between the AC adapter and the power socket 
in the wall.

I obtained the following numbers:

Vendor BIOS: 7,5W (lowest) to 10W (highest)
Libreboot 20150518 (using the precompiled binary binary): 13,3W (lowest) to 
16,1W (highest)
Latest Coreboot, config attached (80a3df260767a6d9ad34b61572d483579c21476c): 
10,4W (lowest) to 13,4W (highest)

While Libreboot performs much worse than Coreboot, Coreboot still eats around 
3W extra when compared with the vendor BIOS. In other words: Coreboot consumes 
around 30-40% more juice than the vendor BIOS which is a very sad result for an 
ultraportable notebook.

Is this a known issue? Has someone else tried the same and obtained different 
numbers?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Issue Tracker down?

[Daniel Kulesz via coreboot]

Hi,

I just wanted to report bug regarding memory initialization on the F2A85-M, but 
it looks like the issue tracker is down:

502 Bad Gateway
nginx/1.4.6 (Ubuntu)

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] F2A85-M: A10-6800k (Richland) supported?

[Daniel Kulesz via coreboot]

Hi,

is or was someone able to run the A10-6800k on the F2A85-M successfully? If 
yes, are any extra patches required?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] F2A85-M: Memory issues

[Daniel Kulesz via coreboot]

Hi Martin,

thank you for the quick reply. I just tried the memtest86 variant you suggested 
and it runs already for 15 minutes without reporting any errors. So the 
memtest86+ from the Ubuntu-Live-CD was probably a false alarm then I suppose. I 
didn't expect that because on a X200 with Libreboot the "regular" memtest86+ 
runs just fine.

It would be cool if you could mention the fact about where to put the RAM 
already in the limitations section of the wiki page. It could save other people 
from flashing coreboot and being disappointed because no vga signal is there 
afterwards. Although one could debate whether this is a limitation or not when 
regarding AMD's specifications, if it was working in vendor bios most people 
will expect to continue working in Coreboot.

Cheers, Daniel



On Mon, 18 Apr 2016 03:54:14 +
Martin Roth <gauml...@gmail.com> wrote:

> Hi Daniel, unless you're using the memtest from the coreboot codebase, the
> memtest failures are likely false.
> 
> Try this one - it should work better under SeaBIOS:
> git clone https://review.coreboot.org/memtest86plus
> 
> You can also just build it into the coreboot image as a secondary payload
> in the payloads menu of kconfig if you have an up-to-date version of
> coreboot.
> 
> In general, AMD specified that you should populate the dimms from the
> furthest away from the cpu to the closest. The vendor might have found that
> it worked fine on this board, so changed their bios to remove that
> restriction. I don't know if that's the issue you're seeing, but it's
> possible.
> 
> I'll test it when I get a chance.
> 
> Thanks for the report.
> Martin
> 
> 
> On Sun, Apr 17, 2016 at 19:52 Daniel Kulesz via coreboot <
> coreboot@coreboot.org> wrote:
> 
> > Hi folks,
> >
> > I just flashed Coreboot 4.3 release on my F2A85-M (the "original", not Pro
> > or whatever) together with Seabios and the VGA ROM. I am running the "bare"
> > board with an AMD A4-5700 APU and two 8GB Corsair Sticks () at 1,5V.  No
> > attached peripherals except an usb stick which I use for booting a live
> > system. Unfortunately, I experienced the following issues:
> >
> > (1) When I plug the memory sticks in the black DIMMs I get no Video,
> > although they were working fine there before with the vendor bios. However,
> > they "work" when inserted in the blue slots.
> > (2) I am getting errors im memtest86+ 5.01 in compatibility mode in mem
> > adresses around 3700M. I tried both sticks, each also in single
> > configuration but the issue persists. I had no issues with the vendor bios
> > (when inserted in the other slots).
> > (3) The CPU temperature is reported wrong in Memtest86+ (Memtest86+
> > reports 15°C while it was around 35-40°C in the vendor bios at around the
> > same fan speed and environment conditions). However, I don't remember if it
> > reported a correct value with the vendor bios.
> >
> > The memory sticks have been reported as follows by the vendor bios:
> >
> > Handle 0x0035, DMI type 17, 34 bytes
> > Memory Device
> > Array Handle: 0x002F
> > Error Information Handle: Not Provided
> > Total Width: 64 bits
> > Data Width: 64 bits
> > Size: 4096 MB
> > Form Factor: DIMM
> > Set: None
> > Locator: DIMM_B1
> > Bank Locator: A1_BANK2
> > Type: DDR3
> > Type Detail: Synchronous Unbuffered (Unregistered)
> > Speed: 1333 MHz
> > Manufacturer: Corsair
> > Serial Number: 
> > Asset Tag: A1_AssetTagNum2
> > Part Number: CMZ4GX3M1A1600C9
> > Rank: 2
> > Configured Clock Speed: 1333 MHz
> >
> > Are these known issues? Or maybe just a false alarm?
> >
> > Cheers, Daniel
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://www.coreboot.org/mailman/listinfo/coreboot
> >

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] F2A85-M: Memory issues

[Daniel Kulesz via coreboot]

Hi folks,

I just flashed Coreboot 4.3 release on my F2A85-M (the "original", not Pro or 
whatever) together with Seabios and the VGA ROM. I am running the "bare" board 
with an AMD A4-5700 APU and two 8GB Corsair Sticks () at 1,5V.  No attached 
peripherals except an usb stick which I use for booting a live system. 
Unfortunately, I experienced the following issues:

(1) When I plug the memory sticks in the black DIMMs I get no Video, although 
they were working fine there before with the vendor bios. However, they "work" 
when inserted in the blue slots.
(2) I am getting errors im memtest86+ 5.01 in compatibility mode in mem 
adresses around 3700M. I tried both sticks, each also in single configuration 
but the issue persists. I had no issues with the vendor bios (when inserted in 
the other slots).
(3) The CPU temperature is reported wrong in Memtest86+ (Memtest86+ reports 
15°C while it was around 35-40°C in the vendor bios at around the same fan 
speed and environment conditions). However, I don't remember if it reported a 
correct value with the vendor bios.

The memory sticks have been reported as follows by the vendor bios:

Handle 0x0035, DMI type 17, 34 bytes
Memory Device
Array Handle: 0x002F
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 4096 MB
Form Factor: DIMM
Set: None
Locator: DIMM_B1
Bank Locator: A1_BANK2
Type: DDR3
Type Detail: Synchronous Unbuffered (Unregistered)
Speed: 1333 MHz
Manufacturer: Corsair 
Serial Number:   
Asset Tag: A1_AssetTagNum2
Part Number: CMZ4GX3M1A1600C9  
Rank: 2
Configured Clock Speed: 1333 MHz

Are these known issues? Or maybe just a false alarm?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASUS F2A85-M: Richland-APU A10-6800k supported?

[Daniel Kulesz via coreboot]

Hi,

with the Richland-patches being available, did someone already try to run one 
of the "high-end" Richland APUs like the A10-6800k in the F2A85-M with Coreboot?

Cheers, Daniel

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot