https://review.coreboot.org/21774
In case anyone else didn't notice - It is a sandy/ivy system with IOMMU.
This is great and should help get coreboot in to the corporate user world.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
Ok, I’ve found one more solution: don’t generate ACPI C-state tables.
In "devicetree.cb" replace all C-states registers with 0, indicating C0 state.
register "c1_battery" = "0" #"2" # ACPI(C1) = MWAIT(C1E)
register "c2_battery" = "0" #"3" # ACPI(C2) = MWAIT(C3)
register "c3_battery" = "0" #"9" # ACPI(C3) = MWAIT(C7S)
register "c1_acpower" = "0" #"2" # ACPI(C1) = MWAIT(C1E)
register "c2_acpower" = "0" #"3" # ACPI(C2) = MWAIT(C3)
register "c3_acpower" = "0" #"9" # ACPI(C3) = MWAIT(C7S)
After this change coreboot wouldn't generate _CST tables for ACPI C-states.
Original BIOSes of two Haswell motherboards that I have, don’t generate _CST tables, so maybe it is not so bad.
But I don’t quite understand why even without those tables "cpupower idle-info" and "cpupower monitor -m Idle_Stats" shows that CPU enters and exits all supported C-states. Btw, Haswell ULT has a lot of C-states: C0, C1, C1E, C2E, C3, C6, C7, C8, C9, C10.
There are a lot of MSRs to control C-states + two alternative interfaces in ACPI (_CST and FADT), so it is quite hard for me to check if all of it is done correctly.
State C3 and lower flush core caches, so maybe this is the reason why commit about EHCI command solves my issue.
Also I've found interesting part in Haswell BWG:
"
Idle Duration Reporting is the capability for devices to communicate to the processor
about their planned period of activity or idleness. Based on when the device would next
interrupt the core, the PCU can place the core in an appropriate idle state.
• On 4th Generation Intel® Core™ processors, cores are expected to report their Idle
Duration time via the respective APIC timers. Since 4th Generation Intel® Core™
processors support Always running APIC timer (ARAT), the PCU will save this data
when cores are in a deep sleep state and use the closest expiring timer value as the
Device Idle duration.
"
So, maybe without APIC-timer cores can't report their activity/idleness time and C-states are not supported?? That is why boot with "noapictimer" doesn't have problems.
Or maybe all problems are from wrong APIC timer. What do you think? What part of ACPI code is responsible for APIC timer setting?
One more interesting observation:
"
On previous processors, the chipset was responsible for actually changing the
processor C-state seen by the package. On 4th Generation Intel® Core™ processors,
this logic moves to the System Agent, and the chipset is no longer responsible for
driving processor package C-state transitions.
"
Can it be that mrc.bin (System Agent blob) just doesn't configured for C-states?
And at the end I want to notice, that according to BWG BIOS should expose different C-states tables to different OSes by reading _PDC method and coreboot doesn't do it at all.
P.S.: This issue was also responsible for USB stuck in Windows 7. So this problem is seems more important than support of some old Linux kernels.
From: Аладышев Константин [mailto:aladyshev@nicevt.ru]
Sent: Thursday, October 19, 2017 5:57 PM
To: 'ron minnich'; 'Julius Werner'
Cc: 'Coreboot'
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
No, unfortunately this option by itself doesn’t help.
I guess my minimal hammer is ‘noapictimer’
But I wonder how these 3 boot parameters (‘noapictimer’ ‘nolapic’ and ‘acpi=off’) separately help to solve my issue.
What part is wrong in ACPI and correct in MP-table? Maybe the problem is in ACPI MADT table? But it doesn’t really have much info that can be wrong. The one strangeness I found compared to original BIOS is mapping between ProcID and APIC ID in lapic entries.
Coreboot has straightforward: 0-0, 1-1, 2-2, 3-3.
But original BIOS has: 1-0, 2-2, 3-1, 4-3
I wonder if it means something?
From: ron minnich [mailto:rminnich@gmail.com]
Sent: Thursday, October 19, 2017 5:29 PM
To: Аладышев Константин; Julius Werner
Cc: Coreboot
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
we had a similar problem and we set
pci=nocrs
which means 'ignore what ACPI tells you and probe it again"
It's much less of a big hammer than 'acpi=off' :-)
On Thu, Oct 19, 2017 at 7:22 AM Аладышев Константин <aladyshev(a)nicevt.ru> wrote:
I've found one more parameter that helps me boot without USB problem: 'noapictimer'
-----Original Message-----
From: Аладышев Константин [mailto:aladyshev@nicevt.ru]
Sent: Wednesday, October 18, 2017 3:58 PM
To: 'Julius Werner'
Cc: 'Coreboot'
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
Ok, I've done some investigations about what can be the source of my problem:
1) last value of COMMAND register from BIOS I've dumped all EHCI registers (pci and memory) at the beginning of linux kernel EHCI initialization. And to my surprise pretty all memory registers in original BIOS look like almost uninitialized compared to my coreboot+seabios image. I don't really know how to work with EHCI controller, but seabios do it through periodic and async schedule and their enable bits (in COMMAND register from commit!) aren't active in original BIOS. I've tried to disable ehci initialization in seabios and after that registers dump started to look almost the same, compared to original bios, but it didn't solve my issue. Also without them USB doesn't work in grub. So it doesn't seem like BIOS last value of COMMAND register really matter.
2) SMI
There are special registers for EHCI controller SMIs in its pci config space:
-USB EHCI Legacy Support Extended
-Intel Specific USB 2.0 SMI
But in both of them SMIs are disabled as in coreboot+seabios image as in original bios.
3) ACPI
In original BIOS ACPI doesn't do anything to EHCI COMMAND register from commit. It doesn't have a name for it or declare it in some region. Anyway I've copied almost all asl EHCI controller code, but it didn't help.
BUT! I've provided MP-table and PIRQ table to coreboot and I can say that the problem disappears when I boot with 'acpi=off' parameter!
Also it disappears when I boot with 'nolapic' parameter
What do they have in common??
-----Original Message-----
From: jwerner(a)google.com [mailto:jwerner@google.com] On Behalf Of Julius Werner
Sent: Tuesday, October 10, 2017 5:56 AM
To: Аладышев Константин
Cc: Coreboot
Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
> And now I'm kinda stuck. The effect of this commit doesn't seem to
> interface with bios for me. So how does original IBASE/DFI bios can
> overcome code error before this commit?
>
> What can be the source of my problem? What should I investigate more
> precise based on result that I've got?
My gut feeling would be to blame ACPI. The Linux patch is about caching a host controller register in the kernel, and in some cases (e.g. ehci_reset()), the patch re-reads the cached version from the hardware whereas the previous code didn't. If some BIOS ACPI mucks with that register, it's possible that this got the kernel's cached copy out of sync before this patch, but with the patch the kernel will re-read it from the hardware at the right time. Maybe only coreboot's ACPI routines touch the register in that path, or maybe the vendor BIOS' routines were more careful to restore the original state afterwards.
Besides ACPI this could also be in SMM code, I guess (especially if the problem occurs around system suspend/resume, although it sounds like it doesn't for you).
--
coreboot mailing list: coreboot(a)coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
There was a talk about the registration process on the wiki and the bugtracker. At the moment its not possible to register and use both systems for example after 2 minutes. Typical user when they want to make a quick edit in a wiki or report a bug are willing to spend around 5 minutes. This include registration and reporting/editing. This is the typical usecase. Because many people normaly did not edit a webpage regulary but want to make a change once, wikipedia for example have made the great solution to just have to press edit button. The change is then beeing reviewed by some wikipedia editor and confirmed. This can take on some pages also a month of time - but that does not matter that much because the information is been produced and its there.
The coreboot maintainer agreed that the recent registration process should be changed. There was a talk about to use a irc bot + webchat for that instead of the more common captcha.
I think IRC would not be something that all people understand directly but ok, it would be still better then the solution we have now.
But please dont use freenode irc or any other IRC server that are blocking TOR users. There are people that run TOR exit nodes at home. Those people are providing great diversity for having a non centrialized TOR network.
Freenode is a terrible example of a network that is blocking people who try to give everyone on the world free internet access. Please do not use freenode if you implement such a IRC-registration process. Please run your own IRC server for such things to not block any IP on this world. IP- or port-blocking is discrimination of usecases and it is a bad example of not following the net neutrality.
Net neutrality is important. Please dont move coreboot into the situation that you cant register because of broken net neutrality.
I don’t think that the problem is connected to operating system version as both Windows 7 and Ubuntu 16.04 act the same for me:
- for S3 time less than ~15s, resume works ok
- for S3 time longer than ~15s, Coreboot won't resume with quick_ram_check error
I use “pm-suspend” to go to S3, but “systemctl suspend” works exactly the same. USB wakeup doesn't work at all for me. I wake system with power button.
From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com]
Sent: Tuesday, October 31, 2017 10:19 AM
To: Аладышев Константин
Cc: Coreboot
Subject: Re: [coreboot] Does S3 work on Haswell boards?
Hello Kostja,
Since presently I am not in Munich/Germany (I am in front of my HSW notebook in my apartment in Belgrade), I have limited abilities to test your question, since I do not have native/bare metal Fedora on my SSD (I have in safe box HDD with dual boot: WIN10 and Fedora 26 in Munich).
Here, I have my notebook (HP EliteBook 840 G1) with SSD, bare metal WIN10 64 PRO and VMWare reader with Fedora 26 VM. IT is based on HSW i5-4300:
[user@192 ~]$ dmesg | grep 4300
[ 0.097524] smpboot: CPU0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz (family: 0x6, model: 0x45, stepping: 0x1)
[user@192 ~]$
Here is the pointer to ark.intel.com for this CPU: https://ark.intel.com/products/76308/Intel-Core-i5-4300U-Processor-3M-Cac...
The current BSP used is UEFI: BIOS 01.39 Rev.A (08 Nov 2016) -> sp77791.exe (12.7 MB)
_______
Being in WIN10, suspend works when I simply press <F3>, but resume works ONLY while I press muse buttons - keyboard <ANY KEY> does not work, although it should?!
I did several attempts to suspend and resume using Fedora 26 VM, but I did not have success. I do remember that this does work with my bare metal Fedora 26:
Kernel used for Fedora26 VM: uname -r -> 4.13.9-200.fc26.x86_64 .
I would strongly suggest to use two methods to check S3 on Linux bare metal:
[1] To use systemctl suspend and systemctl resume commands;
[2] To install on your HSW platform the following package: http://www.linuxfromscratch.org/blfs/view/cvs/general/pm-utils.html
so you can try the following two commands: pm-suspend and pm-hibernate (wakeup should work using keyboard/mouse)!
First, you should do all these tests with UEFI BIOS for your platform, record the results, and then switch to Coreboot, than repeat all use cases, and cross compare.
If you do, please, post your kernel version and results here.
Hope this helps.
Best Regards,
Zoran Stojsavljevic
_______
On Mon, Oct 30, 2017 at 4:49 PM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote:
I have problem with S3 mode on Haswell board. Everything is fine if S3 time
is very small (<15 seconds), but if it is longer, coreboot won't resume. It
fails on quick_ram_check.
I've enabled mrc.cache and ME in coreboot. I use ME binary from original
board and MRC.bin from Google Panther.
Log from S3 resume:
"""
Disabling Watchdog reboot... done.
SMBus controller enabled.
Setting up static northbridge registers... done.
Initializing Graphics...
Back from haswell_early_initialization()
Resume from S3 detected.
CPU id(40651) ucode:0000001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
AES supported, TXT supported, VT supported
PCH type: LP Premium, device id: 9c43, rev id 4
Starting UEFI PEI System Agent
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xfffff7d0/0x1000000
CBFS: CBFS location: 0xf00000~0xfff7c0, align: 64
CBFS: Looking for 'mrc.cache' starting from 0xf00000.
CBFS: - load entry 0xf00000 file name (16 bytes)...
CBFS: (unmatched file @0xf00000: bootsplash.jpg)
CBFS: - load entry 0xf187c0 file name (16 bytes)...
CBFS: (unmatched file @0xf187c0: bootorder)
CBFS: - load entry 0xf18b80 file name (16 bytes)...
CBFS: (unmatched file @0xf18b80: cmos_layout.bin)
CBFS: - load entry 0xf19040 file name (32 bytes)...
CBFS: (unmatched file @0xf19040: pci8086,0a26.rom)
CBFS: - load entry 0xf29080 file name (72 bytes)...
CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin)
CBFS: - load entry 0xf2e100 file name (32 bytes)...
CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt)
CBFS: - load entry 0xf2e140 file name (16 bytes)...
CBFS: (unmatched file @0xf2e140: config)
CBFS: - load entry 0xf2fa00 file name (16 bytes)...
CBFS: (unmatched file @0xf2fa00: revision)
CBFS: - load entry 0xf2fc80 file name (16 bytes)...
CBFS: (unmatched file @0xf2fc80: )
CBFS: - load entry 0xf2ff80 file name (76 bytes)...
CBFS: (unmatched file @0xf2ff80: fallback/romstage)
CBFS: - load entry 0xf38f00 file name (32 bytes)...
CBFS: (unmatched file @0xf38f00: fallback/ramstage)
CBFS: - load entry 0xf4d0c0 file name (32 bytes)...
CBFS: (unmatched file @0xf4d0c0: fallback/payload)
CBFS: - load entry 0xf5e8c0 file name (32 bytes)...
CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom)
CBFS: - load entry 0xf6e900 file name (16 bytes)...
CBFS: (unmatched file @0xf6e900: )
CBFS: - load entry 0xf9ffc0 file name (40 bytes)...
CBFS: (unmatched file @0xf9ffc0: mrc.bin)
CBFS: - load entry 0xfceb40 file name (16 bytes)...
CBFS: (unmatched file @0xfceb40: )
CBFS: - load entry 0xfdffc0 file name (40 bytes)...
CBFS: Found file (offset=0xfe0000, len=65536).
find_current_mrc_cache_local: picked entry 0 from cache block
prepare_mrc_cache: at fffe0010, size fe0 checksum 9771
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xfffff7d0/0x1000000
CBFS: CBFS location: 0xf00000~0xfff7c0, align: 64
CBFS: Looking for 'mrc.bin' starting from 0xf00000.
CBFS: - load entry 0xf00000 file name (16 bytes)...
CBFS: (unmatched file @0xf00000: bootsplash.jpg)
CBFS: - load entry 0xf187c0 file name (16 bytes)...
CBFS: (unmatched file @0xf187c0: bootorder)
CBFS: - load entry 0xf18b80 file name (16 bytes)...
CBFS: (unmatched file @0xf18b80: cmos_layout.bin)
CBFS: - load entry 0xf19040 file name (32 bytes)...
CBFS: (unmatched file @0xf19040: pci8086,0a26.rom)
CBFS: - load entry 0xf29080 file name (72 bytes)...
CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin)
CBFS: - load entry 0xf2e100 file name (32 bytes)...
CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt)
CBFS: - load entry 0xf2e140 file name (16 bytes)...
CBFS: (unmatched file @0xf2e140: config)
CBFS: - load entry 0xf2fa00 file name (16 bytes)...
CBFS: (unmatched file @0xf2fa00: revision)
CBFS: - load entry 0xf2fc80 file name (16 bytes)...
CBFS: (unmatched file @0xf2fc80: )
CBFS: - load entry 0xf2ff80 file name (76 bytes)...
CBFS: (unmatched file @0xf2ff80: fallback/romstage)
CBFS: - load entry 0xf38f00 file name (32 bytes)...
CBFS: (unmatched file @0xf38f00: fallback/ramstage)
CBFS: - load entry 0xf4d0c0 file name (32 bytes)...
CBFS: (unmatched file @0xf4d0c0: fallback/payload)
CBFS: - load entry 0xf5e8c0 file name (32 bytes)...
CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom)
CBFS: - load entry 0xf6e900 file name (16 bytes)...
CBFS: (unmatched file @0xf6e900: )
CBFS: - load entry 0xf9ffc0 file name (40 bytes)...
CBFS: Found file (offset=0xfa0000, len=191236).
System Agent: Starting up...
System Agent: S3 resume detected
System Agent: Initializing PCH
install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845}
install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276}
System Agent: Initializing PCH (SMBUS)
System Agent: Initializing PCH (USB)
System Agent: Initializing PCH (SA Init)
System Agent: Initializing PCH (Me UMA)
System Agent: Initializing Memory
System Agent: Done.
Sanity checking heap.
System Agent Version 1.6.1 Build 2
memcfg DDR3 clock 1600 MHz
memcfg channel assignment: A: 0, B 1, C 2
memcfg channel[0] config (00600010):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 4096 MB width x8 or x32 single rank, selected
DIMMB 0 MB width x8 or x32 single rank
memcfg channel[1] config (00600000):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 0 MB width x8 or x32 single rank, selected
DIMMB 0 MB width x8 or x32 single rank
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Initializing
ME: Current Operation State : Bring up
ME: Current Operation Mode : Normal
ME: Error Code : Debug Failure
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean global reset
ME: Progress Phase State : 0x7b
before quick_ram_check
RAM INIT FAILURE!
""""
It seems like DRAM controller and ME are initialized correctly (like in
normal boot), what can be wrong?
Does S3 work on Haswell boards?
--
coreboot mailing list: coreboot(a)coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Hi Branden,
I read your message and boot log on the web archives, so I can reply.
Copying you direct so we can connect directly - I'm (also) only
subscribed to a daily digest.
So you can indeed use an unmodified asus/p2b build. Perfect. Going
forward you can act as if you have a p2b. We'll note elsewhere this
mainboard can also support a p2-99.
Your boot log does indicate the same missing MBRS error I got. Now I
know what I need to do next.
The early CBMEM init patch is here: https://review.coreboot.org/c/22228/
Apply it to a clean p2b build, config for a spew debug level, and see
if you can capture a log over serial. Also try the two cbmem commands
Paul provided in the patch and see what you get.
Looking forward to your results.
In reply to Keith.
Probably won't show up as a reply since I wasn't subscribed to the
list. I am now though, so it should work out now. I also had to
rewrite this, since gmail didn't like noscript refreshing the page
when I enabled javascript from google to register on gerrit.
My config was actually just the unmodified P2B build originally, but
not built with the coreboot toolchain. As for the modified config, it
was just P2B with the naming changed to P2-99.
Looking at the picture of the P2B board in the wiki again, the P2-99
may actually just be the same board with one of the ram sockets
unpopulated and the 440ZX northbridge chip.
I haven't been able to get flashrom to find the flash chip, despite it
recognizing the chipset and using compatible eeproms - I flashed them
with coreboot on a different board after all.
Running a git build of flashrom didn't help either, still couldn't
find the flash.
It's got an AS97127F, not an AS99127F. I tried to use the trick you
linked from the P3B-F, but i2cset just reported a failure to write. I
had previously tried getting flashrom to use some other board enables
and that didn't work either.
I attached a dmesg log with the ACPI errors. I don't know whether it's
related to a missing MBRS table as you said. It also shows "[Firmware
Bug]: the BIOS has corrupted hw-PMU resources (MSR 186 is 40002e)"
after a reboot. It did that with every build I've tried and not
specific to the ACPI patched version.
I just made a clean unmoddified build for P2B with the coreboot
toolchain. Might only get to flashing it tommorrow though.
I did get signed in on gerrit, so I should be able to run board_status on it.
If you get the early cbmem init patch uploaded I'll try to test that
right away as well.
Hello everyone.
I recently purchased a used Thinkpad X220 with Intel i7-2620M (SandyBridge) CPU,
and have installed coreboot since day one. Everything seemed to work well, but
since then this laptop suffered from shutting down randomly.
The random shutdown appears to be completely random, the machine just simply lost
power as if someone pulls the plug, without any possible precautions. It occurs
with or without battery installed, or the source of power, and determinated
to be irrelevant to CPU temperature. In fact, the system is less likely to shutdown
if it was performing computation-intensive tasks. It occurs on multiple versions
of Linux kernel, stable and master branch of coreboot.
On my system, it also has some random hangs as described in Ticket #121 [1], but I
believe it's a independent issue not related these mysterious shutting downs.
A quick search on the Internet showed many similar reported cases.
https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/Major-X220-Motherb...https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X220-Random-Shutdo...https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/I-ve-bought-the-be...https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/x220-random-shutdo...https://forums.lenovo.com/t5/ThinkPad-X-Series-Laptops/X220-Random-shutdo...https://www.reddit.com/r/thinkpad/comments/3ex0rj/x220_random_hard_shutdown/https://forum.thinkpads.com/viewtopic.php?t=106961
And lots of possible reasons were purposed, from bad battery, bad RAM, to bad
keyboard. The most interesting suggestion was one source (Reddit) claiming a bad
keyboard connection may trigger a poweroff signal and another source also stated
a bended PCB under Trackpoint may short the power button cable and shut the machine
down randomly. I haven't check it on my machine so far...
But it looks like most of the problems were caused by the somewhat defective
motherboard. I'm going to purchase another X220 motherboard with Core i5 next
week, and possiblely to pay someone to rework the board, transplating the Core
i7 to the other motherboard.
Do you ever encountered a problem like this? What is your suggestion for me
to try before replacing the motherboard?
Cheers,
Tom Li
Hi all,
For my graduation project I have to implement the platform Broadwell-DE in U-Boot. Broadwell-DE needs FSP, and in U-Boot the only family to support FSP is BayTrail. I saw in its source code that the architecture is implemented from the files located in src/soc/intel/fsp_baytrail in Coreboot.
Can someone please point me out how to port src/soc/intel/fsp_broadwell_de in U-Boot? I know that I will not need to port all the files, but I don't know which one to be honest.
Thanks in advance!
Vincenzo
Sent with [ProtonMail](https://protonmail.com) Secure Email.
