Re: [coreboot] [baytrail_FSP] question about lpss device with ACPI mode in win8

[Zoran Stojsavljevic]

Hello Cheng,

Again, I'll repeat my questions:
[1] Are you talking about BIOS, where you are enabling in LPSS ACPI
(disabling automatically PCI) mode?
[2] I need better explanation of your use case... Are you using BYT MR4,
then MR5, or instead MR4 BIOS, or...?
[3] For WIN8.1 you need to have the following:
  For BIOS to work (and get rid off these yellow triangles with
question marks):
  [A] ACPI mode in BIOS: South Cluster Configuration -> LPSS & SCC
Configuration -> LPSS LPSS & SCC
   Devices Mode -> Select "ACPI Mode";
  [B] The GPIO controller driver is/should be prerequisite for HS-UART
driver. There is a document named:
Intel_Processor_Win8_IO_Drivers_Gold_MR1. You should ask for it
from INTEL support. If installed
correctly, you should see HS-UART Controller device under
System Devices in Device Manager. Also
new unknown devices should appear: ACPI\BCM2E1A and
ACPI\BCM4752. These devices are for
HS-UART Sub Device Driver;
  [C] You should compile the UART Sub Device Driver (by 1.2.1 of Intel
Atom E3800 Win8.1 HS-UART Sub
Device Driver Sample Code Guide_1.0), and install after
building them. After that you should see Ports in
Device Manager.

Zoran

On Fri, May 13, 2016 at 5:43 AM, cheng yichen  wrote:

>
> HI all
>
> I try to enable Lpss device(i2c hs-uart) with ACPI mdoe.
> i2c and hs-uart will show yellow mark in device manager with win8.1.
> but I can't find the same issue in intel coreboot(versrion MR5).
> Do you have any idea for the issue? Thank you
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Upstream coreboot/SeaBIOS on google/ninja -- no emmc, video

[Zoran Stojsavljevic]

Hello Matt,

I'll try to help you... Please, do understand that I did not get well what
really you are trying to do. Let us do one step at the time.

This step: 2) video output works properly for SeaBIOS and grub/syslinux,
but output is disabled once the OS / kernel driver loads.
___

What I am getting from this email is the following (correct me if I am
wrong): BYT-FSP -> Coreboot -> (payload) SeaBIOS -> grub (2.0???) -> Linux
kernel 3/4.x.y (?).

Now. If you use as payload SeaBIOS, my best understanding is that you'll
use CSM (Compatibility Support Mode). So, in other words, you'll use (if
you will?) in Coreboot vBIOS (not GOP driver). Now, furthermore, you MUST
use vBIOS, since you are using SeaBIOS. And Linux will use vBIOS (not GOP
driver), since you'll pass INT 0x15 mechanisms for Linux GFX (using
mandatory vBIOS passed from Coreboot), enforced from SeaBIOS - CSM?!

The question here is the following: why, for the change, you do not use as
payload TianoCore? This one is UEFI compatible, and very well suits UEFI
compliant Linux? In other words, you will use Linux as UEFI
compliant/compatible OS. Compliant to Tiano Core, which brings to you UEFI
features (initialized by default with Linux). Simply and plain... And see
what will happen?

Final line: I suspect, you did not built-in in Coreboot vBIOS package and
vBIOS init (just serial output), which is, using SeaBIOS payload (CSM
mechanism), I guess, mandatory (for Linux to overtake/inherit legacy, to
work with GFX).

Thank you,
Zoran

On Sun, May 15, 2016 at 12:19 AM, Matt DeVillier 
wrote:

> Greetings all!  Currently I'm working on getting upstream coreboot +
> SeaBIOS working on a Baytrail-based ChromeOS device (NINJA / AOpen
> Chromebox commerical).  After resolving some config issues which prevented
> the board from booting, I'm left with two issues on which I'm stuck:
>
> 1) the internal emmc / sdhci controller fails to initialize, and is
> unavailable for boot or OS installation
> 2) video output works properly for SeaBIOS and grub/syslinux, but output
> is disabled once the OS / kernel driver loads
>
> For the emmc, cbmem shows that the sdhci controller is timing out after
> setting the initial frequency, somewhere after line 410 of
> seabios/src/hw/sdcard.c.  Since the same exact SeaBIOS payload works
> properly with the stock ChromeOS firmware (in both the RW_LEGACY and
> BOOT_STUB slots), I suspect that the issue is with coreboot, but the SoC
> init is pretty much identical between upstream and NINJA's CrOS branch
> (save for a few base addresses and offset calculations), so not sure where
> to start looking.  I've also tried putting the sdhci controller back into
> PCI mode (vs ACPI) which had no effect.
>
> For the video output, the same vgabios file is being used as stock CrOS,
> and same SeaBIOS payload.  The i915 kernel driver reports that no displays
> are connected, and there are some errors in the drm module just prior.  I
> tested with a few different flavors of linux as well as Windows 10, to be
> certain it wasn't driver-related.
>
> Attached are the cbmem and kernel logs from both working (stock CroS
> firmware + upstream SeaBIOS/BOOT_STUB) and non-working (upstream
> coreboot+SeaBIOS) cases.
>
> As the board hasn't been officially upstreamed yet (something I will do
> once these issues are resolved), source can be found in my github repo here
> (it's just 3 commits on top of the current master branch):
> https://github.com/MattDevo/coreboot/tree/ninja_upstream
>
> Hopefully someone can point me in the right direction here :)
>
> cheers,
> Matt
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [baytrail_FSP] question about lpss device with ACPI mode in win8

[cheng yichen]

Hi  Zoran

Base on the version Baytrail_coreboot_MR5_Dec-21-2015(coreboot) that is
released by Intel.
In the coreboot(Intel released and defautle is acpi mode) I can install
driver and device is workable in win8.
I can see hs-uart controller in device manage and no yellow mark.

In last coreboot source code. after I modify "pcdlpsssioenablepcimode" to
"LPSS_PCI_MODE_DISABLE". Then the lpss device will be confgured to ACPI
mode.
but the hs-uart controller and I2C controller will shown yellow mark in
win8 device manager.
Because the main controller is not workable in win8. I don't check the
sub-device device.





2016-05-16 17:16 GMT+08:00 Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com>:

> Hello Cheng,
>
> Again, I'll repeat my questions:
> [1] Are you talking about BIOS, where you are enabling in LPSS ACPI
> (disabling automatically PCI) mode?
> [2] I need better explanation of your use case... Are you using BYT MR4,
> then MR5, or instead MR4 BIOS, or...?
> [3] For WIN8.1 you need to have the following:
>   For BIOS to work (and get rid off these yellow triangles with
> question marks):
>   [A] ACPI mode in BIOS: South Cluster Configuration -> LPSS & SCC
> Configuration -> LPSS LPSS & SCC
>Devices Mode -> Select "ACPI Mode";
>   [B] The GPIO controller driver is/should be prerequisite for HS-UART
> driver. There is a document named:
> Intel_Processor_Win8_IO_Drivers_Gold_MR1. You should ask for
> it from INTEL support. If installed
> correctly, you should see HS-UART Controller device under
> System Devices in Device Manager. Also
> new unknown devices should appear: ACPI\BCM2E1A and
> ACPI\BCM4752. These devices are for
> HS-UART Sub Device Driver;
>   [C] You should compile the UART Sub Device Driver (by 1.2.1 of Intel
> Atom E3800 Win8.1 HS-UART Sub
> Device Driver Sample Code Guide_1.0), and install after
> building them. After that you should see Ports in
> Device Manager.
>
> Zoran
>
> On Fri, May 13, 2016 at 5:43 AM, cheng yichen 
> wrote:
>
>>
>> HI all
>>
>> I try to enable Lpss device(i2c hs-uart) with ACPI mdoe.
>> i2c and hs-uart will show yellow mark in device manager with win8.1.
>> but I can't find the same issue in intel coreboot(versrion MR5).
>> Do you have any idea for the issue? Thank you
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Mayuri Tendulkar]

Hi

Is there any mechanism to build UEFI payload directly in coreboot similar like 
seabios?

Regards
Mayuri
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Zoran Stojsavljevic]

Hello Mayuri,

You should check payload called: Tiano Core (true UEFI payload).

Zoran


On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar <
mayuri.tendul...@aricent.com> wrote:

> Hi
>
>
>
> Is there any mechanism to build UEFI payload directly in coreboot similar
> like seabios?
>
>
>
> Regards
>
> Mayuri
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Mayuri Tendulkar]

Hi Zoran

I have checked that site and downloaded EDK2 code. I am trying to build it on 
Linux but facing some issues.
But if I generate payload file separately, I need to integrate it in coreboot 
separately.

So I am checking if there is way to build the payload in coreboot itself.

Regards
Mayuri

From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
Sent: 16 May 2016 17:57
To: Mayuri Tendulkar 
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or 
Bayley bay

Hello Mayuri,

You should check payload called: Tiano Core (true UEFI payload).

Zoran


On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar 
mailto:mayuri.tendul...@aricent.com>> wrote:
Hi

Is there any mechanism to build UEFI payload directly in coreboot similar like 
seabios?

Regards
Mayuri
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."

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

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Upstream coreboot/SeaBIOS on google/ninja -- no emmc, video

[Matt DeVillier]

Hi Zoran,

appreciate the offer, and I'll try to clarify things:

On 5/16/2016 5:07 AM, Zoran Stojsavljevic wrote:

Hello Matt,

I'll try to help you... Please, do understand that I did not get well 
what really you are trying to do. Let us do one step at the time.
I'm trying to get the board google/ninja (a Baytrail-based Chromebox) 
working with upstream coreboot.  Original google source here:

https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-ninja-5216.383.B
I've already upstreamed several other google boards so I'm familiar with 
the process :)


This step: 2) video output works properly for SeaBIOS and 
grub/syslinux, but output is disabled once the OS / kernel driver loads.

___

What I am getting from this email is the following (correct me if I am 
wrong): BYT-FSP -> Coreboot -> (payload) SeaBIOS -> grub (2.0???) -> 
Linux kernel 3/4.x.y (?).
I'm not using FSP, using soc/intel/baytrail (not fsp_baytrail) since the 
board was not originally set up to do so, and would require a bit of 
reworking (without any obvious benefit).  So coreboot->SeaBIOS (running 
vbios)->grub/syslinux->linux kernel 3/4.x


Now. If you use as payload SeaBIOS, my best understanding is that 
you'll use CSM (Compatibility Support Mode). So, in other words, 
you'll use (if you will?) in Coreboot vBIOS (not GOP driver). Now, 
furthermore, you MUST use vBIOS, since you are using SeaBIOS. And 
Linux will use vBIOS (not GOP driver), since you'll pass INT 
0x15 mechanisms for Linux GFX (using mandatory vBIOS passed from 
Coreboot), enforced from SeaBIOS - CSM?!
CSM mode is only needed when Tianocore is the primary payload, since 
SeaBIOS is primary it is simply set up as a coreboot payload.  I plan to 
use Tiancore + SeaBIOS/CSM eventually, but wanted SeaBIOS alone working 
first (since that's all my firmware releases to date have been).  
coreboot isn't running the vbios, just SeaBIOS (though I tried it both 
ways, with coreboot running the vbios first; there was no change).


The question here is the following: why, for the change, you do not 
use as payload TianoCore? This one is UEFI compatible, and very well 
suits UEFI compliant Linux? In other words, you will use Linux as UEFI 
compliant/compatible OS. Compliant to Tiano Core, which brings to you 
UEFI features (initialized by default with Linux). Simply and plain... 
And see what will happen?
I actually did try Tianocore as the primary payload and had the exact 
same issues, so I went back to SeaBIOS since I know that works in 
conjunction with the factory firmware.


Final line: I suspect, you did not built-in in Coreboot vBIOS package 
and vBIOS init (just serial output), which is, using SeaBIOS payload 
(CSM mechanism), I guess, mandatory (for Linux to overtake/inherit 
legacy, to work with GFX).


Thank you,
Zoran
I'm not quite sure what you're saying here.  If you mean that I did not 
have coreboot perform the video init, then I did try it both ways.  On 
all the other boxes (ie, no built-in display) I've upstreamed, it's not 
been necessary to have coreboot run the vbios, only SeaBIOS.


thanks,
Matt


On Sun, May 15, 2016 at 12:19 AM, Matt DeVillier 
mailto:matt.devill...@gmail.com>> wrote:


Greetings all!  Currently I'm working on getting upstream coreboot
+ SeaBIOS working on a Baytrail-based ChromeOS device (NINJA /
AOpen Chromebox commerical).  After resolving some config issues
which prevented the board from booting, I'm left with two issues
on which I'm stuck:

1) the internal emmc / sdhci controller fails to initialize, and
is unavailable for boot or OS installation
2) video output works properly for SeaBIOS and grub/syslinux, but
output is disabled once the OS / kernel driver loads

For the emmc, cbmem shows that the sdhci controller is timing out
after setting the initial frequency, somewhere after line 410 of
seabios/src/hw/sdcard.c.  Since the same exact SeaBIOS payload
works properly with the stock ChromeOS firmware (in both the
RW_LEGACY and BOOT_STUB slots), I suspect that the issue is with
coreboot, but the SoC init is pretty much identical between
upstream and NINJA's CrOS branch (save for a few base addresses
and offset calculations), so not sure where to start looking. 
I've also tried putting the sdhci controller back into PCI mode

(vs ACPI) which had no effect.

For the video output, the same vgabios file is being used as stock
CrOS, and same SeaBIOS payload.  The i915 kernel driver reports
that no displays are connected, and there are some errors in the
drm module just prior.  I tested with a few different flavors of
linux as well as Windows 10, to be certain it wasn't driver-related.

Attached are the cbmem and kernel logs from both working (stock
CroS firmware + upstream SeaBIOS/BOOT_STUB) and non-working
(upstream coreboot+SeaBIOS) cases.

As the board hasn't been officially upstreamed yet (something

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Martin Roth]

Hi Mayuri,
  As of right now, the coreboot build doesn't have a way to build
tianocore/CorebootPayloadPkg into coreboot automatically, but I'm
working on integrating it.  I had hoped to have my initial push ready
last week, but didn't get it finished.

That said, it's not difficult to build it outside of coreboot, then
add it as an elf payload.

In case you haven't found these pages with the instructions, here they are:
https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-Native-GCC
https://svn.code.sf.net/p/edk2/code/trunk/edk2/CorebootPayloadPkg/BuildAndIntegrationInstructions.txt

Last time I tested, I had some issues with the debug version of the
rom hitting an assert and dying, but the release build booted
successfully.

Martin

On Mon, May 16, 2016 at 6:29 AM, Mayuri Tendulkar
 wrote:
> Hi Zoran
>
>
>
> I have checked that site and downloaded EDK2 code. I am trying to build it
> on Linux but facing some issues.
>
> But if I generate payload file separately, I need to integrate it in
> coreboot separately.
>
>
>
> So I am checking if there is way to build the payload in coreboot itself.
>
>
>
> Regards
>
> Mayuri
>
>
>
> From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> Sent: 16 May 2016 17:57
> To: Mayuri Tendulkar 
> Cc: coreboot@coreboot.org
> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or
> Bayley bay
>
>
>
> Hello Mayuri,
>
>
>
> You should check payload called: Tiano Core (true UEFI payload).
>
>
>
> Zoran
>
>
>
>
>
> On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar
>  wrote:
>
> Hi
>
>
>
> Is there any mechanism to build UEFI payload directly in coreboot similar
> like seabios?
>
>
>
> Regards
>
> Mayuri
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including damage from
> virus."
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including damage from
> virus."
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

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

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Mayuri Tendulkar]

Hi Martin

Yes, I have looked at below links and working on it , but facing some issues 
both in windows and Linux.
Anyway hopefully will sort on those issues soon.

Keep me posted once u integrate payload in coreboot.

Regards
Mayuri

-Original Message-
From: Martin Roth [mailto:gauml...@gmail.com]
Sent: 16 May 2016 20:43
To: Mayuri Tendulkar 
Cc: Zoran Stojsavljevic ; coreboot@coreboot.org
Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or 
Bayley bay

Hi Mayuri,
  As of right now, the coreboot build doesn't have a way to build 
tianocore/CorebootPayloadPkg into coreboot automatically, but I'm working on 
integrating it.  I had hoped to have my initial push ready last week, but 
didn't get it finished.

That said, it's not difficult to build it outside of coreboot, then add it as 
an elf payload.

In case you haven't found these pages with the instructions, here they are:
https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-Native-GCC
https://svn.code.sf.net/p/edk2/code/trunk/edk2/CorebootPayloadPkg/BuildAndIntegrationInstructions.txt

Last time I tested, I had some issues with the debug version of the rom hitting 
an assert and dying, but the release build booted successfully.

Martin

On Mon, May 16, 2016 at 6:29 AM, Mayuri Tendulkar 
 wrote:
> Hi Zoran
>
>
>
> I have checked that site and downloaded EDK2 code. I am trying to
> build it on Linux but facing some issues.
>
> But if I generate payload file separately, I need to integrate it in
> coreboot separately.
>
>
>
> So I am checking if there is way to build the payload in coreboot itself.
>
>
>
> Regards
>
> Mayuri
>
>
>
> From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> Sent: 16 May 2016 17:57
> To: Mayuri Tendulkar 
> Cc: coreboot@coreboot.org
> Subject: Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard
> or Bayley bay
>
>
>
> Hello Mayuri,
>
>
>
> You should check payload called: Tiano Core (true UEFI payload).
>
>
>
> Zoran
>
>
>
>
>
> On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar
>  wrote:
>
> Hi
>
>
>
> Is there any mechanism to build UEFI payload directly in coreboot
> similar like seabios?
>
>
>
> Regards
>
> Mayuri
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended
> solely for the use of the individual to whom it is addressed. It may
> contain privileged or confidential information and should not be
> circulated or used for any purpose other than for what it is intended.
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying,
> altering, or disclosing the contents of this message. Aricent accepts
> no responsibility for loss or damage arising from the use of the
> information transmitted by this email including damage from virus."
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended
> solely for the use of the individual to whom it is addressed. It may
> contain privileged or confidential information and should not be
> circulated or used for any purpose other than for what it is intended.
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying,
> altering, or disclosing the contents of this message. Aricent accepts
> no responsibility for loss or damage arising from the use of the
> information transmitted by this email including damage from virus."
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard or Bayley bay

[Zoran Stojsavljevic]

OK, Mayuri,

You brought an interesting point. And this point is to be not only
investigated by you, rather also by me and, perhaps, Coreboot community.

Since here, in Bayern/Deutschland is Holiday Day, I went to buy a beer in
Munchen HBf, and while walking there I was thinking about your use case.
Thinking deeper.

I know that you are using some INTEL CPU/SoC (do not remember which one, if
you said one). But, while recapping how BIOS looks like, I did notice that
SEC and PEI phases have nothing to do with UEFI EDK2. EDK 2 comes to play
in DXE phase, where EDK2 actually takes place/overtakes control...

It says to me one major thing I did not notice while ago: that ARM SoCs are
also eligible to run on UEFI compliant OSes, namely WIN 8.1+ (including WIN
10 and WIN 10 Athens/RT WIN 10). Which makes very interesting IOT case
namely for ARM, allowing it also to compete in WIN space.

Interestingly enough, this idea did not come to my mind till few hours
ago... I guess, Vincent (Zimmer) already thought about that. ;-)
___

Martin (Roth) just replied, to solve this immediate mystery. probably for
the beginning only for INTEL SoCs, but, I really hope, ARM will also
integrate in this concept seamlessly! :-)

Zoran
___

On Mon, May 16, 2016 at 2:29 PM, Mayuri Tendulkar <
mayuri.tendul...@aricent.com> wrote:

> Hi Zoran
>
>
>
> I have checked that site and downloaded EDK2 code. I am trying to build it
> on Linux but facing some issues.
>
> But if I generate payload file separately, I need to integrate it in
> coreboot separately.
>
>
>
> So I am checking if there is way to build the payload in coreboot itself.
>
>
>
> Regards
>
> Mayuri
>
>
>
> *From:* Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> *Sent:* 16 May 2016 17:57
> *To:* Mayuri Tendulkar 
> *Cc:* coreboot@coreboot.org
> *Subject:* Re: [coreboot] UEFI Payload in coreboot for Intel Minnowboard
> or Bayley bay
>
>
>
> Hello Mayuri,
>
>
>
> You should check payload called: Tiano Core (true UEFI payload).
>
>
>
> Zoran
>
>
>
>
>
> On Mon, May 16, 2016 at 2:12 PM, Mayuri Tendulkar <
> mayuri.tendul...@aricent.com> wrote:
>
> Hi
>
>
>
> Is there any mechanism to build UEFI payload directly in coreboot similar
> like seabios?
>
>
>
> Regards
>
> Mayuri
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Upstream coreboot/SeaBIOS on google/ninja -- no emmc, video

[Zoran Stojsavljevic]

Hello Matt,

I would like to thank you for the reply. I learned something out of it,
indeed. So far, I need to think more on your answers, since immediately I
do not have any thoughts (I am blank). Old dummy cat... Need some time. :-)

But I can answer on the last one comment... This one:

> I'm not quite sure what you're saying here.  If you mean that I did not
have coreboot perform the video init, then
> I did try it both ways.  On all the other boxes (ie, no built-in display)
I've upstreamed, it's not been necessary to
> have coreboot run the vbios, only SeaBIOS.

Here is what you perfectly explained, and I did not know (at least, I know
now): I suggested to you to use vBIOS with Coreboot, and make vBIOS init
there, but you denied my thoughts, saying that you just need to integrate
vBIOS into SeaBIOS (excuse me for my ignorance, I did not know that).

In other words, SeaBIOS is one, enough to do vBIOS init, so vBIOS INT 0x15
and VBT will be passed accordingly to Linux. Am I right in my thoughts?

Why it does not work, namely:

> For the video output, the same vgabios file is being used as stock CrOS,
and same SeaBIOS payload.  The i915
> kernel driver reports that no displays are connected, and there are some
errors in the drm module just prior.  I
> tested with a few different flavors of linux as well as Windows 10, to be
certain it wasn't driver-related.

Again... I need to think about this. I will come to you back!

Thank you,
Zoran

On Mon, May 16, 2016 at 4:17 PM, Matt DeVillier 
wrote:

> Hi Zoran,
>
> appreciate the offer, and I'll try to clarify things:
>
> On 5/16/2016 5:07 AM, Zoran Stojsavljevic wrote:
>
>> Hello Matt,
>>
>> I'll try to help you... Please, do understand that I did not get well
>> what really you are trying to do. Let us do one step at the time.
>>
> I'm trying to get the board google/ninja (a Baytrail-based Chromebox)
> working with upstream coreboot.  Original google source here:
>
> https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-ninja-5216.383.B
> I've already upstreamed several other google boards so I'm familiar with
> the process :)
>
>>
>> This step: 2) video output works properly for SeaBIOS and grub/syslinux,
>> but output is disabled once the OS / kernel driver loads.
>> ___
>>
>> What I am getting from this email is the following (correct me if I am
>> wrong): BYT-FSP -> Coreboot -> (payload) SeaBIOS -> grub (2.0???) -> Linux
>> kernel 3/4.x.y (?).
>>
> I'm not using FSP, using soc/intel/baytrail (not fsp_baytrail) since the
> board was not originally set up to do so, and would require a bit of
> reworking (without any obvious benefit).  So coreboot->SeaBIOS (running
> vbios)->grub/syslinux->linux kernel 3/4.x
>
>>
>> Now. If you use as payload SeaBIOS, my best understanding is that you'll
>> use CSM (Compatibility Support Mode). So, in other words, you'll use (if
>> you will?) in Coreboot vBIOS (not GOP driver). Now, furthermore, you MUST
>> use vBIOS, since you are using SeaBIOS. And Linux will use vBIOS (not GOP
>> driver), since you'll pass INT 0x15 mechanisms for Linux GFX (using
>> mandatory vBIOS passed from Coreboot), enforced from SeaBIOS - CSM?!
>>
> CSM mode is only needed when Tianocore is the primary payload, since
> SeaBIOS is primary it is simply set up as a coreboot payload.  I plan to
> use Tiancore + SeaBIOS/CSM eventually, but wanted SeaBIOS alone working
> first (since that's all my firmware releases to date have been).  coreboot
> isn't running the vbios, just SeaBIOS (though I tried it both ways, with
> coreboot running the vbios first; there was no change).
>
>>
>> The question here is the following: why, for the change, you do not use
>> as payload TianoCore? This one is UEFI compatible, and very well suits UEFI
>> compliant Linux? In other words, you will use Linux as UEFI
>> compliant/compatible OS. Compliant to Tiano Core, which brings to you UEFI
>> features (initialized by default with Linux). Simply and plain... And see
>> what will happen?
>>
> I actually did try Tianocore as the primary payload and had the exact same
> issues, so I went back to SeaBIOS since I know that works in conjunction
> with the factory firmware.
>
>>
>> Final line: I suspect, you did not built-in in Coreboot vBIOS package and
>> vBIOS init (just serial output), which is, using SeaBIOS payload (CSM
>> mechanism), I guess, mandatory (for Linux to overtake/inherit legacy, to
>> work with GFX).
>>
>> Thank you,
>> Zoran
>>
> I'm not quite sure what you're saying here.  If you mean that I did not
> have coreboot perform the video init, then I did try it both ways.  On all
> the other boxes (ie, no built-in display) I've upstreamed, it's not been
> necessary to have coreboot run the vbios, only SeaBIOS.
>
> thanks,
> Matt
>
>>
>> On Sun, May 15, 2016 at 12:19 AM, Matt DeVillier <
>> matt.devill...@gmail.com > wrote:
>>
>> Greetings all!  Currently I'm working on getting upstream coreboot
>> + 

Re: [coreboot] [GSOC 2016] Coreboot panic room

[Denis 'GNUtoo' Carikli]

On Thu, 10 Mar 2016 22:34:45 +
Antonello Dettori  wrote:

> Hello everyone,
Hi,

> I would like to concentrate most of my efforts towards improving and 
> upstreaming the previous efforts, implementing a way to easily access 
> the recovery mode when needed and further the integration between 
> coreboot, serialICE and flashrom for this use-case.
> 
> Regarding the existing patches I would like to know if they would
> need to stay romc-compatible or should the scope be limited to CAR
> boards?
How was it implemented?

I see several building blocks:
- nvramtool and the fallback/normal mecanism.
- Many hardware also do have watchdogs, but I believe it's disabled by
  coreboot.
- SerialICE: I'm not sure it can work from coreboot, or how to
  integrate it in the same flash. Patches to add some kind of support
  for it in coreboot might exist in gerrit.
- libhwremote: works with SerialICE, and was made to work with pciutils
  and superiotool
- Coreboot also has gdb support, and even something like gdbwait, but
  only in ramstage.
- Coreboot also has some code to write to some flash chips, in order to
  store its logs there.

Denis.


pgpuEkLZ9nWfp.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASRock E350M1: MSR 0x00000175 SYSENTER_ESP has 1 inconsistent values across 2 CPUs

[Paul Menzel]

Dear Rudolf,


Am Sonntag, den 15.05.2016, 19:49 +0200 schrieb Rudolf Marek:

> This MSR is used when SYSENTER instruction is used by OS/application. The ESP
> MSR usually points to to the kernel stack of current thread, so if two
> different threads execute on different CPUs it will be different. False
> positive, and they should fix it.

Thank you very much for clearing that up.

I submitted a bug report [1], and there is a patch up for review
disabling the tests [2].

Could you please confirm that disabling the other two MSR tests for CS
and EIP is also the right thing to do?


Thanks,

Paul


[1] https://bugs.launchpad.net/bugs/1582005
[2] https://lists.ubuntu.com/archives/fwts-devel/2016-May/007917.html

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASRock E350M1: MSR 0x00000175 SYSENTER_ESP has 1 inconsistent values across 2 CPUs

[Rudolf Marek]

Hi all,

> Could you please confirm that disabling the other two MSR tests for CS and
> EIP is also the right thing to do?

Yes I think this is OK. The SYSENTER MSRs are used by the OS and there is
nothing which BIOS needs to setup.

Same case is the SYSCALL MSR, GS/FS base and KERNEL GS base and possibly also
MSR_TSC_AUX.

#define MSR_STAR0xc081 /* legacy mode SYSCALL target */
#define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
#define MSR_CSTAR   0xc083 /* compat mode SYSCALL target */
#define MSR_SYSCALL_MASK0xc084 /* EFLAGS mask for syscall */
#define MSR_FS_BASE 0xc100 /* 64bit FS base */
#define MSR_GS_BASE 0xc101 /* 64bit GS base */
#define MSR_KERNEL_GS_BASE  0xc102 /* SwapGS GS shadow */
#define MSR_TSC_AUX 0xc103 /* Auxiliary TSC */

Thanks
Rudolf


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

Re: [coreboot] openbios in config?

[David Griffith]

On Sun, 15 May 2016, Alexander Couzens wrote:


On Sat, 14 May 2016 20:26:08 -0700
David Griffith  wrote:


Is there any interest in having the Coreboot build process downliad
and build OpenBIOS in the same fashion as SeaBIOS is now?


hi david,

I like it. It would be nice if you can upload a patch to gerrit [1]
doing it.

best,
lynxis

[1] https://review.coreboot.org


I'm working on it. So far, downloading from svn works.  It should be 
complete in a few days.



--
David Griffith
d...@661.org

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

[coreboot] Say hi to avatars on review.coreboot.org

[Stefan Reinauer]

Hello coreboot folks,

I've played around with gerrit's avatar feature this weekend and as
a little gimmick, I have turned on avatars for our gerrit instance at
https://review.coreboot.org/

In a never-ending effort to make it harder for everybody in the
community to be mad at each other, you will now have the priceless
opportunity to stare at each other's friendly faces while doing
code reviews.

NOTE: This feature is not using the gravatar service (and as such is
not forwarding any personal information to another site), but only shows
pictures locally stored on photos.coreboot.org.
So if you're not showing up with a photo, I didn't have
a good, publicly available photo of you. Right now the image store is
completely manual, so if you want to have your own avatar show up in
gerrit.coreboot.org, please feel free to send me a picture, preferrably
in JPG format, square, at least 128x128.

Stefan


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

Re: [coreboot] Say hi to avatars on review.coreboot.org

[ron minnich]

There's no way this can work.



On Mon, May 16, 2016 at 4:32 PM Stefan Reinauer <
stefan.reina...@coreboot.org> wrote:

> Hello coreboot folks,
>
> I've played around with gerrit's avatar feature this weekend and as
> a little gimmick, I have turned on avatars for our gerrit instance at
> https://review.coreboot.org/
>
> In a never-ending effort to make it harder for everybody in the
> community to be mad at each other, you will now have the priceless
> opportunity to stare at each other's friendly faces while doing
> code reviews.
>
> NOTE: This feature is not using the gravatar service (and as such is
> not forwarding any personal information to another site), but only shows
> pictures locally stored on photos.coreboot.org.
> So if you're not showing up with a photo, I didn't have
> a good, publicly available photo of you. Right now the image store is
> completely manual, so if you want to have your own avatar show up in
> gerrit.coreboot.org, please feel free to send me a picture, preferrably
> in JPG format, square, at least 128x128.
>
> Stefan
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Say hi to avatars on review.coreboot.org

[ron minnich]

oh. wait.

is that me?

ron

On Mon, May 16, 2016 at 4:39 PM ron minnich  wrote:

> There's no way this can work.
>
>
>
> On Mon, May 16, 2016 at 4:32 PM Stefan Reinauer <
> stefan.reina...@coreboot.org> wrote:
>
>> Hello coreboot folks,
>>
>> I've played around with gerrit's avatar feature this weekend and as
>> a little gimmick, I have turned on avatars for our gerrit instance at
>> https://review.coreboot.org/
>>
>> In a never-ending effort to make it harder for everybody in the
>> community to be mad at each other, you will now have the priceless
>> opportunity to stare at each other's friendly faces while doing
>> code reviews.
>>
>> NOTE: This feature is not using the gravatar service (and as such is
>> not forwarding any personal information to another site), but only shows
>> pictures locally stored on photos.coreboot.org.
>> So if you're not showing up with a photo, I didn't have
>> a good, publicly available photo of you. Right now the image store is
>> completely manual, so if you want to have your own avatar show up in
>> gerrit.coreboot.org, please feel free to send me a picture, preferrably
>> in JPG format, square, at least 128x128.
>>
>> Stefan
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] bootfail on my Mohon Peak CRB.

[김유석]

Dear Sir.

Thank's your advise.

I was solved this issue.

The cause was "Image size".

My spi flash is have a 16MByte size. and coreboot.rom's size is a 2MByte.

And I was write from 0x00. But x86 is must write from bottom. I guess.


*For example*

case 1.
  coreboot image : 2MByte
  flash storage : 16MByte

  You must write start address is 0x00E0(offset 14MByte)

case 2.
  coreboot image : 8MByte
  flash storage : 16MByte

  You must write start address is 0x0080(offset 8MByte)

case 3.
  coreboot image : 16MByte
  flash storage : 16MByte

  You must write start address is 0x(offset 0MByte)


This time, coreboot work is very fine.

Thank you.

2016-02-04 오후 11:02에 WANG FEI 이(가) 쓴 글:
*RANGELEY_POSTGOLD4_FSP_004_20150924.fd is the FSP binary, you can 
rename it to FvFsp.bin and placed it to the path defined in coreboot, 
ie, *`../intel/fsp/rangeley/Fv*, to generate coreboot image.*


On Thu, Feb 4, 2016 at 5:19 AM, 김유석 > wrote:


Dear Martin.

Thank's your advise.

I'm use the serial consol port. but can't see any message.

Thank you.

2016-02-02 오후 9:18에 Martin Roth 이(가) 쓴 글:

You might try a different video card. There's an issue in the
video bios of the aspeed card that came with the mohon peak.

martin
On Tue, Feb 2, 2016 at 00:41 김유석 mailto:poplin...@gmail.com>> wrote:

Dear sir.

My ENV is see below.

*EVB : Intel rangeley Mohon Peak CRB*


This time, I was download the coreboot from git.

poplinux@raw work $ > git clone
http://review.coreboot.org/coreboot.git ./
poplinux@raw work $ > cd coreboot
poplinux@raw coreboot $ > git submodule update --init --checkout

Next, *run make menuconfig* and set-up to mohon peak CRB and
save & exit

*Mainboa**rd*
   Mainboard vendor (*Intel*) --->
   Mainboard model (*Mohon Peak CRB*) --->
   [ ] Configure defaults for the Intel FSP package
   ROM chip size (2048 KB (2 MB)) --->
   (0x0020) Size of CBFS filesystem in ROM
   ()  fmap description file in fmd format

Next, I'm try to build core boot.

  poplinux@raw coreboot $ > make
GENgenerated/bootblock.ld
CP bootblock/arch/x86/bootblock.ld
LINK cbfs/fallback/bootblock.debug
OBJCOPYcbfs/fallback/bootblock.elf
OBJCOPYbootblock.raw.bin
Checking out SeaBIOS revision
01a84bea2d28a19d2405c1ecac4bdef17683cc0c
Switched to branch 'master'

  Performing operation on 'COREBOOT' region...
  Name Offset Type Size
  cbfs master header 0x0cbfs header  32
  fallback/romstage 0x80   stage22684
  cpu_microcode_blob.bin 0x5980 microcode0
  config 0x5a00 raw  127
  revision 0x5ac0 raw  570
  cmos_layout.bin 0x5d40 cmos_layout  1316
  fallback/dsdt.aml 0x62c0 raw  7952
  payload_config 0x8240 raw  1574
  payload_revision 0x88c0 raw  237
  (empty) 0x8a00 null 29848
  mrc.cache 0xfec0 mrc_cache65536
  fallback/ramstage 0x1ff00stage46922
  fallback/payload 0x2b6c0payload  61122
  (empty) 0x3a5c0null 1856216
  bootblock 0x1ff8c0   bootblock1528

Finally, I'm got a coreboot image.


  poplinux@raw build $ > ls build/coreboot.rom
  build/coreboot.rom
  poplinux@raw build $ > ./build/cbfstool build/coreboot.rom
print
Performing operation on 'COREBOOT' region...
Name Offset Type Size
cbfs master header 0x0cbfs header  32
fallback/romstage 0x80   stage22684
cpu_microcode_blob.bin 0x5980 microcode0
config 0x5a00 raw  127
revision 0x5ac0 raw  570
cmos_layout.bin 0x5d40 cmos_layout  1316
fallback/dsdt.aml 0x62c0 raw  7952
payload_config 0x8240 raw  1574
payload_revision 0x88c0 raw  237
(empty) 0x8a00 null 29848
mrc.cache 0xfec0 mrc_cache65536
fallback/ramstage 0x1ff00stage46922
fallback/payload 0x2b6c0payload  61122
(empty) 0x3a5c0null 1856216
bootblock 0x1ff8c0   bootblock1528


And I'm write image to my EVB using *ALL-100 Gang-writ**er*.
spi flash's write *start address is set 0x*. write it
success.

And I'm attach the flash memory to my EVB.

And power-up the my EVB. But can't see any message on my
monitor and serial port both.


*Why did not display any message? **
**A**nd could you support co

Re: [coreboot] [baytrail_FSP] question about lpss device with ACPI mode in win8

[Zoran Stojsavljevic]

Hello Cheng,

I am afraid, I have no ideas anymore what could be wrong. But I have for
you one suggestion (path to resolution, maybe).

No idea what you are using. In the sense BYT-FSP (MR5) -> Coreboot ->
(payload???). You either use SeaBIOS (CSM ON), or Tiano Core/EK2 (CSM OFF).

I would suggest the following: since it depends what payload you use
because you would like to reuse your old HDD with WIN 8.1, to make test
very short (no need to install other HDD with WIN 8.1).

Please, take real UEFI BIOS (for BYT-M N2807 it is Client Group 64bit
A093.R42 or later), and install it on some INTEL CRB (BayleyBay or
BakerSport) where you already have N2807. Then, in relations what payload
you are using, you need to set CSM ON or CSM OFF, to make work/reuse your
original HDD with WIN 8.1.

Please, after you are able to bring your INTEL BYT-M CRB to WIN 8.1,
reboot, and again enter BIOS CMOS. There, under system setup/advanced
settings, you should be able to find southbridge setup, where one of the
options is LPSS.

Please, experiment, with settings within LPSS mode (PCI and ACPI), and,
please, report here do you have the same as with BYT-FSP MR5 settings as
you use "pcdlpsssioenablepcimode" to "LPSS_PCI_MODE_DISABLE" and
"ENABLE/DEFAULT" (do you see the same behavior in WIN 8.1 device manager)?

Thank you,
Zoran

On Mon, May 16, 2016 at 2:06 PM, cheng yichen  wrote:

> Hi  Zoran
>
> Base on the version Baytrail_coreboot_MR5_Dec-21-2015(coreboot) that is
> released by Intel.
> In the coreboot(Intel released and defautle is acpi mode) I can install
> driver and device is workable in win8.
> I can see hs-uart controller in device manage and no yellow mark.
>
> In last coreboot source code. after I modify "pcdlpsssioenablepcimode" to
> "LPSS_PCI_MODE_DISABLE". Then the lpss device will be confgured to ACPI
> mode.
> but the hs-uart controller and I2C controller will shown yellow mark in
> win8 device manager.
> Because the main controller is not workable in win8. I don't check the
> sub-device device.
>
>
>
>
>
> 2016-05-16 17:16 GMT+08:00 Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com>:
>
>> Hello Cheng,
>>
>> Again, I'll repeat my questions:
>> [1] Are you talking about BIOS, where you are enabling in LPSS ACPI
>> (disabling automatically PCI) mode?
>> [2] I need better explanation of your use case... Are you using BYT MR4,
>> then MR5, or instead MR4 BIOS, or...?
>> [3] For WIN8.1 you need to have the following:
>>   For BIOS to work (and get rid off these yellow triangles with
>> question marks):
>>   [A] ACPI mode in BIOS: South Cluster Configuration -> LPSS & SCC
>> Configuration -> LPSS LPSS & SCC
>>Devices Mode -> Select "ACPI Mode";
>>   [B] The GPIO controller driver is/should be prerequisite for
>> HS-UART driver. There is a document named:
>> Intel_Processor_Win8_IO_Drivers_Gold_MR1. You should ask for
>> it from INTEL support. If installed
>> correctly, you should see HS-UART Controller device under
>> System Devices in Device Manager. Also
>> new unknown devices should appear: ACPI\BCM2E1A and
>> ACPI\BCM4752. These devices are for
>> HS-UART Sub Device Driver;
>>   [C] You should compile the UART Sub Device Driver (by 1.2.1 of
>> Intel Atom E3800 Win8.1 HS-UART Sub
>> Device Driver Sample Code Guide_1.0), and install after
>> building them. After that you should see Ports in
>> Device Manager.
>>
>> Zoran
>>
>> On Fri, May 13, 2016 at 5:43 AM, cheng yichen 
>> wrote:
>>
>>>
>>> HI all
>>>
>>> I try to enable Lpss device(i2c hs-uart) with ACPI mdoe.
>>> i2c and hs-uart will show yellow mark in device manager with win8.1.
>>> but I can't find the same issue in intel coreboot(versrion MR5).
>>> Do you have any idea for the issue? Thank you
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot with fsp hangs at post code 19 on Bayley Bay

[Zoran Stojsavljevic]

Hello Kathappan,

Did you try to (using BCT) to enable PCIe x1, at least PCIe0 and PCIe1 (the
same size x1)? Does it work now?

Thank you,
Zoran


On Fri, May 13, 2016 at 9:51 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Kathappan,
>
> I need to look deeper into this area since I am not expert on FSP, but I
> have some ideas what could be wrong.
>
> Several questions for you:
> [1] Which BYT SoC you are using (example BYT-M N2807)?
> [2] How many DDR3 channels (1 or 2) are you using in your design, and what
> is the size of memory (most likely not a problem)?
> [3] PCH. Do you have PCIe channels initialized/set in default soft straps
> (you must have some, at least PCIe root port 0, and PCIe root port 1, as I
> recalled)? << IMPORTANT?
>
> Again, I need to think more about this, and I'll try to find some answers,
> later... Please, try to see/discover [3] using BCT tool!
>
> Zoran
> ___
>
> On Fri, May 13, 2016 at 3:01 PM, Kathappan E <
> kathappa...@lnttechservices.com> wrote:
>
>> Hi all,
>>
>>
>>
>> When I try coreboot on Bayley Bay platform along with fsp
>> (BAYTRAIL_FSP_GOLD_004_22-MAY-2015), it is getting hang at post code 19.
>>
>>
>>
>> Also I tried with debug version fsp
>> (BAYTRAIL_FSP_GOLD_004_22-MAY-2015_DEBUG) , it still at that point and
>> below is the debug log.
>>
>>
>>
>> *Firmware Image*: Have used the 8 MB vendor bios and flashed the last 2
>> MB region(60 to 7f) with coreboot image.
>>
>>
>>
>> *From the debug log*:  coreboot gives the control to FSP binary routine(
>> *FspInitApi*) and it is getting hang when trying to do PCH initialize(
>> *PchMiscInit*) inside FSP part code.
>>
>>
>>
>> *POST 19 code info*: *EFI_COMPUTING_UNIT_CHIPSET* |
>> *EFI_CU_CLOCK_PEI_INIT_ENTRY* ==> Clock Init PEIM Entry
>>
>>
>>
>> I have not seen the clock related setting available when customizing fsp
>> binary using BCT.
>>
>>
>>
>> I tried to disable south cluster component such as EMMC,HSUART,SATA and
>> SIO using BCT , it didn't help me.
>>
>>
>>
>> Can anyone please help me provide some inputs such as related below to
>> proceed further debugging on it ?
>>
>> 1. Any other setting we can try out using BCT
>>
>> 2. About devices configuration to be initialized byPchMiscInit function.
>>
>> 3. Anything need to be cared/double checked from coreboot side in order
>> to giving control to FspInitApi function.
>>
>> 4. Does pch straps settings may cause this since I am using upper 6 MB
>> region flash data which is from vendor bios.
>>
>> 4. Please suggest anything on it.
>>
>>
>>
>> Thanks in advance,
>>
>> Kathappan
>>
>>
>>
>>    Debug log  Start
>> >>>
>>
>>
>>
>> coreboot-coreboot-unknown Thu May 12 08:04:42 UTC 2016 romstage
>> starting...
>>
>> RTC Init
>>
>> POST: 0x44
>>
>> POST: 0x47
>>
>> POST: 0x48
>>
>> Starting the Intel FSP (early_init)
>>
>> PM1_STS = 0x0 PM1_CNT = 0x0 GEN_PMCON1 = 0x44000
>>
>> prev_sleep_state = S5
>>
>> Configure Default UPD Data
>>
>> PcdMrcInitSPDAddr1: 0xa0 (default)
>>
>> PcdMrcInitSPDAddr2: 0xa2 (default)
>>
>> PcdSataMode:0x01 (set)
>>
>> PcdLpssSioEnablePciMode:0x01 (default)
>>
>> PcdMrcInitMmioSize: 0x800 (default)
>>
>> PcdIgdDvmt50PreAlloc:   0x02 (default)
>>
>> PcdApertureSize:0x02 (default)
>>
>> PcdGttSize: 0x02 (default)
>>
>> SerialDebugPortAddress: 0x3f8 (default)
>>
>> SerialDebugPortType:0x01 (default)
>>
>> PcdMrcDebugMsg: 0x01 (default)
>>
>> PcdSccEnablePciMode:0x01 (default)
>>
>> IgdRenderStandby:   0x00 (default)
>>
>> TxeUmaEnable:   0x00 (default)
>>
>> PcdOsSelection: 0x04 (default)
>>
>> PcdEMMC45DDR50Enabled:  0x01 (default)
>>
>> PcdEMMC45HS200Enabled:  0x00 (default)
>>
>> PcdEMMC45RetuneTimerValue:  0x08 (default)
>>
>> PcdEnableIgd:   0x01 (default)
>>
>> AutoSelfRefreshEnable:  0x00 (default)
>>
>> APTaskTimeoutCnt:   0x00 (default)
>>
>> GTT Size:   2 MB
>>
>> Tseg Size:  8 MB
>>
>> Aperture Size:  256 MB
>>
>> IGD Memory Size:64 MB
>>
>> MMIO Size:  2048 MB
>>
>> MIPI/ISP:   Disabled
>>
>> Sdio:   Enabled
>>
>> Sdcard: Enabled
>>
>> SATA:   Enabled
>>
>> SIO Dma 0:  Enabled
>>
>> SIO I2C0:   Enabled
>>
>> SIO I2C1:   Enabled
>>
>> SIO I2C2:   Enabled
>>
>> SIO I2C3:   Enabled
>>
>> SIO I2C4:   Enabled
>>
>> SIO I2C5:   Enabled
>>
>> SIO I2C6:   Enabled
>>
>> Azalia: Enabled
>>
>> SIO Dma1:   Enabled
>>
>> Pwm0:   Enabled
>>
>> Pwm1:   Enabled
>>
>> Hsuart0:Enabled
>>
>> Hsuart1:Enabled
>>
>> Spi:Enabled
>>
>> Lpe:   

[coreboot] New custom board (Intel Baytrail FSP based on Valley Island reference design)

[Naveed Ghori]

Hi,
I am bringing up a new board using coreboot as the bios.

Hardware:

-   Based on Intel Valley Island design (which has TPE)

-  No TPM

Coreboot:

-  Source coreboot 4.4 release

-  Using code based on Bayley bay (Intel FSP)

-  FSP: Gold3

-  Using a bios based on Valley Island for the non-coreboot sections

The board boots, goes through romstage and then freezes early in the ramstage 
(before enabling any devices): see output below
To me it seems there may be a hardware issue (new board, I am suspecting 
memory) but I thought I would ask as someone may have seen something similar.


1)  Could the non coreboot part of the bios chip cause this.

2)  Is there a way to check memory at the rom stage.

3)  Is there any information on the memory map of the bios chip.

4)  Is there a way to check other devices at the romstage or early ram 
stage.

I have tried skipping the "Enumeratin busses" section but it just crashes at 
the next stage (I guess I cannot really expect ti to get very far without its 
busses).

Note: I am new to coreboot and bios development in general.
Any help, suggestion appreciated.

Output Log:
--
coreboot-099d78c-dirty Thu May 12 05:41:22 UTC 2016 romstage starting...
RTC Init
POST: 0x44
POST: 0x47
POST: 0x48
Starting the Intel FSP (early_init)
PM1_STS = 0x100 PM1_CNT = 0x0 GEN_PMCON1 = 0x45008
prev_sleep_state = S5
Configure Default UPD Data
PcdMrcInitSPDAddr1: 0xa0 (default)
PcdMrcInitSPDAddr2: 0xa2 (default)
PcdSataMode:0x01 (set)
PcdLpssSioEnablePciMode:0x01 (default)
PcdMrcInitMmioSize: 0x800 (default)
PcdIgdDvmt50PreAlloc:   0x02 (default)
PcdApertureSize:0x02 (default)
PcdGttSize: 0x02 (default)
SerialDebugPortAddress: 0x3f8 (default)
SerialDebugPortType:0x01 (default)
PcdMrcDebugMsg: 0x00 (default)
PcdSccEnablePciMode:0x01 (default)
IgdRenderStandby:   0x00 (default)
TxeUmaEnable:   0x00 (default)
PcdOsSelection: 0x04 (default)
PcdEMMC45DDR50Enabled:  0x01 (default)
PcdEMMC45HS200Enabled:  0x00 (default)
PcdEMMC45RetuneTimerValue:  0x08 (default)
PcdEnableIgd:   0x00 (default)
AutoSelfRefreshEnable:  0x00 (default)
APTaskTimeoutCnt:   0x00 (default)
GTT Size:   2 MB
Tseg Size:  8 MB
Aperture Size:  256 MB
IGD Memory Size:64 MB
MMIO Size:  2048 MB
MIPI/ISP:   Disabled
Sdio:   Enabled
Sdcard: Enabled
SATA:   Enabled
SIO Dma 0:  Enabled
SIO I2C0:   Enabled
SIO I2C1:   Enabled
SIO I2C2:   Enabled
SIO I2C3:   Enabled
SIO I2C4:   Enabled
SIO I2C5:   Enabled
SIO I2C6:   Enabled
Azalia: Enabled
SIO Dma1:   Enabled
Pwm0:   Enabled
Pwm1:   Enabled
Hsuart0:Enabled
Hsuart1:Enabled
Spi:Enabled
Lpe:Disabled
eMMC Mode:  eMMC 4.5
SATA Mode:  AHCI
Xhci:   Enabled
CBFS: 'Master Header Locator' located CBFS at [100:1fffc0)
CBFS: Locating 'mrc.cache'
CBFS: Found @ offset fec0 size 1
find_current_mrc_cache_local: No valid fast boot cache found.
FSP MRC cache not present.
POST: 0x92
POST: 0x4a
romstage_main_continue status: 0  hob_list_ptr: 7ae2
FSP Status: 0x0
PM1_STS = 0x101 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808
romstage_main_continue: prev_sleep_state = S0
Baytrail Chip Variant: Bay Trail-I (ISG/embedded)
MRC v0.100
2 channels of DDR3 @ 1333MHz
POST: 0x4b
POST: 0x4c
POST: 0x4d
CBMEM:
IMD: root @ 7adff000 254 entries.
IMD: root @ 7adfec00 62 entries.
POST: 0x4e
POST: 0x4f
CBFS: 'Master Header Locator' located CBFS at [100:1fffc0)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 46380 size d5be


coreboot-099d78c-dirty Thu May 12 05:41:22 UTC 2016 ramstage starting...
POST: 0x39
Moving GDT to 7adfe9c0...ok
POST: 0x80
POST: 0x70
BS: BS_PRE_DEVICE times (us): entry 0 run 1168 exit 0
POST: 0x71
CBFS: 'Master Header Locator' located CBFS at [100:1fffc0)
CBFS: Locating 'cpu_microcode_blob.bin'
CBFS: Found @ offset 1ff00 size 26400
microcode: sig=0x30679 pf=0x1 revision=0x901
CPUID: 00030679
Cores: 4
Revision ID: 11
Stepping: D0
msr(17) = 90041743
msr(ce) = 06001700
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 30606 exit 0
POST: 0x72
Enumerating buses...
Show all devs... Before device enumeration.
Root Dev


Naveed Ghori | Lead Firmware & Driver Engineer

DTI Group Ltd | Transit Security & Surveillance

31 Affleck Road, Perth Airport, Western Australia 6105, AU

P +61 8 9373 2905,151 | F +61 8 9479 1190 | naveed.gh...@dti.com.au



Visit our website www.d