coreboot December 2016

coreboot@coreboot.org

57 participants
121 discussions

by Pok Gu

The difficulty with calculating by hand is there are some checksum bits. If your goal is to overclock the ram to maximize its performance, you probably have to do it again and again for servel times so that the ram reaches its best performance without failing the memtest (the higher the speed the more likely to fail the memtest). Without a tool or a script the checksum bits has to be calculated everytime by hand...I am calling for a tool to make this eaiser... Possibly you don't need to invest extra money (but just some time) to use that tool. Thaiphoon Burner has a free version that it does not allow you to save the spd.bin but it has a hex editor that can show you the modified hex bits and the calculated checksum. It can be used as a reference. Then manually modify the spd.bin file and write it using some free tools (e.g., RWEveryting on Windows or eeprom/i2c-tool on Linux). 2016-12-17 5:21 GMT+08:00 David Hendricks <dhendrix(a)google.com>: > > On Fri, Dec 16, 2016 at 11:01 AM, Pok Gu <pokgoo002(a)gmail.com> wrote: > >> Thaiphoon Burne is the most popular and probably the only tool for >> modifying the spd.bin. It has many built-in templates and you only need to >> select the speed, clocking, and voltage you like (e.g., DDR3-1688/DDR3-1333 >> and CL10/CL11 and 1.35V/1.5V) and it will do all the rest calculations and >> generate the spd.bin for you. Then, the only thing you need to do is to >> flash the spd.bin to the spd chip on the ram, and reboot, and your ram >> stick is overclocked. >> >> Unfortunately, it is only available on Windows. So I have one harddisk >> loaded with Windows 7 and Thaiphoon Burne specialized for this work. >> >> I haven't found any linux software can do this unless you calculate and >> modify the spd.bin by hand. (If anyone found one let me know) >> > > Cool - I never knew about that tool. Seems like a good investment if the > goal is to generate an spd.bin from scratch. > > Sebastien - What are you trying to do, exactly? If you only need to change > one or two parameters, then a hex editor and a calculator should be > sufficient. The relevant specification for SPDs is JEDEC Standard No. 21-C > Annex K for DDR3 and Annex L for DDR4. (you'll need to register with > jedec.org to download the specs) > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. >

4 years, 7 months

Re: [coreboot] spd binaries

by David Hendricks

On Fri, Dec 16, 2016 at 11:01 AM, Pok Gu <pokgoo002(a)gmail.com> wrote: > Thaiphoon Burne is the most popular and probably the only tool for > modifying the spd.bin. It has many built-in templates and you only need to > select the speed, clocking, and voltage you like (e.g., DDR3-1688/DDR3-1333 > and CL10/CL11 and 1.35V/1.5V) and it will do all the rest calculations and > generate the spd.bin for you. Then, the only thing you need to do is to > flash the spd.bin to the spd chip on the ram, and reboot, and your ram > stick is overclocked. > > Unfortunately, it is only available on Windows. So I have one harddisk > loaded with Windows 7 and Thaiphoon Burne specialized for this work. > > I haven't found any linux software can do this unless you calculate and > modify the spd.bin by hand. (If anyone found one let me know) > Cool - I never knew about that tool. Seems like a good investment if the goal is to generate an spd.bin from scratch. Sebastien - What are you trying to do, exactly? If you only need to change one or two parameters, then a hex editor and a calculator should be sufficient. The relevant specification for SPDs is JEDEC Standard No. 21-C Annex K for DDR3 and Annex L for DDR4. (you'll need to register with jedec.org to download the specs) -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

4 years, 7 months

Re: [coreboot] spd binaries

by Pok Gu

Thaiphoon Burne is the most popular and probably the only tool for modifying the spd.bin. It has many built-in templates and you only need to select the speed, clocking, and voltage you like (e.g., DDR3-1688/DDR3-1333 and CL10/CL11 and 1.35V/1.5V) and it will do all the rest calculations and generate the spd.bin for you. Then, the only thing you need to do is to flash the spd.bin to the spd chip on the ram, and reboot, and your ram stick is overclocked. Unfortunately, it is only available on Windows. So I have one harddisk loaded with Windows 7 and Thaiphoon Burne specialized for this work. I haven't found any linux software can do this unless you calculate and modify the spd.bin by hand. (If anyone found one let me know) 2016-12-15 17:40 GMT+08:00 sebastien basset <sbhome1(a)gmail.com>: > Hello, > > > Are there tools to create or modify spd.bin for ddram ? i found > decode-dimms but no parse input file, if you have a file exemple ? > > -- > Sébastien Basset > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

4 years, 7 months

Re: [coreboot] How to add a new SuperIO ?

by ron minnich

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 >

4 years, 7 months

Re: [coreboot] your preferred method for supplying power to chip for RPi spi flashing?

by Michael Carbone

Peter Stuge wrote: > Michael Carbone wrote: >> I have been attempting to use a raspberry pi for spi flashing and when I >> use the 3.3v pin the raspberry pi doesn't power up as the chip draws too >> much power through the 3.3v pin for the raspberry pi to also run. > > It's not the flash chip drawing current, it's the rest of the mainboard. > > A PC mainboard has 10-20 different voltages. The 3.3 V rail with the > flash chip is only one of them. Each platform (CPU+chipset) defines a > strict sequence and timing for turning voltages on, for the platform > to function correctly. > > If the mainboard is otherwise unpowered and the 3.3 V rail is connected > to an external supply then that sequence and the timing is guaranteed to > be violated. This could cause anything from permanent hardware damage > (maybe unlikely, but certainly possible) to random malfunction, e.g. > excessive current draw, as long as the outside supply is connected. > > >> What is your recommended method for powering the chip and RPi? >> >> Looking online [1] some folks recommend using laptop AC adapter + >> wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure >> that's a dependable strategy > > In fact I consider it the *only* dependable strategy. It is the > obvious way to adhere to the required power up sequence. Thanks everyone for sharing their advice on this -- I can confirm that the Wake-on-LAN method works. If you are interested I have documented the full process of flashing an x230 with Heads: https://github.com/mfc/flashing-docs/wiki/Walkthrough-for-flashing-Heads-on… -- Michael Carbone Qubes OS | https://www.qubes-os.org @QubesOS <https://www.twitter.com/QubesOS> PGP fingerprint: D3D8 BEBF ECE8 91AC 46A7 30DE 63FC 4D26 84A7 33B4

4 years, 7 months

How to add a new SuperIO ?

by Agrain Patrick

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

4 years, 7 months

ASUS KFSN4-DRE Automated Test Failure [master]

by Raptor Engineering Automated Coreboot Test Stand

The ASUS KFSN4-DRE fails verification for branch master as of commit 31be2c969eed74510c3546bad0dbb9a7334f5843 The following tests failed: VIDEO_FAILURE Commits since last successful test: 31be2c9 soc/intel/common: remove mrc cache assumptions See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

4 years, 7 months

spd binaries

by sebastien basset

Hello, Are there tools to create or modify spd.bin for ddram ? i found decode-dimms but no parse input file, if you have a file exemple ? -- Sébastien Basset

4 years, 7 months

Re: [coreboot] TALOS project short of funding goals - where to now?

by Timothy Pearson

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/14/2016 02:07 PM, Zoran Stojsavljevic wrote: >> The coreboot project is pretty much dead in the water without it, */ > the only real choices for further development are either /* > */ > super low power crappy ARM devices /* or always going to be > expensive IBM/TYAN POWER servers, so what do we do? > > What is wrong with "super low power crappy ARM devices"? I'll take this particular question in isolation. If this is the only type of computer available that does not require proprietary software to function, then everyone should probably stop using a number of prominent open source projects such as LibreOffice, Chromium, Firefox, Xorg, KDE, Gnome, and the GIMP, among others. Open source hardware is also out due to the processing power required to effectively design anything more complex than a SoC breakout board or microprocessor board. Under the proposed conditions, these software packages and hardware designs effectively require proprietary systems and software for development, and therefore run contrary to normal libre software philosophy. On our end, we consider this unacceptable, which is why we have been working to provide powerful hardware for people doing real development work. Not everything can be created on a smart phone or tablet, and in point of fact, _most_ things cannot. I understand that many users or developers of small projects don't need powerful hardware, but please don't make the grave mistake of assuming that everything will continue as-is on the development side if said hardware is not available. - -- 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/ iQEcBAEBAgAGBQJYUdkdAAoJEK+E3vEXDOFbzhsH/RCjGZXoYrrLMOEE+1p4DB+M 8JU+VXWdGf0f0Ul1NWa6KH8mO6TqtYz2vCEatowe4NH5agXivDmqIYUoqx/piqzs 9t56NGZCslaaUusqey353KLwvYHVsP1RrG6bkPvCOMizZUFtL3BwE5IxPi1dFZFv bPwnkChp3jSZKEZ3ikaQFMbewz+P9jYw9OIrenubOUDIOUdjGU1oQd5d/dr5AUFS sPxqMK4yDSX1wcdTmjW3IOvLoU+u/073kHcVCgzvXJtWSH/AyvRHBEUcuFCeuL+O MKgyBcZEeEB8teH4w8gmVPluyN+DePkh9lC/HYbuU2q1AZfFsEUPpgeiNITBTS0= =oB4X -----END PGP SIGNATURE-----

4 years, 7 months

post_code to text file

by Haleigh Novak

Hello All, I was wondering if it would be possible to add a few lines in the post_code method so it also writes all the codes to a text file and then keep that text file around so it could be read once the system is running - for debugging purposes because a post_code reader is currently unavailable to me. I know that the BIOS handles the post codes and my chosen BIOS is coreboot and I have added just a couple lines to the post code method right after mainboard_post() is called in order to print the codes to a file in / as well. But I don't have any idea how to pass a small text file along from coreboot up to yocto jethro during boot - is this even possible? Any comments, thoughts, ideas, guidance would be greatly appriciated. Thank you. HN

4 years, 7 months

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2016