[coreboot] Yet another gerrit update (2.14.1)

2017-06-08 Thread Patrick Georgi via coreboot
Hi everybody,

I just updated our gerrit instance, which should fix a number of
performance related regressions.

Since there were requests for supporting ecdsa and ed25519 keys in gerrit's
ssh interface, I also want to point out that 2.14 brought support for them.
I didn't mention it because it was known to be broken, but 2.14.1 is
supposed to fix it, so feel free to use it now.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] riscv: How to debug (王翔)

2017-06-08 Thread 王翔
On Friday,June 9, 2017  at 12:34 PM,王翔 wrote:
>On Friday,June 9, 2017 9:17 AM, Jonathan Neuschäfer wrote:
>>On Thu, Jun 08, 2017 at 05:32:31PM +0800, 王翔 wrote:
>>> I try to debug coreboot with **spike**.
>>> I has apply the **8250 usart patch** to **spike**.


>>I haven't updated the patches at [1] in a while. Please check if the two
>>patches in [2] work for you if you also apply the following patch to
>>coreboot:


>>
>>diff --git a/src/mainboard/emulation/spike-riscv/uart.c 
>>b/src/mainboard/emulation/spike-riscv/uart.c
>>index 57647fee1d..26ab630091 100644
>>--- a/src/mainboard/emulation/spike-riscv/uart.c
>>+++ b/src/mainboard/emulation/spike-riscv/uart.c
>>@@ -20,5 +20,5 @@
 
> >uintptr_t uart_platform_base(int idx)
 >>{
>>- return (uintptr_t) 0x40001000;
>>+ return (uintptr_t) 0x0210;
 >>}
>>
>>[1]: https://github.com/riscv/riscv-isa-sim/pull/53
>>[2]: https://github.com/neuschaefer/riscv-isa-sim/commits/uart-update


>I get source frome  https://github.com/riscv/riscv-tools.git.
>Compare the difference with https://github.com/riscv/riscv-isa-sim/pull/53 and 
>fix the code.
>The difference of Our patch is **UART_BASE**. You use 0x0210, me use 
>0x40001000.
>In my test 0x40001000 can be work with **coreboot**, but 0x0210 can not.
>My patch is in the attachment of the message.


I'm sorry. I not change **uintptr_t uart_platform_base(int idx)**


>>> But I get from the official website of the code can not pass the test.
>>> I found some BUG when I debug this.


>>What did you test? How did it fail?


>I test by **spike**.  I have report the patch.
>https://review.coreboot.org/#/c/20043/
>https://review.coreboot.org/#/c/20105/


But these bugs still exist.


>>Regards,
>>Jonathan Neuschäfer


>Regards,
>王翔


Regards,
王翔









--



王翔

安全研究员

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





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

Re: [coreboot] riscv: How to debug (王翔)

2017-06-08 Thread 王翔
On Friday,June 9, 2017 9:17 AM, Jonathan Neuschäfer wrote:
>On Thu, Jun 08, 2017 at 05:32:31PM +0800, 王翔 wrote:
>> I try to debug coreboot with **spike**. 
>> I has apply the **8250 usart patch** to **spike**.


>I haven't updated the patches at [1] in a while. Please check if the two
>patches in [2] work for you if you also apply the following patch to
>coreboot:


>
>diff --git a/src/mainboard/emulation/spike-riscv/uart.c 
>b/src/mainboard/emulation/spike-riscv/uart.c
>index 57647fee1d..26ab630091 100644
>--- a/src/mainboard/emulation/spike-riscv/uart.c
>+++ b/src/mainboard/emulation/spike-riscv/uart.c
>@@ -20,5 +20,5 @@
 
 >uintptr_t uart_platform_base(int idx)
 >{
>-  return (uintptr_t) 0x40001000;
>+  return (uintptr_t) 0x0210;
 >}
>
>[1]: https://github.com/riscv/riscv-isa-sim/pull/53
>[2]: https://github.com/neuschaefer/riscv-isa-sim/commits/uart-update


I get source frome  https://github.com/riscv/riscv-tools.git. 
Compare the difference with https://github.com/riscv/riscv-isa-sim/pull/53 and 
fix the code.
The difference of Our patch is **UART_BASE**. You use 0x0210, me use 
0x40001000.
In my test 0x40001000 can be work with **coreboot**, but 0x0210 can not.
My patch is in the attachment of the message.


>> But I get from the official website of the code can not pass the test.
>> I found some BUG when I debug this.


>What did you test? How did it fail?


I test by **spike**.  I have report the patch.
https://review.coreboot.org/#/c/20043/
https://review.coreboot.org/#/c/20105/


>Regards,
>Jonathan Neuschäfer


Regards,
王翔







--



王翔

安全研究员

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





广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024

0001-uart-patch.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] riscv: How to debug

2017-06-08 Thread Jonathan Neuschäfer
On Thu, Jun 08, 2017 at 05:32:31PM +0800, 王翔 wrote:
> I try to debug coreboot with **spike**. 
> I has apply the **8250 usart patch** to **spike**.

