Daniel Kulesz via coreboot | 24 May 20:20 2016

Target Evaluation: Gigabyte GA-EG45M-DS2H

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 <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

cheng yichen | 24 May 13:42 2016
Picon

Re: Microcode problem with Braswell CPU

Hi all

I find the same problem in my mainboard.The cpu type is N3150. 
but I can't find why the microcode is not loaded to SOC. 
Could you please share your exprience to me? Thank you
 
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
David Griffith | 24 May 10:27 2016
Gravatar

T60: running nvramcui and coreinfo secondary payloads


I'm at the boot menu.  When I select "nvramcui", I get this:

IO space mapped serial not present. Could not find coreboot options table.

Then the firmware locks up.  If I try coreinfo, I get the first sentence, 
then the screen blanks and the firmware locks up.  Ctrl-Alt-Del does 
nothing.  Taking the exact same .config and setting it for QEMU, coreinfo 
works, but selecting nvramcui causes "Could not find coreboot option 
table" to be printed.

-- 
David Griffith
dave <at> 661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Naveed Ghori | 24 May 08:03 2016
Picon

Debug builds and memory testing

Hi all,

 

Is there a debug build of coreboot or a way to test memory very early on.

My custom board goes through the romstage just fine but stops booting while trying to enumerate the buses.

 

I am suspecting RAM might be an issue so would like to eliminate that by doing a memory test on it.

--------------

POST: 0x72

Enumerating buses...

Show all devs... Before device enumeration.

Root Dev

--------------

 

Thanks in advance,

Naveed

Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

31 Affleck Road, Perth Airport, Western Australia 6105, AU

P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.ghori <at> dti.com.au



Visit our website www.dti.com.au

The information contained in this email is confidential. If you receive this email in error, please inform DTI Group Ltd via the above contact details. If you are not the intended recipient, you may not use or disclose the information contained in this email or attachments.

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Mayuri Tendulkar | 24 May 07:26 2016

Query regarding coreboot for new intel customized board

Hi team

 

I am working on building coreboot for one of our customized board. This is based on Intel ISX board reference design, reference can be taken as Minnowboard or BayleyBay CRB.

 

As per documentation given under coreboot, I created folder with my board name under src/intel/mainboard/xxx and did changes required.

 

If I tried the coreboot with these changes on minnowboard, it got stuck at FSP MRC Cache not found.

 

But if the same code changes I copied under  src/intel/mainboard/minnowmax and built, it booted fine.

 

I would like to know what is the importance of these board names, SMBIOS table name, serial no which are defined for Minnowmax.

 

Is there some master registry where all these are stored, and if any new entry comes, how we should add it.

 

Regards

Mayuri

 

 

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Patrick Rudolph | 23 May 17:42 2016

Re: ThinkPad x220 - Status

On 2016-05-23 05:20 PM, Nuno Moreira wrote:
> Hi Iru, Arian and Alexander.
> Thanks a lot for your feedback :)
> 
> Trying to reply to your input and presenting some questions emerging
> from it:
> 
> [IRU] "X220 has been supported for years :)"
> [/ME] Indeed. My mistake. After a better Internet search, I can see
> support at least since 2013. Thanks for the correction, Iru ;)
> 
> [IRU] "To unlock RAM speed in coreboot, you can see my article, but I
> haven't tested it yet."
> [/ME] Thanks a lot for this. I think I'll take the "risk" ant try to
> get 1866Mhz speed (fingers crossed).
> 
> [IRU] "tp-smapi depends on the proprietary firmware, and you can set
> the battery threshold with ectool."
> [/ME] Oh, this is great. I was not aware of this tool. I was looking
> to tpacpi-bat as an alternative. Gotta check what fits me&scripts
> better.
> 
> [ARIAN] "If you had damaged the ME firmware, you would not reach
> coreboot or any other firmware - the blob is signed"
> [ARIAN] "If you had damaged the NIC firmware, ethernet would probably
> be broken, so that's clearly defined."
> [/ME] That's good to know. Everything should be ok then, since BIOS
> can boot and Ethernet is working fine :)
> 
> [ARIAN] "refining the wiki would be a good thing to do"
> [/ME] Indeed. I'll try to update the Wiki after I finished my testing.
> 
> [ARIAN] "That's RAM _clock_ not data rate which is double the clock
> rate (-> DDR) - you're not any worse off than with the original
> firmware."
> [/ME] Also good news. This means the current speed is the default
> maximum of 1333 MHz. The problem in dmidecode info presentation is
> probably related with the issue Alexander presents below then.
> 
Should we put the DDR frequency or real frequency here ?
From users point of view DDR frequency does make more sense.
It looks like some vendors put DDR frequency and others the real
frequency here...

