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.
>
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.
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
>
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
>
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
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
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
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
-----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-----
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