I haven't updated the patches at [1] in a while. Please check if the two
patches in [2] work for you if you also apply the following patch to
coreboot:


diff --git a/src/mainboard/emulation/spike-riscv/uart.c 
b/src/mainboard/emulation/spike-riscv/uart.c
index 57647fee1d..26ab630091 100644
--- a/src/mainboard/emulation/spike-riscv/uart.c
+++ b/src/mainboard/emulation/spike-riscv/uart.c
@@ -20,5 +20,5 @@
 
 uintptr_t uart_platform_base(int idx)
 {
-   return (uintptr_t) 0x40001000;
+   return (uintptr_t) 0x0210;
 }


[1]: https://github.com/riscv/riscv-isa-sim/pull/53
[2]: https://github.com/neuschaefer/riscv-isa-sim/commits/uart-update

> But I get from the official website of the code can not pass the test.
> I found some BUG when I debug this.

What did you test? How did it fail?


Regards,
Jonathan Neuschäfer


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Rene Shuster
Here's the direct download link without registering (hate to give springer
any information):
https://link.springer.com/content/pdf/10.1007%2F978-1-4302-6572-6.pdf

On Thu, Jun 8, 2017 at 4:51 PM, Peter Stuge  wrote:

> ron minnich wrote:
> > Ah gee Peter, thanks for making me look at a web page with this sentence:
> > "Safeguarding the Future of Computing with Intel Embedded Security and
> > Management Engine"
> >
> > My irony-meter immediately went to 11 ... million.
>
> Ha! :)
>
> I can really recommend eyeing through that book to get confirmation on
> where Intel has been heading for several platform generations now, or
> just for fun. (Techie advisory: Intense buzzword bingo)
>
>
> Chapter 1: Cyber Security in the Mobile Age
> Chapter 2: Intel's Embedded Solutions: from Management to Security
> Chapter 3: Building Blocks of the Security and Management Engine
> Chapter 4: The Engine: Safeguarding Itself before Safeguarding Others
>
> (Remember to check those password lengths, ey.)
>
> Chapter 5: Privacy at the Next Level: Intel's Enhanced Privacy
> Identification (EPID) Technology
> Chapter 6: Boot with Integrity, or Don't Boot
> Chapter 7: Trust Computing, Backed by the Intel Platform Trust Technology
> Chapter 8: Unleashing Premium Entertainment with Hardware-Based Content
> Protection
> Chapter 9: Breaking the Boundaries with Dynamically Loaded Applications
>
> (Chapter 9 is my favorite! It describes how the ME OS can dynamically
> load third-party Java code.)
>
> Chapter 10: Intel Identity Protection Technology: the Robust, Convenient,
> and Cost-Effective Way to Deter Identity Theft
> Chapter 11: Looking Ahead: Tomorrow's Innovations Built on Today's
> Foundation
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] and here we go again!

2017-06-08 Thread ron minnich
"Microsoft's security team has come across a malware family that uses
Intel's Active Management Technology (AMT) Serial-over-LAN (SOL) interface

 as a file transfer tool. The problem with Intel AMT SOL is that it's part
of Intel's ME, a separate chip inside Intel CPUs that runs its own OS and
stays on even when the main CPU is off."

This is getting monotonous. All these AMT exploits, ...

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

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Peter Stuge
ron minnich wrote:
> Ah gee Peter, thanks for making me look at a web page with this sentence:
> "Safeguarding the Future of Computing with Intel Embedded Security and
> Management Engine"
> 
> My irony-meter immediately went to 11 ... million.

Ha! :)

I can really recommend eyeing through that book to get confirmation on
where Intel has been heading for several platform generations now, or
just for fun. (Techie advisory: Intense buzzword bingo)


Chapter 1: Cyber Security in the Mobile Age
Chapter 2: Intel's Embedded Solutions: from Management to Security
Chapter 3: Building Blocks of the Security and Management Engine
Chapter 4: The Engine: Safeguarding Itself before Safeguarding Others

(Remember to check those password lengths, ey.)

Chapter 5: Privacy at the Next Level: Intel's Enhanced Privacy Identification 
(EPID) Technology
Chapter 6: Boot with Integrity, or Don't Boot
Chapter 7: Trust Computing, Backed by the Intel Platform Trust Technology
Chapter 8: Unleashing Premium Entertainment with Hardware-Based Content 
Protection
Chapter 9: Breaking the Boundaries with Dynamically Loaded Applications

(Chapter 9 is my favorite! It describes how the ME OS can dynamically
load third-party Java code.)

Chapter 10: Intel Identity Protection Technology: the Robust, Convenient, and 
Cost-Effective Way to Deter Identity Theft
Chapter 11: Looking Ahead: Tomorrow's Innovations Built on Today's Foundation


//Peter

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


Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread ron minnich
Ah gee Peter, thanks for making me look at a web page with this sentence:
"Safeguarding the Future of Computing with Intel Embedded Security and
Management Engine"

My irony-meter immediately went to 11 ... million.

On Thu, Jun 8, 2017 at 1:43 PM Peter Stuge  wrote:

> Rene Shuster wrote:
> > Not an expert obviously, but I was under the impression the Digital
> > Restriction Management was achieved through Widevine. No?
>
> DRM requires hardware support to be useful. If the Widevine software
> component was solely responsible for DRM then another software
> component running on the same system (e.g. in the kernel) would be
> able to capture all video frames.
>
> Please study Intel PAVP and Intel Insider. The best information I
> have seen on the topic so far is Intel's ME book. Free PDF download
> after registration.
>
> http://www.apress.com/9781430265719
>
> Chapter 8: Unleashing Premium Entertainment with Hardware-Based
> Content Protection Technology
>
> 20 pages explain how it works.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Peter Stuge
Rene Shuster wrote:
> Not an expert obviously, but I was under the impression the Digital
> Restriction Management was achieved through Widevine. No?

DRM requires hardware support to be useful. If the Widevine software
component was solely responsible for DRM then another software
component running on the same system (e.g. in the kernel) would be
able to capture all video frames.

Please study Intel PAVP and Intel Insider. The best information I
have seen on the topic so far is Intel's ME book. Free PDF download
after registration.

http://www.apress.com/9781430265719

Chapter 8: Unleashing Premium Entertainment with Hardware-Based
Content Protection Technology

20 pages explain how it works.


//Peter

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


[coreboot] coreboot community meeting minutes for June 8, 2017

2017-06-08 Thread Martin Roth
These are the minutes from yesterday's coreboot community meeting.
Information about the next meeting is at the bottom.

Today's meeting was very short again, with not much news due to a focus on
the Denver conference for the past couple of weeks.  We had a total of 7
people attending.

###
Date: Thursday, June 8, 2017

Infrastructure News
* Gerrit was updated to version 2.14
  - May be having some server errors?  This was reported on the IRC channel.
  - New user interface can be selected with the "New UI" button at the
bottom of the page.
* Need to check on coreboot REACTS instance
  - Philipp and Martin plan to update this over the next week
* Jenkins servers are using docker image v1.44a - This added the Ada
toolchain to the image. This update actually happened a couple months back.


Conferences
* Denver coreboot conference finished yesterday
  - Follow-up messages were sent out to attendees to see what should be
changed and what should stay the same in future meetings.
  - We will start getting videos posted over the weekend - A significant
amount of editing needs to happen to combine the audio and video streams.

##
Next meeting is Thursday, June 22, 2017
Check the coreboot calendar for the time in your timezone
https://www.coreboot.org/calendar.html

Join using the bluejeans web app or the phone bridge:
https://bluejeans.com/616384323

Phone bridge call in numbers:  https://www.bluejeans.com/numbers
Meeting ID: 616384323

Current agenda & history:
https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Rene Shuster
Not an expert obviously, but I was under the impression the Digital
Restriction Management was achieved through Widevine. No?

On Thu, Jun 8, 2017 at 3:46 PM, Patrick Georgi  wrote:

> Since these discussions flare up time and time again (without ever being
> resolved in any productive way because the discussion happens in the wrong
> forum [0]):
> Netflix et al are (probably) required by their contracts with the content
> providers (producers, distributors) to make it reasonably hard to access
> the unencrypted bits of sufficiently high quality video (discussing the
> merit and feasibility of these approaches should also happen elsewhere [0]).
> The PSP (or ME, or ARM TrustZone) provide the technical means for a
> programmable DRM path (what Intel calls the PAVP, protected audio/video
> path, which seems to be partly implemented by the ME) with sufficient
> security guarantees that Netflix et al are willing to risk sending HD  (or
> 4K or better) video through that channel.
>
> Therefore: A CPU with PSP/ME/ARM TZ is one that won't support Netflix [1].
>
>
> Patrick
>
> [0] Preaching to the choir is fun the first 10 times. It's slightly less
> fun the next 10 times. And totally tedious the 1000th-1010th times. Sorry
> that you're late to the party but that's not our fault.
> Worse, debating these things here helps nothing since the people that you
> really should to talk to for making a difference aren't subscribed to
> technical lists like this one. They probably play golf and enjoy the sun.
> You can likely talk to them if you present a business case with ~8
> significant non-zero digits in some currency not very unlike the USD. While
> playing golf. And enjoying the sun.
>
> [1] It's quite possible to build designs that come without such a "locked
> down processor with access to everything". There's also little money to be
> had in building these, while the current designs have a certain level of
> maturity that makes any significant deviation a serious risk: These chains
> of contracts that connect these coprocessors with Hollywood (probably) come
> with contractual penalties for breaches that result from reckless behavior
> (such as changing the security architecture nilly-willy). "Not rocking the
> boat" is a rather sensible option under such constraints.
> Those ~8 significant digits in some USD-style currency mentioned earlier
> might help change that risk assessment. You won't be able to crowdfund them
> here.
>
> 2017-06-08 21:00 GMT+02:00 Rene Shuster :
>
>> Nico,
>> Would you mind to elaborate and enlighten us on this matter?
>>
>> On Thu, Jun 8, 2017 at 1:31 PM, Nico Huber  wrote:
>>
>>> On 08.06.2017 16:48, Johnysecured88 via coreboot wrote:
>>> > Does anyone anticipate the new EPYC cpus not having PSP?
>>>
>>> Well, I don't. The answer is quite simple if you ask the question
>>> differently: Do you expect AMD to drop Netflix support?
>>>
>>> Nico
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>>
>> --
>> Tech III * AppControl * Endpoint Protection * Server Maintenance
>> Buncombe County Schools Technology Department Network Group
>> ComicSans Awareness Campaign 
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Patrick Georgi via coreboot
Since these discussions flare up time and time again (without ever being
resolved in any productive way because the discussion happens in the wrong
forum [0]):
Netflix et al are (probably) required by their contracts with the content
providers (producers, distributors) to make it reasonably hard to access
the unencrypted bits of sufficiently high quality video (discussing the
merit and feasibility of these approaches should also happen elsewhere [0]).
The PSP (or ME, or ARM TrustZone) provide the technical means for a
programmable DRM path (what Intel calls the PAVP, protected audio/video
path, which seems to be partly implemented by the ME) with sufficient
security guarantees that Netflix et al are willing to risk sending HD  (or
4K or better) video through that channel.

Therefore: A CPU with PSP/ME/ARM TZ is one that won't support Netflix [1].


Patrick

[0] Preaching to the choir is fun the first 10 times. It's slightly less
fun the next 10 times. And totally tedious the 1000th-1010th times. Sorry
that you're late to the party but that's not our fault.
Worse, debating these things here helps nothing since the people that you
really should to talk to for making a difference aren't subscribed to
technical lists like this one. They probably play golf and enjoy the sun.
You can likely talk to them if you present a business case with ~8
significant non-zero digits in some currency not very unlike the USD. While
playing golf. And enjoying the sun.

[1] It's quite possible to build designs that come without such a "locked
down processor with access to everything". There's also little money to be
had in building these, while the current designs have a certain level of
maturity that makes any significant deviation a serious risk: These chains
of contracts that connect these coprocessors with Hollywood (probably) come
with contractual penalties for breaches that result from reckless behavior
(such as changing the security architecture nilly-willy). "Not rocking the
boat" is a rather sensible option under such constraints.
Those ~8 significant digits in some USD-style currency mentioned earlier
might help change that risk assessment. You won't be able to crowdfund them
here.

2017-06-08 21:00 GMT+02:00 Rene Shuster :

> Nico,
> Would you mind to elaborate and enlighten us on this matter?
>
> On Thu, Jun 8, 2017 at 1:31 PM, Nico Huber  wrote:
>
>> On 08.06.2017 16:48, Johnysecured88 via coreboot wrote:
>> > Does anyone anticipate the new EPYC cpus not having PSP?
>>
>> Well, I don't. The answer is quite simple if you ask the question
>> differently: Do you expect AMD to drop Netflix support?
>>
>> Nico
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign 
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Rene Shuster
Nico,
Would you mind to elaborate and enlighten us on this matter?

On Thu, Jun 8, 2017 at 1:31 PM, Nico Huber  wrote:

> On 08.06.2017 16:48, Johnysecured88 via coreboot wrote:
> > Does anyone anticipate the new EPYC cpus not having PSP?
>
> Well, I don't. The answer is quite simple if you ask the question
> differently: Do you expect AMD to drop Netflix support?
>
> Nico
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD EPYC and PSP

2017-06-08 Thread Nico Huber
On 08.06.2017 16:48, Johnysecured88 via coreboot wrote:
> Does anyone anticipate the new EPYC cpus not having PSP?

Well, I don't. The answer is quite simple if you ask the question
differently: Do you expect AMD to drop Netflix support?

Nico


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


Re: [coreboot] Coreboot + Seabios Asus F2A85-M LE card

2017-06-08 Thread Piotr Kubaj via coreboot
https://www.coreboot.org/VGA_support

On 17-06-08 11:01:55, Gabriel Bosque wrote:
> Internal. Where do I find firmware for it?
> 
> Tanks in advance
> 
> 2017-06-08 10:45 GMT-03:00 Piotr Kubaj :
> 
> > Do you use the internal GPU or external? If you use internal, you probably
> > need firmware from AMD (SeaVGABIOS won't work). If you have external GPU,
> > you don't need VGA option ROM at all.
> >
> > Anyway, you don't need SeaVGABIOS.
> >
> > You also put CONFIG_QEMU_HARDWARE=y, which is unnecessary.
> >
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

-- 
  
/ No matter where I go, the place is \
\ always called "here".  /
  
\   ^__^
 \  (oo)\___
(__)\   )\/\
||w |
|| ||


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] AMD EPYC and PSP

2017-06-08 Thread Johnysecured88 via coreboot
Does anyone anticipate the new EPYC cpus not having PSP?

Sent with [ProtonMail](https://protonmail.com) Secure Email.-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot + Seabios Asus F2A85-M LE card

2017-06-08 Thread Gabriel Bosque
Internal. Where do I find firmware for it?

Tanks in advance

2017-06-08 10:45 GMT-03:00 Piotr Kubaj :

> Do you use the internal GPU or external? If you use internal, you probably
> need firmware from AMD (SeaVGABIOS won't work). If you have external GPU,
> you don't need VGA option ROM at all.
>
> Anyway, you don't need SeaVGABIOS.
>
> You also put CONFIG_QEMU_HARDWARE=y, which is unnecessary.
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot + Seabios Asus F2A85-M LE card

2017-06-08 Thread Piotr Kubaj via coreboot
Do you use the internal GPU or external? If you use internal, you probably need 
firmware from AMD (SeaVGABIOS won't work). If you have external GPU, you don't 
need VGA option ROM at all.

Anyway, you don't need SeaVGABIOS.

You also put CONFIG_QEMU_HARDWARE=y, which is unnecessary.


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot + Seabios Asus F2A85-M LE card

2017-06-08 Thread Gabriel Bosque
I forgot the .configs...

2017-06-08 8:21 GMT-03:00 Gabriel Bosque :

> Thanks for the feedback!
> I imagine I just need to put the vbios file if the video card is not
> default ... anyway could you suggest a file for me to test? (For this
> motherboard model)
>
> 2017-06-08 0:01 GMT-03:00 Rafael Machado  gmail.com>:
>
>> Hi Gabriel.
>> Since you are beginning in this world, be really carefull about using
>> binaries you do not know the content. You could have a virus or a something
>> similar installed on your system. :)
>>
>> Happy studies!
>>
>> Em Qua, 7 de jun de 2017 16:18, taii...@gmx.com 
>> escreveu:
>>
>>> You probably forgot to include the required VBIOS file required to use
>>> the integrated video.
>>>
>>> Any serial output?
>>> On 06/07/2017 09:43 AM, Gabriel Bosque wrote:
>>>
>>> Hello everyone, thank you for accepting me in the group.
>>> I am totally newbie, however, I would very much like to have a pc running
>>> coreboot + seabios on an Asus F2A85-M LE card, could someone send me a .rom
>>> to write to memory?
>>> I have tried to compile, but nothing appears on the display ... I think if
>>> you confirm that it actually runs, it becomes easier to get the doubts
>>> later, through this group
>>> Thank you very much
>>>
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>>
>
#
# Automatically generated file; DO NOT EDIT.
# SeaBIOS Configuration
#

#
# General Features
#
CONFIG_COREBOOT=y
# CONFIG_QEMU is not set
# CONFIG_CSM is not set
CONFIG_QEMU_HARDWARE=y
CONFIG_THREADS=y
CONFIG_RELOCATE_INIT=y
CONFIG_BOOTMENU=y
CONFIG_BOOTSPLASH=y
CONFIG_BOOTORDER=y
CONFIG_COREBOOT_FLASH=y
CONFIG_LZMA=y
CONFIG_CBFS_LOCATION=0
CONFIG_MULTIBOOT=y
CONFIG_ENTRY_EXTRASTACK=y
CONFIG_MALLOC_UPPERMEMORY=y
CONFIG_ROM_SIZE=0

#
# Hardware support
#
CONFIG_ATA=y
# CONFIG_ATA_DMA is not set
# CONFIG_ATA_PIO32 is not set
CONFIG_AHCI=y
CONFIG_SDCARD=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_SCSI=y
CONFIG_PVSCSI=y
CONFIG_ESP_SCSI=y
CONFIG_LSI_SCSI=y
CONFIG_MEGASAS=y
CONFIG_MPT_SCSI=y
CONFIG_FLOPPY=y
CONFIG_FLASH_FLOPPY=y
CONFIG_NVME=y
CONFIG_PS2PORT=y
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_XHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_UAS=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y
CONFIG_SERIAL=y
CONFIG_LPT=y
CONFIG_RTC_TIMER=y
CONFIG_HARDWARE_IRQ=y
CONFIG_PMTIMER=y
CONFIG_TSC_TIMER=y

#
# BIOS interfaces
#
CONFIG_DRIVES=y
CONFIG_CDROM_BOOT=y
CONFIG_CDROM_EMU=y
CONFIG_PCIBIOS=y
CONFIG_APMBIOS=y
CONFIG_PNPBIOS=y
CONFIG_OPTIONROMS=y
CONFIG_PMM=y
CONFIG_BOOT=y
CONFIG_KEYBOARD=y
CONFIG_KBD_CALL_INT15_4F=y
CONFIG_MOUSE=y
CONFIG_S3_RESUME=y
CONFIG_VGAHOOKS=y
# CONFIG_DISABLE_A20 is not set
CONFIG_TCGBIOS=y

#
# VGA ROM
#
CONFIG_NO_VGABIOS=y
# CONFIG_VGA_GEODEGX2 is not set
# CONFIG_VGA_GEODELX is not set
# CONFIG_VGA_COREBOOT is not set
# CONFIG_BUILD_VGABIOS is not set
CONFIG_VGA_EXTRA_STACK_SIZE=512

#
# Debugging
#
CONFIG_DEBUG_LEVEL=1
CONFIG_DEBUG_SERIAL=y
CONFIG_DEBUG_SERIAL_PORT=0x3f8
CONFIG_DEBUG_IO=y
CONFIG_DEBUG_COREBOOT=y
#
# Automatically generated file; DO NOT EDIT.
# SeaBIOS Configuration
#

#
# General Features
#
CONFIG_COREBOOT=y
# CONFIG_QEMU is not set
# CONFIG_CSM is not set
CONFIG_QEMU_HARDWARE=y
CONFIG_THREADS=y
CONFIG_RELOCATE_INIT=y
CONFIG_BOOTMENU=y
CONFIG_BOOTSPLASH=y
CONFIG_BOOTORDER=y
CONFIG_COREBOOT_FLASH=y
CONFIG_LZMA=y
CONFIG_CBFS_LOCATION=0
CONFIG_MULTIBOOT=y
CONFIG_ENTRY_EXTRASTACK=y
CONFIG_MALLOC_UPPERMEMORY=y
CONFIG_ROM_SIZE=0

#
# Hardware support
#
CONFIG_ATA=y
CONFIG_ATA_DMA=y
CONFIG_ATA_PIO32=y
CONFIG_AHCI=y
CONFIG_SDCARD=y
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_SCSI=y
CONFIG_PVSCSI=y
CONFIG_ESP_SCSI=y
CONFIG_LSI_SCSI=y
CONFIG_MEGASAS=y
CONFIG_MPT_SCSI=y
CONFIG_FLOPPY=y
CONFIG_FLASH_FLOPPY=y
CONFIG_NVME=y
CONFIG_PS2PORT=y
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_XHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_UAS=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y
CONFIG_SERIAL=y
CONFIG_LPT=y
CONFIG_RTC_TIMER=y
CONFIG_HARDWARE_IRQ=y
CONFIG_PMTIMER=y
CONFIG_TSC_TIMER=y

#
# BIOS interfaces
#
CONFIG_DRIVES=y
CONFIG_CDROM_BOOT=y
CONFIG_CDROM_EMU=y
CONFIG_PCIBIOS=y
CONFIG_APMBIOS=y
CONFIG_PNPBIOS=y
CONFIG_OPTIONROMS=y
CONFIG_PMM=y
CONFIG_BOOT=y
CONFIG_KEYBOARD=y
CONFIG_KBD_CALL_INT15_4F=y
CONFIG_MOUSE=y
CONFIG_S3_RESUME=y
CONFIG_VGAHOOKS=y
# CONFIG_DISABLE_A20 is not set
CONFIG_TCGBIOS=y

#
# VGA ROM
#
# CONFIG_NO_VGABIOS is not set
# CONFIG_VGA_GEODEGX2 is not set
# CONFIG_VGA_GEODELX is not set
CONFIG_VGA_COREBOOT=y
CONFIG_BUILD_VGABIOS=y
CONFIG_VGA_EMULATE_TEXT=y
CONFIG_VGA_FIXUP_ASM=y
CONFIG_VGA_ALLOCATE_EXTRA_STACK=y
CONFIG_VGA_EXTRA_STACK_SIZE=512
CONFIG_VGA_VBE=y

#
# Debugging
#
CONFIG_DEBUG_LEVEL=1
CONFIG_DEBUG_SERIAL=y
CONFIG_DEBUG_SERIAL_PORT=0x3f8
CONFIG_DEBUG_IO=y
CONFIG_DEBUG_COREBOOT=y
#
# Automatically generated file; DO NOT EDIT.
# SeaBIOS Configuration
#

#
# General Features
#
CONFIG_COREBOOT=y
# CONFIG_QEMU is not set
# CONFIG_

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

2017-06-08 Thread Raptor Engineering Automated Coreboot Test Stand
The ASUS KFSN4-DRE fails verification for branch master as of commit 
2e7f6ccafc3e633ed9001b3c3863253ee0630429

The following tests failed:
VIDEO_FAILURE

Commits since last successful test:
2e7f6cc fsp/gop: Add running the GOP to the choice of gfx init
d4ebeaf device/Kconfig: Put gfx init methods into a `choice`
26ce9af device/Kconfig: Introduce MAINBOARD_FORCE_NATIVE_VGA_INIT
eb881d4 3rdparty/libgfxinit: Update submodule pointer
7b79a33 3rdparty/libhwbase: Update submodule pointer

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 
 regarding any issues stemming from this 
notification


1496928284-0-automaster.log.bz2
Description: application/bzip2
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] APTIO

2017-06-08 Thread Rene Shuster
I'll prefer text-based over GUI due to the faster way of navigating through
the menus, but then I saw the mouse pointer on the screenshots​...
Worst is when the defacto standard of text-based navigation with TAB /
SHIFT+TAB / arrow keys / SPACE (select) is implemented sloppy (or not
working at all and you are forced to use a mouse) or when TABing through
the settings is not in order (recent example: DELL Precision 7510).

On Wed, Jun 7, 2017 at 9:20 PM, Julius Werner  wrote:

> But does it have Bluetooth support? I feel like I should really be
> able to use my Bluetooth mouse to configure my DRAM timings.
>
> Also no .webp for the splash screen image... like some sort of BIOS
> from 2010. Sad.
>
> On Wed, Jun 7, 2017 at 4:16 PM, ron minnich  wrote:
> > read it and weep, or something.
> >
> > https://ami.com/ami_downloads/Aptio_TSE_Data_Sheet.pdf
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>



-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot + Seabios Asus F2A85-M LE card

2017-06-08 Thread Gabriel Bosque
Thanks for the feedback!
I imagine I just need to put the vbios file if the video card is not
default ... anyway could you suggest a file for me to test? (For this
motherboard model)

2017-06-08 0:01 GMT-03:00 Rafael Machado 
:

> Hi Gabriel.
> Since you are beginning in this world, be really carefull about using
> binaries you do not know the content. You could have a virus or a something
> similar installed on your system. :)
>
> Happy studies!
>
> Em Qua, 7 de jun de 2017 16:18, taii...@gmx.com 
> escreveu:
>
>> You probably forgot to include the required VBIOS file required to use
>> the integrated video.
>>
>> Any serial output?
>> On 06/07/2017 09:43 AM, Gabriel Bosque wrote:
>>
>> Hello everyone, thank you for accepting me in the group.
>> I am totally newbie, however, I would very much like to have a pc running
>> coreboot + seabios on an Asus F2A85-M LE card, could someone send me a .rom
>> to write to memory?
>> I have tried to compile, but nothing appears on the display ... I think if
>> you confirm that it actually runs, it becomes easier to get the doubts
>> later, through this group
>> Thank you very much
>>
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] make crossgcc-i386 : ubsan.c error (with fix!) for GCC

