[coreboot] SPI Flash debug console

[Youness Alaoui]

Hi everyone,

I mentioned this during my presentation at the coreboot conference
last week, and I was waiting for it to be merged before I announced it
on the mailing list.

For those of you working on recent hardware (this was tested on
skylake only, for broadwell to work, we need to add the spi controller
to romstage and convert it to use CAR_GLOBAL, I don't know about other
archs), if you don't have a debug header, or if you don't want to go
through the trouble of soldering on UART pads or you just don't have
any easy access to the debug console, then you can enable the "SPI
Flash console output" option in the Console menu.
It will automatically add an area to the FMAP which will contain your
console log. After you turn on the machine, you can dump the SPI flash
and use cbfstool to get the full console log :
cbfstool coreboot.rom read -r CONSOLE -f console.log

The console log will contain all stages including the bootblock and
romstage, so it's useful to debug memory init issues. Since most of us
debugging coreboot on new mainboards will already have our external
SPI flasher hooked up, we can just read the rom before writing a new
one to it and get the log at the same time.

Note that the console log will not be reset on poweroff/reboot, it
will continue to grow until the whole area is full, at which point it
will stop writing anything to the flash. This is to avoid excessive
SPI writes in case you forget to disable the option once you get the
machine booting.

That's it, I hope it's useful to someone else!

Thanks to Matt DeVillier and Aaron Durbin for helping
debug/test/review the implementation.

Youness.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] FYI - KGPE-D16's are $30 off on newegg with a coupon code

[taii...@gmx.com]

$30 off the usual $415 is nice if anyone is considering getting one.

The open box one for $311 probably doesn't have a warranty, so ask asus 
first by email if you want to buy it open box.


"ASUCENT58FF6"

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KFSN4-DRE Automated Test Failure [master]

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/2017 04:01 PM, Timothy Pearson wrote:
> On 06/09/2017 02:06 PM, Nico Huber wrote:
>> On 09.06.2017 17:27, Raptor Engineering Automated Coreboot Test Stand wrote:
>>> The ASUS KFSN4-DRE fails verification for branch master as of commit 
>>> 43dcbfd85581de4f173953282a4917c1ee9a5922
>>>
>>> The following tests failed:
>>> VIDEO_FAILURE
> 
>> May be fixed with https://review.coreboot.org/#/c/20131/. REACTS didn't
>> tell me (yet). Behaviour is still different from before the Kconfig
>> changes: SeaVGABIOS (cbvga) is now always included, also when running
>> in text mode (it seems there wasn't any VGA BIOS run before on REACTS,
>> don't know if SeaBIOS displayed anything at all in this config?).
> 
>> Nico
> 
> It looks like the recent Gerrit updates broke the REACTS Gerrit
> integration.  We're working on a fix and should have the main system
> back up and running, along with patches for those with existing support
> contracts, by early next week.
> 
> Sorry for the temporary breakage, and thanks for working on a fix for
> the video failure!
> 

Just wanted to let everyone know that the master REACTS instance at
Raptor Engineering is back up and testing changesets assigned to it.
Hotfixes have also gone out to those holding an active REACTS support
contract.

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

iQEcBAEBAgAGBQJZPsVNAAoJEK+E3vEXDOFbulUH/3M+zqeHPpiiXZXJR2AG2VGr
6t4z1iZooKaXu2fE1CetQNoHDjlDETUq1LsYuTi9nI16ruw3tOz/BqdSkoOKsQb3
5JdSiwie7ho3PTICQN3dAkC/ahszJj1HUOlmht8qXbF9IsrDFZds1OC4lKnsYFHL
CHhFbzC04C8PboYJ7NeefZjmHej2zNfe7QT1EjUXenY5SWAA6EI9lB1nYh0Oksb/
JvtTVdQteyThBNwq4I5Oc9TbFsVS6ViCpgaZ8kKThFD9b5csqR5+ilbeH0d3Ol54
k5RIknX6FY6FOWDUmhqGYJJbq+DMoEwjundMsTD1m5Va+A9Qs546yvfIruxpWSA=
=63Mh
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Where to buy the KCMA-D8? *brand new*

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/11/2017 01:09 PM, Johnysecured88 wrote:
> The problem is there are no heavy duty apps for the power arch.
> Photoshop, Premiere, All Adobe apps, all Autocad/3ds max, the list goes
> on an on.

Respectfully, if you are using those applications, you have far larger
issues to worry about than whether the underlying system can be owner
controlled -- you have zero control over the application layer and
(probably) the kernel and firmware due to the increasing DRM
requirements for those applications.

That being said, as POWER systems become more widespread I expect ports
of big name software to become available; at least software that already
had a Linux port.  For others, the best course of action is really to
somehow get development of the competing open source solution off the
ground and up to feature parity with the commercial offering(s) -- by
the time you get a vendor's attention with a multi-million dollar
proposition, you could just directly fund development of one of the open
source packages and bring it up to a high degree of polish.

 I myself am building an opteron server build but I also plan
> on taking you up on the upcoming offering.
> 
> The question is, what options are there for running x86 on power9? If
> there were a good performing emulation layer it would be great. Ive seen
> the qemu demo and it doesnt seem to be on par with normal
> virtualizations. Ive heard of hardware assisted emulation but I dont
> believe power9 chips will have that?

POWER has had hardware virtualization extensions since at *least*
POWER7, and IIRC significantly before that.  However, they help POWER
run on POWER, and do not directly help x86 run on POWER.

The biggest issue with QEMU cross-arch emulation for heavy-duty apps is
really the fact that there is no direct mapping of vector instructions.
 If someone could invest the $$$ needed to make that happen, x86 apps
could run with only a several time slowdown versus the hundredfold or
more slowdown due to guest vector instructions being serialised on the
host platform.  There are a few demos from some Chinese researchers
exploring this idea (x86-->ARM), and the results are very impressive.

Of course, if you start relying on this for anything other than academic
purposes you *might* run into the same legal problem that prevents the
manufacture of non-Intel and non-AMD x86 chips -- you'd be using the
patented, copyrighted x86 instruction set without the express permission
of Intel.  The reason I say "might" is that if your x86 apps are old
enough, or support an old enough version of the x86 instruction set, you
might be able to use a modified version of QEMU that avoids any patent
infringement and still have your x86 application(s) run.

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

iQEcBAEBAgAGBQJZPsEwAAoJEK+E3vEXDOFb8WcH/RjCqCKzS0sfeXMih0FdIQxa
e6bAoX+w1aNuFE7qsq6MMhLHSKjKGaPw/MOqc9HB9/+aFbm5b8v900MtvibDw8Tb
Kn7IUNntxkLBNEt79/FiOtOHGEp6YRa83gbUOohORRun/S6bhav6OkBph+Dxl7BQ
Y9wN8gDy5XDaGlxY6aUlDjHtqO2N1skf96460OzqkoOXYXtTID8GZQQ2bho59iv9
NVZvSE0xs3nt7yk594EfRHIgTA1EVHIBA5TO+hwnUqyXRHsQWWPqVpwn+Ph6SoSJ
HsS7wz8banKvQFE/eh0eBM8FiAj2ZBdAgbquYP4wX1285BbhPNp2OG+X3DgLECg=
=pc+h
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] riscv: How to implement configstring

[ron minnich]

On Mon, Jun 12, 2017 at 12:13 AM 王翔  wrote:

>
> The configstring implement by spike or other SOC?
>

yes.

But it seems they will eventually use FDT, since most of the people in the
discussion think Linux compatibility is the single most important thing.
ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] riscv: How to implement configstring

[王翔]

I try to boot linux use coreboot. But I get some error.

Jumping to boot code at 9000()
CPU0: stack: 8080 - 80801000, lowest used address 
8084, stack used: 4092 bytes
Config string: ''
We don't have virtual memory...
OK, let's go
Got timer interrupt but found no timer.


This is due to the inability to get configstring.





const char *configstring(void)
{
uint32_t addr = *(uint32_t *)CONFIG_RISCV_CONFIGSTRING;
return (const char *)(uintptr_t)addr;
}




The configstring implement by spike or other SOC?
If this is done through coreboot, maybe a global variable is more appropriate.
This avoids modifying the link script.









--



王翔

安全研究员

广州市腾御安信息科技有限公司





广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot