coreboot November 2017

coreboot@coreboot.org

61 participants
110 discussions

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Аладышев Константин 02 Nov '17

02 Nov '17

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

2 1

Re: [coreboot] New bugtracker/wiki registration process - please do not use freenode irc servers
by dz6g239＠tuta.io 02 Nov '17

02 Nov '17

First: We want to make the registration progress more simple and fast. Have you read the broken (later more about that) howto you have posted? Tor users should not have to do anything more of work then regular users do. Otherwise it would be a discrimination of people who support tor. Its of course also agains the net neutrality. Data packages that have been send by different IP-Adresses should not be handled different. Second: Have you followed the howto by yourself? It writes at a point "First, you are going to need log into your Freenode account. ". I dont have a Freenode account and i dont think that everyone who want to register to coreboot to report a bug should already have a freenode account or otherwise he is lost. That would be a horrible situation. Third: The idea was/is to use a webchat link for verification. I dont know any SASL supporting webchat services that are able to connect to .onion IRC servers. So if IRC verification should be enabled for some reason, please run your own IRC server where you know by yourself that it does not block any single valid IP address from this planet. thanks > On 31.10.2017 15:50, > dz6g239(a)tuta.io> wrote: >> There was a talk about the registration process on the wiki and the >> bugtracker. [...] >> >> 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.[...] >> >> But please dont use freenode irc or any other IRC server that are >> blocking TOR users. > > https://freenode.net/kb/answer/chat> contradicts your claims. > There are loads of people on the net disagreeing with you as well, and > there are even HowTos: > https://medium.com/@defcon201/tutorial-connecting-to-freenode-via-tor-like-… > > So... have you actually tried it? > > Regards, > Carl-Daniel > > -- > coreboot mailing list: > coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] New bugtracker/wiki registration process - please do not use freenode irc servers
by dz6g239＠tuta.io 02 Nov '17

02 Nov '17

Thanks for your note. Please then run few tor exit nodes after you checked the law in your country to help the network. > > Those people are providing great diversity for having a non centralized TOR network. > > In sincere hope that TOR network will change (for the much better) state of Humanity, as it appears not to be in great shape in these modern times, after all! > Zoran > On Tue, Oct 31, 2017 at 3:50 PM, <> dz6g239(a)tuta.io> > wrote: > >> >> 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. >> >> -- >> coreboot mailing list: >> coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

BayTrail PCIe problems (hangup) in FSP (in U-Boot)
by Stefan Roese 02 Nov '17

02 Nov '17

Hi, I'm facing a PCIe init related problem most likely caused in the Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you don't mind me posting this question on this coreboot list, since here many more people are present with Intel FSP knowledge. So here we go: We are currently struggling with an FSP PCIe related issue on our BayTrail target. Here we use an PLX / Avago PCIe switch, connected to the PCIe root port of the CPU with a PCIe x4 link. The BIOS always boots fine. Only U-Boot doesn't boot at all. No output on the console. This is on some boards, somehow depending on the PLX switch that is connected. Measuring has shown, that the PCIe clock is only stable for ~20ms before data is transferred in the U-Boot case. In the BIOS case, the time between clock stable and data is ~120ms. The PCIe spec mentions, that the clock should be asserted for more than 100ms. So U-Boot is violating the spec here, which might be the root cause. I've now instrumented the U-Boot with many early debug and delay code and found, that it hangs inside of the FSP code. I then installed the DEBUG FSP blob and have found, that its stuck (as expected) in the FSP PCIe init: .... CommonUsbInit() - End ConfigureUsb() End PchInitRootPorts() Start Here the log from a different board, with stable and working 4 times x1 PCIe links (different board with 4 times x1 PCIe links -> pci-good): ... CommonUsbInit() - End ConfigureUsb() End PchInitRootPorts() Start Root Port 1 device enabled. RpEnableMask: 0xF Root Port 2 device enabled. RpEnableMask: 0xF Root Port 3 device enabled. RpEnableMask: 0xF Root Port 4 device enabled. RpEnableMask: 0xF PchInitRootPorts() End ConfigureSata() Start ... I've attached the logs, so that you can review them yourself as well. Do you have any ideas, whats going on in the PCI init stuff in the FSP? Or if and how we can influence this PCIe related configuration to solve this hangup inside of the FSP? Has such a problem or a similar one been noticed on some BayTrail platforms with coreboot before? BTW: I've just found a workaround (more ugly hack) to solve this issue. If I disable the link in the PCIe root port (PCI BDF 0,0x1c,0) in the LCTL register before jumping into the FSP, the FSP "survives" the init phase and jumps back into U-Boot. I can then re-force the link before the U-Boot PCI scan is done and then everything is fine. The PCIe PLX switch is detected correctly and all downstream ports seem to be working as expected. Thanks, Stefan

3 2

New bugtracker/wiki registration process - please do not use freenode irc servers
by dz6g239＠tuta.io 02 Nov '17

02 Nov '17

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.

7 7

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Kevin O'Connor 02 Nov '17

02 Nov '17

On Wed, Nov 01, 2017 at 03:28:45PM +0000, Scheithauer, Mario wrote: > Hi Tahnia, > > We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + SeaBios (master) running. > Attached are all necessary coreboot adaptions and the config file for SeaBios. > After the generation, a hack in coreboot.rom is still necessary so that SeaBios can find the VBIOS. > SeaBios expects at the end of the CBFS the address from the beginning of the CBFS section (see SeaBiosPointer.jpg). When you say "a hack in coreboot.rom", are you referring to the CONFIG_CBFS_LOCATION=0xfff9f000 seabios setting or was some additional change necessary? -Kevin

2 1

Re: [coreboot] ASUS P2-99 with P2B config
by Branden Waldner 02 Nov '17

02 Nov '17

I did manage to get a clean build that board_status wouldn't complain about being dirty. The problem was I couldn't clone board_status properly, have a crappy isp. I can probably clone it from some where else tommorrow, or else I'll have to wait a week. After using git clean I was able to actually build crossgcc-i386 on the 32bit debian stretch I've got setup with the p2-99. board_status didn't like the 64bit utils in the build directory after I copied everything over from the 64bit machine. Too bad I don't have a pata/sata adapter or use NFS, that would have made it easy to chroot into and build with a faster machine. I tried your cbmem patch https://review.coreboot.org/c/22228/ applied with git fetch https://review.coreboot.org/coreboot refs/changes/28/22228/1 && git checkout FETCH_HEAD. I've got a serial capture and the log of cbmem -c attached. cbmem -t fails with "Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory".

1 0

KGPE-D16 AMD-vi fails because combined sata is enabled
by Thierry Laurion 02 Nov '17

02 Nov '17

Xen error: (XEN) AMD-Vi: SP5100 erratum 28 detected, disabling IOMMU. (XEN) If possible, disable SATA Combined mode in BIOS or contact your vendor for BIOS update. (XEN) AMD-Vi: Error initialization (XEN) I/O virtualisation disabled -but HAP is working, (XEN) HVM: SVM enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB Src:https://lists.gt.net/xen/users/371020 AMD's SP5100 chipset can be placed into SATA Combined mode that may cause prevent dom0 from booting when IOMMU is enabled and per-device interrupt remapping table is used. While SP5100 erratum 28 requires BIOSes to disable this mode, some may still use it. src: https://lists.alpinelinux.org/alpine-devel/2724.html ENABLE_IDE_COMBINED_MODE available for sp800 but not for sp700, for ewhich sp5100 is derived from: https://www.coreboot.org/Coreboot_Options SP5100 Product Errata 46836 Rev. 3.00 June 2012 P.18 Product Errata 28 Incorrect IOMMU Table Accessed in SATA Combined Mode Description Systems with SP5100 SATA set to AHCI or IDE combined mode with SATA port 4 or 5 in use will use the SATA source ID for IDE DMA when consulting the IOMMU tables. Potential Effect on System Operating systems where the IDE and SATA tables are separated will experience I/O page faults. Several warnings will be issued during kernel initialization, ultimately leading to the inability to boot the operating system due to the boot disk not being found. Suggested Workaround Disable combined mode by setting a platform BIOS callback option to CIMx called "SataIdeCombinedMode" to 0. This change will not have an impact on AHCI/RAID mode, however, in IDE mode, the total number of available ports is reduced by two. Fix Planned No src:https://support.amd.com/TechDocs/46836.pdf Coreboot: Release 4.6 Xen: 4.8.x Xen code responsible for detection: https://github.com/xenserver/xen-4.3.pg/blob/master/tweak-iommu-errata-poli… Is there something i'm missing? Is it possible to disable combined sata mode for sb700 from coreboot? Thanks, Thierry

1 0

Re: [coreboot] Problems changing payload on Intel Leaf Hill
by Scheithauer, Mario 01 Nov '17

01 Nov '17

Hi Tahnia, We have an APL CRB Oxbow Hill (B0-stepping) with coreboot (master) + SeaBios (master) running. Attached are all necessary coreboot adaptions and the config file for SeaBios. After the generation, a hack in coreboot.rom is still necessary so that SeaBios can find the VBIOS. SeaBios expects at the end of the CBFS the address from the beginning of the CBFS section (see SeaBiosPointer.jpg). Furthermore you have to pay attention to the IGD PCI ID. Intel uses different PCI Device IDs in different CPU versions for IGD (5a84 or 5a85). The console output only works via MMIO on the CRB. Therefore you need the LPSS UART0 Micro USB port. With all these adjustments we can boot a system on the CRB and have full console output. Now you just need all the necessary blobs around coreboot (IFWI, FSP, VBIOS, uCode). You can use the Intel FIT tool to separate the most of the components from the original BIOS. Hope that helps, Mario Von: coreboot [mailto:coreboot-bounces@coreboot.org] Im Auftrag von Tahnia Lichtenstein Gesendet: Donnerstag, 26. Oktober 2017 11:55 An: Cameron Craig Cc: coreboot(a)coreboot.org Betreff: Re: [coreboot] Problems changing payload on Intel Leaf Hill Hi Craig, coreboot folks, Short answer is no, I have not had any luck, I am still stuck! As per suggestions from the coreboot community, I tried the following, which results in no change (i.e. no serial debug console output and no graphics output once coreboot transitions to payload): Tianocore • Ensure UDK2017 CorebootPayloadPkg sets up serial console port with 115200 bps baud, 8 data bits, no parity, 1 stop bit to match coreboot config – However I am unsure if the com port matches coreboot’s config (COM2) • Compile UDK2017 with the same toolchain as coreboot (previously compiled using VS2015 toolchain)… After this didn’t work I’m now just using plain GCC5 • Compile UDK2017 32-bit version (as my previous attempts focused on 64-bit). After this didn’t work I reverted back to 64-bit version, since I would like to run 64-bit Windows 10 IoT (amongst others) • Try using VGA BIOS Option ROM, to no avail o The only relevant files I could find were vbt.bin and vbt.dat variants. I believe this is the type of video “drivers” required by a UEFI payload (as opposed to vbios)? o I could not find any vbios file compatible with Leaf Hill o Intel provides a tool to create your own vbios file from a template, but this seemed error-prone to me, so I have not yet tried this o I managed to find a “gop_10.0_1035_64bit.zip” which contains an IntelGopDriver.efi, but I have not tried to integrate this into the Tianocore build because I don’t know how (yet) SeaBIOS • The SeaBIOS config previously used the wrong COM port for serial console output – I changed it to COM 2 to match coreboot’s config. The rest of the serial console settings looked fine to me • The SeaBIOS serial debug level was previously set to 1, which I changed to 8 • As per above Tianocore efforts, I was not able to obtain a compatible VGA BIOS Option ROM, so could not try this • Even without graphics, I would have expected the COM port config update to show me output on the serial console, which is not the case • Qemu does work using SeaBIOS Following discussion on another coreboot thread (“Intel Leaf Hill Coreboot Trouble”), I tried the following: U-Boot • Following discussion with Craig, I realised U-Boot requires some updates to incorporate coreboot’s device tree. • I followed U-Boot’s readme instructions and am fairly certain it is now set up correctly. (see https://github.com/qemu/u-boot/blob/master/doc/README.x86) o I tried including uboot payload directly in coreboot's make menuconfig as well as loading it through running the cbfs command to add it - does not seem to make a difference) • I also applied Intel’s provided patch to support Leaf Hill • The U-Boot payload gets further than Tianocore and SeaBIOS – there is serial console output, and U-Boot loads its command line interface • When running the “pci” command, the output seems to match the coreboot device tree • When running “usb start” I get “no controllers found” • When running “sf probe 0” I get “Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19)” • I tried to poke around in the U-Boot .config. o Manually enabling USB and SPI flash support in this config file results in “redeclaration” of variables warnings o Following up on these warnings, it really does seem that USB and SPI flash is already enabled by other deeper level config files • No idea why USB does not work, and have not yet tested to see what else also does not work • Verified that SSD SATA device works, but unable to load Yocto from SDD (due to some strange System D initialization errors) • My Yocto build was verified to work using the precompiled payload obtained from Intel • When you say U-Boot would require a lot of work, have you identified in detail what needs to be done? Is most of it not already done in the Intel U-Boot patch? o Does the GPL license extend to code patches for GPL projects? Am I allowed for instance to share a U-Boot code patch if it was obtained from an Intel website that requires CNDA access? Various payload config files attached with accompanying coreboot configs and serial output logs. Also attached coreboot device tree (to compare to uboot's "pci" command output). Any ideas what I'm doing wrong? Regards, Tahnia On Tue, Oct 24, 2017 at 4:51 PM, Cameron Craig <Cameron.Craig(a)exterity.com<mailto:Cameron.Craig@exterity.com>> wrote: Hi Tahnia et al, Have you had any luck with Tianocore or SeaBIOS on Leaf Hill? I would be interested to know if you (or anyone!) have managed to get any of these working on Leaf Hill. We are now also considering these, as U-Boot on Leaf Hill looks like a fair bit of work. Cheers, Cameron > Cameron Craig | Graduate Software Engineer | Exterity Limited tel: +44 1383 828 250<tel:%2B44%201383%20828%20250> | fax: | mobile: e: Cameron.Craig(a)exterity.com<mailto:Cameron.Craig@exterity.com> | w: www.exterity.com<http://www.exterity.com> -----Original Message----- >From: coreboot [mailto:coreboot-bounces@coreboot.org<mailto:coreboot-bounces@coreboot.org>] On Behalf Of Nico >Huber >Sent: 10 October 2017 15:12 >To: Tahnia Lichtenstein; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> >Subject: Re: [coreboot] Problems changing payload on Intel Leaf Hill > >Hi Tahnia, > >On 10.10.2017 10:29, Tahnia Lichtenstein wrote: >> ... >> >> Then I built this version of coreboot with a self-compiled payload, >> such as Tianocore UDK2017 CorebootPayloadPkg or SeaBIOS, using the >> .confg files provided by Intel for UEFI payloads or legacy payloads >> respectively (just modified for specific payload type and path, and >> disabling verified and measured boot). I stitched the coreboot output >> with the Intel-provided blobs using the exact same method as before. >> Then, in run-time, coreboot transitions to the payload and nothing >> happens from then on (i.e. no further serial debug messages, no change to >display monitor). > >you've only attached config files for your coreboot but not for the payloads. >It's hard to tell what output to expect without that (e.g. >do you have serial output enabled in your SeaBIOS build? if you let the >coreboot build environment configure SeaBIOS it is enabled expli- citly). So >with the current information you've provided, it could just be that the >payloads don't try to output anything on serial. > >Output on a monitor is a little more complicated and depends on each >payload. SeaBIOS expects a Video BIOS to be present. This can either be an >option ROM from a gfx adapter card (looking at your logs, you don't seem to >have one), a Video BIOS file in CBFS matching the inte- grated gfx adapter, or, >in case coreboot already configured a frame- buffer, a Video BIOS shim called >SeaVGABIOS (aka. cbvga in this case, it's a separate component in the SeaBIOS >source). > >Current CorebootPayloadPkg *should* be able to use a preconfigured >framebuffer. I never tried it, though, and there are reports that it doesn't >always work... It's generally possible that Intel's precom- piled UEFI payload >has it's own gfx driver (GOP) built in. > >> ... >> Am I not specifying the correct configuration options for Tianocore >> and SeaBIOS? I.e. is there more to it than just selecting the payload >> type and specifying the payload path? Do I need to configure or update >> memory addresses or ranges to match payload sizes, or some such? Do I >> need to make specific changes to the payloads' source code to support >> the platform? Any advice on how/where to start debugging? > >Usually there is nothing more to specify. The best option, IMO, is to get one of >the simpler payloads (SeaBIOS should do) to output on serial. >You can also test your SeaBIOS binary in QEMU to make sure it does out- put >something. > >Hope that helps, >Nico > >-- >coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> >https://mail.coreboot.org/mailman/listinfo/coreboot > >___________________________________________________________ >___________ >This email has been scanned by the Symantec Email Security.cloud service. >For more information please visit http://www.symanteccloud.com >___________________________________________________________ >___________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

1 0

Re: [coreboot] Does S3 work on Haswell boards?
by Аладышев Константин 01 Nov '17

01 Nov '17

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-Cache… 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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2017