2017-06-08 Thread Paul Kocialkowski
On Sun, 2017-06-04 at 22:49 +, qma ster wrote:
> Good day! While building the coreboot's toolchain by using GCC 7.1.1
> version, I am getting the following error:
> 
> ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and
> integer [-fpermissive]
>|| xloc.file == '\0' || xloc.file[0] == '\xff'
> 
> The fix is very simple - just open
> ./util/crossgcc/gcc-6.3.0/gcc/ubsan.c and change
> 
>|| xloc.file == '\0' || xloc.file[0] == '\xff'
> 
> to
> 
>|| xloc.file[0] == '\0' || xloc.file[0] == '\xff'
> 
> Found this solution here -
> https://patchwork.openembedded.org/patch/138884/ . Would be great if
> you could somehow import it to your code

Submitted to gerrit as https://review.coreboot.org/#/c/20103/

Cheers!

-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

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


Re: [coreboot] GRUB boot menu is not showing GRUB2

2017-06-08 Thread Dhanasekar Jaganathan
Ok.. Fine

Thank you very much...Mariusz, Zoran and Nico.

On Thu, Jun 8, 2017 at 3:01 PM, Nico Huber  wrote:

> On 07.06.2017 17:34, Dhanasekar Jaganathan wrote:
> > Hi Nico,
> >
> > I have taken the Flash Region's dump of my vendor BIOS using Ifdtool
> (which
> > is copied below),
> >
> > *FLREG0:0x000f*
> > *  Flash Region 0 (Flash Descriptor):  -  *
> > *FLREG1:0x07ff0200*
> > *  Flash Region 1 (BIOS): 0020 - 007f *
> > *FLREG2:0x0fff*
> > *  Flash Region 2 (Intel ME): 00fff000 - 0fff (unused)*
> > *FLREG3:0x0fff*
> > *  Flash Region 3 (GbE): 00fff000 - 0fff (unused)*
> > *FLREG4:0x0fff*
> > *  Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)*
> >
> > From this dump, BIOS region is from 0x20 to 0x07F.
> >
> > So *CONFIG_ROM_SIZE is 8MB *and *CONFIG_CBFS_SIZE is 6MB ( 0x7F -
> > 0x20 = 0x5F)*
> >
> > Am I correct?
>
> Yes, that's correct. The 0x7f is actually inclusive, so it's exactly
> 6MiB.
>
> Nico
>
> >
> > Please correct me, if I am wrong.
> >
> > Thanks,
> > Dhanasekar
> >
> >
> > On Wed, Jun 7, 2017 at 8:26 PM, Nico Huber 
> wrote:
> >
> >> On 07.06.2017 16:49, Dhanasekar Jaganathan wrote:
> >>> Hi Nico,
> >>>
> >>> Thanks for the info..
> >>>
> >>> Actually, I have given "*make al*l" to rebuild the coreboot source.
> >>>
> >>> Is it correct way to rebuilt to the source?
> >>
> >> That should work fine.
> >>
> >>>
> >>> Or I have to run *make crossgcc-i386 CPUS=$(nproc)* and *make*
> >>
> >> crossgcc is only needed once.
> >>
> >> Nico
> >>
> >>>
> >>> Thanks,
> >>> Dhanaeskar
> >>>
> >>> On Wed, Jun 7, 2017 at 7:17 PM, Nico Huber 
> >> wrote:
> >>>
>  On 07.06.2017 15:38, Dhanasekar Jaganathan wrote:
> > Hi Nico,
> >
> > Following is my complete Payload setting,
> >
> > 1.Add a payload -> (GRUB2)
> > 2.GRUB2 version -> (HEAD)
> > 3.Include GRUB2 runtime config file into ROM image = Y
> > 4.Gave the path of grub.cfg (which I copied from Fedora OS when
> booted
> >> is
> > booted with other BIOS vendor).
> >
> > Based on this, please provide your comments.
> 
>  I can only repeat myself: With this setup, you have to rebuild your
>  coreboot every time you make changes to your grub.cfg. (You probably
>  know that already and did so, but didn't tell it?)
> 
>  Nico
> 
> >>>
> >>
> >
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] riscv: How to debug

2017-06-08 Thread 王翔
I try to debug coreboot with **spike**. 
I has apply the **8250 usart patch** to **spike**.
But I get from the official website of the code can not pass the test.
I found some BUG when I debug this.
I want to submit the code but I can't test it. What can i do,  who can help me.


I get code from `https://review.coreboot.org/coreboot.git`







--



王翔

安全研究员

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





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

Re: [coreboot] GRUB boot menu is not showing GRUB2

2017-06-08 Thread Nico Huber
On 07.06.2017 17:34, Dhanasekar Jaganathan wrote:
> Hi Nico,
> 
> I have taken the Flash Region's dump of my vendor BIOS using Ifdtool (which
> is copied below),
> 
> *FLREG0:0x000f*
> *  Flash Region 0 (Flash Descriptor):  -  *
> *FLREG1:0x07ff0200*
> *  Flash Region 1 (BIOS): 0020 - 007f *
> *FLREG2:0x0fff*
> *  Flash Region 2 (Intel ME): 00fff000 - 0fff (unused)*
> *FLREG3:0x0fff*
> *  Flash Region 3 (GbE): 00fff000 - 0fff (unused)*
> *FLREG4:0x0fff*
> *  Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)*
> 
> From this dump, BIOS region is from 0x20 to 0x07F.
> 
> So *CONFIG_ROM_SIZE is 8MB *and *CONFIG_CBFS_SIZE is 6MB ( 0x7F -
> 0x20 = 0x5F)*
> 
> Am I correct?

Yes, that's correct. The 0x7f is actually inclusive, so it's exactly
6MiB.

Nico

> 
> Please correct me, if I am wrong.
> 
> Thanks,
> Dhanasekar
> 
> 
> On Wed, Jun 7, 2017 at 8:26 PM, Nico Huber  wrote:
> 
>> On 07.06.2017 16:49, Dhanasekar Jaganathan wrote:
>>> Hi Nico,
>>>
>>> Thanks for the info..
>>>
>>> Actually, I have given "*make al*l" to rebuild the coreboot source.
>>>
>>> Is it correct way to rebuilt to the source?
>>
>> That should work fine.
>>
>>>
>>> Or I have to run *make crossgcc-i386 CPUS=$(nproc)* and *make*
>>
>> crossgcc is only needed once.
>>
>> Nico
>>
>>>
>>> Thanks,
>>> Dhanaeskar
>>>
>>> On Wed, Jun 7, 2017 at 7:17 PM, Nico Huber 
>> wrote:
>>>
 On 07.06.2017 15:38, Dhanasekar Jaganathan wrote:
> Hi Nico,
>
> Following is my complete Payload setting,
>
> 1.Add a payload -> (GRUB2)
> 2.GRUB2 version -> (HEAD)
> 3.Include GRUB2 runtime config file into ROM image = Y
> 4.Gave the path of grub.cfg (which I copied from Fedora OS when booted
>> is
> booted with other BIOS vendor).
>
> Based on this, please provide your comments.

 I can only repeat myself: With this setup, you have to rebuild your
 coreboot every time you make changes to your grub.cfg. (You probably
 know that already and did so, but didn't tell it?)

 Nico

>>>
>>
> 



0x138B3CE3.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot