November 2014 - coreboot - mail.coreboot.org

Re: [coreboot] Coreboot and HP Pavilion 6746C-L? (Idwer Vollering)
by theodore.preuninger＠lycos.com Nov. 5, 2014

Nov. 5, 2014

#1 Ok, so let me get this straight.... It is possible, but it requires opening up the case to getting to the hardware - while the computer is on? #2 Also is it worth it, considering from the risk? Risk URL ID http://www.coreboot.org/FAQ#Can_I_do_any_serious_damage_mucking_around_with… Thank you On 2014-11-05 17:22, coreboot-request(a)coreboot.org wrote: > Send coreboot mailing list submissions to > coreboot(a)coreboot.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.coreboot.org/mailman/listinfo/coreboot [2] > or, via email, send a message with subject or body 'help' to > coreboot-request(a)coreboot.org > > You can reach the person managing the list at > coreboot-owner(a)coreboot.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of coreboot digest..." > > Today's Topics: > > 1. Re: Coreboot and HP Pavilion 6746C-L? (Idwer Vollering) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 5 Nov 2014 15:22:53 +0100 > From: Idwer Vollering <vidwer(a)gmail.com> > To: coreboot <coreboot(a)coreboot.org>, Joseph Smith > <joe(a)settoplinux.org> > Subject: Re: [coreboot] Coreboot and HP Pavilion 6746C-L? > Message-ID: > <CAPp9OrnE7Huj75OGEXY8KuFLmnQEDtBYcH_PUg9rx2YsLvkY2w(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 2014-11-04 4:38 GMT+01:00 <theodore.preuninger(a)lycos.com>: > >> Step 1 (or equal to step 1) and step 5 From http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph05159&tmp_task=prodi… [1] Intel Socket 370 Pentium III Celeron i810 > > i810 might still work. > Here's a photo of the board, with a close-up of the flash chip: > http://i.ebayimg.com/00/s/MTYwMFgxNjAw/z/htIAAOSw7NNUJcHW/$_57.JPG [3] > > You still need spare flash chips and a way to program them. > See http://www.coreboot.org/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F [4] > > When you can program the chip you'll want to see console output, either > over the serial or EHCI debug port. > >> DMI string baseboard-manufacturer: "Trigem Computer, Inc." DMI string baseboard-product-name: "Cognac" DMI string baseboard-version: "None" DMI string chassis-type: "Other" DMI chassis-type is not specific enough. > > It actually is a desktop: blame the vendor or ODM for being lazy/lax and > not filling that in. > >> Found ITE Super I/O, ID 0x8702 on port 0x2e > > Unsupported as-is, but generic enough to configure it to send serial output. > >> ======================================================================== WARNING! You may be running flashrom on an unsupported laptop. We could not detect this for sure because your vendor has not setup the SMBIOS tables correctly. You can enforce execution by adding '-p internal:laptop=this_is_not_a_laptop' to the command line, but please read the following warning if you are not sure. > > This one is easy to handle by yourself :) > > Idwer >

1 0

Re: [coreboot] coreboot Digest, Vol 117, Issue 12
by Bruce Griffith Nov. 5, 2014

Nov. 5, 2014

> Missing signature at end. Does this mail reflect the opinions > of You as an individual developer, SAGE or the unanimous voice > of SAGE and AMD Advanced Embedded Solutions division? I speak only for myself. I will make it plain that I am speaking for AMD if that ever happens. > The community needs to evaluate if infrastructure of said > binaryPI brings any added value for coreboot, when there is no > promise or a schedule for scrubbed AGESA sources. There is no promise from AMD that there will ever be another source code release of AGESA. In fact, they have stated that there will not be one. I personally believe that there is a business case to be made to AMD for future source code releases but that has to come from AMD customers that buy AMD products in large quantities. However, I do believe that how easy the community makes it to integrate AMD's source directly impacts the ability to build a business case for future source releases. We should drop any discussion of future source code releases since AMD is not participating in the discussion. > You have verified binaryPI uses (almost) exactly the same API > as open-source AGESA so far. This complex API between AGESA > component and coreboot does not fall under the mere > aggregation terms of GPL, it is a form of runtime linking. In > other words the distribution of binaryPI violates rights of > every copyright holder in the coreboot sourcebase. I am not > fond of Google's MRC binary or Intel's FSP either, but their > implementation appears to be a single entry/exit with an array > of platform configuration data. For binary PI there is an open-source library file that converts from the AGESA calls that have been used by wrappers into a single entry call into binary PI. This dispatch interface has been part of AGESA since before AGESA was used by coreboot. I pushed a patch that contains the definition of the AGESA API. The spec documents how the dispatch mechanism works. I am not a lawyer and therefore my opinion on whether binary PI meets the conditions that allow binary aggregation within GPL is not relevant. AMD believes that the binary PI mechanism meets the requirements of GPLv2. I don't know enough about Google's implementation or Intel's implementation to compare MRC vs. FSP vs. AGESA. Most of the structures that are referenced by the AGESA API could be made opaque and the agesa/Proc headers completely eliminated. The changes in headers from version-to-version of AGESA are mostly about computing sizes for memory allocations. Based on this, I suspect that the AGESA API is actually much LESS complex than MRC or FSP. > Existing code in the tree suggests even AMD AES and SAGE were > not able to implement ACPI S3 within the AGESA API for fam15tn > and fam16kb, but chose to bypass the API and link directly > with a couple functions in AGESA vendorcode proper. Trinity S3 was developed immediately after CIM-X was integrated into AGESA, when the FCH additions to the API were immature. Kabini S3 is a copy of Trinity S3. I do not know of any attempts to develop coreboot S3 code through the API so I don't think you can say that it is impossible to do so. Other (non- coreboot) users of AGESA have S3 working so I am pretty sure it can be done. Don't equate a bad implementation with bad design. > Can You explain SAGE's role in all of this? I implemented binary PI on AMD's behalf. They have asked me to push reference implementations for Steppe Eagle and Bald Eagle into the community. > Would an early release of AGESA sources affect negatively on > SAGE's consultation revenue? I have no dog in that hunt (meaning "No"). I also don't see how the question is relevant. > I assume here binaryPI is virtually impossible to debug for > board bring-up. I assume binaryPI is built with all debugging > output to console (aka IDS) disabled with no possibility to > enable at runtime? I debugged the initial binary PI for Steppe Eagle largely without any tools except coreboot debug spew. From what I have heard, this is pretty much the same as the story for F2A85-M development. It is difficult but not impossible. There is no possibility of enabling IDS from the public release of binary PI. > In my opinion maintaining an API involves a single set of > header files ... I can see that even within the two binaryPI > releases pushed to coreboot blobs.git, the header files are > not the same. You just described the difference between an API and an ABI. AGESA uses an API not an ABI. AGESA uses structures that vary between releases. The code must be recompiled to update to a newer version. An Application Binary Interface does not have that restriction. > In the spirit of AGESA API, platform specifics would belong to > BiosCallOuts and no board-specific agesawrapper.c file should > have ever existed. But since board-specific agesawrapper.c > files did exists, someone though it was okay to modify those > nevertheless. The wrappers in agesawrapper.c are EXACTLY where mainboard specific customizations belong. Read the AGESA API spec. It is how runtime variation between platforms was designed to be implemented. However, there is a lot of boiler-plate code in agesawrapper.c. I would like to see new callouts created for each of the approx 9 AGESA stages and the boiler-plate code made the same for ALL AGESA-based code. In other words, move agesawrapper.c somewhere like src/northbridge. Split agesawrapper.c into a romstage component, a ramstage component, and an S3 component. Expand processor and platform specific OEM customization routines to each of the AGESA stages. This would accommodate platform-to- platform variation by customizing the OEM routine (i.e. this would allow change from SATA combined mode to pure AHCI or RAID, disable USB ports, etc.). > You are effectively saying that you do not want any of the > improvements that coreboot has gained from Chromebook > development, to be available on AMD reference designs? Is this > the opinion of You as an individual, the opinion of SAGE or > that of the AMD Advanced Embedded Solutions division? I am speaking for me, but I very much believe that I am accurately reflecting what AMD would want. I am not in any way saying I don't want the contributions that you are implying you intend to make. I want them very much. But you are specifically excluding these improvements for binary PI based designs. I am stating that all of AMD's stuff should stay on one side of this fence that you are proposing. Since you are excluding binary PI from getting the "Chromebook development" changes, I guess that means the rest of AMD's platforms are excluded, too. > To think further, understand that a requirement to use a > common agesawrapper.c file across fam12-fam16kb is for the > vendorcode to actually expose a common API. A common API does > not involve forking the header files for each family > separately. The community has the possibility to unify the > function prototypes within the different families of open- > source AGESA API, should we find any. I don't know of any relevant function prototypes that have changed in the AGESA API since 2008. Any change in the function prototypes used by coreboot would have broken the dispatcher and that's not permissible under the Arch 2008 spec. If you are referring to callbacks, those also have a single fixed function signature. The usage of the signature may have changed from version to version but that was poor implementation (i.e. bugs). The AMD library is still completely open-sourced with binary PI. There are no AGESA header file changes that are relevant to coreboot in general. coreboot needs them to compile but it uses very few fields defined by them. You could replace most of the structs with an array of bytes of known length. The code would not function differently. The downside is that coreboot would lose some of its ability to control runtime option selection within AGESA (that largely is not used by current coreboot code). What is the issue that we are trying to solve by harmonizing and #ifdef'ing the *actual* AGESA header files currently located in src/vendorcode and 3rdparty/pi/amd? ------------------------ AMD is trying to run a business. They are contributing code to coreboot to enable their next-gen processors. Aside from the fact that you do not like that AMD has stopped open-sourcing AGESA, what problem are we trying to solve in this discussion? My objective is to get Steppe Eagle and Bald Eagle processors released, as quickly as possible, into coreboot. I really do not have much of a personal agenda beyond that. Respectfully, Bruce Griffith

1 0

Re: [coreboot] Baytrail FSP Gold3
by Wen Wang Nov. 5, 2014

Nov. 5, 2014

York, We have BayleyBay and our own Baytrail I B3 based system. Both of them have memory module, no memory-down. Are there any code examples for updating the UPD_DATA_REGION structure? Thanks! Wen Date: Tue, 4 Nov 2014 18:46:13 +0000 From: "Yang, York" <york.yang(a)intel.com> To: "coreboot(a)coreboot.org" <coreboot(a)coreboot.org> Subject: Re: [coreboot] Baytrail FSP Gold3 Message-ID: <9A382F7099884143A15663C92EF473694FAE8A1C(a)FMSMSX109.amr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Yes, it requires a couple of coreboot updates. Basically the changes is in UPD_DATA_REGION structure to add some elements to configure platform via FSP. Which platform are you working on, is it a memory-down or memory module. Sincerely, York -----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Wen Wang Sent: Tuesday, November 04, 2014 7:14 AM To: coreboot(a)coreboot.org Subject: [coreboot] Baytrail FSP Gold3 Hello, Has anybody tried baytrail FSP Gold3 on B3 with the current coreboot? Does it require coreboot updates? Thanks! Wen -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

2 1

Coreboot and HP Pavilion 6746C-L?
by theodore.preuninger＠lycos.com Nov. 5, 2014

Nov. 5, 2014

Step 1 (or equal to step 1) and step 5 From http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph05159&tmp_task=prodi… Intel Socket 370 Pentium III Celeron i810 Step 2 lspci -tvnn -[0000:00]-+-00.0 Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) [8086:7120] +-01.0 Intel Corporation 82810 (CGC) Chipset Graphics Controller [8086:7121] +-1e.0-[01]--+-0b.0 Accton Technology Corporation SMC2-1211TX [1113:1211] | +-0d.0 Accton Technology Corporation SMC2-1211TX [1113:1211] | -0e.0 LSI Corporation LT WinModem [11c1:044e] +-1f.0 Intel Corporation 82801AA ISA Bridge (LPC) [8086:2410] +-1f.1 Intel Corporation 82801AA IDE Controller [8086:2411] +-1f.2 Intel Corporation 82801AA USB Controller [8086:2412] +-1f.3 Intel Corporation 82801AA SMBus Controller [8086:2413] -1f.5 Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] Step 3 sudo superiotool -dV superiotool r6637 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Found ITE IT8702F (id=0x8702, rev=0x4) at 0x2e No dump available for this Super I/O Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. Probing for Server Engines Super I/O at 0x2e... Failed. Returned data: id=0xffff, rev=0xff Step 4 sudo flashrom -p internal -V flashrom v0.9.6.1-r1563 on Linux 3.13.0-37-generic (i686) flashrom is free software, get the source code at http://www.flashrom.org flashrom was built with libpci 3.1.9, GCC 4.7.1, little endian Command line (3 args): flashrom -p internal -V Calibrating delay loop... OS timer resolution is 2 usecs, 276M loops per second, delay more than 10% too short (got 78% of expected delay), recalculating... 238M loops per second, delay more than 10% too short (got 67% of expected delay), recalculating... 353M loops per second, 10 myus = 10 us, 100 myus = 98 us, 1000 myus = 967 us, 10000 myus = 10658 us, 8 myus = 10 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "00101880 6746C" DMI string system-product-name: "15290800050383" DMI string system-version: "2 " DMI string baseboard-manufacturer: "Trigem Computer, Inc." DMI string baseboard-product-name: "Cognac" DMI string baseboard-version: "None" DMI string chassis-type: "Other" DMI chassis-type is not specific enough. Found ITE Super I/O, ID 0x8702 on port 0x2e ======================================================================== WARNING! You may be running flashrom on an unsupported laptop. We could not detect this for sure because your vendor has not setup the SMBIOS tables correctly. You can enforce execution by adding '-p internal:laptop=this_is_not_a_laptop' to the command line, but please read the following warning if you are not sure. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See http://www.flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Aborting. Error: Programmer initialization failed. Step 6 lspci 00:00.0 Host bridge: Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) (rev 03) 00:01.0 VGA compatible controller: Intel Corporation 82810 (CGC) Chipset Graphics Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02) 00:1f.2 USB controller: Intel Corporation 82801AA USB Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 02) 01:0b.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) 01:0d.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) 01:0e.0 Communication controller: LSI Corporation LT WinModem user-name@pc-name:~$ sudo lspci -vnn 00:00.0 Host bridge [0600]: Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) [8086:7120] (rev 03) Flags: bus master, fast devsel, latency 0 Kernel driver in use: agpgart-intel 00:01.0 VGA compatible controller [0300]: Intel Corporation 82810 (CGC) Chipset Graphics Controller [8086:7121] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation 82810 (CGC) Chipset Graphics Controller [8086:7121] Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 16 Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at f4000000 (32-bit, non-prefetchable) [size=512K] Expansion ROM at <unassigned> [disabled] Capabilities: [dc] Power Management version 1 00:1e.0 PCI bridge [0604]: Intel Corporation 82801AA PCI Bridge [8086:2418] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 00003000-00003fff Memory behind bridge: f4100000-f41fffff 00:1f.0 ISA bridge [0601]: Intel Corporation 82801AA ISA Bridge (LPC) [8086:2410] (rev 02) Flags: bus master, medium devsel, latency 0 Kernel driver in use: lpc_ich 00:1f.1 IDE interface [0101]: Intel Corporation 82801AA IDE Controller [8086:2411] (rev 02) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801AA IDE Controller [8086:2411] Flags: bus master, medium devsel, latency 0 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 00000370 (type 3, non-prefetchable) I/O ports at 1800 [size=16] Kernel driver in use: ata_piix 00:1f.2 USB controller [0c03]: Intel Corporation 82801AA USB Controller [8086:2412] (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801AA USB Controller [8086:2412] Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at 1820 [size=32] Kernel driver in use: uhci_hcd 00:1f.3 SMBus [0c05]: Intel Corporation 82801AA SMBus Controller [8086:2413] (rev 02) Subsystem: Intel Corporation 82801AA SMBus Controller [8086:2413] Flags: medium devsel, IRQ 9 I/O ports at 1810 [size=16] 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 02) Subsystem: Intel Corporation Device [8086:5643] Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at 1200 [size=256] I/O ports at 1300 [size=64] Kernel driver in use: snd_intel8x0 01:0b.0 Ethernet controller [0200]: Accton Technology Corporation SMC2-1211TX [1113:1211] (rev 10) Subsystem: Hewlett-Packard Company Device [103c:9207] Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at 3000 [size=256] Memory at f4100000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Kernel driver in use: 8139too 01:0d.0 Ethernet controller [0200]: Accton Technology Corporation SMC2-1211TX [1113:1211] (rev 10) Subsystem: Hewlett-Packard Company Device [103c:9207] Flags: bus master, medium devsel, latency 64, IRQ 17 I/O ports at 3400 [size=256] Memory at f4100400 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Kernel driver in use: 8139too 01:0e.0 Communication controller [0780]: LSI Corporation LT WinModem [11c1:044e] Subsystem: Risq Modular Systems, Inc. Device [1235:044e] Flags: bus master, fast Back2Back, medium devsel, latency 64, IRQ 10 Memory at f4100800 (32-bit, non-prefetchable) [size=256] I/O ports at 3c00 [size=8] I/O ports at 3800 [size=256] Capabilities: [f8] Power Management version 2

2 1

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
by Werner Zeh Nov. 4, 2014

Nov. 4, 2014

Great. It was my pleasure to help you :) Am 04.11.2014 um 18:49 schrieb Gailu Singh: > Hi Werner, > > Thanks for your help and support. It was indeed due to wrong FSP. D0 > stepping is installed and it only worked now with Gold3 FSP and > updated microcode. > > Thank you very much. > > On Tue, Nov 4, 2014 at 12:48 AM, Werner Zeh <werner.zeh(a)gmx.net > <mailto:werner.zeh@gmx.net>> wrote: > > Hi. > > Now you have coreboot running. > coreboot searches for FSP, finds it and executes the first call > into it. > FSP returns with an error and what you see is this (taken from > src/drivers/intel/fsp/cache_as_ram.inc): > > /* > * Failures for postcode 0xBB - failed in the FSP: > * > * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully. > * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid. > * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the > microcode region. > * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not > met. > * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed > * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has > been invoked > */ > > So what you actually see is error code 0x07 from FSP. This can > mean that your CPU is not supported by this FSP version. > If you use GOLD1 or GOLD2, then a D0 stepping is not supported and > if you have in advance a D0 stepping installed on your board, > than you have to use GOLD3 FSP release as it was already mentioned. > > I had the same issue and it was due to missing D0-Support in GOLD1 > release. So, I would suggest to try the right FSP-release from Intel. > > Bye > Werner > > Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot: > > With the changed TXE/descriptor, it moved ahead but now > toggling between POST codes 0x66 and 0x07. I checked > ./src/include/console/post_codes.h and these POST codes are > not defined there so I doubt that these are coming from > coreboot code. Are these post codes coming from FSP code? If > yes, How do I interpret them? Do I need to ask Intel? Any > pointers please? > > On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil > <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com> > <mailto:seanmcneil3@gmail.com <mailto:seanmcneil3@gmail.com>>> > wrote: > > You mentioned just copying the .fd file, so I assumed it > was being > used directly in your coreboot image. FSP needs to be > incorporated > into flash, yes. It should, however, be patched with the BCT > program as what is provided in the .fd is usually not > patched with > the a configuration that you desire. Thus you should run > bct and > configure/patch the .fd and generate a .bin to include > into coreboot. > > I am a little confused by your email below. You state that > you are > not using the .fd directly then contradict yourself in the > next > sentence. Bottom line is I would not include any .fd file > from the > FSP archive directly. Use BCT to patch it and do not name > it .fd. > This avoids any confusion regarding whether you are > including a > patched FSP or not. Just because there is a bsf file > included in > the GOLD release doesn't mean that the .fd was patched > with those > settings and that it is valid. > > Best of luck to you. There are many issues you will have to > resolve dealing with new hardware. I've gone through the > process > with a lot of support from Intel and it is not that easy. > Especially when certain components found on the CRB are not > provided on custom hardware. > > Cheers, > Sean > > > On 11/02/2014 08:01 PM, Gailu Singh wrote: > > Hi Sean, > > 1. This is not for a real project and we are trying to > understand > FSP interaction with coreboot to look at feasibility for > considering coreboot in our future projects. > Unfortunately I do > not have board documentation so was not able to > determine which > one is serial port 0 though I know that port 0 is > specified in > coreboot config. That was the reason I was trying on all 3 > available ports. > 2. I am not using .fd directly. I believe that FSP > need to be > included in bootloader (coreboot in this case) and we are > providing path to coreboot so that it can be included in > coreboot. In my original post I only said that I > copied .fd to a > path expected by coreboot configuration. May I know > how did you > conclude that I am using it directly? May be that can > give me > some pointer. > 3. I had checked the bsf file in the FSP kit with BCT > tool and it > is configured for non-ECC RAM, so I believe that no > change is > required in .fd. Am I wrong? > 4. Yes, I agree that there is no documentation > available on how > to create entire 8MB binary with Firmware Description, > TXE, > coreboot etc so for safe route I only touched upper 2 > MB as > recommended in one of the initial commit for baytrail FSP > integration and some posts related to similar discussion. > > > > On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil > <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com> > <mailto:seanmcneil3@gmail.com > <mailto:seanmcneil3@gmail.com>>> wrote: > > Coreboot and FSP are not as easy to understand as > you can > see. I also would suggest that you seek assistance > from > either Sage (who has good experience that I > understand serves > the USA and Europe markets and contributed the current > Coreboot+FSP code) or perhaps a company in Asia > such as Zien > Solutions (of Vietnam). There are a number of > issues that you > are failing to understand: > > 1) As stated, the first serial port is actually > connected to > a USB->Serial converter and delivered out of the > microUSB > connector on the CRB. > 2) You need to configure the FSP with Intels > program to > create a ROMable image and not use the .fd file > directly. > 3) BayleyBay needs to be configured for non-ECC > RAM whereas > Bakersport needs to be configured for ECC. > 4) You don't necessarily need the TXE security > module, but > you could very well cause problems if it is partially > overwritten. Best is to create a correct 8MB image > to flash > that has the proper Intel Firmware Description > block at the > beginning. > > Regards, > Sean > > > On 11/02/2014 02:25 AM, Gaumless via coreboot wrote: > > First, the serial ports: The serial console > is on the > first serial port on the micro-USB connection. > > The 0x0000 on the post code display means that > it's not > actually starting to boot - it's probably > hanging in the > TXE. There are known issues with upgrading to > coreboot > from some of the bayleybay roms. I thought > Intel was > going to document that, but I don't know if > they did. > > The Gold 2 FSP doesn't support D0 parts, so if > you have a > D0, you need the Gold 3. Also, the FSP is > targeted at > the embedded sku Baytrail-I. It might work > with M/D > parts, I haven't tested that. > > Assuming all that is ok, you probably need to > start from > a different rom. It might be failing because > of the TXE > security. You'll probably need to talk to > your Intel > contact to get that update. > > Finally, if this is not a personal project, > you might be > interested in contacting Sage and look at > purchasing a > BSP to get up and running. Either way, let us > know > whether you make progress or need more help. > > Martin > > > On Nov 1, 2014, at 11:48 AM, Gailu Singh > via coreboot > <coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > <mailto:coreboot@coreboot.org > <mailto:coreboot@coreboot.org>>> wrote: > > Hi Experts, > > I am trying to boot BayleyBay CRB Rev 3 using > coreboot and have no success so far. I > have serial > port (DB9) connected and using 115200 Baud > Rate. No > message comes on serial at all. Here is > the procedure > I followed. > > 1. Pulled latest coreboot from git. > 2. Pulled following from > BAY_TRAIL_FSP_KIT. The > reason for doing it is that > BAYTRAIL_FSP.fd is not > in git and .config refers to it. Also > .config refers > to ../intel/cpu/baytrail/microcode > a) created intel directory parallel > to coreboot > and copied > BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd > in to intel/fsp/baytrail/BAYTRAIL_FSP.fd > b) Copied *.h from Microcode folder > in the kit > to intel/cpu/baytrail/microcode. > 3. Configured the coreboot for mainboard > as intel > bayleybay. My .config is attached. > 4. Build Coreboot. Below is the prints > from cbfstool. > cmos_layout.bin 0x0 > cmos_layout 1132 > fallback/romstage 0x4c0 stage > 27813 > fallback/ramstage 0x71c0 stage > 67431 > fallback/payload 0x17980 payload 268859 > config 0x59400 raw 4363 > (empty) 0x5a540 null 744088 > cpu_microcode_blob.bin 0x110000 > microcode 104448 > (empty) 0x129840 null 157528 > mrc.cache 0x14ffc0 (unknown) 65536 > (empty) 0x160000 null 393112 > fsp.bin 0x1bffc0 (unknown) 229376 > (empty) 0x1f8000 null 31640 > 5. Flashed the coreboot.rom in upper 2MB > (0X0600000-0x07FFFFF) > 6. Reboot the board > 7. Nothing comes on Serial Console (DB9). > Also tried > to connect Micro usb cable which detects > two serial > ports but no output to any of them as well. > 8. Before flashing coreboot.rom, 4 digit > display was > displaying something on two digits and > rest two were > zero. Now all 4 digits stays at zeros. > > Looking for help to get at least serial > working so > that I can get some logs to debug it. I do > not have > copy of original BIOS that was there in > Flash and > forgot to make a copy using programmer > though I > ensured that I only touch upper 2MB. I am > stuck and > have no logs to debug it. > > Thanks in advance. > <my.config> > -- coreboot mailing list: > coreboot(a)coreboot.org <mailto:coreboot@coreboot.org> > <mailto:coreboot@coreboot.org > <mailto:coreboot@coreboot.org>> > http://www.coreboot.org/mailman/listinfo/coreboot > > > > > > > > > > >

1 0

Baytrail FSP Gold3
by Wen Wang Nov. 4, 2014

Nov. 4, 2014

Hello, Has anybody tried baytrail FSP Gold3 on B3 with the current coreboot? Does it require coreboot updates? Thanks! Wen

2 1

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help
by Werner Zeh Nov. 4, 2014

Nov. 4, 2014

Hi. Now you have coreboot running. coreboot searches for FSP, finds it and executes the first call into it. FSP returns with an error and what you see is this (taken from src/drivers/intel/fsp/cache_as_ram.inc): /* * Failures for postcode 0xBB - failed in the FSP: * * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully. * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid. * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode region. * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met. * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked */ So what you actually see is error code 0x07 from FSP. This can mean that your CPU is not supported by this FSP version. If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you have in advance a D0 stepping installed on your board, than you have to use GOLD3 FSP release as it was already mentioned. I had the same issue and it was due to missing D0-Support in GOLD1 release. So, I would suggest to try the right FSP-release from Intel. Bye Werner Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot: > With the changed TXE/descriptor, it moved ahead but now toggling > between POST codes 0x66 and 0x07. I checked > ./src/include/console/post_codes.h and these POST codes are not > defined there so I doubt that these are coming from coreboot code. Are > these post codes coming from FSP code? If yes, How do I interpret > them? Do I need to ask Intel? Any pointers please? > > On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil <seanmcneil3(a)gmail.com > <mailto:seanmcneil3@gmail.com>> wrote: > > You mentioned just copying the .fd file, so I assumed it was being > used directly in your coreboot image. FSP needs to be incorporated > into flash, yes. It should, however, be patched with the BCT > program as what is provided in the .fd is usually not patched with > the a configuration that you desire. Thus you should run bct and > configure/patch the .fd and generate a .bin to include into coreboot. > > I am a little confused by your email below. You state that you are > not using the .fd directly then contradict yourself in the next > sentence. Bottom line is I would not include any .fd file from the > FSP archive directly. Use BCT to patch it and do not name it .fd. > This avoids any confusion regarding whether you are including a > patched FSP or not. Just because there is a bsf file included in > the GOLD release doesn't mean that the .fd was patched with those > settings and that it is valid. > > Best of luck to you. There are many issues you will have to > resolve dealing with new hardware. I've gone through the process > with a lot of support from Intel and it is not that easy. > Especially when certain components found on the CRB are not > provided on custom hardware. > > Cheers, > Sean > > > On 11/02/2014 08:01 PM, Gailu Singh wrote: >> Hi Sean, >> >> 1. This is not for a real project and we are trying to understand >> FSP interaction with coreboot to look at feasibility for >> considering coreboot in our future projects. Unfortunately I do >> not have board documentation so was not able to determine which >> one is serial port 0 though I know that port 0 is specified in >> coreboot config. That was the reason I was trying on all 3 >> available ports. >> 2. I am not using .fd directly. I believe that FSP need to be >> included in bootloader (coreboot in this case) and we are >> providing path to coreboot so that it can be included in >> coreboot. In my original post I only said that I copied .fd to a >> path expected by coreboot configuration. May I know how did you >> conclude that I am using it directly? May be that can give me >> some pointer. >> 3. I had checked the bsf file in the FSP kit with BCT tool and it >> is configured for non-ECC RAM, so I believe that no change is >> required in .fd. Am I wrong? >> 4. Yes, I agree that there is no documentation available on how >> to create entire 8MB binary with Firmware Description, TXE, >> coreboot etc so for safe route I only touched upper 2 MB as >> recommended in one of the initial commit for baytrail FSP >> integration and some posts related to similar discussion. >> >> >> >> On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil >> <seanmcneil3(a)gmail.com <mailto:seanmcneil3@gmail.com>> wrote: >> >> Coreboot and FSP are not as easy to understand as you can >> see. I also would suggest that you seek assistance from >> either Sage (who has good experience that I understand serves >> the USA and Europe markets and contributed the current >> Coreboot+FSP code) or perhaps a company in Asia such as Zien >> Solutions (of Vietnam). There are a number of issues that you >> are failing to understand: >> >> 1) As stated, the first serial port is actually connected to >> a USB->Serial converter and delivered out of the microUSB >> connector on the CRB. >> 2) You need to configure the FSP with Intels program to >> create a ROMable image and not use the .fd file directly. >> 3) BayleyBay needs to be configured for non-ECC RAM whereas >> Bakersport needs to be configured for ECC. >> 4) You don't necessarily need the TXE security module, but >> you could very well cause problems if it is partially >> overwritten. Best is to create a correct 8MB image to flash >> that has the proper Intel Firmware Description block at the >> beginning. >> >> Regards, >> Sean >> >> >> On 11/02/2014 02:25 AM, Gaumless via coreboot wrote: >> >> First, the serial ports: The serial console is on the >> first serial port on the micro-USB connection. >> >> The 0x0000 on the post code display means that it's not >> actually starting to boot - it's probably hanging in the >> TXE. There are known issues with upgrading to coreboot >> from some of the bayleybay roms. I thought Intel was >> going to document that, but I don't know if they did. >> >> The Gold 2 FSP doesn't support D0 parts, so if you have a >> D0, you need the Gold 3. Also, the FSP is targeted at >> the embedded sku Baytrail-I. It might work with M/D >> parts, I haven't tested that. >> >> Assuming all that is ok, you probably need to start from >> a different rom. It might be failing because of the TXE >> security. You'll probably need to talk to your Intel >> contact to get that update. >> >> Finally, if this is not a personal project, you might be >> interested in contacting Sage and look at purchasing a >> BSP to get up and running. Either way, let us know >> whether you make progress or need more help. >> >> Martin >> >> >> On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot >> <coreboot(a)coreboot.org >> <mailto:coreboot@coreboot.org>> wrote: >> >> Hi Experts, >> >> I am trying to boot BayleyBay CRB Rev 3 using >> coreboot and have no success so far. I have serial >> port (DB9) connected and using 115200 Baud Rate. No >> message comes on serial at all. Here is the procedure >> I followed. >> >> 1. Pulled latest coreboot from git. >> 2. Pulled following from BAY_TRAIL_FSP_KIT. The >> reason for doing it is that BAYTRAIL_FSP.fd is not >> in git and .config refers to it. Also .config refers >> to ../intel/cpu/baytrail/microcode >> a) created intel directory parallel to coreboot >> and copied BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd >> in to intel/fsp/baytrail/BAYTRAIL_FSP.fd >> b) Copied *.h from Microcode folder in the kit >> to intel/cpu/baytrail/microcode. >> 3. Configured the coreboot for mainboard as intel >> bayleybay. My .config is attached. >> 4. Build Coreboot. Below is the prints from cbfstool. >> cmos_layout.bin 0x0 cmos_layout 1132 >> fallback/romstage 0x4c0 stage >> 27813 >> fallback/ramstage 0x71c0 stage >> 67431 >> fallback/payload 0x17980 payload 268859 >> config 0x59400 raw 4363 >> (empty) 0x5a540 null 744088 >> cpu_microcode_blob.bin 0x110000 microcode 104448 >> (empty) 0x129840 null 157528 >> mrc.cache 0x14ffc0 (unknown) 65536 >> (empty) 0x160000 null 393112 >> fsp.bin 0x1bffc0 (unknown) 229376 >> (empty) 0x1f8000 null 31640 >> 5. Flashed the coreboot.rom in upper 2MB >> (0X0600000-0x07FFFFF) >> 6. Reboot the board >> 7. Nothing comes on Serial Console (DB9). Also tried >> to connect Micro usb cable which detects two serial >> ports but no output to any of them as well. >> 8. Before flashing coreboot.rom, 4 digit display was >> displaying something on two digits and rest two were >> zero. Now all 4 digits stays at zeros. >> >> Looking for help to get at least serial working so >> that I can get some logs to debug it. I do not have >> copy of original BIOS that was there in Flash and >> forgot to make a copy using programmer though I >> ensured that I only touch upper 2MB. I am stuck and >> have no logs to debug it. >> >> Thanks in advance. >> <my.config> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> <mailto:coreboot@coreboot.org> >> http://www.coreboot.org/mailman/listinfo/coreboot >> >> >> > > > >

2 1

[Coreboot] Works on HP Pavilion 6746C-L?
by theodore.preuninger＠lycos.com Nov. 4, 2014

Nov. 4, 2014

Since I do not know if coreboot work on my machine, here is the requested info that you want.. If I missed anything, please reply. Thank you Step 1 (or equal to step 1) and step 5 From http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph05159&tmp_task=prodi… [1] Intel Socket 370 Pentium III Celeron i810 Step 2 lspci -tvnn -[0000:00]-+-00.0 Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) [8086:7120] +-01.0 Intel Corporation 82810 (CGC) Chipset Graphics Controller [8086:7121] +-1e.0-[01]--+-0b.0 Accton Technology Corporation SMC2-1211TX [1113:1211] | +-0d.0 Accton Technology Corporation SMC2-1211TX [1113:1211] | -0e.0 LSI Corporation LT WinModem [11c1:044e] +-1f.0 Intel Corporation 82801AA ISA Bridge (LPC) [8086:2410] +-1f.1 Intel Corporation 82801AA IDE Controller [8086:2411] +-1f.2 Intel Corporation 82801AA USB Controller [8086:2412] +-1f.3 Intel Corporation 82801AA SMBus Controller [8086:2413] -1f.5 Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] Step 3 sudo superiotool -dV superiotool r6637 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Found ITE IT8702F (id=0x8702, rev=0x4) at 0x2e No dump available for this Super I/O Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. Probing for Server Engines Super I/O at 0x2e... Failed. Returned data: id=0xffff, rev=0xff Step 4 sudo flashrom -p internal -V flashrom v0.9.6.1-r1563 on Linux 3.13.0-37-generic (i686) flashrom is free software, get the source code at http://www.flashrom.org [2] flashrom was built with libpci 3.1.9, GCC 4.7.1, little endian Command line (3 args): flashrom -p internal -V Calibrating delay loop... OS timer resolution is 2 usecs, 276M loops per second, delay more than 10% too short (got 78% of expected delay), recalculating... 238M loops per second, delay more than 10% too short (got 67% of expected delay), recalculating... 353M loops per second, 10 myus = 10 us, 100 myus = 98 us, 1000 myus = 967 us, 10000 myus = 10658 us, 8 myus = 10 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "00101880 6746C" DMI string system-product-name: "15290800050383" DMI string system-version: "2 " DMI string baseboard-manufacturer: "Trigem Computer, Inc." DMI string baseboard-product-name: "Cognac" DMI string baseboard-version: "None" DMI string chassis-type: "Other" DMI chassis-type is not specific enough. Found ITE Super I/O, ID 0x8702 on port 0x2e ======================================================================== WARNING! You may be running flashrom on an unsupported laptop. We could not detect this for sure because your vendor has not setup the SMBIOS tables correctly. You can enforce execution by adding '-p internal:laptop=this_is_not_a_laptop' to the command line, but please read the following warning if you are not sure. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See http://www.flashrom.org/Laptops [3] for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Aborting. Error: Programmer initialization failed. Step 6 lspci 00:00.0 Host bridge: Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) (rev 03) 00:01.0 VGA compatible controller: Intel Corporation 82810 (CGC) Chipset Graphics Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA IDE Controller (rev 02) 00:1f.2 USB controller: Intel Corporation 82801AA USB Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801AA SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 02) 01:0b.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) 01:0d.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) 01:0e.0 Communication controller: LSI Corporation LT WinModem user-name@pc-name:~$ sudo lspci -vnn 00:00.0 Host bridge [0600]: Intel Corporation 82810 GMCH (Graphics Memory Controller Hub) [8086:7120] (rev 03) Flags: bus master, fast devsel, latency 0 Kernel driver in use: agpgart-intel 00:01.0 VGA compatible controller [0300]: Intel Corporation 82810 (CGC) Chipset Graphics Controller [8086:7121] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation 82810 (CGC) Chipset Graphics Controller [8086:7121] Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 16 Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at f4000000 (32-bit, non-prefetchable) [size=512K] Expansion ROM at <unassigned> [disabled] Capabilities: [dc] Power Management version 1 00:1e.0 PCI bridge [0604]: Intel Corporation 82801AA PCI Bridge [8086:2418] (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 I/O behind bridge: 00003000-00003fff Memory behind bridge: f4100000-f41fffff 00:1f.0 ISA bridge [0601]: Intel Corporation 82801AA ISA Bridge (LPC) [8086:2410] (rev 02) Flags: bus master, medium devsel, latency 0 Kernel driver in use: lpc_ich 00:1f.1 IDE interface [0101]: Intel Corporation 82801AA IDE Controller [8086:2411] (rev 02) (prog-if 80 [Master]) Subsystem: Intel Corporation 82801AA IDE Controller [8086:2411] Flags: bus master, medium devsel, latency 0 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 00000370 (type 3, non-prefetchable) I/O ports at 1800 [size=16] Kernel driver in use: ata_piix 00:1f.2 USB controller [0c03]: Intel Corporation 82801AA USB Controller [8086:2412] (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation 82801AA USB Controller [8086:2412] Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at 1820 [size=32] Kernel driver in use: uhci_hcd 00:1f.3 SMBus [0c05]: Intel Corporation 82801AA SMBus Controller [8086:2413] (rev 02) Subsystem: Intel Corporation 82801AA SMBus Controller [8086:2413] Flags: medium devsel, IRQ 9 I/O ports at 1810 [size=16] 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 02) Subsystem: Intel Corporation Device [8086:5643] Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at 1200 [size=256] I/O ports at 1300 [size=64] Kernel driver in use: snd_intel8x0 01:0b.0 Ethernet controller [0200]: Accton Technology Corporation SMC2-1211TX [1113:1211] (rev 10) Subsystem: Hewlett-Packard Company Device [103c:9207] Flags: bus master, medium devsel, latency 64, IRQ 18 I/O ports at 3000 [size=256] Memory at f4100000 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Kernel driver in use: 8139too 01:0d.0 Ethernet controller [0200]: Accton Technology Corporation SMC2-1211TX [1113:1211] (rev 10) Subsystem: Hewlett-Packard Company Device [103c:9207] Flags: bus master, medium devsel, latency 64, IRQ 17 I/O ports at 3400 [size=256] Memory at f4100400 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Kernel driver in use: 8139too 01:0e.0 Communication controller [0780]: LSI Corporation LT WinModem [11c1:044e] Subsystem: Risq Modular Systems, Inc. Device [1235:044e] Flags: bus master, fast Back2Back, medium devsel, latency 64, IRQ 10 Memory at f4100800 (32-bit, non-prefetchable) [size=256] I/O ports at 3c00 [size=8] I/O ports at 3800 [size=256] Capabilities: [f8] Power Management version 2 Links: ------ [1] http://h10025.www1.hp.com/ewfrf/wc/document?docname=bph05159&tmp_task=p… [2] http://www.flashrom.org [3] http://www.flashrom.org/Laptops

1 0

IMB-A180 Real Time Clock is 20-30% slow (coreboot only, not original AMI BIOS)
by Mark C. Mason Nov. 4, 2014

Nov. 4, 2014

We are working with both vanilla Coreboot and Sage's BSP version of Coreboot, and we stumbled upon the fact that the system clock is running 20-30% slow. This does not occur when booting from the original AMI BIOS. We are running both CentOS 6.4 and Ubuntu 14.04 versions of Linux. To reproduce, run "sleep 10" and time it with a stopwatch. Our timings indicate about 12.2 seconds when booting from either vanilla or Sage BSP Coreboot. I've searched the Coreboot mailing list archives (and google), but I don't see anything. Does anyone know anything about this? I'll start looking at the code, but any help will be greatly appreciated. Best regards, Mark Mason Engineering Design Team

2 1

Re: [coreboot] Fwd: [Intel-gfx] i915.fastboot bug report - not working on coreboot
by Peter Stuge Nov. 4, 2014

Nov. 4, 2014

Charles Devereaux via coreboot wrote: > Could someone from the list help him pinpoint why coreboot is using a > different mode? I will not. The answer to this is already well known - the coreboot code is doing something different, probably because it doesn't know better, probably because the programmer has not written correct code. > This would make native video init compatible While I appreciate that there are many users who would like all kinds of things to work without them being able to fix it themselves, the reality is that things will work when someone fixes them. All these things are well-known problems. Correct patches would be great. //Peter

3 2