coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

Re: [coreboot] Rangeley FSP reports "Err[24]: GetSet Value exceeds limits" during memory init
by Zoran Stojsavljevic 22 Jan '17

22 Jan '17

Hello Andy, I would advise to you to try the same coreboot with DIMM or SIMM INTEL Rangeley based CRB, and see if this does work, for some reason? Couple of experiments more with different CRBs with different memory configurations would not make too much headaches, don't you think? If you do not use BCT tool, the following is true. You should use Binary Configuration TOOL (BCT) to change some configuration parameters for Rangeley (you should have in Rangeley FSP package also included BCT)! *As previously discussed, even though Intel FSP is a binary file, it needs a provision to customize its internal states and features; therefore, it has reserved a data region inside the binary for customization. The data area also contains a couple of platform-specific parameters that Intel FSP would otherwise have no knowledge about, or would initialize the board with default values. The Boot Setting File (BSF) plays an important role for this purpose. It is basically a text file that contains firmware internal settings associated with the board; for example, the SMBUS (System Management Bus) address of a SPD (Serial Presence Detect) ROM on a DIMM (Dual Inline Memory Module) is one of the data in the BSF.* *$gPlatformFspPkgTokenSpaceGuid_PcdMrcInitSPDAddr1 1 byte $_DEFAULT_ = 0xA0* *$gPlatformFspPkgTokenSpaceGuid_PcdMrcInitSPDAddr2 1 byte $_DEFAULT_ = 0xA2* *The data in BSF is represented in a GUI-based tool, which allows developers to visualize the meaning of each component in BSF. With the GUI and BSF, it is collectively called a Binary Configuration Tool (BCT). There are three versions of BCT: one runs under Windows, one runs under Linux, and the third is a command-line option under Linux.* Please, search for the book called: *Embedded Firmware Solutions [describing INTEL FSP]...* And search for Chapter 3. There, everything is explicitly well explained/organized. Hope this helps, Zoran On Fri, Jan 20, 2017 at 1:47 PM, Andy Knowles < aknowles(a)gallleonec.onmicrosoft.com> wrote: > I’m trying to bring up an Intel Rangeley based prototype board using > coreboot and Intel FSP. During FspInitEntry, FSP prints: > > > > Err[24]: GetSet Value exceeds limits > > > > to serial debug and halts. Does anyone know what this means? > > > > I’m using the Memory Down option in the FSP and filling in the > MEM_DOWN_DIMM_CONFIG structure in mainboard/…/romstage.c > > I can see that the FSP is reading and validating this structure, as > changing the ram speed has an effect on memory clock frequency, and if I > put in invalid values the FSP will complain. I’ve tried reducing memory > speed, disabling ECC, disabling channel 1 but I always get the same error. > > > > Does anyone else have any experience with Memory Down on Rangeley? > > > > Andy Knowles > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)
by Zoran Stojsavljevic 22 Jan '17

22 Jan '17

Hello Stefan, In addition what Charlotte wrote to you, I would advise you the following (as general approach for mem problems): [1] Please, for testing the memory, use secondary Coreboot payload called MEMTEST: [user@localhost coreboot]$ cat .config | grep MEMTEST CONFIG_MEMTEST_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_STABLE=y # CONFIG_MEMTEST_MASTER is not set Instead going to SeaBIOS or GRUB2 as payloads. This memtest86+ could (my best guess) show to you what is wrong with your memory configuration. [2] You can also (since you are able to in some cases go to Linux) stop in GRUB2, after installing from Linux memtest86+ package into the GRUB2 boot options (this can also help too, my best guess). (extra advise: if you use legacy/CSM ON, which is in Coreboot in 99.999% cases used, it would be much easier for you to deal with memtest86+) Best Regards, Zoran On Sat, Jan 21, 2017 at 11:55 AM, Stefan Tauner < stefan.tauner(a)alumni.tuwien.ac.at> wrote: > Hi Vladimir, > > since you have REed the raminit for Nehalem I'd like you to ask if you > have any knowledge, information or pointers about using 8 GB DIMMs with > it or even using more than 8 GB in total. In my case it is about an > Arrandale i5-520M (in a Thinkpad 410s). > > I know that an i7-820QM (Clarksfield) is perfectly capable of working > with 8 GB DIMMs and probably up to 32 GB or even more (the Thinkpad > W510 has 4 DIMM slots and I have tested it with 20 GB) and that is from > around the same time as the Arrendale chips - which does not mean > anything but I still refuse to accept that Nehalem is that limited. The > official specs are not trustworthy IMHO and cpuid(1) and /proc/cpuinfo > show the same physical address width of 36 bits (which would indicate a > maximum of 64 GB). > > The current raminit for Nehalem in coreboot is not able to train the two > 8 GB DIMMs I have tested so far. I have added a debug output to > choose_reg178 in the first loop before the margins are compared to > STANDARD_MIN_MARGIN that shows that all margins are 0. If there is > anything I could try or information I can provide, please let me know. > > The (ancient) vendor firmware I've been using on the T410s does > sometimes manage to boot Linux with an 8 GB DIMM (dmesg is attached > including the e820 map), but it is quite broken and memtest86 locks up > or reboots within seconds so that's probably not a good target for RE > efforts. :) > > -- > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

x200s' nvram will reset to default value if last boot is a normal boot of debian.
by Persmule 21 Jan '17

21 Jan '17

Hi all, I recently built and flashed a coreboot image to my thinkpad x200s, with an IFD generated by libreboot's ich9gen. After flashing, everything seems okay, but if I let the Debian GNU/Linux installed on that machine finish its booting, all the reasonable value inside NVRAM will be reset to default during next boot (detected via nvrancui), whether I shut it down properly or cut its power violently. I have done several tests, whose result is listed below: Boot mode NVRAM reset? payload (reboot immediately) no parted magic no trisquel live no kali live no Debian recovery mode (reboot immediately) no Debian installer no Debian normal boot (with or without display manager) yes Debian recovery mode (finish recovery and continue booting) yes Debian normal boot with kernel of Debian installer yes If I modify those value with nvramtool and reboot, they will be reset to default. If I zero the nvram region in a normal booted Debian by running "# nvramtool -B /dev/zero" and reboot, the content of NVRAM will keep all zero, and will reset during next reboot. Now in order to keep using my preferred value, I may have to write those value to cmos.default, enable STATIC_OPTION_TABLE, and then build them into the image. The problem should be inside the Debian user land. Do you guys have any clue how to locate it? Best regards, Persmule

2 1

!! Resource didn't fit !! / Porting coreboot to the Supermicro X9SPU-F mainboard
by Renze Nicolai 21 Jan '17

21 Jan '17

Hello everyone, I am trying to port coreboot to the Supermicro X9SPU-F mainboard, starting with the code for the ga-b75m-d3v mainboard (which is also based on the Intel C216 chipset). I've put the code here: https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/tree/master/c oreboot-x9spu-f/src/mainboard/supermicro/x9spu-f And I've put all the information that might be needed here: https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/tree/master/i nfo Including a bootlog extracted using the PC speaker: https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/blob/master/i nfo/bootlog I did not get the serial ports to work yet. The mainboard has both a WPCM450 and a NCT6776F superio chip. I think the serial port on the back of the machine is connected to the NCT6776F chip, which is driven by the WPCM450. If anyone knows what I did wrong with the superio chips please do tell me! But the main problem is with the PCI express config: The board stops booting when it tries to enable the resources for PCI 00:1c.6 Earlier in the bootlog this message appears: ---- Setting resources... DOMAIN: 0000 io: base:65 size:203a align:12 gran:0 limit:2f7 !! Resource didn't fit !! aligned base 1000 size 1000 limit 2f7 1fff needs to be <= 2f7 (limit) PCI: 00:1c.6 1c * [0x0 - 0xfff] io PCI: 00:1c.6 1c * [0x0 - 0xfff] io !! Resource didn't fit !! aligned base 1000 size 1000 limit 2f7 1fff needs to be <= 2f7 (limit) PCI: 00:1c.7 1c * [0x1000 - 0x1fff] io ... !! Resource didn't fit !! aligned base 1000 size 20 limit 2f7 101f needs to be <= 2f7 (limit) PCI: 05:00.0 18 * [0x0 - 0x1f] io ---- Where could these errors be coming from and how can I solve them? Did I make some kind of mistake in the devicetree.cb? Also: where do the values used in the "subsystemid" lines in the devicetree come from? Thank you! Greetings, Renze Nicolai

2 3

Setup required for autotest & older boards?
by Jeremy Banks 21 Jan '17

21 Jan '17

Hello all, Two questions: First, I was reading the Testing section of the Development Guidelines on the wiki [1] and the autotest section caught my eye. It said to ask on the mailing list, so here I am. Besides the always-online host system, what is the special circuitry required? Is it particularly expensive or difficult to acquire or set up? Second, what kinds of boards are considered valuable testing targets? Is coreboot wanting more testing on newer boards or are there gaps in older boards, chipsets, super I/Os that need a hardware testing target? I ask because I'm in the process of cleaning up and have some older motherboards boards and related parts I will be disposing of. Think socket AM3, AM2 and older. It's helpful to have these available as testing targets, great. Otherwise, I'll be disposing of them. Regards, Jeremy Banks

1 0

REACTS Pricing Changes
by Timothy Pearson 20 Jan '17

20 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, We have implemented a new, flexible licensing system for our REACTS coreboot test solution. The new licensing model allows you to only pay for what you intend to use, replacing of the old fixed 5-DUT licensing system, thus lowering the barrier to entry to get a REACTS system installed and verifying _your_ hardware. Since the first announcement of the REACTS, the system has received several feature upgrades, which are provided at no additional cost to holders of a REACTS support contract. The system now supports testing of varying architectures (currently i386, i686-pae, and x86_64), testing of S3 resume path operation, external Flash write, and much more. As always, the core system is also available under the AGPL for those with appropriate existing infrastructure wanting to assemble a test system from scratch. When you purchase a REACTS license, you are helping us continue to maintain and improve the only publicly available CI hardware testing solution for coreboot. To date REACTS has been instrumental in allowing massive cleanup, refactoring, and overall improvement of the AMD native codebase without fear of causing regression on tested hardware. If you are interested in helping this effort by purchasing a license for a ready-to-run REACTS control system, please visit the REACTS information page at https://www.raptorengineering.com/content/REACTS/intro.html 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/ iQEcBAEBAgAGBQJYdrQAAAoJEK+E3vEXDOFbCgIH/RcSuG7tWXcYS2ZvJwDotN8G eMQQO8cJXpYXAkuVGBwZESIrYgNJLkUZxRP3jfcoff55NCB537oDK1O9XidSX77s LEsAlik2M5LuytwDX30GQnvcjG2Q0vL67r25HhuL3rPj5jSPnmybDZjU4TSatnO5 S64UlnkmIpY40IZTg+YyFoKLxTnsry5Qrczu+sMhYuXCHGj67vmlvI1Ontu31iwP VwVftlll5kv1bGDaetNYaQ+3i6NtHRyB4hqopGEC8VQBYDvHTtOgdnwfM+T4eyWj movCkOoMmcS/J7gZmtBsJ0ippOcSB7g4u7U6BIfuBgyiJH+pbkFoswMTPVaqRfY= =IMtC -----END PGP SIGNATURE-----

2 2

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system
by Zoran Stojsavljevic 20 Jan '17

20 Jan '17

Ron, Google should devote more funds to you, guys, for the experiments. This is what I am trying to say. Google should fund couple of these extravagant platforms, in order to spread Coreboot usage to these server platform architectures. Sergey Brin is Russian, and he should help to push Open Source mentality. Ordinary Russians are very good guys too! ;-) Zoran On Fri, Jan 20, 2017 at 7:03 AM, ron minnich <rminnich(a)gmail.com> wrote: > Zoran, you are one of The Good Guys in my world. But I don't understand > what you're trying to say. > > ron >

1 0

ASUS KCMA-D8 workstation board port offer
by Timothy Pearson 20 Jan '17

20 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, After reviewing some of the comments on the ASUS KGPE-D16 being essentially too large of a system and too expensive for many people, and the fact that modern, blob-free systems are not really available in the mid-range arena, Raptor Engineering would like to offer to create a native initalization blob-free port for the ASUS KCMA-D8, which is essentially the KGPE-D16's ATX-compatible "little brother". We would be asking $15,000 for the port, including upstreaming to the master coreboot tree. We already have extensive experience with these Family 10h/15h boards, and would be able to create a port of similar quality to the existing KGPE-D16 source in terms of both code quality and overall functionality. If this is something you might be interested in please let me know. We are able to accept multiple payments from various sources for the same project (within limits), so if this is something your local Linux groups or similar might be interested in we should be able to keep the cost on any one individual or organization to a reasonable level. Thank you for your consideration, - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWQROpAAoJEK+E3vEXDOFbR2cH/3FTqGFH+cU/HVrBUPcoKjii h9OC7SGeXdyoLZvob/YayG+g47Yppkg2um4pAC7dmGl/OXtkGh13hlsrQ8BNiYcz g0kQUdNKYh9dmBC3YnlxU6a7psh473TdyuLILrl7/8WgI8DZnRtjy62Oo5k6XAKW jfYb/bGC8I3tArYrgQDmFxz2dOejuTZit56I+mbWNtvbuQov2BDmrPPMLRuEvG3M QHCAo/Pjaajzl4rmtrgu0GHcxHsgAnJcnrcPkFYeSDKt7QxSTNOB6NqhcnYdh1SY RiA5Z/3enuDs+XNhS+6qMeKOcrEuf+Ccs7sGsgq5tWm20JA+bBoByvrXhHqVUxU= =DKfR -----END PGP SIGNATURE-----

7 16

Rangeley FSP reports "Err[24]: GetSet Value exceeds limits" during memory init
by Andy Knowles 20 Jan '17

20 Jan '17

I'm trying to bring up an Intel Rangeley based prototype board using coreboot and Intel FSP. During FspInitEntry, FSP prints: Err[24]: GetSet Value exceeds limits to serial debug and halts. Does anyone know what this means? I'm using the Memory Down option in the FSP and filling in the MEM_DOWN_DIMM_CONFIG structure in mainboard/.../romstage.c I can see that the FSP is reading and validating this structure, as changing the ram speed has an effect on memory clock frequency, and if I put in invalid values the FSP will complain. I've tried reducing memory speed, disabling ECC, disabling channel 1 but I always get the same error. Does anyone else have any experience with Memory Down on Rangeley? Andy Knowles

1 0

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system
by ron minnich 20 Jan '17

20 Jan '17

Zoran, you are one of The Good Guys in my world. But I don't understand what you're trying to say. ron

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2017