> [ALEXANDER] "we might written the wrong value into dmidata. (dmidecode
> reads a description written by the firmware, has nothing to do with
> the real values)."
> [/ME] This is the most "logical" possibility I think. DO YOU GUYS KNOW
> ABOUT ANY OTHER METHOD TO GET/READ THE "REAL" RAM CLOCK SPEED? I would
> like to apply the RAM speed unlock patch presented by Iru and check
> the speed with different RAM modules (2x4G 1333Mhz and 2x8GB 1866Mhz)
> in order to confirm if the max speed is really unlocked. But if
> dmidecode always presents 667MHz as RAM speed I will never know if it
> is working or not :(
> 
The "real" frequency is the value reported by dmidecode.
It is the frequency the ram is running at, it isn't hardcoded to 667Mhz.
You can use it to verify the current RAM speed.
I don't think there's another linux tool to get real values.

> [ALEXANDER] "tp smapi depends on lot of SMM/SMI code. So tp-smapi
> kernel module asked the Lenovo BIOS to tell the EC to do something.
> coreboot don't want to support SMM/SMI APIs, because they are quite
> dangerous. But there is another way to get those features back. We
> know how to enable it, but we haven't yet create a way to control this
> by the user. One thing could be a userspace tool executed as root or
> we add another CMOS configuration for it. Any idea?"
> [/ME] Thanks for the clarification, Alexander. Well, in my user
> perspective, I think a user-space tool will be better because it can
> be used to update the thresholds more easily. If we only rely on CMOS
> config we would need to re-flash it every time we want to change the
> thresholds. (AFAIK, x220 only supports HW flash. We cannot re-flash
> from OS).
> 
> [ALEXANDER] "It looks you're using the native graphics init instead of
> the binary blob VGABIOS. The last time I tried it, I had a lot of
> problems."
> [/ME] Yes, I'm using NGI. I did not suffer from the well-know "one
> color blur image" problem yet.
> 
> [ALEXANDER] "Thanks for your feedback. Feel free to create tickets or
> updating the x220 wiki page."
> [/ME] You're welcome and Thanks for your support. I'll definitely try
> to update the Wiki after I finished my testing.
> 
> --sigkill
> 
> On Mon, May 23, 2016 at 3:02 PM, Alexander Couzens <lynxis <at> fe80.eu>
> wrote:
> 
>> hey,
>>
>> nice you made it!
>>
>>> *3) Coreboot rocks but... Current Open issues:*
>>> ---------------------------------------------
>>> I decided to use coreboot-4.4 release instead of git-master.
>>> As payload I'm using SeaBIOS (booting Archlinux with Syslinux as
>>> bootloader).
>> That's ok.
>>
>>> Before, with dmidecode -t 17 the speed was 1333Mhz and now it is
>> just
>>> 667Mhz...
>> we might written the wrong value into dmidata. (dmidecode reads a
>> description written by the firmware, has nothing to do with the real
>> values).
>>
>>> *3.2) TP-SMAPI: *
>>> --------------
>> tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module
>> asked the Lenovo BIOS to tell the EC to do something. coreboot don't
>> want to support SMM/SMI APIs, because they are quite dangerous.
>> But there is another way to get those features back.
>> We know how to enable it, but we haven't yet create a way to control
>> this by the user.
>>
>> One thing could be a userspace tool executed as root or we add
>> another
>> CMOS configuration for it. Any idea?
>>
>>> *3.3) Config files:*
>>> ------------------
>>> coreboot - http://pastebin.com/9ymtxLBW
>> It looks you're using the native graphics init instead of the binary
>> blob VGABIOS. The last time I tried it, I had a lot of problems. [3]
>>
>> Thanks for your feedback. Feel free to create tickets or updating
>> the
>> x220 wiki page.
>>
>> Best,
>> lynxis
>>
>> [3] https://ticket.coreboot.org/issues/37
>> --
>> Alexander Couzens
>>
>> mail: lynxis <at> fe80.eu
>> jabber: lynxis <at> fe80.eu
>> mobile: +4915123277221 [1]
>> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
> 
>  
> 
> Links:
> ------
> [1] tel:%2B4915123277221

Regards,
Patrick

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Nuno Moreira | 23 May 15:00 2016
Picon
Gravatar

ThinkPad x220 - Status

Hello, everyone.

First of all, I would like to thanks and to congratulate all the community who helps to develop and to optimize this great project. Keep it up :)

I would appreciate if you can give me some opinions or point me to someone who will, regarding the Open Issues I present below (3.1 and 3.2).
Trying to give you a brief contextualization of my status before and after Coreboot.

1) Init:
--------
Recently I bought a refurbished x220 and flashed it with a custom BIOS (Lenovo ThinkPad x220_1.40-(8DET70WW)-8duj26us_NWL_ADV_AES_PM_Speedo) because I wanted to unlock the RAM speed to be 1866MHz (max RAM speed is locked to 1333Mhz in official BIOS), white-list some Wi-Fi cards, Advanced Chipset Config menu, etc.

This custom BIOS worked perfectly until I changed some settings related with Intel VT-x. If I recall correctly, I activated SR-IOV for PCI-E, saved and exited and after that x220 = BRICKED.

I tried every typical troubleshooting/workaround (Removing as much HW as possible, unplug BIOS battery for hours, etc), nothing worked.
x220 BIOS never booted again and the machine was in a constant boot loop. Don't know why/how this happened in the first place, but since it is a custom BIOS and it is very hard to reach the developer, I knew I could never get it to work without an intrusive method...  

2) Coreboot as Salvation:
-------------------------
I started to look for alternatives, and luckily, Coreboot supports x220 since a couple of months ago :)
After dealing with all the learning curve to understand the minimal requirements to compile and install Coreboot (tricky part is basically the need for HW flashing) I managed to get a working BIOS and x220 is now (almost 100%) operational :)
I've read and used the blobs from the "damaged" custom BIOS. I'm not sure if this can affect the functionality of Coreboot. Apparently, it does not.
(Let me know if anyone of you need details/help about/with the HW flashing in this type of chip (MX25L6406E/MX25L6408E)).

3) Coreboot rocks but... Current Open issues:
---------------------------------------------
I decided to use coreboot-4.4 release instead of git-master.
As payload I'm using SeaBIOS (booting Archlinux with Syslinux as bootloader).

3.1) RAM speed:
---------------
I've 2 x 8GB DRR3-1866MHz installed. The 16GB are detected but the speed reported is just 667MHz.
With the official BIOS, the max speed was 1333Mhz. Don't know how Coreboot is handling this subject in this particular main-board...
DDR timings are a little bit confusing to me, I guess...

Before, with dmidecode -t 17 the speed was 1333Mhz and now it is just 667Mhz...
This 667MHz speed I get with coreboot is 2x667=1333Mhz or in reality is 2x333MHz?
In "northbridge/intel/sandybridge/raminit.c" we can see the following statement:

    /* Maximum supported DDR3 frequency is 1066MHz (DDR3 2133) so make sure
     * we cap it if we have faster DIMMs.
     * Then, align it to the closest JEDEC standard frequency */

=> So, if I'm understanding it correctly, current 667 Mhz is not the maximum
speed supported.
Any idea on how I can get higher speeds?

3.2) TP-SMAPI:
--------------
Looks like tp-smapi is not available using Coreboot. It was OK with the official and custom BIOS before.
From what I've read, this is not a Coreboot limitation... Not sure if the blobs/EC are not ok for tp-smapi now...
I use tp-smapi for battery threshold, etc. TLP also uses tp-smapi. So it is kinda of important to me.

=> Anyone using tp-smapi with no problems out there?

3.3) Config files:
------------------
coreboot - http://pastebin.com/9ymtxLBW
seabios - http://pastebin.com/rUU7ajRH
cmos.default - http://pastebin.com/Pm5vS15R

Thanks in advance, guys.
All the best \o

--sigkill

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
David Griffith | 23 May 12:28 2016
Gravatar

Need a bigger CBFS size. What's a save value?


I'm experimenting with a Thinkpad T60p, specifically getting something 
working that includes PXE and secondary payloads.  Apparently the default 
CBFS size of 0x40000 is too small because the build process complains it 
can't add ipxe.rom and guesses that there's no room.  Just now I tried 
specifying a size of 0x200000, thinking that would work because I have a 
two megabyte SPI flash chip.  I went through the procedures on 
https://www.coreboot.org/Board:lenovo/t60 and 
https://www.coreboot.org/Board:lenovo/x60/Installation which led to a T60p 
that shows a black screen and is non-responsive.  So, I guess that was a 
wrong value.

So, what's a safe value for the CBFS size that will allow me to add PXE 
and some other secondary payloads?

-- 
David Griffith
dave <at> 661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Martin Roth | 23 May 03:30 2016
Picon
Gravatar

Re: SeaBios serial(RX) is not running.

Kyösti, thanks for doing that.

