coreboot January 2017

coreboot@coreboot.org

75 participants
186 discussions

power controller/serial port mux
by ron minnich 10 Jan '17

10 Jan '17

I need an ethernet-attached device for controlling power to 4 to 8 systems, and also a serial port mux which can allow multiple users to go to different systems. If there is a box that does both that's a plus. I figure this group knows more than anybody about a good choice. thanks ron

1 0

Re: [coreboot] failing ref on the KGPE-D16
by ron minnich 10 Jan '17

10 Jan '17

thanks, that works. It's also nice and clean, modulo my initial misunderstanding :-) On Mon, Jan 9, 2017 at 8:51 PM Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Tue, Jan 10, 2017 at 1:16 AM, ron minnich <rminnich(a)gmail.com> wrote: > > > This is the commit that causes KGPE-D16 to fail: > commit c2973d196d1224a1253478dc29d5f8fa004eaab8 > Author: Furquan Shaikh <furquan(a)chromium.org> > Date: Tue Nov 29 22:07:42 2016 -0800 > > > Sorry Furquan! I can't run if I build with this one. > > > I think I found a relatively clean fix for this: > > https://review.coreboot.org/#/c/18082/ > > Kyösti >

1 0

Re: [coreboot] coreboot on KGPE-D16 "boot-loops"
by Pi Van Den Cirkel 10 Jan '17

10 Jan '17

It boots! with Nanya (Nanya 4GB 2Rx8 PC3-10600E-9-10-E0 1333 ECC) but only one CPU socket is populated (i dont have more Nanya modules). If i populate the other socket with HMT125R7BFR8C-H9, it blocks at ```ERROR: PNP: 002e.b 70 irq size: 0x0000000001 not assigned``` Serial console output (set to debug level) is attached. The fan runs at max rpm all the time. Is this expected? The kernel complains: do_IRQ: 1.55 No irq handler for vector do_IRQ: 2.55 No irq handler for vector do_IRQ: 3.55 No irq handler for vector do_IRQ: 4.55 No irq handler for vector do_IRQ: 5.55 No irq handler for vector do_IRQ: 6.55 No irq handler for vector do_IRQ: 7.55 No irq handler for vector do_IRQ: 8.55 No irq handler for vector do_IRQ: 9.55 No irq handler for vector do_IRQ: 10.55 No irq handler for vector Is this RAM expected to work: http://www.kingston.com/dataSheets/KVR16R11D4_8.pdf? I could find non-expensive modules on ebay ... Cannot afford the RAM on HCL. On Mon, Jan 9, 2017 at 1:47 PM, ron minnich <rminnich(a)gmail.com> wrote: > I'd be curious to know if any ram you have works ... > > On Mon, Jan 9, 2017 at 10:34 AM Pi Van Den Cirkel <opdecirkel(a)gmail.com> > wrote: >> >> Hey Timothy, I provided log for two cases. >> 1) With RAM: HMT42GR7CMR4C-G7 D8 AC - two modules, one module in slot A2 >> The log is: https://paste.debian.net/hidden/83d4816c/ and repeats over >> and over again starting at: >> >> coreboot-4.5-771-gf3e2679-dirty Fri Jan 6 20:33:58 UTC 2017 romstage >> starting... >> >> 2) With RAM Module: Nanya 4GB 2Rx8 PC3-10600E-9-10-E0 1333 ECC >> (NT4GC72B8PG0NF-CG) >> The boot process blockes at: ```ERROR: PNP: 002e.b 70 irq size: >> 0x0000000001 not assigned``` >> Full log: https://paste.debian.net/hidden/d38ffc04/ >> >> Let me know if you want me to enable extra logging. >> >> Thank you for helping! >> >> Another one with: >> >> On Mon, Jan 9, 2017 at 11:42 AM, Timothy Pearson >> <tpearson(a)raptorengineering.com> wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 01/09/2017 10:27 AM, Taiidan(a)gmx.com wrote: >> >> I don't know if this is the same problem as I lack a null modem cable >> >> but mine sometimes takes 30 seconds or so to actually boot and show vga >> >> output. >> >> >> >> If I flip the power switch and turn it back on after a little while I >> >> have to wait much longer, in the meantime the PWM fans are off and it >> >> is >> >> dead to the world. >> >> >> >> There is also a problem where loading the kernel too fast results in an >> >> immediate reboot, I must wait at the grub screen for 15 seconds or so >> >> if >> >> I don't want this to happen >> >> >> >> >> >> I am curious do you guys have a uniprocessor system without the second >> >> 8pin connection? >> >> >> > >> > Could I get full coreboot serial boot logs from both of these machines? >> > Without the logs I would just be guessing. >> > >> > Thanks! >> > >> > - -- >> > 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/ >> > >> > iQEcBAEBAgAGBQJYc71pAAoJEK+E3vEXDOFby+gH/3fcHF3FdnSYklKTyjURqc8L >> > DXfIMyLQrBmMZKPcTFqBEriWyIon4qXEZJ/1lshO+7gjMLmk+Q2QC/Kjc7hux2Z1 >> > gEzfalAUX8L+nhtEQJI3CtyX2GhiIj2oC7uifAlthcI/DAwoK52UQtdfDcJ8pSh4 >> > iBLDgS6XK22i+NgUvDare41sAp8Ibg+emOA8CQ2azl/CYIQv9x1MrU8T8e9j/3mt >> > 7bBPRZ1UrlT3rqy6a1kp/cA1CnyW4JkiAaVq7v+sZfc/CTAPdDf3Bb0/Te07//yg >> > n6JbsQsh6IVqFCjlt6eM54xMD/aNCrVd9bbXKjyFBYJtTx0t8UDglXmVPepg8l4= >> > =nxZ6 >> > -----END PGP SIGNATURE----- >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] failing ref on the KGPE-D16
by Kyösti Mälkki 10 Jan '17

10 Jan '17

On Tue, Jan 10, 2017 at 1:16 AM, ron minnich <rminnich(a)gmail.com> wrote: > > This is the commit that causes KGPE-D16 to fail: > commit c2973d196d1224a1253478dc29d5f8fa004eaab8 > Author: Furquan Shaikh <furquan(a)chromium.org> > Date: Tue Nov 29 22:07:42 2016 -0800 > > > Sorry Furquan! I can't run if I build with this one. > I think I found a relatively clean fix for this: https://review.coreboot.org/#/c/18082/ Kyösti

1 0

Re: [coreboot] Does the Core2Quad Mobile Q9100 require microcode updates?
by Taiidan＠gmx.com 10 Jan '17

10 Jan '17

Reasons to hate microcode updates: * They enable companies to ship broken CPU's and fix them later thus a CPU undergoes less testing (remember when software/games didn't have and worked fine without a day one patch?) * Theoretically a nation state actor could screw around with a CPU and have an internal microcode update to secure their own systems, or something else like that. * It is a black box (at least with intel) that is just another step of the war on general purpose computing- the tivoization of hardware.

4 4

Re: [coreboot] new problem with KGPE-d16
by ron minnich 10 Jan '17

10 Jan '17

This is called "why we should print the values and not just a message like 'transfer too big'" :-) nice catch. Hope that fixes it. On Mon, Jan 9, 2017 at 3:57 PM Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Tue, Jan 10, 2017 at 12:13 AM, ron minnich <rminnich(a)gmail.com> wrote: > > what's weird is coreboot is unchanged, just the payload. > > I am wondering if anyone recognizes this > > IMD small region: > IMD ROOT 0. bfffec00 00000400 > ROMSTAGE 1. bfffebe0 00000004 > GDT 2. bfffe9e0 00000200 > Writing AMD DCT configuration to Flash > CBFS: 'Master Header Locator' located CBFS at [100:ffffc0) > CBFS: Locating 's3nv' > CBFS: Found @ offset 2fec0 size 10000 > Manufacturer: ef > SF: Detected W25Q128 with sector size 0x1000, total 0x1000000 > FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()? > SF: Failed to send command 06: 1 > FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()? > SF: Failed to send command 06: 1 > > Also ... "Too much to write" ... I'll submit a CL but, folks, "Too much to > write"? How about some numbers on this kind of message :-) > > > All AMD southbridge/spi.c is affected: spi_ctrlr_xfer() fails with > bytesout==0. > > - bytesout--; > + if (bytesout) > + bytesout--; > > That alone might fix it, but will need to check datasheets about resetting > fifo pointers. > > Kyösti >

1 0

Re: [coreboot] new problem with KGPE-d16
by Kyösti Mälkki 10 Jan '17

10 Jan '17

On Tue, Jan 10, 2017 at 12:13 AM, ron minnich <rminnich(a)gmail.com> wrote: > what's weird is coreboot is unchanged, just the payload. > > I am wondering if anyone recognizes this > > IMD small region: > IMD ROOT 0. bfffec00 00000400 > ROMSTAGE 1. bfffebe0 00000004 > GDT 2. bfffe9e0 00000200 > Writing AMD DCT configuration to Flash > CBFS: 'Master Header Locator' located CBFS at [100:ffffc0) > CBFS: Locating 's3nv' > CBFS: Found @ offset 2fec0 size 10000 > Manufacturer: ef > SF: Detected W25Q128 with sector size 0x1000, total 0x1000000 > FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()? > SF: Failed to send command 06: 1 > FCH SPI: Too much to write. Does your SPI chip driver use spi_crop_chunk()? > SF: Failed to send command 06: 1 > > Also ... "Too much to write" ... I'll submit a CL but, folks, "Too much to > write"? How about some numbers on this kind of message :-) > > All AMD southbridge/spi.c is affected: spi_ctrlr_xfer() fails with bytesout==0. - bytesout--; + if (bytesout) + bytesout--; That alone might fix it, but will need to check datasheets about resetting fifo pointers. Kyösti

1 0

failing ref on the KGPE-D16
by ron minnich 10 Jan '17

10 Jan '17

This is the commit that causes KGPE-D16 to fail: commit c2973d196d1224a1253478dc29d5f8fa004eaab8 Author: Furquan Shaikh <furquan(a)chromium.org> Date: Tue Nov 29 22:07:42 2016 -0800 Sorry Furquan! I can't run if I build with this one. ron

1 0

Re: [coreboot] new problem with KGPE-d16
by Timothy Pearson 10 Jan '17

10 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2017 05:12 PM, ron minnich wrote: > > > On Mon, Jan 9, 2017 at 3:00 PM Timothy Pearson > <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/09/2017 04:55 PM, ron minnich wrote: > > yes I do. I'm working from ToT. Bisecting now > > This brings up an interesting question. How should we be testing for > payload-dependent failures on systems like the REACTS? The possibility > of the payload causing breakage within coreboot itself was not even > considered before now. > > > I think what we need is a good regression test payload kernel. This is > what I"ve done on ports to powerpc and riscv. You have a simple > priveleged mode bundle of code that exercises known failure cases. > > I've found plan 9 (now harvey) to be an easy code base for this, but a > smaller, lighter kernel would probably be even better. Agreed. I'll add this to our master list of desired features in REACTS. - -- 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/ iQEcBAEBAgAGBQJYdBkiAAoJEK+E3vEXDOFbtYYH/RXbDOTf5Z8QG+QM/hvuInXt dgoQ766jXr12b7qbNb/Do+oj6NHKxjiDfAWMbrPUKYTNCaxP22JDF3qhohQQGs8c 3YCJ8rYGM9G0JGPPoY8mgIfY5UjnEDC5sQdJewLD9nw1VsxPAC+IVVY62wPSacKV zdoDxF3lKLjqbQAqDmJEpAJSTmULZqhRsWKNvffiITQvcD2hIwuWNpGW5oibCHtD 27kFvy6vn32hQRBa0b97daq2VN3Kguwk+fNiGo+rVQd/jPveljq6PA0GWA9IlU5R 5s/6vVapgglwhycQZS/GcYrluPKA8lA9FIJjX5GkXQwKHRLpeu3N9jnjxfg6+4M= =zHWt -----END PGP SIGNATURE-----

1 0

Re: [coreboot] new problem with KGPE-d16
by Timothy Pearson 10 Jan '17

10 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2017 04:55 PM, ron minnich wrote: > yes I do. I'm working from ToT. Bisecting now This brings up an interesting question. How should we be testing for payload-dependent failures on systems like the REACTS? The possibility of the payload causing breakage within coreboot itself was not even considered before now. - -- 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/ iQEcBAEBAgAGBQJYdBYAAAoJEK+E3vEXDOFbt6EIAJZ5Dfg5WvkeA4OKWlOqX9R/ ZSmqOyaJFmf4PQEsYlhnJqH6NkvSnYJIekwKG8oEC7zOVyJe439BQe/9t42kMZkL PB9EX9NedeMO9jLsSMz5C6sSxn4UIJrqHJ//w2uowVmjvNb/kOkq2Yd8Elx2tS// bQk5At+zL/HE/86ZVmgfHxyelAkyjYAEf4c2IrmZT72uyoH3NX4aIdvnTftoNhsV 7pTpRqTtlcAg2fp7JX2v6vfiee6SculQDq+xVCDtXTYACZVsUYZnbS5c/158KKAv Rndq+mYZwSoJGQFcRQm6hkAMfRPzvQWoYhVAW5LrQaiQu1HbyHgyRGPS4Jx4ULc= =P5u1 -----END PGP SIGNATURE-----

2 1

← Newer
1
...
12
13
14
15
16
17
18
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