coreboot December 2016

coreboot@coreboot.org

57 participants
121 discussions

Re: [coreboot] How does intelmetool's support for Skylake?
by Shawn 30 Dec '16

30 Dec '16

This is a work around patch( I think?): https://github.com/hardenedlinux/intelmetool/commit/ad778fc347b2bb0494abe21… ./intelmetool -s RCBA at 0x00000000 MEI not hidden on PCI, checking if visible MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI ME Status : 0xa0000245 ME Status 2 : 0x86110306 ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : YES ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : M0 with UMA ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : Clean Moff->Mx wake ME: Power Management Event : Pseudo-global reset ME: Progress Phase State : Unknown 0x11 PCI READ [bc] : 0x000000bc ME: Extend Register not valid ME seems okay on this board WRITE [00] : CB: 0x80040007 WRITE [00] : CB: 0x000002ff READ [08] : CB: 0x801c0007 READ [08] : CB: 0x000082ff READ [08] : CB: 0x000b0000 READ [08] : CB: 0x0000049c READ [08] : CB: 0x000b0000 READ [08] : CB: 0x0000049c READ [08] : CB: 0x000b0000 READ [08] : CB: 0x0000049c ME: Firmware Version 11.0.1180.0 (code) 11.0.1180.0 (recovery) 11.0.1180.0 (fitc) WRITE [00] : CB: 0x80080007 WRITE [00] : CB: 0x00000203 WRITE [00] : CB: 0x00000000 READ [08] : CB: 0x800d0007 READ [08] : CB: 0x00008203 READ [08] : CB: 0x00000000 READ [08] : CB: 0x111a4004 READ [08] : CB: 0x00000031 ME Capability: Full Network manageability : OFF ME Capability: Regular Network manageability : OFF ME Capability: Manageability : OFF ME Capability: Small business technology : OFF ME Capability: Level III manageability : OFF ME Capability: IntelR Anti-Theft (AT) : OFF ME Capability: IntelR Capability Licensing Service (CLS) : ON ME Capability: IntelR Power Sharing Technology (MPC) : OFF ME Capability: ICC Over Clocking : ON ME Capability: Protected Audio Video Path (PAVP) : ON ME Capability: IPV6 : OFF ME Capability: KVM Remote Control (KVM) : OFF ME Capability: Outbreak Containment Heuristic (OCH) : OFF ME Capability: Virtual LAN (VLAN) : ON ME Capability: TLS : OFF ME Capability: Wireless LAN (WLAN) : OFF exiting On Fri, Dec 30, 2016 at 11:04 AM, Shawn <citypw(a)gmail.com> wrote: > Hi Zoran, > > Thanks for the info. I added my Device ID into the intelmetool.h: > > diff --git a/intelmetool.h b/intelmetool.h > index d79d6b0..16ca43a 100644 > --- a/intelmetool.h > +++ b/intelmetool.h > @@ -225,6 +225,7 @@ > #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914 > #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916 > #define PCI_DEVICE_ID_INTEL_ICH9 0x2918 > +#define PCI_DEVICE_ID_INTEL_SUNRISE 0x9d3a > > #define PCI_DEV_CAN_DISABLE_ME_IF_PRESENT(x) ( \ > ( (x) == PCI_DEVICE_ID_INTEL_ICH8 ) || \ > @@ -232,6 +233,7 @@ > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DH ) || \ > ( (x) == PCI_DEVICE_ID_INTEL_ICH9DO ) || \ > ( (x) == PCI_DEVICE_ID_INTEL_ICH9R ) || \ > + ( (x) == PCI_DEVICE_ID_INTEL_SUNRISE ) || \ > ( (x) == PCI_DEVICE_ID_INTEL_ICH9 )) > > // Not sure at all > > This one should be the ME? > +-16.0 Intel Corporation Sunrise Point-LP CSME HECI [8086:9d3a] > > #./intelmetool -s > Not sure if ME hardware is present because you have a `Sunrise > Point-LP CSME HECI`, but it is possible to disable it if you do, > continuing... > RCBA at 0x00000000 > MEI not hidden on PCI, checking if visible > MEI device not found, huh? > exiting > > > > On Thu, Dec 29, 2016 at 12:50 AM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: >>>> I'm not sure if intelmetool support Skylake as well. >> >> Investigated more. The coreboot intelmetool is the latest one, as I >> understood (comparing one from github and coreboot). >> >> And Sunrise Point is NOT supported (look into latest coreboot's >> coreboot/util/intelmetool/intelmetool.h). You can try to add it (as Device >> ID), manually, peek around the C code, and see if this can help you. >> >> Zoran >> >> On Wed, Dec 28, 2016 at 5:26 PM, Zoran Stojsavljevic >> <zoran.stojsavljevic(a)gmail.com> wrote: >>> >>> Hello Shawn, >>> >>> Please, follow my CLI transcript from my Future Fedora 26 VM over WIN10 >>> (now rawhide) with Fedora 4.8.15 kernel implanted (kernel 4.10.0-rc0 gives >>> me lot of griefs, I do not trust it, so I eliminated it for now): >>> >>> [zoran@localhost ~]$ cd projects/ >>> [zoran@localhost projects]$ mkdir intelmetool >>> [zoran@localhost projects]$ cd intelmetool/ >>> [zoran@localhost intelmetool]$ pwd >>> /home/zoran/projects/intelmetool >>> [zoran@localhost intelmetool]$ uname -r >>> 4.8.15-300.fc25.x86_64 >>> [zoran@localhost intelmetool]$ git clone >>> https://github.com/zamaudio/intelmetool.git >>> Cloning into 'intelmetool'... >>> remote: Counting objects: 214, done. >>> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214 >>> Receiving objects: 100% (214/214), 72.42 KiB | 0 bytes/s, done. >>> Resolving deltas: 100% (125/125), done. >>> [zoran@localhost intelmetool]$ ls -al >>> total 12 >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >>> drwxrwxr-x. 10 zoran zoran 4096 Dec 28 17:05 .. >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 intelmetool >>> [zoran@localhost intelmetool]$ cd intelmetool/ >>> [zoran@localhost intelmetool]$ ls -al >>> total 100 >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >>> [zoran@localhost intelmetool]$ su -m >>> Password: >>> [root@localhost intelmetool]# make >>> gcc -Wall -O0 -g -I. -c me_status.c -o me_status.o >>> gcc -Wall -O0 -g -I. -c me.c -o me.o >>> me.c: In function ‘mei_dump’: >>> me.c:63:18: warning: variable ‘csr’ set but not used >>> [-Wunused-but-set-variable] >>> struct mei_csr *csr; >>> ^~~ >>> gcc -Wall -O0 -g -I. -c mmap.c -o mmap.o >>> mmap.c: In function ‘map_physical_exact’: >>> mmap.c:11:26: warning: passing argument 1 of ‘mmap’ makes pointer from >>> integer without a cast [-Wint-conversion] >>> virt_addr = mmap(mapto, len, PROT_WRITE | PROT_READ, >>> MAP_SHARED|MAP_FIXED, >>> ^~~~~ >>> In file included from mmap.h:4:0, >>> from mmap.c:1: >>> /usr/include/sys/mman.h:57:14: note: expected ‘void *’ but argument is of >>> type ‘uint64_t {aka long unsigned int}’ >>> extern void *mmap (void *__addr, size_t __len, int __prot, >>> ^~~~ >>> gcc -Wall -O0 -g -I. -o intelmetool intelmetool.o me_status.o me.o mmap.o >>> -lpci >>> [root@localhost intelmetool]# date >>> Wed Dec 28 17:07:26 CET 2016 >>> [root@localhost intelmetool]# ls -al >>> total 228 >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:07 . >>> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >>> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >>> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >>> -rwxr-xr-x. 1 root root 47008 Dec 28 17:07 intelmetool >>> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >>> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >>> -rw-rw-r--. 1 zoran zoran 22144 Dec 28 17:06 intelmetool.o >>> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >>> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >>> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >>> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >>> -rw-r--r--. 1 root root 28984 Dec 28 17:07 me.o >>> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >>> -rw-r--r--. 1 root root 15704 Dec 28 17:07 me_status.o >>> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >>> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >>> -rw-r--r--. 1 root root 7648 Dec 28 17:07 mmap.o >>> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >>> [root@localhost intelmetool]# ./intelmetool >>> ME is not present on your board because we found a `82371AB/EB/MB PIIX4 >>> ISA`, you are safe, exiting >>> [root@localhost intelmetool]# >>> _______ >>> >>> Do NOT forget: I run Fedora rawhide on VMWorkstation 12.5.2 Type 2 HYP on >>> the top of WIN10 64 Pro! >>> >>> Please, do the same on Mint18 distro on raw HW, and see if this will give >>> you some different results then what you have presently? >>> >>> Please, let us know! >>> >>> Zoran >>> >>> On Wed, Dec 28, 2016 at 11:06 AM, Shawn <citypw(a)gmail.com> wrote: >>>> >>>> Hi Zoran, >>>> >>>> I created hwdb.bin via: >>>> >>>> # udevadm hwdb --update >>>> >>>> The result is still "segfault". dmesg: >>>> >>>> [ 972.044664] intelmetool[5055]: segfault at 16 ip 000000000040169e >>>> sp 000072ed96a44680 error 4 in intelmetool[400000+6000] >>>> [ 972.044674] grsec: Segmentation fault occurred at 0000000000000016 >>>> in /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 >>>> [ 972.044685] grsec: denied resource overstep by requesting 4096 for >>>> RLIMIT_CORE against limit 0 for >>>> /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >>>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 >>>> >>>> >>>> On Mon, Dec 26, 2016 at 9:49 PM, Zoran Stojsavljevic >>>> <zoran.stojsavljevic(a)gmail.com> wrote: >>>> > Not sure if your strace log has anything to do with intelmetool. >>>> > >>>> > I did on your strace log the following (and in RED is possible cause of >>>> > your >>>> > problems): >>>> > >>>> > [zoran@localhost projects]$ cat crash.log | grep ENOENT >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > open("/usr/share/misc/pci.ids.gz", O_RDONLY) = -1 ENOENT (No such file >>>> > or >>>> > directory) >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) >>>> > = -1 >>>> > ENOENT (No such file or directory) >>>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) >>>> > = -1 >>>> > ENOENT (No such file or directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>>> > directory) >>>> > open("/root/.pciids-cache", O_RDONLY) = -1 ENOENT (No such file or >>>> > directory) >>>> > open("/etc/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No >>>> > such >>>> > file or directory) >>>> > open("/etc/udev/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such >>>> > file or >>>> > directory) >>>> > open("/usr/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT >>>> > (No >>>> > such file or directory) >>>> > open("/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No >>>> > such >>>> > file or directory) >>>> > [zoran@localhost projects]$ >>>> > >>>> > I guess, you have one very important missing file in your Linux >>>> > configuration, this one: /etc/systemd/hwdb/hwdb.bin... >>>> > /etc/udev/hwdb.bin ?! >>>> > >>>> > Here is good read: >>>> > https://www.freedesktop.org/software/systemd/man/hwdb.html >>>> > >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >>>> > >>>> > Have no idea who is creating this file, but you can check your Linux >>>> > distro >>>> > / tree with the following paths to find hwdb.bin: >>>> > >>>> > /etc/systemd/hwdb/hwdb.bin >>>> > /etc/udev/hwdb.bin <<======= In my Fedora rawhide VM >>>> > (future Fedora 26) I have here hwdb.bin ======= >>>> > /usr/lib/systemd/hwdb/hwdb.bin >>>> > /lib/systemd/hwdb/hwdb.bin >>>> > >>>> > If you don't have in any, please, create one with the following link: >>>> > >>>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >>>> > >>>> > Please, let us know! >>>> > >>>> > Zoran >>>> > >>>> > On Mon, Dec 26, 2016 at 3:42 PM, Shawn <citypw(a)gmail.com> wrote: >>>> >> >>>> >> Hi, >>>> >> >>>> >> intelmetool occurs "segfault" on my laptop running Mint 18 with >>>> >> PaX/Grsecurity 4.7.10. The PCI info: >>>> >> >>>> >> -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM >>>> >> Registers [8086:1904] >>>> >> +-02.0 Intel Corporation Sky Lake Integrated Graphics >>>> >> [8086:1916] >>>> >> +-04.0 Intel Corporation Skylake Processor Thermal >>>> >> Subsystem [8086:1903] >>>> >> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI >>>> >> Controller [8086:9d2f] >>>> >> +-14.2 Intel Corporation Sunrise Point-LP Thermal >>>> >> subsystem [8086:9d31] >>>> >> +-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C >>>> >> Controller [8086:9d60] >>>> >> +-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C >>>> >> Controller [8086:9d61] >>>> >> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI >>>> >> [8086:9d3a] >>>> >> +-1c.0-[01]----00.0 NVIDIA Corporation GM107M [GeForce GTX >>>> >> 960M] [10de:139b] >>>> >> +-1c.4-[02]----00.0 Samsung Electronics Co Ltd NVMe SSD >>>> >> Controller [144d:a802] >>>> >> +-1c.6-[03]----00.0 Qualcomm Atheros Killer E2400 Gigabit >>>> >> Ethernet Controller [1969:e0a1] >>>> >> +-1c.7-[04]----00.0 Qualcomm Atheros QCA6174 802.11ac >>>> >> Wireless Network Adapter [168c:003e] >>>> >> +-1d.0-[05]----00.0 Samsung Electronics Co Ltd NVMe SSD >>>> >> Controller [144d:a802] >>>> >> +-1d.2-[06-3e]-- >>>> >> +-1f.0 Intel Corporation Sunrise Point-LP LPC Controller >>>> >> [8086:9d48] >>>> >> +-1f.2 Intel Corporation Sunrise Point-LP PMC [8086:9d21] >>>> >> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio >>>> >> [8086:9d70] >>>> >> \-1f.4 Intel Corporation Sunrise Point-LP SMBus >>>> >> [8086:9d23] >>>> >> >>>> >> The crash log was attached! I'm not sure if intelmetool support >>>> >> Skylake as well. One tiny feature of PaX/Grsecurity prevent the ioperm >>>> >> for killing the potential threats in case which >>>> >> the adversary re-flash the SPI ROM once they get the root priv. It >>>> >> does affect flashrom but intelmetool. I also ran intelmetool on the >>>> >> distro( Mint 18) kernel and got the same result. >>>> >> >>>> >> >>>> >> -- >>>> >> GNU powered it... >>>> >> GPL protect it... >>>> >> God blessing it... >>>> >> >>>> >> regards >>>> >> Shawn >>>> >> >>>> >> -- >>>> >> coreboot mailing list: coreboot(a)coreboot.org >>>> >> https://www.coreboot.org/mailman/listinfo/coreboot >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> GNU powered it... >>>> GPL protect it... >>>> God blessing it... >>>> >>>> regards >>>> Shawn >>> >>> >> > > > > -- > GNU powered it... > GPL protect it... > God blessing it... > > regards > Shawn -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

Re: [coreboot] How does intelmetool's support for Skylake?
by Shawn 30 Dec '16

30 Dec '16

Hi Zoran, Thanks for the info. I added my Device ID into the intelmetool.h: diff --git a/intelmetool.h b/intelmetool.h index d79d6b0..16ca43a 100644 --- a/intelmetool.h +++ b/intelmetool.h @@ -225,6 +225,7 @@ #define PCI_DEVICE_ID_INTEL_ICH9DO 0x2914 #define PCI_DEVICE_ID_INTEL_ICH9R 0x2916 #define PCI_DEVICE_ID_INTEL_ICH9 0x2918 +#define PCI_DEVICE_ID_INTEL_SUNRISE 0x9d3a #define PCI_DEV_CAN_DISABLE_ME_IF_PRESENT(x) ( \ ( (x) == PCI_DEVICE_ID_INTEL_ICH8 ) || \ @@ -232,6 +233,7 @@ ( (x) == PCI_DEVICE_ID_INTEL_ICH9DH ) || \ ( (x) == PCI_DEVICE_ID_INTEL_ICH9DO ) || \ ( (x) == PCI_DEVICE_ID_INTEL_ICH9R ) || \ + ( (x) == PCI_DEVICE_ID_INTEL_SUNRISE ) || \ ( (x) == PCI_DEVICE_ID_INTEL_ICH9 )) // Not sure at all This one should be the ME? +-16.0 Intel Corporation Sunrise Point-LP CSME HECI [8086:9d3a] #./intelmetool -s Not sure if ME hardware is present because you have a `Sunrise Point-LP CSME HECI`, but it is possible to disable it if you do, continuing... RCBA at 0x00000000 MEI not hidden on PCI, checking if visible MEI device not found, huh? exiting On Thu, Dec 29, 2016 at 12:50 AM, Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com> wrote: >>> I'm not sure if intelmetool support Skylake as well. > > Investigated more. The coreboot intelmetool is the latest one, as I > understood (comparing one from github and coreboot). > > And Sunrise Point is NOT supported (look into latest coreboot's > coreboot/util/intelmetool/intelmetool.h). You can try to add it (as Device > ID), manually, peek around the C code, and see if this can help you. > > Zoran > > On Wed, Dec 28, 2016 at 5:26 PM, Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: >> >> Hello Shawn, >> >> Please, follow my CLI transcript from my Future Fedora 26 VM over WIN10 >> (now rawhide) with Fedora 4.8.15 kernel implanted (kernel 4.10.0-rc0 gives >> me lot of griefs, I do not trust it, so I eliminated it for now): >> >> [zoran@localhost ~]$ cd projects/ >> [zoran@localhost projects]$ mkdir intelmetool >> [zoran@localhost projects]$ cd intelmetool/ >> [zoran@localhost intelmetool]$ pwd >> /home/zoran/projects/intelmetool >> [zoran@localhost intelmetool]$ uname -r >> 4.8.15-300.fc25.x86_64 >> [zoran@localhost intelmetool]$ git clone >> https://github.com/zamaudio/intelmetool.git >> Cloning into 'intelmetool'... >> remote: Counting objects: 214, done. >> remote: Total 214 (delta 0), reused 0 (delta 0), pack-reused 214 >> Receiving objects: 100% (214/214), 72.42 KiB | 0 bytes/s, done. >> Resolving deltas: 100% (125/125), done. >> [zoran@localhost intelmetool]$ ls -al >> total 12 >> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >> drwxrwxr-x. 10 zoran zoran 4096 Dec 28 17:05 .. >> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 intelmetool >> [zoran@localhost intelmetool]$ cd intelmetool/ >> [zoran@localhost intelmetool]$ ls -al >> total 100 >> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 . >> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >> [zoran@localhost intelmetool]$ su -m >> Password: >> [root@localhost intelmetool]# make >> gcc -Wall -O0 -g -I. -c me_status.c -o me_status.o >> gcc -Wall -O0 -g -I. -c me.c -o me.o >> me.c: In function ‘mei_dump’: >> me.c:63:18: warning: variable ‘csr’ set but not used >> [-Wunused-but-set-variable] >> struct mei_csr *csr; >> ^~~ >> gcc -Wall -O0 -g -I. -c mmap.c -o mmap.o >> mmap.c: In function ‘map_physical_exact’: >> mmap.c:11:26: warning: passing argument 1 of ‘mmap’ makes pointer from >> integer without a cast [-Wint-conversion] >> virt_addr = mmap(mapto, len, PROT_WRITE | PROT_READ, >> MAP_SHARED|MAP_FIXED, >> ^~~~~ >> In file included from mmap.h:4:0, >> from mmap.c:1: >> /usr/include/sys/mman.h:57:14: note: expected ‘void *’ but argument is of >> type ‘uint64_t {aka long unsigned int}’ >> extern void *mmap (void *__addr, size_t __len, int __prot, >> ^~~~ >> gcc -Wall -O0 -g -I. -o intelmetool intelmetool.o me_status.o me.o mmap.o >> -lpci >> [root@localhost intelmetool]# date >> Wed Dec 28 17:07:26 CET 2016 >> [root@localhost intelmetool]# ls -al >> total 228 >> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:07 . >> drwxrwxr-x. 3 zoran zoran 4096 Dec 28 17:06 .. >> drwxrwxr-x. 8 zoran zoran 4096 Dec 28 17:06 .git >> -rw-rw-r--. 1 zoran zoran 16 Dec 28 17:06 .gitignore >> -rwxr-xr-x. 1 root root 47008 Dec 28 17:07 intelmetool >> -rw-rw-r--. 1 zoran zoran 8956 Dec 28 17:06 intelmetool.c >> -rw-rw-r--. 1 zoran zoran 9783 Dec 28 17:06 intelmetool.h >> -rw-rw-r--. 1 zoran zoran 22144 Dec 28 17:06 intelmetool.o >> -rw-rw-r--. 1 zoran zoran 532 Dec 28 17:06 LICENSE >> -rw-rw-r--. 1 zoran zoran 351 Dec 28 17:06 Makefile >> -rw-rw-r--. 1 zoran zoran 16810 Dec 28 17:06 me.c >> -rw-rw-r--. 1 zoran zoran 10622 Dec 28 17:06 me.h >> -rw-r--r--. 1 root root 28984 Dec 28 17:07 me.o >> -rw-rw-r--. 1 zoran zoran 7246 Dec 28 17:06 me_status.c >> -rw-r--r--. 1 root root 15704 Dec 28 17:07 me_status.o >> -rw-rw-r--. 1 zoran zoran 1109 Dec 28 17:06 mmap.c >> -rw-rw-r--. 1 zoran zoran 224 Dec 28 17:06 mmap.h >> -rw-r--r--. 1 root root 7648 Dec 28 17:07 mmap.o >> -rw-rw-r--. 1 zoran zoran 90 Dec 28 17:06 README.md >> [root@localhost intelmetool]# ./intelmetool >> ME is not present on your board because we found a `82371AB/EB/MB PIIX4 >> ISA`, you are safe, exiting >> [root@localhost intelmetool]# >> _______ >> >> Do NOT forget: I run Fedora rawhide on VMWorkstation 12.5.2 Type 2 HYP on >> the top of WIN10 64 Pro! >> >> Please, do the same on Mint18 distro on raw HW, and see if this will give >> you some different results then what you have presently? >> >> Please, let us know! >> >> Zoran >> >> On Wed, Dec 28, 2016 at 11:06 AM, Shawn <citypw(a)gmail.com> wrote: >>> >>> Hi Zoran, >>> >>> I created hwdb.bin via: >>> >>> # udevadm hwdb --update >>> >>> The result is still "segfault". dmesg: >>> >>> [ 972.044664] intelmetool[5055]: segfault at 16 ip 000000000040169e >>> sp 000072ed96a44680 error 4 in intelmetool[400000+6000] >>> [ 972.044674] grsec: Segmentation fault occurred at 0000000000000016 >>> in /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 >>> [ 972.044685] grsec: denied resource overstep by requesting 4096 for >>> RLIMIT_CORE against limit 0 for >>> /usr/local/bin/intelmetool[intelmetool:5055] uid/euid:0/0 >>> gid/egid:0/0, parent /bin/bash[bash:4332] uid/euid:0/0 gid/egid:0/0 >>> >>> >>> On Mon, Dec 26, 2016 at 9:49 PM, Zoran Stojsavljevic >>> <zoran.stojsavljevic(a)gmail.com> wrote: >>> > Not sure if your strace log has anything to do with intelmetool. >>> > >>> > I did on your strace log the following (and in RED is possible cause of >>> > your >>> > problems): >>> > >>> > [zoran@localhost projects]$ cat crash.log | grep ENOENT >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > open("/usr/share/misc/pci.ids.gz", O_RDONLY) = -1 ENOENT (No such file >>> > or >>> > directory) >>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) >>> > = -1 >>> > ENOENT (No such file or directory) >>> > connect(4, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) >>> > = -1 >>> > ENOENT (No such file or directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or >>> > directory) >>> > open("/root/.pciids-cache", O_RDONLY) = -1 ENOENT (No such file or >>> > directory) >>> > open("/etc/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No >>> > such >>> > file or directory) >>> > open("/etc/udev/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such >>> > file or >>> > directory) >>> > open("/usr/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT >>> > (No >>> > such file or directory) >>> > open("/lib/systemd/hwdb/hwdb.bin", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No >>> > such >>> > file or directory) >>> > [zoran@localhost projects]$ >>> > >>> > I guess, you have one very important missing file in your Linux >>> > configuration, this one: /etc/systemd/hwdb/hwdb.bin... >>> > /etc/udev/hwdb.bin ?! >>> > >>> > Here is good read: >>> > https://www.freedesktop.org/software/systemd/man/hwdb.html >>> > >>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >>> > >>> > Have no idea who is creating this file, but you can check your Linux >>> > distro >>> > / tree with the following paths to find hwdb.bin: >>> > >>> > /etc/systemd/hwdb/hwdb.bin >>> > /etc/udev/hwdb.bin <<======= In my Fedora rawhide VM >>> > (future Fedora 26) I have here hwdb.bin ======= >>> > /usr/lib/systemd/hwdb/hwdb.bin >>> > /lib/systemd/hwdb/hwdb.bin >>> > >>> > If you don't have in any, please, create one with the following link: >>> > >>> > http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd-hwdb&ampsect=8 >>> > >>> > Please, let us know! >>> > >>> > Zoran >>> > >>> > On Mon, Dec 26, 2016 at 3:42 PM, Shawn <citypw(a)gmail.com> wrote: >>> >> >>> >> Hi, >>> >> >>> >> intelmetool occurs "segfault" on my laptop running Mint 18 with >>> >> PaX/Grsecurity 4.7.10. The PCI info: >>> >> >>> >> -[0000:00]-+-00.0 Intel Corporation Sky Lake Host Bridge/DRAM >>> >> Registers [8086:1904] >>> >> +-02.0 Intel Corporation Sky Lake Integrated Graphics >>> >> [8086:1916] >>> >> +-04.0 Intel Corporation Skylake Processor Thermal >>> >> Subsystem [8086:1903] >>> >> +-14.0 Intel Corporation Sunrise Point-LP USB 3.0 xHCI >>> >> Controller [8086:9d2f] >>> >> +-14.2 Intel Corporation Sunrise Point-LP Thermal >>> >> subsystem [8086:9d31] >>> >> +-15.0 Intel Corporation Sunrise Point-LP Serial IO I2C >>> >> Controller [8086:9d60] >>> >> +-15.1 Intel Corporation Sunrise Point-LP Serial IO I2C >>> >> Controller [8086:9d61] >>> >> +-16.0 Intel Corporation Sunrise Point-LP CSME HECI >>> >> [8086:9d3a] >>> >> +-1c.0-[01]----00.0 NVIDIA Corporation GM107M [GeForce GTX >>> >> 960M] [10de:139b] >>> >> +-1c.4-[02]----00.0 Samsung Electronics Co Ltd NVMe SSD >>> >> Controller [144d:a802] >>> >> +-1c.6-[03]----00.0 Qualcomm Atheros Killer E2400 Gigabit >>> >> Ethernet Controller [1969:e0a1] >>> >> +-1c.7-[04]----00.0 Qualcomm Atheros QCA6174 802.11ac >>> >> Wireless Network Adapter [168c:003e] >>> >> +-1d.0-[05]----00.0 Samsung Electronics Co Ltd NVMe SSD >>> >> Controller [144d:a802] >>> >> +-1d.2-[06-3e]-- >>> >> +-1f.0 Intel Corporation Sunrise Point-LP LPC Controller >>> >> [8086:9d48] >>> >> +-1f.2 Intel Corporation Sunrise Point-LP PMC [8086:9d21] >>> >> +-1f.3 Intel Corporation Sunrise Point-LP HD Audio >>> >> [8086:9d70] >>> >> \-1f.4 Intel Corporation Sunrise Point-LP SMBus >>> >> [8086:9d23] >>> >> >>> >> The crash log was attached! I'm not sure if intelmetool support >>> >> Skylake as well. One tiny feature of PaX/Grsecurity prevent the ioperm >>> >> for killing the potential threats in case which >>> >> the adversary re-flash the SPI ROM once they get the root priv. It >>> >> does affect flashrom but intelmetool. I also ran intelmetool on the >>> >> distro( Mint 18) kernel and got the same result. >>> >> >>> >> >>> >> -- >>> >> GNU powered it... >>> >> GPL protect it... >>> >> God blessing it... >>> >> >>> >> regards >>> >> Shawn >>> >> >>> >> -- >>> >> coreboot mailing list: coreboot(a)coreboot.org >>> >> https://www.coreboot.org/mailman/listinfo/coreboot >>> > >>> > >>> >>> >>> >>> -- >>> GNU powered it... >>> GPL protect it... >>> God blessing it... >>> >>> regards >>> Shawn >> >> > -- GNU powered it... GPL protect it... God blessing it... regards Shawn

1 0

AMD codebase change, multiple mainboards affected
by Timothy Pearson 29 Dec '16

29 Dec '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I intend to merge this patch (or a variant thereof) shortly: https://review.coreboot.org/#/c/17625 This is a large patch for AMD systems to clean up the #include mess in the native AMD support, and as a result it touches most Family 10h/15h mainboards along with a handful of K8 systems. Many of these mainboards do not have any test entries in the coreboot test database, and it is unknown if these boards function with the current code or will continue to function after this patch has been applied. If anyone has one of the following mainboards, please: 1.) Submit a test report with the current coreboot HEAD revision 2.) Test the referenced patch on your hardware and report back if a regression was found Advansus a785e-i AMD bimini_fam10 AMD mahogany AMD mahogany_fam10 AMD serengeti_cheetah AMD serengeti_cheetah_fam10 AMD tilapia_fam10 Asrock 939a785gmh ASUS m2n-e ASUS m4a78-em ASUS m4a785-m ASUS m5a88-v Avalue eax-785e Broadcom blast Gigabyte m57sli Gigabyte ma785gm Gigabyte ma785gmt Gigabyte ma78gm HP dl145_g1 HP dl145_g3 HP dl165_g6_fam10 IEI kino-780am2-fam10 Iwill dk8_htx Jetway pa78vm5 MSI ms7260 MSI ms9185 MSI ms9282 MSI ms9652_fam10 NVIDIA l1_2pvv Sun ultra40m2 Supermicro h8dme Supermicro h8dmr Supermicro h8dmr_fam10 Supermicro h8qme_fam10 Supermicro h8scm_fam10 Tyan s2912 Tyan s2912_fam10 I also request that no new patches for the AMD native support or supported boards be merged until this large patch has been approved to reduce the rebase load on Damien. Thank you! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYZUzSAAoJEK+E3vEXDOFbxyoIAIvBUMEXPoMlNaqzlqV6yobJ FBB7RDy2ib19xKqA0E9DX2bXh4H3Fh7dGK4IsJdHVp1f+h8fpA4hyHmVlyA5fLmg IWD0UG+F4iWkNzq58ca9OjX/40kTZ4bNKfej6a3KFLUGVMBOaO9etB09z+afyGBa SvxyfqfI/nIOT6Ft5K4U0JL6pEXttgCcoBaZTcIXIpggmKQDgHpCpb2xCCGrChH6 8l/x9hEGJ8Ba0lc8PWhblr0wVwHLVrNUEkALMRJvORRdRRd2ZOLzwmdrp+hbt4oL OdkJzK0AT2QtzxgJxhWFnm37myoFIriR0IeQIsY5n0d2H8MEx/aDqR4tVYa+py0= =nbE5 -----END PGP SIGNATURE-----

1 0

Re: [coreboot] How to add a new SuperIO ?
by ron minnich 29 Dec '16

29 Dec '16

I took a look. I don't consider myself qualified to +2 but I added reviewers who should be able to. On Thu, Dec 29, 2016 at 4:50 AM Agrain Patrick < patrick.agrain(a)al-enterprise.com> wrote: > Hello all, > > > > I’ve pushed the code to support the EXAR SuperIO XR28V382. > > It is marked “[WIP]” with “XR28V382” in the title. > > > > Can anybody have a look at it and meaby point me to a bug, missing > configuration or other… that could explain the messages on the console > displayed below ? > > > > Thanks. > > Patrick Agrain > > > > *De :* coreboot [mailto:coreboot-bounces@coreboot.org] *De la part de* > Agrain Patrick > *Envoyé :* jeudi 29 décembre 2016 09:43 > *À :* ron minnich; coreboot(a)coreboot.org > > > *Objet :* Re: [coreboot] How to add a new SuperIO ? > > > > Hi Ron, > > Thanks for the advice. > > It would be the first time that I will push code into a GIT project with > Gerrit. Therefore, let me a few moment to gather all required information > to perform this without disturbance for others. > > For the moment, I pulled the Coreboot project and add/modify the required > files. Platform build is OK. > > Now, the push… if you have any checklist to follow, it could be helpful. > > > > Best regards, > > Patrick Agrain > > > > *De :* ron minnich [mailto:rminnich@gmail.com <rminnich(a)gmail.com>] > *Envoyé :* vendredi 16 décembre 2016 19:18 > *À :* Agrain Patrick; coreboot(a)coreboot.org > *Objet :* Re: [coreboot] How to add a new SuperIO ? > > > > it's way easier if you push your changes to gerrit marked as a WIP. People > can see the code and will likely spot any problems very quickly. > > > > On Fri, Dec 16, 2016 at 12:40 AM Agrain Patrick < > patrick.agrain(a)al-enterprise.com> wrote: > > Hi all, > > I'm trying to add a new superIO chip to the source tree. > The chip is an EXAR XR28V932. > I tried to take example of the existing superIO chips, like the i3100 and > it8716 to compose a correct source tree as following: > [agrain1@frilldlin059 coreboot]$ ls -als ./src/superio/exar/xr28v382/ > total 10 > 1 drwxr-xr-x 2 agrain1 dhs2 512 Dec 16 09:03 . > 1 drwxr-xr-x 3 agrain1 dhs2 512 Dec 15 09:41 .. > 1 -rw-r--r-- 1 agrain1 dhs2 687 Dec 15 09:34 Makefile.inc > 3 -rw-r--r-- 1 agrain1 dhs2 2614 Dec 16 09:03 superio.c > 2 -rw-r--r-- 1 agrain1 dhs2 1287 Dec 15 16:28 xr28v382.h > > I modified the devicetree.cb of my board (based on an Intel Mohon Peak) as > following: > device pci 1f.0 on end # LPC bridge > chip superio/exar/xr28v382 # Super I/O > device pnp 2e.0 on # Com1 > io 0x60 = 0x3f8 > irq 0x70 = 4 > end > device pnp 2e.1 off # Com2 > end > device pnp 2e.8 off # Watchdog > end > end > device pci 1f.3 on end # SMBus 0 > > Now the output of the console log (DEBUG level): > <...> > PCI: pci_scan_bus for bus 00 > PCI: 00:00.0 [8086/1f0f] enabled > PCI: Static device PCI: 00:01.0 not found, disabling it. > child PNP: 002e.0 not a PCI device > child PNP: 002e.1 not a PCI device > child PNP: 002e.8 not a PCI device > child PNP: 002e.0 not a PCI device > child PNP: 002e.1 not a PCI device > child PNP: 002e.8 not a PCI device > child PNP: 002e.0 not a PCI device > child PNP: 002e.1 not a PCI device > child PNP: 002e.8 not a PCI device > child PNP: 002e.0 not a PCI device > <...> > PCI: 00:1f.0 [8086/1f38] enabled > child PNP: 002e.0 not a PCI device > child PNP: 002e.1 not a PCI device > child PNP: 002e.8 not a PCI device > child PNP: 002e.0 not a PCI device > child PNP: 002e.1 not a PCI device > child PNP: 002e.8 not a PCI device > child PNP: 002e.0 not a PCI device > child PNP: 002e.1 not a PCI device > child PNP: 002e.8 not a PCI device > PCI: 00:1f.3 [8086/1f3c] enabled > child PNP: 002e.0 not a PCI device > <...> > PCI: Left over static devices: > PNP: 002e.0 > PNP: 002e.1 > PNP: 002e.8 > PCI: Check your devicetree.cb. > PCI: pci_scan_bus for bus 01 > <...> > DOMAIN: 0000 (Intel Rangeley Northbridge) > PCI: 00:00.0 (Intel Rangeley Northbridge) > PCI: 00:01.0 (Intel Rangeley Northbridge) > PCI: 00:02.0 (Intel Rangeley Northbridge) > PCI: 00:03.0 (Intel Rangeley Northbridge) > PCI: 00:04.0 (Intel Rangeley Northbridge) > PCI: 00:0b.0 (Intel Rangeley Southbridge) > PCI: 00:0e.0 (Intel Rangeley Southbridge) > PCI: 00:13.0 (Intel Rangeley Southbridge) > PCI: 00:14.0 (Intel Rangeley Southbridge) > PCI: 00:14.1 (Intel Rangeley Southbridge) > PCI: 00:14.2 (Intel Rangeley Southbridge) > PCI: 00:14.3 (Intel Rangeley Southbridge) > PCI: 00:16.0 (Intel Rangeley Southbridge) > PCI: 00:17.0 (Intel Rangeley Southbridge) > PCI: 00:18.0 (Intel Rangeley Southbridge) > PCI: 00:1f.0 (Intel Rangeley Southbridge) > PNP: 002e.0 (EXAR XR28V382 Super I/O) > PNP: 002e.1 (EXAR XR28V382 Super I/O) > PNP: 002e.8 (EXAR XR28V382 Super I/O) > PCI: 00:1f.3 (Intel Rangeley Southbridge) > PCI: 00:0f.0 (unknown) > PCI: 01:00.0 (unknown) > > I guess that the "" are not normal, isn't it ? > And so the " Check your devicetree.cb." ? > Moreover, I put a printk() in the init function of the chip and do not see > it in the log. > What particular point should I also check to be sure that I do not miss > anything ? > > Thanks for your help. > Best regards, > Patrick Agrain > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

nvramtool options
by Samuthira Pandian T 29 Dec '16

29 Dec '16

Hi Team, I couldn't read the value from Ubuntu using the "nvramtool -a" command. I am getting the below error while running the "nvramtool -a" command. nvramtool: CMOS option table not found in coreboot table. Apparently, the coreboot installed on this system was built without specifying HAVE_OPTION_TABLE. But that option is enabled in the coreboot. Kindly help me resolve this issue. Regards, Samuthira "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

coreboot to grub flag updates
by Samuthira Pandian T 29 Dec '16

29 Dec '16

Hi Team, I need to set some flag parameter in coreboot (romstage.c) file and read the same flag value from grub.cfg file. Is there any easy way to do the same operation. If so, kindly let me know for the procedure. Thanks, Samuthira "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

1 0

Re: [coreboot] How to add a new SuperIO ?
by Agrain Patrick 29 Dec '16

29 Dec '16

Hello all, I’ve pushed the code to support the EXAR SuperIO XR28V382. It is marked “[WIP]” with “XR28V382” in the title. Can anybody have a look at it and meaby point me to a bug, missing configuration or other… that could explain the messages on the console displayed below ? Thanks. Patrick Agrain De : coreboot [mailto:coreboot-bounces@coreboot.org] De la part de Agrain Patrick Envoyé : jeudi 29 décembre 2016 09:43 À : ron minnich; coreboot(a)coreboot.org Objet : Re: [coreboot] How to add a new SuperIO ? Hi Ron, Thanks for the advice. It would be the first time that I will push code into a GIT project with Gerrit. Therefore, let me a few moment to gather all required information to perform this without disturbance for others. For the moment, I pulled the Coreboot project and add/modify the required files. Platform build is OK. Now, the push… if you have any checklist to follow, it could be helpful. Best regards, Patrick Agrain De : ron minnich [mailto:rminnich@gmail.com] Envoyé : vendredi 16 décembre 2016 19:18 À : Agrain Patrick; coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Objet : Re: [coreboot] How to add a new SuperIO ? it's way easier if you push your changes to gerrit marked as a WIP. People can see the code and will likely spot any problems very quickly. On Fri, Dec 16, 2016 at 12:40 AM Agrain Patrick <patrick.agrain(a)al-enterprise.com<mailto:patrick.agrain@al-enterprise.com>> wrote: Hi all, I'm trying to add a new superIO chip to the source tree. The chip is an EXAR XR28V932. I tried to take example of the existing superIO chips, like the i3100 and it8716 to compose a correct source tree as following: [agrain1@frilldlin059 coreboot]$ ls -als ./src/superio/exar/xr28v382/ total 10 1 drwxr-xr-x 2 agrain1 dhs2 512 Dec 16 09:03 . 1 drwxr-xr-x 3 agrain1 dhs2 512 Dec 15 09:41 .. 1 -rw-r--r-- 1 agrain1 dhs2 687 Dec 15 09:34 Makefile.inc 3 -rw-r--r-- 1 agrain1 dhs2 2614 Dec 16 09:03 superio.c 2 -rw-r--r-- 1 agrain1 dhs2 1287 Dec 15 16:28 xr28v382.h I modified the devicetree.cb of my board (based on an Intel Mohon Peak) as following: device pci 1f.0 on end # LPC bridge chip superio/exar/xr28v382 # Super I/O device pnp 2e.0 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.1 off # Com2 end device pnp 2e.8 off # Watchdog end end device pci 1f.3 on end # SMBus 0 Now the output of the console log (DEBUG level): <...> PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/1f0f] enabled PCI: Static device PCI: 00:01.0 not found, disabling it. child PNP: 002e.0 not a PCI device child PNP: 002e.1 not a PCI device child PNP: 002e.8 not a PCI device child PNP: 002e.0 not a PCI device child PNP: 002e.1 not a PCI device child PNP: 002e.8 not a PCI device child PNP: 002e.0 not a PCI device child PNP: 002e.1 not a PCI device child PNP: 002e.8 not a PCI device child PNP: 002e.0 not a PCI device <...> PCI: 00:1f.0 [8086/1f38] enabled child PNP: 002e.0 not a PCI device child PNP: 002e.1 not a PCI device child PNP: 002e.8 not a PCI device child PNP: 002e.0 not a PCI device child PNP: 002e.1 not a PCI device child PNP: 002e.8 not a PCI device child PNP: 002e.0 not a PCI device child PNP: 002e.1 not a PCI device child PNP: 002e.8 not a PCI device PCI: 00:1f.3 [8086/1f3c] enabled child PNP: 002e.0 not a PCI device <...> PCI: Left over static devices: PNP: 002e.0 PNP: 002e.1 PNP: 002e.8 PCI: Check your devicetree.cb. PCI: pci_scan_bus for bus 01 <...> DOMAIN: 0000 (Intel Rangeley Northbridge) PCI: 00:00.0 (Intel Rangeley Northbridge) PCI: 00:01.0 (Intel Rangeley Northbridge) PCI: 00:02.0 (Intel Rangeley Northbridge) PCI: 00:03.0 (Intel Rangeley Northbridge) PCI: 00:04.0 (Intel Rangeley Northbridge) PCI: 00:0b.0 (Intel Rangeley Southbridge) PCI: 00:0e.0 (Intel Rangeley Southbridge) PCI: 00:13.0 (Intel Rangeley Southbridge) PCI: 00:14.0 (Intel Rangeley Southbridge) PCI: 00:14.1 (Intel Rangeley Southbridge) PCI: 00:14.2 (Intel Rangeley Southbridge) PCI: 00:14.3 (Intel Rangeley Southbridge) PCI: 00:16.0 (Intel Rangeley Southbridge) PCI: 00:17.0 (Intel Rangeley Southbridge) PCI: 00:18.0 (Intel Rangeley Southbridge) PCI: 00:1f.0 (Intel Rangeley Southbridge) PNP: 002e.0 (EXAR XR28V382 Super I/O) PNP: 002e.1 (EXAR XR28V382 Super I/O) PNP: 002e.8 (EXAR XR28V382 Super I/O) PCI: 00:1f.3 (Intel Rangeley Southbridge) PCI: 00:0f.0 (unknown) PCI: 01:00.0 (unknown) I guess that the "" are not normal, isn't it ? And so the " Check your devicetree.cb." ? Moreover, I put a printk() in the init function of the chip and do not see it in the log. What particular point should I also check to be sure that I do not miss anything ? Thanks for your help. Best regards, Patrick Agrain -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] iPXE on multiple chips with the same PCI ID
by Аладышев Константин 29 Dec '16

29 Dec '16

Hello! Thanks for an answer! Yes, it’s the same board. (Haswell ULT + Lynxpoint) This is a custom board, so I don’t push it to coreboot repository, and therefore it is kinda hard for me to keep up to date with coreboot project. So I’ve fixed on some stable release and developed from there. Again, board is custom, so you’re right, there is no proprietary BIOS. There is definitely overlapping of some kind. I at least want to know the source of it. Is this problem caused by iPXE image or Coreboot/Seabios allocation? I'll try to port my coreboot changes to the newest release someday, but now it sounds like a shot in the dark. From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Thursday, December 29, 2016 1:12 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] iPXE on multiple chips with the same PCI ID Hello Konstantin, Seems that your board plays kind of fiber based GIGa router with several (max. 10) optical i/f attached. Insinuates the same board from the previous email. Correct? Here is what CPU is used: https://ark.intel.com/products/75114/Intel-Core-i7-4650U-Processor-4M-Cache… (CPUID - 0x40651). Glanced via attached log. Yup, there are all visible, and in early stage there are some resource allocations for all three I350 devices/PCIe buses, seems that these resources overlap per device (in early stages). Could not say with 100% certainty. Lot of kludges, assumptions... But let us take the different route, for now (to save the time). Questions to you: [1] Why you are using very old Coreboot build 4.0 (coreboot-4.0-8341-g5e6dd5f-dirty Thu Mar 19 10:15:27 UTC 2015)??? [2] Did you ever use BIOS for this router? How does BIOS behave in the term of PXE booting? I start doubting that customized/tailored BIOS ever existed for this proprietary HSW built board!? TO DO: [1] To rebuild Coreboot with the latest and greatest Coreboot 4.5, and repeat the tests again? Please, let us know! :-) Zoran On Wed, Dec 28, 2016 at 3:17 PM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: I have a board with multiple external PCIe Ethernet I350 chips. In my lspci I have: 03.00.0 (4-port I350) 03.00.1 03.00.2 03.00.3 04.00.0 (4-port I350) 04.00.1 04.00.2 04.00.3 05.00.0 (2-port I350) 05.00.1 I builtin iPXE image to coreboot and I have all of these devices in Seabios bootmenu. But the problem is that I can only boot from ports of the first appeared chip. In the example above it will be 03.00.x boot devices. If I’ll physically unplug 03.00.x chip, I’ll be able to boot from 04.00.x boot devices. And if I’ll unplug 03.00.x and 04.00.x chip, I’ll be able to boot from 05.00.x boot devices. Does someone had the same problem and how to solve it? Coreboot+SeaBIOS log is in attachment (it has some additional printk’s) -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] USB EHCI power management
by Аладышев Константин 29 Dec '16

29 Dec '16

Salut, Zoran! The question isn’t specific to LynxPoint PCH. It is related to EHCI specification. Every southbridge with EHCI controller should support these registers in a right way. Anyway, after months of investigation I solved this issue couple of days after I posted this letter. The solution was very simple, I just needed to explicitly disable XHCI through RCBA registers: /* Disable unused devices (board specific) */ RCBA_RMW_REG_32(FD, ~0, PCH_DISABLE_ALWAYS | PCH_DISABLE_XHCI), It seems like “device pci 14.0 off end # USB3 XHCI” record in devicetree.cb is not enough. I spend so much time on this, cause USB worked perfectly without this RCBA register until S3 suspend/resume sequence. For complete answer, I’ll post solutions to my questions: 1) D3hot 2) Yes 3) Yes, and in resume BIOS sequence they still be suspended. But besides suspend bit all other bits in this F0-Fx register should be preserved (like current connection status)! If it isn’t so, something is wrong 4) It should be enabled automatically already in resume BIOS sequence From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Tuesday, December 27, 2016 7:35 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] USB EHCI power management Privet Konstantin, Ja mogu i po Russkomu (russkij keyboard ne imeet dlja menja nikakogo smisla perekljucat6, tak cto ja po Russkomu naucilsja davnim, prezde cem (paru let prezde) ZX81 i Spektrum pojavilis6, no budu ja pisat6 po Anglijskij, tak cto ljudi Coreboot-a mogut ponjat6 ob cem mi zdes6 tolkujem/hozjataistvujem. :-) _______ I do not think that people here, Coreboot people, have appropriate detailed documentation for Lynx Point (Series 8 PCH), which primarily serves to HSW (CORE 4) Family. It also served (as experimental PCH) to some SKL (Core 6) families. Before Sunrise Point (Series 10, I believe) PCH came to existence. About 14+ months ago. For the bigger picture, I'll suggest to you the following test scenario: [1] You should do all of this what you have asked here with HSW (CORE 4) true BIOS, and then installing on the top of it any Linux distro (I use Fedora, I mastered it, but you can use any Linux distro of your free choice): [A] After bringing BIOS up, and GRUB2, then Linux... You should exercise exactly the same scenario as you described with Coreboot BSP. Then, you should take any and every possible detailed log which you can (to compare with the same scenario using Coreboot). [B] You should see if you have the same behavior as you describe it in your original email. [2] You say/write heading: USB EHCI power management. What about: USB xHCI power management (there is duality there, in Lynx Point PCH, don't you know?)? I hope this email helps somehow. :-) Zoran On Tue, Dec 27, 2016 at 10:24 AM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: I have a problem with USB EHCI on board with Lynxpoint-LP southbridge. First of all system doesn't wakeup from USB devices from S3. EHCI controller is listed in "/proc/acpi/wakeup" as "enabled" and GPE number is seemed to be configured correctly to PME_B0, but it doesn't work. More troubling issue that USB stops working after wakeup (for example from power button). In attempt to solve this issue I started to investigate how exactly EHCI works in S3 suspend/resume sequence. And I have some questions: 1) PCI_config: PWR_CNTL_STS register (54-55h) What power state should enter EHCI controller when system enters S3? D0 state or D3hot ? 2) MEM_BASE: USB2.0_CMD (20-23h) Is it correct, that system disables "Run/Stop (RS)" bit when system enters S3? 3) MEM_BASE: RMHPORTSTSN (F0h) Is it correct, that all ports became suspended when system enters S3? 4) Who is responsible to set "Run/Stop (RS)" and bring USB ports from suspended state? BIOS or OS? 5) Is there any board in coreboot that has USB EHCI working correctly with S3 suspend/resume? -- coreboot mailing list: coreboot(a)coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot

2 1

iPXE on multiple chips with the same PCI ID
by Аладышев Константин 29 Dec '16

29 Dec '16

I have a board with multiple external PCIe Ethernet I350 chips. In my lspci I have: 03.00.0 (4-port I350) 03.00.1 03.00.2 03.00.3 04.00.0 (4-port I350) 04.00.1 04.00.2 04.00.3 05.00.0 (2-port I350) 05.00.1 I builtin iPXE image to coreboot and I have all of these devices in Seabios bootmenu. But the problem is that I can only boot from ports of the first appeared chip. In the example above it will be 03.00.x boot devices. If I'll physically unplug 03.00.x chip, I'll be able to boot from 04.00.x boot devices. And if I'll unplug 03.00.x and 04.00.x chip, I'll be able to boot from 05.00.x boot devices. Does someone had the same problem and how to solve it? Coreboot+SeaBIOS log is in attachment (it has some additional printk's)

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 December 2016