On Mon, May 23, 2016 at 12:47 AM, 김유석 책임연구원 <kay.kim <at> hansol.com> wrote:
> Dear Sir.
>
> Thank's your work.
>
>
> Enable the bi-direction serial console is done.
>
>
> 2016-05-20 오후 8:36에 Kyösti Mälkki 이(가) 쓴 글:
>
>
>
> On Tue, May 17, 2016 at 10:46 PM, Martin Roth <gaumless <at> gmail.com> wrote:
>>
>> Hi,
>>   If you want bi-directional serial port in SeaBIOS, I think you need
>> to stick with the version from Sage. As far as I know, it's never been
>> supported in the upstream SeaBIOS version.
>>
>
> I have pulled this serial to keyboard mapping change from SageBIOS and
> posted on the seabios list today. Hitting ESC and changing boot media seemed
> to work.
>
> BR,
> Kyösti
>
>
>

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
thejapanscout . | 21 May 23:14 2016
Picon

Coreboot, supporting this Dell laptop motherboard?

I want to see if coreboot could support an old Latitude D510 I have from late 2005. It's suitable for low-end operations such as running Firefox and computations, and I'm currently running Lubuntu on this thing.

Vendor: Dell
Motherboard ID: 3TZKF91, according to dmidecode -s system-seriel-number
CPU: Pentium M, Type 0, Family 6, Model 13, Stepping 8
Northbridge/Southbridge: likely 82915GM(?), ICH6/M Southbridge

lspci -tvnn output:
-[0000:00]-+-00.0  Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590]
           +-02.0  Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592]
           +-02.1  Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792]
           +-1d.0  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658]
           +-1d.1  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 [8086:2659]
           +-1d.2  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 [8086:265a]
           +-1d.3  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 [8086:265b]
           +-1d.7  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c]
           +-1e.0-[02-06]--+-00.0  Broadcom Corporation BCM4401-B0 100Base-TX [14e4:170c]
           |               +-01.0  Texas Instruments PCI6515 Cardbus Controller [104c:8036]
           |               +-01.2  Texas Instruments Device [104c:8037]
           |               \-03.0  Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318]
           +-1e.2  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller [8086:266e]
           +-1e.3  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller [8086:266d]
           +-1f.0  Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge [8086:2641]
           \-1f.2  Intel Corporation 82801FBM (ICH6M) SATA Controller [8086:2653]

There is no Super I/O chip on the mainboard, nor one can be detected by superiotool. Sadly, this is where my venture ends here as flashrom refuses to identify the motherboard because it halts if it finds an unsupported laptop, so I can't identify the flash chip. SPI, maybe?
--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
David Griffith | 20 May 06:33 2016
Gravatar

Re: permissions error building external payload

On Thu, 19 May 2016, Martin Roth wrote:

> -coreboot mailing list
>
> Everyone with a coreboot gerrit account automatically has the rights
> to push, but you may need to configure some things.
>
> Log into the coreboot gerrit if you haven't already done it.
> Once logged in, you'll need to set a username first thing.
> Next, upload your ssh key or generate an html password.
>
> If you downloaded the original repo that you've been working in with
> anonymous http, at this point you'll want to set a new remote or
> origin with the new repo information if you're good with git, or just
> clone a new copy of the repo if you're not reasonably expert in git.
>
>
> Make sure you run 'make gitconfig' to set up the hooks.  You need the
> commit-msg hook at the very least to generate the change-id line in
> the commit message.
>
> Here's the page about git & gerrit on our wiki.  https://www.coreboot.org/Git
>
>
> If it's git that's telling you you need push rights, you're trying to
> push directly into git, not into gerrit.  running 'make gitconfig'
> should take care of this as well.  Make sure you amend your commit to
> get the change-id into the commit message if that's the case.
>
> For the future though, this is the command to push into gerrit:
> git push origin HEAD:refs/for/master

Ah, I see.  I didn't do "make gitconfig".  So, I pulled down a fresh copy 
of the repo, did "make gitconfig", applied my changes, then typed "git 
commit -a".  I got this:

===begin quote===
...
lint-stable-013-site-local
Verify that site-local is not in the coreboot repository
========
success
========
WARNING: please write a paragraph that describes the config symbol fully
#33: FILE: payloads/external/OpenBIOS/Kconfig:7:
+config OPENBIOS_STABLE

WARNING: please write a paragraph that describes the config symbol fully
#38: FILE: payloads/external/OpenBIOS/Kconfig:12:
+config OPENBIOS_MASTER

total: 0 errors, 2 warnings, 117 lines checked
===end quote===

Where should these paragraphs go?  Basically I just copied and adapted 
what I found in payloads/external/SeaBIOS.

-- 
David Griffith
dave <at> 661.org

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot


Gmane