[coreboot] CBFS mounting failure

[Gailu Singh]

Hi Experts,

We are using grub2 payload.

When we configure coreboot with CONFIG_CBFS_SIZE and CONFIG_ROM_SIZE to be
same, grub fails to mount cbfsdisk. We added prints and found that it fails
at following check in grub-core/fs/cbfs.c

  ptr = grub_cpu_to_le32 (ptr);
  header_off = (grub_disk_get_size (disk) << GRUB_DISK_SECTOR_BITS)
+ (grub_int32_t) ptr;

  if (grub_disk_read (disk, 0, header_off,
  sizeof (head), ))
goto fail;

However if we keep margin of min 64KB between CONFIG_ROM_SIZE and
CONFIG_CBFS_SIZE it works perfectly.

Is there any possibility that coreboot mess up cbfs layout when both rom
size and cbfs size are same

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

[coreboot] CONFIG_CBFS_SIZE vs CONFIG_ROM_SIZE

[Gailu Singh]

Hi Experts,

If we use CBFS_SIZE to be same as ROM_SIZE on our apollolake board grub
fails to load grub.cfg located in CBFS. Based on experiments we found that
grub.cfg is loaded correctly if we keep minimum difference of 64KB between
CBFS_SIZE and ROM_SIZE if we reduce it to less that 64KB problem happens.

Can someone please explain the behavior and if it is expected behavior or a
bug?
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] USB Support on Apollo Lake

[Gailu Singh]

Hi Zoran,

Thanks for the detailed inputs. You are right we were using EHCI in BYT and
we used it with grub2 without any issue. If I understood it correctly the
usb 2.0 card I was planning to use over pcie is not going to work as we
can't mix with usb3.0 root hub, so not worth even trying that option.

Would you mind sharing the product details of xHCI 3.0 passive Belkin USB
2.0 bridge so that I can buy and try that. Tried to find on Amazon and
Google but couldn't locate a product matching to this criteria (probably my
poor keywords)

Regarding UARTs, yes there are driver in Linux but not in Grub, so can not
use grub console, linux console works fine. USB to UART converter could  be
an option but USB itself is not working. All my problems end up at USB,
(keyboard, uart, mass storage)

Thanks again for your help and support

On Mon, Mar 20, 2017 at 6:41 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Hello Gaily,
>
> Several time here, on Coreboot threads, I wrote the following (regarding
> BYT and post ATOM families skus):
>
> There are two root hub controllers in BYT: USB 3.0 - xHCI and USB 2.0
> (legacy one) - EHCI. The trick here is that you/nobody could not have them
> both working at the same time. Either you set/select one, or another. Why?
> They are on the different clocking domains. In other words all your USBs
> will hang out either of USB 3.0 root hub, either of USB 2.0 root hub. You
> could NOT mix outside USB ports (to have them hanging out from both root
> hubs mixed).
>
> To enhance/fix this further, past BYT time, INTEL totally removed from
> ATOM silicon (not only) EHCI legacy USB 2.0 root hub, because of that bug.
> So, since BSW (including APL-I, former BXT-I), there is ONLY USB 3.0 xHCI
> root hub. The (maybe) efficient method is to put on xHCI 3.0 passive Belkin
> USB 2.0 bridge as bypass, maybe this can make this transition smooth. Helps
> with my HSW notebook, since mine notebook USB 3.0 root hub ports do not
> work with my printer USB 2.0 eHCI port, connected straight (with Belkin
> does, but on WIN10 OS).
>
> About IO mapped UART I have no idea, but I think there should be some
> (virtual?!) UARTs available. Not sure how this design plays out (certainly,
> you should have SW drivers for these for Linux). Have no clue about
> GRUB/GRUB2 implementation.
>
> You might also try USB to UART physical converter, and see if it is
> recognized by GRUB2. Does work for Linux.
>
> Zoran
>
> On Mon, Mar 20, 2017 at 1:01 PM, Gailu Singh <gail...@gmail.com> wrote:
>
>> Hi Werner,
>>
>> Thanks for your detailed clarification. Looks like Intel removing various
>> legacy interfaces and support for alternatives is yet to be developed in
>> grub. No only they removed USB2.0 altogether, they also removed IO mapped
>> UART and we can't get serial console working on this board either with grub.
>>
>> For USB I am making a last attempt to use PCIE USB2.0 card and ordered
>> following from Aliexpress but I have serious doubts if this will work in
>> Grub2. Will post the results once I get the cards delivered.
>>
>> https://www.aliexpress.com/item/Hot-New-Mini-PCI-E-Card-Slot
>> -Expansion-to-USB-2-0-Interface-Adapter-Riser-Card/325315080
>> 95.html?spm=2114.13010608.0.0.KTeUNS
>>
>>
>> Thank you very much once again.
>>
>> On Mon, Mar 20, 2017 at 5:18 PM, Zeh, Werner <werner@siemens.com>
>> wrote:
>>
>>> Hi Gailu.
>>>
>>> I don't think that one can configure the xHCI to behave like an EHCI so
>>> that GRUB2 can natively support it.
>>> xHCI has different version number in the PCI space which will prevent
>>> the EHCI driver in GRUB2 to use this controller at all.
>>> Not speaking about the complete different register set and operational
>>> model.
>>>
>>> What in turn should work is that "some of the BIOS" (which in
>>> coreboot-context is the payload like SeaBIOS) will handle all the
>>> xHCI stuff and provide a legacy interface to the OS (and here GRUB acts
>>> as an OS) to just read mass storage devices using interrupts.
>>>
>>> Beside that you are lost with GRUB2 and xHCI, sorry!
>>>
>>> Werner
>>>
>>> >Hi Experts,
>>> >
>>> >Does coreboot support USB port initialization in legacy mode on Apollo
>>> Lake as some of the BIOS does so that grub or other payloads can use it as
>>> USB2.0?
>>> >
>>> >There is no USB2.0 port on this board and Grub2 doesn't support xhci so
>>> we seems to be reaching to a dead end.
>>> >
>>> >I am trying to see if the dual role USB ports can be initialized in
>>> coreboot/fsp so that they can act as USB2.0 for payloads.
>>> >
>>> >Thanks
>>>
>>
>>
>> --
>> 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] USB Support on Apollo Lake

[Gailu Singh]

Hi Werner,

Thanks for your detailed clarification. Looks like Intel removing various
legacy interfaces and support for alternatives is yet to be developed in
grub. No only they removed USB2.0 altogether, they also removed IO mapped
UART and we can't get serial console working on this board either with grub.

For USB I am making a last attempt to use PCIE USB2.0 card and ordered
following from Aliexpress but I have serious doubts if this will work in
Grub2. Will post the results once I get the cards delivered.

https://www.aliexpress.com/item/Hot-New-Mini-PCI-E-Card-Slot-Expansion-to-USB-2-0-Interface-Adapter-Riser-Card/32531508095.html?spm=2114.13010608.0.0.KTeUNS


Thank you very much once again.

On Mon, Mar 20, 2017 at 5:18 PM, Zeh, Werner  wrote:

> Hi Gailu.
>
> I don't think that one can configure the xHCI to behave like an EHCI so
> that GRUB2 can natively support it.
> xHCI has different version number in the PCI space which will prevent the
> EHCI driver in GRUB2 to use this controller at all.
> Not speaking about the complete different register set and operational
> model.
>
> What in turn should work is that "some of the BIOS" (which in
> coreboot-context is the payload like SeaBIOS) will handle all the
> xHCI stuff and provide a legacy interface to the OS (and here GRUB acts as
> an OS) to just read mass storage devices using interrupts.
>
> Beside that you are lost with GRUB2 and xHCI, sorry!
>
> Werner
>
> >Hi Experts,
> >
> >Does coreboot support USB port initialization in legacy mode on Apollo
> Lake as some of the BIOS does so that grub or other payloads can use it as
> USB2.0?
> >
> >There is no USB2.0 port on this board and Grub2 doesn't support xhci so
> we seems to be reaching to a dead end.
> >
> >I am trying to see if the dual role USB ports can be initialized in
> coreboot/fsp so that they can act as USB2.0 for payloads.
> >
> >Thanks
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom

[Gailu Singh]

Failing grub code
--
static void
init_cbfsdisk (void)
{
  grub_uint32_t ptr;
  struct cbfs_header *head;

  ptr = *(grub_uint32_t *) 0xfffc;
  head = (struct cbfs_header *) (grub_addr_t) ptr;
  grub_dprintf ("cbfs", "head=%p\n", head);

  /* coreboot current supports only ROMs <= 16 MiB. Bigger ROMs will
 have problems as RCBA is 18 MiB below end of 32-bit typically,
 so either memory map would have to be rearranged or we'd need to
support
 reading ROMs through controller directly.
   */
  if (ptr < 0xff00
  || 0x - ptr < (grub_uint32_t) sizeof (*head) + 0xf
  || !validate_head (head))
return;
--

On Sun, Mar 19, 2017 at 11:47 AM, Gailu Singh <gail...@gmail.com> wrote:

> Hi Experts,
>
> On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and
> found that cbfs header address validation fails.
>
> According to https://github.com/mrnuke/coreboot/blob/master/
> documentation/cbfs.txt,
> "A pointer to the location of the header will be located at offset -4 from
> the end of the ROM. This translates to address 0xFFFC on a normal x86
> system. The pointer will be to physical memory somewhere between -
> 0xB000 and 0xFFF0".
>
>
> We checked the coreboot.rom in hex editor and address in last 4 bytes is
> all ones () as a result grub is not able to find cbfs header.
>
>
> We have earlier used coreboot on baytrail and in the coreboot.rom cbfs
> header address in last 4 byte was a valid pointer.
>
>
> What is the location grub can find cbfs header on this board?
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Intel Leafhill/Apollolake wrong CBFS header address in coreboot.rom

[Gailu Singh]

Hi Experts,

On Intel Leafhill board grub fails to find cbfsdisk. We tried to debug and
found that cbfs header address validation fails.

According to
https://github.com/mrnuke/coreboot/blob/master/documentation/cbfs.txt,
"A pointer to the location of the header will be located at offset -4 from
the end of the ROM. This translates to address 0xFFFC on a normal x86
system. The pointer will be to physical memory somewhere between -
0xB000 and 0xFFF0".


We checked the coreboot.rom in hex editor and address in last 4 bytes is
all ones () as a result grub is not able to find cbfs header.


We have earlier used coreboot on baytrail and in the coreboot.rom cbfs
header address in last 4 byte was a valid pointer.


What is the location grub can find cbfs header on this board?
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Inteal Leafhill : Linux SATA driver fails when used with coreboot+grub

[Gailu Singh]

Hi,

For multiple Intel SOCs I see sata initialization in sata.c file but that
seems to be missing for apollolake. Could that be a reason?

./soc/intel/skylake/sata.c
./soc/intel/broadwell/sata.c
./soc/intel/baytrail/sata.c
./soc/intel/braswell/sata.c

Thanks

On Mon, Mar 6, 2017 at 12:28 AM, Gailu Singh <gail...@gmail.com> wrote:

> Hi Again,
>
> I tried to find out the details for following error
>
> ata1: SATA link down (SStatus 4 SControl 300)
>
> As per status register description
>
> SStatus 4 : Phy in offline mode as a result of the interface being
> disabled or running in a BIST loopback mode
>
> Is there any chance that coreboot/grub/Linux is putting SATA in to BIST
> loopback mode?
>
> I am trying to understand who is responsible for SATA Linux status 4 and
> possible candidates are
> a) coreboot
> b) grub
> c) Linux
>
> Looking forward to your expert advice
>
>
> Thanks
>
> On Fri, Mar 3, 2017 at 9:29 PM, Gailu Singh <gail...@gmail.com> wrote:
>
>> Hi Experts,
>>
>> I am trying to boot Linux 4.1 with coreboot and grub but SATA drive fails
>> with error  "ata1: SATA link down (SStatus 4 SControl 300)". It is
>> interesting that GRUB2 can use the SATA drive without issue and able to
>> load kernel from SATA disk.
>>
>> If I use same SATA Drive with Coreboot+UEFI payload then Linux driver
>> just works fine and I am able to boot linux.
>>
>> Any Idea What might be going wrong with Linux Driver. Does it expect
>> something from BIOS/Coreboot that is not fulfilled
>>
>> Linux boot logs:
>> -
>> Initializing cgroup subsys cpuset
>> Initializing cgroup subsys cpu
>> Initializing cgroup subsys cpuacct
>> Linux version 4.1.21-WR8.0.0.11_standard (vgahlaut@ubuntu) (gcc version
>> 5.2.0 (Wind River Linux 5.2.0-8.0-intel-apollolake-i-64) ) #1 SMP
>> PREEMPT Mon Feb 6 18:38:46 PST 2017
>> Command line: BOOT_IMAGE=(ahci0,msdos1)/boot/bzImage root=/dev/sda1
>> rootdelay=10 console=ttyS2,115200
>> KERNEL supported cpus:
>>   Intel GenuineIntel
>>   AMD AuthenticAMD
>>   Centaur CentaurHauls
>> e820: BIOS-provided physical RAM map:
>> BIOS-e820: [mem 0x-0x0fff] type 16
>> BIOS-e820: [mem 0x1000-0x0009] usable
>> BIOS-e820: [mem 0x000a-0x000f] reserved
>> BIOS-e820: [mem 0x0010-0x0fff] usable
>> BIOS-e820: [mem 0x1000-0x12150fff] reserved
>> BIOS-e820: [mem 0x12151000-0x7a64] usable
>> BIOS-e820: [mem 0x7a65-0x7aff] type 16
>> BIOS-e820: [mem 0x7b00-0x7fff] reserved
>> BIOS-e820: [mem 0xd000-0x] reserved
>> BIOS-e820: [mem 0x0001-0x00017fff] usable
>> NX (Execute Disable) protection: active
>> SMBIOS 2.7 present.
>> e820: last_pfn = 0x18 max_arch_pfn = 0x4
>> PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC
>> e820: last_pfn = 0x7a650 max_arch_pfn = 0x4
>> Scanning 1 areas for low memory corruption
>> Using GB pages for direct mapping
>> init_memory_mapping: [mem 0x-0x000f]
>> init_memory_mapping: [mem 0x17fe0-0x17fff]
>> init_memory_mapping: [mem 0x16000-0x17fdf]
>> init_memory_mapping: [mem 0x0010-0x0fff]
>> init_memory_mapping: [mem 0x12151000-0x7a64]
>> init_memory_mapping: [mem 0x1-0x15fff]
>> ACPI: Early table checksum verification disabled
>> ACPI: RSDP 0x000F 24 (v02 CORE  )
>> ACPI: XSDT 0x7A6690E0 5C (v01 CORE   COREBOOT  CORE
>> )
>> ACPI: FACP 0x7A66BA60 00010C (v05 CORE   COREBOOT  CORE
>> 0001)
>> ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aEventBlock:
>> 32/16 (20150410/tbfadt-623)
>> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aEventBlock: 16,
>> using default 32 (20150410/tbfadt-704)
>> ACPI: DSDT 0x7A669280 0027D8 (v05 COREv4 COREBOOT 20110725 INTL
>> 20160831)
>> ACPI: FACS 0x7A669240 40
>> ACPI: FACS 0x7A669240 40
>> ACPI: SSDT 0x7A66BB70 000774 (v02 CORE   COREBOOT 002A CORE
>> 002A)
>> ACPI: MCFG 0x7A66C2F0 3C (v01 CORE   COREBOOT  CORE
>> )
>> ACPI: TCPA 0x7A66C330 32 (v02 CORE   COREBOOT  CORE
>> )
>> ACPI: TPM2 0x7A66C370 34 (v04 CORE   COREBOOT  CORE
>> )
>> ACPI: APIC 0x7A66C3B0 6C

Re: [coreboot] Inteal Leafhill : Linux SATA driver fails when used with coreboot+grub

[Gailu Singh]

Hi Again,

I tried to find out the details for following error

ata1: SATA link down (SStatus 4 SControl 300)

As per status register description

SStatus 4 : Phy in offline mode as a result of the interface being disabled
or running in a BIST loopback mode

Is there any chance that coreboot/grub/Linux is putting SATA in to BIST
loopback mode?

I am trying to understand who is responsible for SATA Linux status 4 and
possible candidates are
a) coreboot
b) grub
c) Linux

Looking forward to your expert advice


Thanks

On Fri, Mar 3, 2017 at 9:29 PM, Gailu Singh <gail...@gmail.com> wrote:

> Hi Experts,
>
> I am trying to boot Linux 4.1 with coreboot and grub but SATA drive fails
> with error  "ata1: SATA link down (SStatus 4 SControl 300)". It is
> interesting that GRUB2 can use the SATA drive without issue and able to
> load kernel from SATA disk.
>
> If I use same SATA Drive with Coreboot+UEFI payload then Linux driver just
> works fine and I am able to boot linux.
>
> Any Idea What might be going wrong with Linux Driver. Does it expect
> something from BIOS/Coreboot that is not fulfilled
>
> Linux boot logs:
> -
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Initializing cgroup subsys cpuacct
> Linux version 4.1.21-WR8.0.0.11_standard (vgahlaut@ubuntu) (gcc version
> 5.2.0 (Wind River Linux 5.2.0-8.0-intel-apollolake-i-64) ) #1 SMP PREEMPT
> Mon Feb 6 18:38:46 PST 2017
> Command line: BOOT_IMAGE=(ahci0,msdos1)/boot/bzImage root=/dev/sda1
> rootdelay=10 console=ttyS2,115200
> KERNEL supported cpus:
>   Intel GenuineIntel
>   AMD AuthenticAMD
>   Centaur CentaurHauls
> e820: BIOS-provided physical RAM map:
> BIOS-e820: [mem 0x-0x0fff] type 16
> BIOS-e820: [mem 0x1000-0x0009] usable
> BIOS-e820: [mem 0x000a-0x000f] reserved
> BIOS-e820: [mem 0x0010-0x0fff] usable
> BIOS-e820: [mem 0x1000-0x12150fff] reserved
> BIOS-e820: [mem 0x12151000-0x7a64] usable
> BIOS-e820: [mem 0x7a65-0x7aff] type 16
> BIOS-e820: [mem 0x7b00-0x7fff] reserved
> BIOS-e820: [mem 0xd000-0x] reserved
> BIOS-e820: [mem 0x0001-0x00017fff] usable
> NX (Execute Disable) protection: active
> SMBIOS 2.7 present.
> e820: last_pfn = 0x18 max_arch_pfn = 0x4
> PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC
> e820: last_pfn = 0x7a650 max_arch_pfn = 0x4
> Scanning 1 areas for low memory corruption
> Using GB pages for direct mapping
> init_memory_mapping: [mem 0x-0x000f]
> init_memory_mapping: [mem 0x17fe0-0x17fff]
> init_memory_mapping: [mem 0x16000-0x17fdf]
> init_memory_mapping: [mem 0x0010-0x0fff]
> init_memory_mapping: [mem 0x12151000-0x7a64]
> init_memory_mapping: [mem 0x1-0x15fff]
> ACPI: Early table checksum verification disabled
> ACPI: RSDP 0x000F 24 (v02 CORE  )
> ACPI: XSDT 0x7A6690E0 5C (v01 CORE   COREBOOT  CORE
> )
> ACPI: FACP 0x7A66BA60 00010C (v05 CORE   COREBOOT  CORE
> 0001)
> ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aEventBlock:
> 32/16 (20150410/tbfadt-623)
> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aEventBlock: 16, using
> default 32 (20150410/tbfadt-704)
> ACPI: DSDT 0x7A669280 0027D8 (v05 COREv4 COREBOOT 20110725 INTL
> 20160831)
> ACPI: FACS 0x7A669240 40
> ACPI: FACS 0x7A669240 40
> ACPI: SSDT 0x7A66BB70 000774 (v02 CORE   COREBOOT 002A CORE
> 002A)
> ACPI: MCFG 0x7A66C2F0 3C (v01 CORE   COREBOOT  CORE
> )
> ACPI: TCPA 0x7A66C330 32 (v02 CORE   COREBOOT  CORE
> )
> ACPI: TPM2 0x7A66C370 34 (v04 CORE   COREBOOT  CORE
> )
> ACPI: APIC 0x7A66C3B0 6C (v01 CORE   COREBOOT  CORE
> )
> ACPI: HPET 0x7A66C420 38 (v01 CORE   COREBOOT  CORE
> )
> Zone ranges:
>   DMA  [mem 0x1000-0x00ff]
>   DMA32[mem 0x0100-0x]
>   Normal   [mem 0x0001-0x00017fff]
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x1000-0x0009]
>   node   0: [mem 0x0010-0x0fff]
>   node   0: [mem 0x12151000-0x7a64]
>   node   0: [mem 0x0001-0x00017fff]
> Initmem setup node 0 [mem 0x1000-0x00017fff]
> ACPI: PM-Timer IO Port: 0x408
> IOAPIC

[coreboot] Inteal Leafhill : Linux SATA driver fails when used with coreboot+grub

[Gailu Singh]

Hi Experts,

I am trying to boot Linux 4.1 with coreboot and grub but SATA drive fails
with error  "ata1: SATA link down (SStatus 4 SControl 300)". It is
interesting that GRUB2 can use the SATA drive without issue and able to
load kernel from SATA disk.

If I use same SATA Drive with Coreboot+UEFI payload then Linux driver just
works fine and I am able to boot linux.

Any Idea What might be going wrong with Linux Driver. Does it expect
something from BIOS/Coreboot that is not fulfilled

Linux boot logs:
-
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 4.1.21-WR8.0.0.11_standard (vgahlaut@ubuntu) (gcc version
5.2.0 (Wind River Linux 5.2.0-8.0-intel-apollolake-i-64) ) #1 SMP PREEMPT
Mon Feb 6 18:38:46 PST 2017
Command line: BOOT_IMAGE=(ahci0,msdos1)/boot/bzImage root=/dev/sda1
rootdelay=10 console=ttyS2,115200
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  Centaur CentaurHauls
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0fff] type 16
BIOS-e820: [mem 0x1000-0x0009] usable
BIOS-e820: [mem 0x000a-0x000f] reserved
BIOS-e820: [mem 0x0010-0x0fff] usable
BIOS-e820: [mem 0x1000-0x12150fff] reserved
BIOS-e820: [mem 0x12151000-0x7a64] usable
BIOS-e820: [mem 0x7a65-0x7aff] type 16
BIOS-e820: [mem 0x7b00-0x7fff] reserved
BIOS-e820: [mem 0xd000-0x] reserved
BIOS-e820: [mem 0x0001-0x00017fff] usable
NX (Execute Disable) protection: active
SMBIOS 2.7 present.
e820: last_pfn = 0x18 max_arch_pfn = 0x4
PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC
e820: last_pfn = 0x7a650 max_arch_pfn = 0x4
Scanning 1 areas for low memory corruption
Using GB pages for direct mapping
init_memory_mapping: [mem 0x-0x000f]
init_memory_mapping: [mem 0x17fe0-0x17fff]
init_memory_mapping: [mem 0x16000-0x17fdf]
init_memory_mapping: [mem 0x0010-0x0fff]
init_memory_mapping: [mem 0x12151000-0x7a64]
init_memory_mapping: [mem 0x1-0x15fff]
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000F 24 (v02 CORE  )
ACPI: XSDT 0x7A6690E0 5C (v01 CORE   COREBOOT  CORE
)
ACPI: FACP 0x7A66BA60 00010C (v05 CORE   COREBOOT  CORE
0001)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aEventBlock:
32/16 (20150410/tbfadt-623)
ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aEventBlock: 16, using
default 32 (20150410/tbfadt-704)
ACPI: DSDT 0x7A669280 0027D8 (v05 COREv4 COREBOOT 20110725 INTL
20160831)
ACPI: FACS 0x7A669240 40
ACPI: FACS 0x7A669240 40
ACPI: SSDT 0x7A66BB70 000774 (v02 CORE   COREBOOT 002A CORE
002A)
ACPI: MCFG 0x7A66C2F0 3C (v01 CORE   COREBOOT  CORE
)
ACPI: TCPA 0x7A66C330 32 (v02 CORE   COREBOOT  CORE
)
ACPI: TPM2 0x7A66C370 34 (v04 CORE   COREBOOT  CORE
)
ACPI: APIC 0x7A66C3B0 6C (v01 CORE   COREBOOT  CORE
)
ACPI: HPET 0x7A66C420 38 (v01 CORE   COREBOOT  CORE
)
Zone ranges:
  DMA  [mem 0x1000-0x00ff]
  DMA32[mem 0x0100-0x]
  Normal   [mem 0x0001-0x00017fff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x1000-0x0009]
  node   0: [mem 0x0010-0x0fff]
  node   0: [mem 0x12151000-0x7a64]
  node   0: [mem 0x0001-0x00017fff]
Initmem setup node 0 [mem 0x1000-0x00017fff]
ACPI: PM-Timer IO Port: 0x408
IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8086a701 base: 0xfed0
smpboot: Allowing 4 CPUs, 0 hotplug CPUs
PM: Registered nosave memory: [mem 0x-0x0fff]
PM: Registered nosave memory: [mem 0x000a-0x000f]
PM: Registered nosave memory: [mem 0x1000-0x12150fff]
PM: Registered nosave memory: [mem 0x7a65-0x7aff]
PM: Registered nosave memory: [mem 0x7b00-0x7fff]
PM: Registered nosave memory: [mem 0x8000-0xcfff]
PM: Registered nosave memory: [mem 0xd000-0x]
e820: [mem 0x8000-0xcfff] available for PCI devices
clocksource refined-jiffies: mask: 0x max_cycles: 0x,
max_idle_ns: 1910969940391419 ns
setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Embedded 32 pages/cpu @88017fc0 s93912 r8192 d28968 u524288
Built 1 zonelists in Zone order, 

Re: [coreboot] UART on Apollo Lake

[Gailu Singh]

I got the info from my .config that UART on this board are 8250 memory
mapped UART instead of typical IO mapped. Looks like grub2 does not support
memory mapped UART.

On Wed, Mar 1, 2017 at 8:51 AM, Gailu Singh <gail...@gmail.com> wrote:

> Hi Experts,
>
> Are UARTs available on Apollo Lake different than traditional 8250 UART?
> Or any specific settings (jumper etc) required to use them?
>
> Problem Statement:
> I am using UART available (through micro USB port) on Leafhill CRB. I am
> able to get coreboot logs but grub fails to detect these uart.
>
> I have following in my grub2.cfg
> serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1
>
> Grub output an error
> serial port COM0 not found
>
> If I change --unit=0 to 1 or 2 grub2 reports similar error
>
> serial port COM1 not found
> serial port COM2 not found
>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] UART on Apollo Lake

[Gailu Singh]

Hi Experts,

Are UARTs available on Apollo Lake different than traditional 8250 UART? Or
any specific settings (jumper etc) required to use them?

Problem Statement:
I am using UART available (through micro USB port) on Leafhill CRB. I am
able to get coreboot logs but grub fails to detect these uart.

I have following in my grub2.cfg
serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1

Grub output an error
serial port COM0 not found

If I change --unit=0 to 1 or 2 grub2 reports similar error

serial port COM1 not found
serial port COM2 not found
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ApolloLake Oxbohill CRB GRUB2 menu on serial Console

[Gailu Singh]

Hi,

Tried to change --unit=0 to --unit=2 as the serial port index used in
coreboot is 2. Still grub2 menu is not shown on serial console.



On Mon, Feb 27, 2017 at 4:34 PM, Gailu Singh <gail...@gmail.com> wrote:

> Hi Experts,
>
> I have built grub2 with coreboot platform support (./configure 
> --with-platform=coreboot)
> and managed to load it as elf payload in coreboot. I have added terminal
> support in grub configuration coreboot.cfg as follows
>
> serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1
> terminal_input --append serial terminal_output --append serial
> terminal_input --append usb_keyboard #add keyboard support.
>
> menuentry 'Boot From Hard Disk (Linux)' { insmod (cbfsdisk)/ahci.mod linux
> (ahci1,msdos1)/boot/bzImage root=/dev/sda1 resume=/dev/sda5
> console=ttyS0,115200 }
>
>
> While I see coreboot logs on serial console, I do not see grub2 menu on
> serial console. I can see grub2 menu on HDMI display though, however my
> USB keyboard is not working so not able to control grub either through
> display or serial console.
>
> Any help is appreciated.
>
> Thanks
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] USB Support on Apollo Lake

[Gailu Singh]

Hi Experts,

Does coreboot support USB port initialization in legacy mode on Apollo Lake
as some of the BIOS does so that grub or other payloads can use it as
USB2.0?

There is no USB2.0 port on this board and Grub2 doesn't support xhci so we
seems to be reaching to a dead end.

I am trying to see if the dual role USB ports can be initialized in
coreboot/fsp so that they can act as USB2.0 for payloads.

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

[coreboot] ApolloLake Oxbohill CRB GRUB2 menu on serial Console

[Gailu Singh]

Hi Experts,

I have built grub2 with coreboot platform support (./configure
--with-platform=coreboot)
and managed to load it as elf payload in coreboot. I have added terminal
support in grub configuration coreboot.cfg as follows

serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1 terminal_input
--append serial terminal_output --append serial terminal_input --append
usb_keyboard #add keyboard support.

menuentry 'Boot From Hard Disk (Linux)' { insmod (cbfsdisk)/ahci.mod linux
(ahci1,msdos1)/boot/bzImage root=/dev/sda1 resume=/dev/sda5
console=ttyS0,115200 }


While I see coreboot logs on serial console, I do not see grub2 menu on
serial console. I can see grub2 menu on HDMI display though, however my USB
keyboard is not working so not able to control grub either through display
or serial console.

Any help is appreciated.

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

Re: [coreboot] Coreboot at Apollo Lake Oxbohill CRB

[Gailu Singh]

Thank you once again for your help and support.

Managed to build the coreboot 16MB image with FSP, ifwi and descriptor.bin
and flashed it on the board. When power-on board, I see Red LED (DS3B1) is
ON that seems to be some error. User guide only provide description of 4
LEDs (DS6B1, DS2C1, DS6B2, D5L1) so I assume red led is indicating some
error condition.

Currently:
DS6B1 : Green ON
DS6B2 : Green ON
DS2C1 : OFF
DS3B1 : RED ON

No Output on serial console or HDMI.





On Sun, Feb 26, 2017 at 12:42 AM, Andrey Petrov <andrey.pet...@intel.com>
wrote:

> On 02/25/2017 11:05 AM, Gailu Singh wrote:
>
> Thanks Andrey,
>
> Manage to extract required blob with SplitFspBin.py.' I have prebuilt
> IFWI binary. only missing part is to find/generate correct descriptor.bin.
>
> just dd if=fitimage.bin bs=4096 count=1 of=descriptor.bin
> where fitimage.bin is output from FIT tool.
>
> -Andrey
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot at Apollo Lake Oxbohill CRB

[Gailu Singh]

Thanks Andrey,

Manage to extract required blob with SplitFspBin.py.' I have prebuilt IFWI
binary. only missing part is to find/generate correct descriptor.bin.

On Sun, Feb 26, 2017 at 12:20 AM, Andrey Petrov <andrey.pet...@intel.com>
wrote:

>
> On 02/25/2017 02:48 AM, Gailu Singh wrote:
>
> >>you need a bunch of blobs (of course), most importantly fitimage.bin and 
> >>fsp.
>
> >>Please use https://review.coreboot.org/#/c/18479/3 as starting point.
> >>That is for Leafhill. But once you apply that patch, select mainboard
> >>intel/leafhill in 'make nconfig', put the sacred blobs in the designated
> >>location and 'make' should give you flashable coreboot.rom.
>
> I pulled the leafhill patches and yes I get options to specify FSP when 
> selected leafhill. However not clear about the difference between FSP-M.fv 
> and FSP-S.fv. I have FSP.bsf and FSP.fd files for FSP. Can you please let me 
> know how to create required FSP blob from FSP.bsf and FSP.fd files?
>
> You need to use script to break the big blob into smaller blobs:
> https://github.com/tianocore/edk2/blob/master/IntelFsp2Pkg/
> Tools/SplitFspBin.py
>
> $ SplitFspBin.py split FSP.fd
>
> Here is some video on FSP2.0 and what blobs does what:
>
> https://www.youtube.com/watch?v=uzfiTiP9dEM=youtu.be
>
> Here is formal FSP2.0 spec:
>
> http://www.intel.com/content/www/us/en/embedded/software/
> fsp/fsp-architecture-spec-v2.html
>
> Best,
> Andrey
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot at Apollo Lake Oxbohill CRB

[Gailu Singh]

>>you need a bunch of blobs (of course), most importantly fitimage.bin and fsp.

>>Please use https://review.coreboot.org/#/c/18479/3 as starting point.
>>That is for Leafhill. But once you apply that patch, select mainboard
>>intel/leafhill in 'make nconfig', put the sacred blobs in the designated
>>location and 'make' should give you flashable coreboot.rom.


I pulled the leafhill patches and yes I get options to specify FSP
when selected leafhill. However not clear about the difference between
FSP-M.fv and FSP-S.fv. I have FSP.bsf and FSP.fd files for FSP. Can
you please let me know how to create required FSP blob from FSP.bsf
and FSP.fd files?



On Sat, Feb 25, 2017 at 10:49 AM, Gailu Singh <gail...@gmail.com> wrote:

> Hi Experts,
>
> I have built coreboot image for Apollo Lake and trying to boot Oxbohill
> CRB but no console or display at HDMI port.
>
> My coreboot.rom details
>
> Name   Offset Type Size
> cbfs master header 0x0cbfs header  32
> fallback/romstage  0x80   stage28268
> cpu_microcode_blob.bin 0x6f40 microcode0
> fallback/ramstage  0x6fc0 stage65343
> config 0x16f40raw  291
> revision   0x170c0raw  569
> fallback/postcar   0x17340stage16916
> fallback/dsdt.aml  0x1b5c0raw  99
> fallback/payload   0x1b680payload  361265
> (empty)0x73a00null 443544
> mrc.cache  0xdfec0mrc_cache65536
> (empty)0xeff00null 32664
> bootblock  0xf7ec0bootblock32768
>
> This is an 8 MB image, I flashed it to SPI flash at address 0. When I boot
> the board no output is observed either on USB serial console or on HDMI
> display.
>
> Do I need to add something more to see at least coreboot log. I am tryng
> to use GRUB2 as payload to coreboot.
>
> Thanks
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Coreboot at Apollo Lake Oxbohill CRB

[Gailu Singh]

Hi Experts,

I have built coreboot image for Apollo Lake and trying to boot Oxbohill CRB
but no console or display at HDMI port.

My coreboot.rom details

Name   Offset Type Size
cbfs master header 0x0cbfs header  32
fallback/romstage  0x80   stage28268
cpu_microcode_blob.bin 0x6f40 microcode0
fallback/ramstage  0x6fc0 stage65343
config 0x16f40raw  291
revision   0x170c0raw  569
fallback/postcar   0x17340stage16916
fallback/dsdt.aml  0x1b5c0raw  99
fallback/payload   0x1b680payload  361265
(empty)0x73a00null 443544
mrc.cache  0xdfec0mrc_cache65536
(empty)0xeff00null 32664
bootblock  0xf7ec0bootblock32768

This is an 8 MB image, I flashed it to SPI flash at address 0. When I boot
the board no output is observed either on USB serial console or on HDMI
display.

Do I need to add something more to see at least coreboot log. I am tryng to
use GRUB2 as payload to coreboot.

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

Re: [coreboot] Memory corruption on Resume from S3 Baytrail

[Gailu Singh]

Problem resolved by reserving initial 64K memory. Thanks to Stefan for his
help.

On Wed, Dec 10, 2014 at 11:12 AM, Gailu Singh gail...@gmail.com wrote:

 Hi,

 In  coreboot developer manual memory map section (
 http://www.coreboot.org/Developer_Manual/Memory_map) there is specific
 mention of low memory.

 *0x0 - 0x9*: Low 640kB. Should not be clobbered on S3
 suspend/resume (exceptions?)

 How do I tell Linux not to use this memory? I tried linux kernel argument
 memap=640K@0x0 to reserve the space but my kernel does not boot with that.

 What changes are expected in Linux kernel configuration for S3
 suspend/resume to work smoothly with coreboot?





 On Sun, Nov 23, 2014 at 12:54 PM, Stefan Reinauer 
 stefan.reina...@coreboot.org wrote:

 On 11/19/14 11:36 AM, Gailu Singh wrote:

 Hi Experts,

 I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume
 from Linux (kernel 3.10). I can suspend with pm-suspend and resume with
 power button; however after resuming I get following logs in Linux
 Corrupted low memory at c0001004 (1004 phys) = 0008eaea
 Corrupted low memory at c0001008 (1008 phys) = b0606600
 ...
 Corrupted low memory at c00018fc (18fc phys) = 08ea

 This seems to be caused by coreboot as I do not see these logs if I use
 BIOS instead of coreboot.
 Is it true that during resume coreboot uses RAM portion already mapped
 by Linux and thus corrupting it. How to I avoid the RAM conflict?


 Looks like coreboot (or FSP) is overwriting this memory with some
 trampoline code.

 One (ugly) way to fix this would be to just reserve the space in the
 memory table. The better way would be to track down where this is actually
 happening and fix it there.

 Stefan



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

Re: [coreboot] Memory corruption on Resume from S3 Baytrail

[Gailu Singh]

Hi,

In  coreboot developer manual memory map section (
http://www.coreboot.org/Developer_Manual/Memory_map) there is specific
mention of low memory.

*0x0 - 0x9*: Low 640kB. Should not be clobbered on S3
suspend/resume (exceptions?)

How do I tell Linux not to use this memory? I tried linux kernel argument
memap=640K@0x0 to reserve the space but my kernel does not boot with that.

What changes are expected in Linux kernel configuration for S3
suspend/resume to work smoothly with coreboot?





On Sun, Nov 23, 2014 at 12:54 PM, Stefan Reinauer 
stefan.reina...@coreboot.org wrote:

 On 11/19/14 11:36 AM, Gailu Singh wrote:

 Hi Experts,

 I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume
 from Linux (kernel 3.10). I can suspend with pm-suspend and resume with
 power button; however after resuming I get following logs in Linux
 Corrupted low memory at c0001004 (1004 phys) = 0008eaea
 Corrupted low memory at c0001008 (1008 phys) = b0606600
 ...
 Corrupted low memory at c00018fc (18fc phys) = 08ea

 This seems to be caused by coreboot as I do not see these logs if I use
 BIOS instead of coreboot.
 Is it true that during resume coreboot uses RAM portion already mapped by
 Linux and thus corrupting it. How to I avoid the RAM conflict?


 Looks like coreboot (or FSP) is overwriting this memory with some
 trampoline code.

 One (ugly) way to fix this would be to just reserve the space in the
 memory table. The better way would be to track down where this is actually
 happening and fix it there.

 Stefan

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

[coreboot] PCIe PME vs ACPI Interrupt

[Gailu Singh]

Hi Experts,

I am working on S3 wakeup from PCIE WAKE Signal on Baytrail SOC (Bayleybay
board) with Intel FSP.
When I send WOL packet ACPI interrupt count does not increase though PCIe
PME interrupt count increases.

Can you please provide some pointers why I am not getting ACPI interrupt
for the wake event?

in /proc/interrupts, PCIe PME counter increments and acpi counter remains 0.
 9:  0  0   IO-APIC-fasteoi   acpi
103: 2  0   PCI-MSI-edge  PCIe PME


My Root Port ASL is below.

Device (RP01)
{
Name (_ADR, 0x001c)
Name (_PRW, Package (0x02)
{
0x09,
0x03
})
Device (PXSX)
{
Name (_ADR, Zero)
Name (_PRW, Package (0x02)
{
0x09,
0x03
})
}
Method (_PRT)
{
If (PICM) {
Return (Package() {
#undef PIC_MODE
#include irq_helper.h
PCI_DEV_PIRQ_ROUTE(0x0, A, B, C, D)
})
} Else {
Return (Package() {
#define PIC_MODE
#include irq_helper.h
PCI_DEV_PIRQ_ROUTE(0x0, A, B, C, D)
})
}
}
}
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[Gailu Singh]

When tracing the problem I found that there is no GPE events getting
triggered even though they are enabled. All the gpe interrupt counters are
zero in /sys/firmware/acpi/interrupts. GPE0a_EN register has desired bits
enabled. Any idea what could be the reason for not getting GPE events?

On Fri, Nov 28, 2014 at 3:52 PM, WANG FEI wangfei.ji...@gmail.com wrote:

 Guilu,

 About the item 2, please refer to
 https://www.pcisig.com/specifications/conventional/pcipm1.2.pdf, chapter
 3, my experience is based on this spec. I bet PCIE devices should be
 compatible with this doc.

 This doc will focus on PCI/PCIE devices behind PCI/PCIE bridges/root
 ports, it's described how to configure the PCI/PCIE devices to wake
 themselves from PME signals. This job suppose to be done before system
 sleep(S1/S3/S4/S5).

 -Fei

 On Fri, Nov 28, 2014 at 6:42 AM, Gailu Singh gail...@gmail.com wrote:

 Hi Wang Fei,

 Thank you very much for your help. I checked the things you suggested but
 still it does not work. Here are some details.

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.
 You are right  PCIE Wake was disabled in smm.c I enabled it
 - enable_pm1(PWRBTN_EN | GBL_EN | PCIEXPWAK_DIS);
 + enable_pm1(PWRBTN_EN | GBL_EN);
  I Enabled GPE registers as well
 + enable_gpe(PCI_EXP_EN | PCIE_WAKE1_EN | PCIE_WAKE2_EN |
 SUS_GPIO_EN1 | SUS_GPIO_EN2);

 3) Report WOL PME single in ASL _GPE{} with _Lxx method
  I have _Lxx methods in GPE as below
 Method(_L11) {
 Notify(PWRB, 0x02) /* NOTIFY_DEVICE_WAKE */
 }

  4) (Option) If WOL PME single connect a GPIO, you have to configure
 GPIO pin as well.
  I tried configuring GPIO in gpio.c as GPIO_ACPI_WAKE and
 GPIO_ACPI_SCI
  - GPIO_DEFAULT,   /* GPIO_S5[01] */
  - GPIO_DEFAULT,   /* GPIO_S5[02] */
  + GPIO_ACPI_WAKE, /* GPIO_S5[01] */
  + GPIO_ACPI_WAKE, /* GPIO_S5[02] */

 2) PCIE Card ACPI register: Yeah, you need set some registers of the
 PCIE card to allow it waked by packages.
 I am not clear about this. Can you please elaborate little more
 on this. Do I need it to wake SoC or is it required for SoC to wake PCIe
 card after resume? From power button resume card works fine post resume.

 Am I doing something wrong in the first three things you suggested?

 Best Regards

 On Wed, Nov 26, 2014 at 8:33 PM, WANG FEI wangfei.ji...@gmail.com
 wrote:

 I remember WOL PME wakeup function need configure 3-4 different areas,

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.

 2) PCIE Card ACPI register: Yeah, you need set some registers of the
 PCIE card to allow it waked by packages.

 3) Report WOL PME single in ASL _GPE{} with _Lxx method

 4) (Option) If WOL PME single connect a GPIO, you have to configure GPIO
 pin as well.

 Please check your code and see if anything missed.

 On Tue, Nov 25, 2014 at 2:27 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Sean,

 Thanks for your help and showing me the direction. You are right GPIO
 pins for PMC_WAKE_PCIE were set to GPIO_DEFAULT in
 src/mainboard/intel/bayleybay_fsp/gpio.c. I have changed that to
 GPIO_ACPI_WAKE now. This seems to be one step closer to the solution but
 looks like something still missing as wakeup from PCIE device is still not
 working with coreboot. Any other thing that I should look at?

 Best Regards

 Perhaps you do not have all your GPIO pins set properly.

 On Mon, Nov 24, 2014 at 5:04 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have PCIe card that supports wake on lan and it works fine with
 BIOS. On sending magic packet System wakes up from S3.

 However If I use same Linux image with coreboot wake from PCI device
 does not wake the system. System wakes up from S3 using power button only.

 I suspected the problem with dsdt and took dsdt binary from bios
 setup, disassembled it and replaced dsdt.asl in coreboot with the one from
 bios to match dsdt configuration. Now my dsdt and linux image are same but
 still system does not wake from PCI PME (WOL) in coreboot but works fine
 with bios.

 In both cases wakeup is enabled in
 /sys/bus/pci/devices/\:01\:00.0/power/wakeup

 Can you please advise what else could be the problem?

 PME signal is connected to GPIOS5 on the SoC.

 Best Regards



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





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

Re: [coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[Gailu Singh]

Also there are 0 acpi interrupts in /proc/acpi/interrupts

#cat /proc/interrupts | grep -i acpi
  9:  0  0   IO-APIC-fasteoi   acpi

On Fri, Nov 28, 2014 at 11:13 PM, Gailu Singh gail...@gmail.com wrote:

 When tracing the problem I found that there is no GPE events getting
 triggered even though they are enabled. All the gpe interrupt counters are
 zero in /sys/firmware/acpi/interrupts. GPE0a_EN register has desired bits
 enabled. Any idea what could be the reason for not getting GPE events?

 On Fri, Nov 28, 2014 at 3:52 PM, WANG FEI wangfei.ji...@gmail.com wrote:

 Guilu,

 About the item 2, please refer to
 https://www.pcisig.com/specifications/conventional/pcipm1.2.pdf, chapter
 3, my experience is based on this spec. I bet PCIE devices should be
 compatible with this doc.

 This doc will focus on PCI/PCIE devices behind PCI/PCIE bridges/root
 ports, it's described how to configure the PCI/PCIE devices to wake
 themselves from PME signals. This job suppose to be done before system
 sleep(S1/S3/S4/S5).

 -Fei

 On Fri, Nov 28, 2014 at 6:42 AM, Gailu Singh gail...@gmail.com wrote:

 Hi Wang Fei,

 Thank you very much for your help. I checked the things you suggested
 but still it does not work. Here are some details.

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.
 You are right  PCIE Wake was disabled in smm.c I enabled it
 - enable_pm1(PWRBTN_EN | GBL_EN | PCIEXPWAK_DIS);
 + enable_pm1(PWRBTN_EN | GBL_EN);
  I Enabled GPE registers as well
 + enable_gpe(PCI_EXP_EN | PCIE_WAKE1_EN | PCIE_WAKE2_EN
 | SUS_GPIO_EN1 | SUS_GPIO_EN2);

 3) Report WOL PME single in ASL _GPE{} with _Lxx method
  I have _Lxx methods in GPE as below
 Method(_L11) {
 Notify(PWRB, 0x02) /* NOTIFY_DEVICE_WAKE */
 }

  4) (Option) If WOL PME single connect a GPIO, you have to configure
 GPIO pin as well.
  I tried configuring GPIO in gpio.c as GPIO_ACPI_WAKE and
 GPIO_ACPI_SCI
  - GPIO_DEFAULT,   /* GPIO_S5[01] */
  - GPIO_DEFAULT,   /* GPIO_S5[02] */
  + GPIO_ACPI_WAKE, /* GPIO_S5[01] */
  + GPIO_ACPI_WAKE, /* GPIO_S5[02] */

 2) PCIE Card ACPI register: Yeah, you need set some registers of the
 PCIE card to allow it waked by packages.
 I am not clear about this. Can you please elaborate little more
 on this. Do I need it to wake SoC or is it required for SoC to wake PCIe
 card after resume? From power button resume card works fine post resume.

 Am I doing something wrong in the first three things you suggested?

 Best Regards

 On Wed, Nov 26, 2014 at 8:33 PM, WANG FEI wangfei.ji...@gmail.com
 wrote:

 I remember WOL PME wakeup function need configure 3-4 different areas,

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.

 2) PCIE Card ACPI register: Yeah, you need set some registers of the
 PCIE card to allow it waked by packages.

 3) Report WOL PME single in ASL _GPE{} with _Lxx method

 4) (Option) If WOL PME single connect a GPIO, you have to configure
 GPIO pin as well.

 Please check your code and see if anything missed.

 On Tue, Nov 25, 2014 at 2:27 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Sean,

 Thanks for your help and showing me the direction. You are right GPIO
 pins for PMC_WAKE_PCIE were set to GPIO_DEFAULT in
 src/mainboard/intel/bayleybay_fsp/gpio.c. I have changed that to
 GPIO_ACPI_WAKE now. This seems to be one step closer to the solution but
 looks like something still missing as wakeup from PCIE device is still not
 working with coreboot. Any other thing that I should look at?

 Best Regards

 Perhaps you do not have all your GPIO pins set properly.

 On Mon, Nov 24, 2014 at 5:04 PM, Gailu Singh gail...@gmail.com
 wrote:

 Hi Experts,

 I have PCIe card that supports wake on lan and it works fine with
 BIOS. On sending magic packet System wakes up from S3.

 However If I use same Linux image with coreboot wake from PCI device
 does not wake the system. System wakes up from S3 using power button 
 only.

 I suspected the problem with dsdt and took dsdt binary from bios
 setup, disassembled it and replaced dsdt.asl in coreboot with the one 
 from
 bios to match dsdt configuration. Now my dsdt and linux image are same 
 but
 still system does not wake from PCI PME (WOL) in coreboot but works fine
 with bios.

 In both cases wakeup is enabled in
 /sys/bus/pci/devices/\:01\:00.0/power/wakeup

 Can you please advise what else could be the problem?

 PME signal is connected to GPIOS5 on the SoC.

 Best Regards



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






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

Re: [coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[Gailu Singh]

Hi Wang Fei,

Thank you very much for your help. I checked the things you suggested but
still it does not work. Here are some details.

1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.
You are right  PCIE Wake was disabled in smm.c I enabled it
- enable_pm1(PWRBTN_EN | GBL_EN | PCIEXPWAK_DIS);
+ enable_pm1(PWRBTN_EN | GBL_EN);
 I Enabled GPE registers as well
+ enable_gpe(PCI_EXP_EN | PCIE_WAKE1_EN | PCIE_WAKE2_EN |
SUS_GPIO_EN1 | SUS_GPIO_EN2);

3) Report WOL PME single in ASL _GPE{} with _Lxx method
 I have _Lxx methods in GPE as below
Method(_L11) {
Notify(PWRB, 0x02) /* NOTIFY_DEVICE_WAKE */
}

 4) (Option) If WOL PME single connect a GPIO, you have to configure GPIO
pin as well.
 I tried configuring GPIO in gpio.c as GPIO_ACPI_WAKE and
GPIO_ACPI_SCI
 - GPIO_DEFAULT,   /* GPIO_S5[01] */
 - GPIO_DEFAULT,   /* GPIO_S5[02] */
 + GPIO_ACPI_WAKE, /* GPIO_S5[01] */
 + GPIO_ACPI_WAKE, /* GPIO_S5[02] */

2) PCIE Card ACPI register: Yeah, you need set some registers of the PCIE
card to allow it waked by packages.
I am not clear about this. Can you please elaborate little more on
this. Do I need it to wake SoC or is it required for SoC to wake PCIe card
after resume? From power button resume card works fine post resume.

Am I doing something wrong in the first three things you suggested?

Best Regards

On Wed, Nov 26, 2014 at 8:33 PM, WANG FEI wangfei.ji...@gmail.com wrote:

 I remember WOL PME wakeup function need configure 3-4 different areas,

 1) SoC ACPI registers: Enable PCIE PME in PM and GPE registers.

 2) PCIE Card ACPI register: Yeah, you need set some registers of the PCIE
 card to allow it waked by packages.

 3) Report WOL PME single in ASL _GPE{} with _Lxx method

 4) (Option) If WOL PME single connect a GPIO, you have to configure GPIO
 pin as well.

 Please check your code and see if anything missed.

 On Tue, Nov 25, 2014 at 2:27 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Sean,

 Thanks for your help and showing me the direction. You are right GPIO
 pins for PMC_WAKE_PCIE were set to GPIO_DEFAULT in
 src/mainboard/intel/bayleybay_fsp/gpio.c. I have changed that to
 GPIO_ACPI_WAKE now. This seems to be one step closer to the solution but
 looks like something still missing as wakeup from PCIE device is still not
 working with coreboot. Any other thing that I should look at?

 Best Regards

 Perhaps you do not have all your GPIO pins set properly.

 On Mon, Nov 24, 2014 at 5:04 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have PCIe card that supports wake on lan and it works fine with BIOS.
 On sending magic packet System wakes up from S3.

 However If I use same Linux image with coreboot wake from PCI device
 does not wake the system. System wakes up from S3 using power button only.

 I suspected the problem with dsdt and took dsdt binary from bios setup,
 disassembled it and replaced dsdt.asl in coreboot with the one from bios to
 match dsdt configuration. Now my dsdt and linux image are same but still
 system does not wake from PCI PME (WOL) in coreboot but works fine with
 bios.

 In both cases wakeup is enabled in
 /sys/bus/pci/devices/\:01\:00.0/power/wakeup

 Can you please advise what else could be the problem?

 PME signal is connected to GPIOS5 on the SoC.

 Best Regards



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



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

[coreboot] Baytrail How to enable PM1_STS_EN.PCIEXP_WAKE_EN register bit

[Gailu Singh]

Hi Experts,

I need to enable power management register bit (PM1_STS_EN.PCIEXP_WAKE_EN)
of baytrail. I searched for PM1_STS_EN in the source but didn't find
anything related to that. Any suggestion how to do it?

Best Regards
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[Gailu Singh]

Hi Sean,

Thanks for your help and showing me the direction. You are right GPIO pins
for PMC_WAKE_PCIE were set to GPIO_DEFAULT in
src/mainboard/intel/bayleybay_fsp/gpio.c. I have changed that to
GPIO_ACPI_WAKE now. This seems to be one step closer to the solution but
looks like something still missing as wakeup from PCIE device is still not
working with coreboot. Any other thing that I should look at?

Best Regards

Perhaps you do not have all your GPIO pins set properly.

On Mon, Nov 24, 2014 at 5:04 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have PCIe card that supports wake on lan and it works fine with BIOS. On
 sending magic packet System wakes up from S3.

 However If I use same Linux image with coreboot wake from PCI device does
 not wake the system. System wakes up from S3 using power button only.

 I suspected the problem with dsdt and took dsdt binary from bios setup,
 disassembled it and replaced dsdt.asl in coreboot with the one from bios to
 match dsdt configuration. Now my dsdt and linux image are same but still
 system does not wake from PCI PME (WOL) in coreboot but works fine with
 bios.

 In both cases wakeup is enabled in
 /sys/bus/pci/devices/\:01\:00.0/power/wakeup

 Can you please advise what else could be the problem?

 PME signal is connected to GPIOS5 on the SoC.

 Best Regards


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

[coreboot] WOL/PCI PME wakeup from S3 Baytrail SoC (Bayleybay CRB)

[Gailu Singh]

Hi Experts,

I have PCIe card that supports wake on lan and it works fine with BIOS. On
sending magic packet System wakes up from S3.

However If I use same Linux image with coreboot wake from PCI device does
not wake the system. System wakes up from S3 using power button only.

I suspected the problem with dsdt and took dsdt binary from bios setup,
disassembled it and replaced dsdt.asl in coreboot with the one from bios to
match dsdt configuration. Now my dsdt and linux image are same but still
system does not wake from PCI PME (WOL) in coreboot but works fine with
bios.

In both cases wakeup is enabled in
/sys/bus/pci/devices/\:01\:00.0/power/wakeup

Can you please advise what else could be the problem?

PME signal is connected to GPIOS5 on the SoC.

Best Regards
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to get coreboot debug prints during suspend resume

[Gailu Singh]

Hi Experts,

Is it possible to get coreboot debug prints during suspend/resume?

Best Regards
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Memory corruption on Resume from S3 Baytrail

[Gailu Singh]

Hi Stefan,

I am using FSP. My cbfs prints are below.

Name   Offset Type Size
cmos_layout.bin0x20   cmos_layout  1132
pci8086,0f31.rom   0x2004c0   optionrom65536
fallback/romstage  0x210500   stage27813
fallback/ramstage  0x217200   stage68181
fallback/payload   0x227cc0   payload  269102
config 0x269840   raw  4540
(empty)0x26aa40   null 4871576
cpu_microcode_blob.bin 0x71   microcode208896
(empty)0x743040   null 53080
mrc.cache  0x74ffc0   (unknown)65536
(empty)0x76   null 393112
fsp.bin0x7bffc0   (unknown)229376
(empty)0x7f8000   null 31640


On Fri, Nov 21, 2014 at 2:06 AM, Stefan Reinauer 
stefan.reina...@coreboot.org wrote:

 * Gailu Singh gail...@gmail.com [141119 20:36]:
  Hi Experts,
 
  I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume
 from
  Linux (kernel 3.10). I can suspend with pm-suspend and resume with power
  button; however after resuming I get following logs in Linux
  Corrupted low memory at c0001004 (1004 phys) = 0008eaea
  Corrupted low memory at c0001008 (1008 phys) = b0606600
  ...
  Corrupted low memory at c00018fc (18fc phys) = 08ea
 
  This seems to be caused by coreboot as I do not see these logs if I use
 BIOS
  instead of coreboot.
  Is it true that during resume coreboot uses RAM portion already mapped
 by Linux
  and thus corrupting it. How to I avoid the RAM conflict?

 Hi Gailu,

 is this happening with FSP or mrc.bin?

 Stefan


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

[coreboot] Memory corruption on Resume from S3 Baytrail

[Gailu Singh]

Hi Experts,

I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume
from Linux (kernel 3.10). I can suspend with pm-suspend and resume with
power button; however after resuming I get following logs in Linux
Corrupted low memory at c0001004 (1004 phys) = 0008eaea
Corrupted low memory at c0001008 (1008 phys) = b0606600
...
Corrupted low memory at c00018fc (18fc phys) = 08ea

This seems to be caused by coreboot as I do not see these logs if I use
BIOS instead of coreboot.
Is it true that during resume coreboot uses RAM portion already mapped by
Linux and thus corrupting it. How to I avoid the RAM conflict?
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] USB keyboard wakeup from S3 Baytrail: Bayley Bay CRB

[Gailu Singh]

Hi Experts,

I am trying to use ACPI_RESUME functionality of coreboot on Bayley Bay CRB
and unable to wakeup board with USB Keyboard. Board resumes with power
button only. Below is the detailed description.

1. I am using EHCI instead of XHCI as I need to support boot from USB in
grub.
2. Enabled S3 support in coreboot File:
src/soc/intel/fsp_baytrail/acpi/usb.asl, Chnage: Name (_PRW, Package(){ 13,
3 })
3. Linux Kernel Version: 3.10

In Linux I see following in /proc/acpi/wakeup
root@localhost:~# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
EHC1  S3*enabled   pci::00:1d.0
XHCI  S3*disabled

When I plugin USB keyboard following are logs
root@localhost:~# usb 1-1.2: new low-speed USB device number 3 using
ehci-pci
input: SIGMACHIP USB Keyboard as
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input3
hid-generic 0003:1C4F:0016.0001: input: USB HID v1.10 Keyboard [SIGMACHIP
USB Keyboard] on usb-:00:1d.0-1.2/input0
input: SIGMACHIP USB Keyboard as
/devices/pci:00/:00:1d.0/usb1/1-1/1-1.2/1-1.2:1.1/input/input4
hid-generic 0003:1C4F:0016.0002: input: USB HID v1.10 Device [SIGMACHIP USB
Keyboard] on usb-:00:1d.0-1.2/input1

Based on above information I tried to enable wakeup from USB keyboard as
follows
echo enabled  /sys/devices/pci\:00/\:00\:1d.0/usb1/power/wakeup
echo enabled  /sys/bus/usb/devices/1-1/power/wakeup

Still see the same entried in /proc/acpi/wakeup
root@localhost:~# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
EHC1  S3*enabled   pci::00:1d.0
XHCI  S3*disabled

Did pm-suspend. Following are the logs
root@localhost:~# pm-suspend
ata2.00: configured for UDMA/100
ata2: EH complete
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

At this stage power to USB keyboard is off. No LED for Capslock. Nothing
happens when I press any key on the keyboard.

System resumes with power button with the following logs.
POST: 0x76
Finalize devices...
DOMAIN:  final
FspNotify(EnumInitPhaseAfterPciEnumeration)
Devices finalized
BS: BS_POST_DEVICE times (us): entry 0 run 12389 exit 0
POST: 0x77
Trying to find the wakeup vector...
Looking on 000f for valid checksum
Checksum 1 passed
Checksum 2 passed all OK
RSDP found at 000f
RSDT found at 7add7030 ends at 7add7068
FADT found at 7add9cf0
FACS found at 7add7210
OS waking vector is 0009c090
BS: BS_OS_RESUME_CHECK times (us): entry 0 run 26951 exit 0
POST: 0x78
Restore GNVS pointer to 0x7adfb000
POST: 0xfd

sd 1:0:0:0: [sda] Synchronizing SCSI cache
sd 1:0:0:0: [sda] Stopping disk
PM: suspend of devices complete after 601.507 msecs
[ cut here ]
WARNING: at /home/linux/3.10-r0/linux/drivers/clk/clk.c:842
__clk_disable+0x50/0x70()
Modules linked in:
CPU: 1 PID: 453 Comm: pm-suspend Not tainted 3.10.38 #1
Hardware name: Intel Bayley Bay CRB/Bayley Bay CRB, BIOS
4.0-7016-g0a66991-dirty 11/15/2014
   f407de08 c181ea2c f407de30 c1036c7e c1a1541d c1a80588
 034a c16ca130 c16ca130 f4d89420 f4d89420 c13d8bf0 f407de40 c1036d42
 0009  f407de4c c16ca130 0246 f407de5c c16ca22a f4d89420
Call Trace:
 [c181ea2c] dump_stack+0x16/0x18
 [c1036c7e] warn_slowpath_common+0x5e/0x80
 [c16ca130] ? __clk_disable+0x50/0x70
 [c16ca130] ? __clk_disable+0x50/0x70
 [c13d8bf0] ? dw_pci_resume_early+0x20/0x20
 [c1036d42] warn_slowpath_null+0x22/0x30
 [c16ca130] __clk_disable+0x50/0x70
 [c16ca22a] clk_disable+0x1a/0x30
 [c13d7ca0] dw_dma_suspend+0x20/0x30
 [c13d8c02] dw_pci_suspend_late+0x12/0x20
 [c149f1bb] dpm_run_callback.isra.3+0x2b/0x70
 [c1823d37] ? _raw_spin_unlock_irq+0x17/0x40
 [c149f79d] dpm_suspend_end+0x4d/0x490
 [c1079598] suspend_devices_and_enter+0xf8/0x440
 [c181a528] ? printk+0x50/0x52
 [c1079a90] pm_suspend+0x1b0/0x220
 [c1078aab] state_store+0x5b/0xb0
 [c1078a50] ? wakeup_count_show+0x50/0x50
 [c1355997] kobj_attr_store+0x17/0x30
 [c11905bb] sysfs_write_file+0x9b/0x110
 [c1190520] ? sysfs_open_file+0x1f0/0x1f0
 [c113aea9] vfs_write+0x99/0x190
 [c113b481] SyS_write+0x51/0x90
 [c182a5be] sysenter_do_call+0x12/0x12
---[ end trace d63a3167b6ae1b8f ]---
[ cut here ]
WARNING: at /home/linux/3.10-r0/linux/drivers/clk/clk.c:751
__clk_unprepare+0x50/0x70()
Modules linked in:
CPU: 1 PID: 453 Comm: pm-suspend Tainted: GW3.10.38 #1
Hardware name: Intel Bayley Bay CRB/Bayley Bay CRB, BIOS
4.0-7016-g0a66991-dirty 11/15/2014
   f407de0c c181ea2c f407de34 c1036c7e c1a1541d c1a80588
 02ef c16cab60 c16cab60 f4d89420 f4c4c064 c13d8bf0 f407de44 c1036d42
 0009  f407de50 c16cab60 f4d89420 f407de5c c16cab97 f4d89420
Call Trace:
 [c181ea2c] dump_stack+0x16/0x18
 [c1036c7e] warn_slowpath_common+0x5e/0x80
 [c16cab60] ? __clk_unprepare+0x50/0x70
 [c16cab60] ? __clk_unprepare+0x50/0x70
 [c13d8bf0] ? 

Re: [coreboot] Changing console uart on Bayley Bay CRB

[Gailu Singh]

Hi David,

Thanks for your inputs. I had some build problem building superiotool from
coreboot due to missing pci.h. I copied superiotool from my ubuntu12.04 and
have requested output below. Is it the case that superio chip on this board
listed by superiotool (WPCE775x / NPCE781x) is not supported by coreboot?
In src/superio/nuvoton directory I see nct5104d and wpcm 450 directory.

root@localhost:~# ./superiotool -v
superiotool r6637
root@localhost:~# ./superiotool
superiotool r6637
Found Nuvoton WPCE775x / NPCE781x (id=0x00, rev=0x04) at 0x4e
root@localhost:~# ./superiotool -d
superiotool r6637
Found Nuvoton WPCE775x / NPCE781x (id=0x00, rev=0x04) at 0x4e
Register dump:
idx 20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f
val fc 11 00 00 06 00 00 04  00 14 01 01 00 00 00 00
def fc 11 RR RR RR 00 00 MM  00 04 RR RR RR 00 RR RR
LDN 0x03 (CIR Port (CIRP))
idx 30 60 61 70 71 74 75 f0
val 00 00 00 00 00 00 00 00
def 00 03 f8 04 03 04 04 02
LDN 0x04 (Mobile System Wake-Up Control Config (MSWC))
idx 30 60 61 70 71 74 75
val 00 00 00 00 03 04 04
def 00 00 00 00 03 04 04
LDN 0x05 (Mouse config (KBC))
idx 30 70 71 74 75
val 00 0c 03 04 04
def 00 0c 03 04 04
LDN 0x06 (Keyboard config (KBC))
idx 30 60 61 62 63 70 71 74  75
val 00 00 60 00 64 01 03 04  04
def 00 00 60 00 64 01 03 04  04
LDN 0x0f (Shared memory (SHM))
idx 30 60 61 70 71 74 75 f0  f1 f2 f3 f4 f5 f6 f7 f8  f9 fa fb
val 00 00 00 00 03 04 04 09  87 03 00 00 00 00 00 00  00 00 00
def 00 00 00 00 00 04 04 MM  07 RR RR 00 00 00 00 00  00 00 00
LDN 0x11 (Power management I/F Channel 1 (PM1))
idx 30 60 61 62 63 70 71 74  75
val 01 00 62 00 66 00 03 04  04
def 00 00 62 00 66 01 03 04  04
LDN 0x12 (Power management I/F Channel 2 (PM2))
idx 30 60 61 62 63 70 71 74  75
val 01 00 80 00 80 00 03 04  04
def 00 00 68 00 6c 01 03 04  04
LDN 0x15 (Enhanced Wake On CIR (EWOC))
idx 30 60 61 62 63 70 71 74  75
val 00 00 00 00 00 00 00 00  00
def 00 00 00 00 00 00 03 04  04
LDN 0x17 (Power Management I/F Channel 3 (PM3))
idx 30 60 61 62 63 70 71 74  75
val 01 00 81 00 81 00 03 04  04
def 00 00 6a 00 6e 01 03 04  04
LDN 0x1a (Serial Port with Fast Infrared Port (FIR))
idx 30 60 61 70 71 74 75 f0
val 00 00 00 00 00 00 00 00
def 00 02 f8 03 03 04 04 02
root@localhost:~# ./superiotool -e
superiotool r6637
Found Nuvoton WPCE775x / NPCE781x (id=0x00, rev=0x04) at 0x4e
root@localhost:~#

On Sun, Nov 9, 2014 at 12:23 PM, David Hendricks david.hendri...@gmail.com
wrote:

 Hi Gailu,
 You might need to set an enable bit for the UART2 logical device in the
 EC. Can you run superiotool (from coreboot/util/superiotool) to dump the EC
 config registers on the CRB?

 (I'm just guessing - I've never used a Bayley Bay CRB)

 On Fri, Nov 7, 2014 at 8:46 AM, Gailu Singh gail...@gmail.com wrote:

 Hi,

 I got the schematics now and I see that J9B4 is connected to Embedded
 Controller (EC), so I think that this is not 8250 UART2. Am I right?

 I am not able to find the documentation what purpose is served by
 Embedded Controller and does coreboot use it at all? Any pointers please. I
 am trying to understand what is the purpose of COM port at J9B4. Any
 specific document that I should refer to to understand it? I checked user
 guide and schematics.

 There are 2 com ports I see using usb to serial and Port0 is used for
 console. Is another port on usb to serial is spare and can be used for
 console or is it serving some other purpose in coreboot.



 On Fri, Nov 7, 2014 at 3:51 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have working console uart 0 on Baytrail CRB board. However I am trying
 to change to uart 2 (J9B4) DB9 connector. I have changed
 CONFIG_UART_FOR_CONSOLE=2 from menuconfig, cleaned and rebuild and flashed
 coreboot but do not see any log on port 2. Is there any other changes
 required apart from CONFIG_UART_FOR_CONSOLE ?





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



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

[coreboot] SuperIO support on Bayley Bay CRB (Baytrail SoC)

[Gailu Singh]

Hi Experts,

May I know if the support for SuperIO on Bayley Bay CRB is available in
coreboot? and can I access UART available on SuperIO?

This board seems to be using Nuvoton SuperIO chip (NPCE985EA0DX). I checked
src/superio directory and do not see this chip listed there. Data sheet is
also not  available on Nuvoton web site. Can anyone please help?
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Changing console uart on Bayley Bay CRB

[Gailu Singh]

Hi Experts,

I have working console uart 0 on Baytrail CRB board. However I am trying to
change to uart 2 (J9B4) DB9 connector. I have changed
CONFIG_UART_FOR_CONSOLE=2 from menuconfig, cleaned and rebuild and flashed
coreboot but do not see any log on port 2. Is there any other changes
required apart from CONFIG_UART_FOR_CONSOLE ?
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changing console uart on Bayley Bay CRB

[Gailu Singh]

Hi,

I got the schematics now and I see that J9B4 is connected to Embedded
Controller (EC), so I think that this is not 8250 UART2. Am I right?

I am not able to find the documentation what purpose is served by Embedded
Controller and does coreboot use it at all? Any pointers please. I am
trying to understand what is the purpose of COM port at J9B4. Any specific
document that I should refer to to understand it? I checked user guide and
schematics.

There are 2 com ports I see using usb to serial and Port0 is used for
console. Is another port on usb to serial is spare and can be used for
console or is it serving some other purpose in coreboot.



On Fri, Nov 7, 2014 at 3:51 PM, Gailu Singh gail...@gmail.com wrote:

 Hi Experts,

 I have working console uart 0 on Baytrail CRB board. However I am trying
 to change to uart 2 (J9B4) DB9 connector. I have changed
 CONFIG_UART_FOR_CONSOLE=2 from menuconfig, cleaned and rebuild and flashed
 coreboot but do not see any log on port 2. Is there any other changes
 required apart from CONFIG_UART_FOR_CONSOLE ?




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

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help

[Gailu Singh]

Hi Werner,

Thanks for your help and support. It was indeed due to wrong FSP. D0
stepping is installed and it only worked now with Gold3 FSP and updated
microcode.

Thank you very much.

On Tue, Nov 4, 2014 at 12:48 AM, Werner Zeh werner@gmx.net wrote:

 Hi.

 Now you have coreboot running.
 coreboot searches for FSP, finds it and executes the first call into it.
 FSP returns with an error and what you see is this (taken from
 src/drivers/intel/fsp/cache_as_ram.inc):

 /*
  * Failures for postcode 0xBB - failed in the FSP:
  *
  * 0x00 - FSP_SUCCESS: Temp RAM was initialized successfully.
  * 0x02 - FSP_INVALID_PARAMETER: Input parameters are invalid.
  * 0x0E - FSP_NOT_FOUND: No valid microcode was found in the microcode
 region.
  * 0x03 - FSP_UNSUPPORTED: The FSP calling conditions were not met.
  * 0x07 - FSP_DEVICE_ERROR: Temp RAM initialization failed
  * 0x14 - FSP_ALREADY_STARTED: Temp RAM initialization has been invoked
  */

 So what you actually see is error code 0x07 from FSP. This can mean that
 your CPU is not supported by this FSP version.
 If you use GOLD1 or GOLD2, then a D0 stepping is not supported and if you
 have in advance a D0 stepping installed on your board,
 than you have to use GOLD3 FSP release as it was already mentioned.

 I had the same issue and it was due to missing D0-Support in GOLD1
 release. So, I would suggest to try the right FSP-release from Intel.

 Bye
 Werner

 Am 03.11.2014 um 17:23 schrieb Gailu Singh via coreboot:

 With the changed TXE/descriptor, it moved ahead but now toggling between
 POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h
 and these POST codes are not defined there so I doubt that these are coming
 from coreboot code. Are these post codes coming from FSP code? If yes, How
 do I interpret them? Do I need to ask Intel? Any pointers please?

 On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com
 mailto:seanmcne...@gmail.com wrote:

 You mentioned just copying the .fd file, so I assumed it was being
 used directly in your coreboot image. FSP needs to be incorporated
 into flash, yes. It should, however, be patched with the BCT
 program as what is provided in the .fd is usually not patched with
 the a configuration that you desire. Thus you should run bct and
 configure/patch the .fd and generate a .bin to include into coreboot.

 I am a little confused by your email below. You state that you are
 not using the .fd directly then contradict yourself in the next
 sentence. Bottom line is I would not include any .fd file from the
 FSP archive directly. Use BCT to patch it and do not name it .fd.
 This avoids any confusion regarding whether you are including a
 patched FSP or not. Just because there is a bsf file included in
 the GOLD release doesn't mean that the .fd was patched with those
 settings and that it is valid.

 Best of luck to you. There are many issues you will have to
 resolve dealing with new hardware. I've gone through the process
 with a lot of support from Intel and it is not that easy.
 Especially when certain components found on the CRB are not
 provided on custom hardware.

 Cheers,
 Sean


 On 11/02/2014 08:01 PM, Gailu Singh wrote:

 Hi Sean,

 1. This is not for a real project and we are trying to understand
 FSP interaction with coreboot to look at feasibility for
 considering coreboot in our future projects. Unfortunately I do
 not have board documentation so was not able to determine which
 one is serial port 0 though I know that port 0 is specified in
 coreboot config. That was the reason I was trying on all 3
 available ports.
 2. I am not using .fd directly. I believe that FSP need to be
 included in bootloader (coreboot in this case) and we are
 providing path to coreboot so that it can be included in
 coreboot. In my original post I only said that I copied .fd to a
 path expected  by coreboot configuration. May I know how did you
 conclude that I am using it directly? May be that can give me
 some pointer.
 3. I had checked the bsf file in the FSP kit with BCT tool and it
 is configured for non-ECC RAM, so I believe that no change is
 required in .fd. Am I wrong?
 4. Yes, I agree that there is no documentation available on how
 to create entire 8MB binary with Firmware Description, TXE,
 coreboot etc so for safe route I only touched upper 2 MB as
 recommended in one of the initial commit for baytrail FSP
 integration and some posts related to similar discussion.



 On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil
 seanmcne...@gmail.com mailto:seanmcne...@gmail.com wrote:

 Coreboot and FSP are not as easy to understand as you can
 see. I also would suggest that you seek assistance from
 either Sage (who has good experience that I understand

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help

[Gailu Singh via coreboot]

With the changed TXE/descriptor, it moved ahead but now toggling between
POST codes 0x66 and 0x07. I checked ./src/include/console/post_codes.h and
these POST codes are not defined there so I doubt that these are coming
from coreboot code. Are these post codes coming from FSP code? If yes, How
do I interpret them? Do I need to ask Intel? Any pointers please?

On Sun, Nov 2, 2014 at 6:50 PM, Sean McNeil seanmcne...@gmail.com wrote:

  You mentioned just copying the .fd file, so I assumed it was being used
 directly in your coreboot image. FSP needs to be incorporated into flash,
 yes. It should, however, be patched with the BCT program as what is
 provided in the .fd is usually not patched with the a configuration that
 you desire. Thus you should run bct and configure/patch the .fd and
 generate a .bin to include into coreboot.

 I am a little confused by your email below. You state that you are not
 using the .fd directly then contradict yourself in the next sentence.
 Bottom line is I would not include any .fd file from the FSP archive
 directly. Use BCT to patch it and do not name it .fd. This avoids any
 confusion regarding whether you are including a patched FSP or not. Just
 because there is a bsf file included in the GOLD release doesn't mean that
 the .fd was patched with those settings and that it is valid.

 Best of luck to you. There are many issues you will have to resolve
 dealing with new hardware. I've gone through the process with a lot of
 support from Intel and it is not that easy. Especially when certain
 components found on the CRB are not provided on custom hardware.

 Cheers,
 Sean


 On 11/02/2014 08:01 PM, Gailu Singh wrote:

   Hi Sean,

  1. This is not for a real project and we are trying to understand FSP
 interaction with coreboot to look at feasibility for considering coreboot
 in our future projects. Unfortunately I do not have board documentation so
 was not able to determine which one is serial port 0 though I know that
 port 0 is specified in coreboot config. That was the reason I was trying on
 all 3 available ports.
  2. I am not using .fd directly. I believe that FSP need to be included in
 bootloader (coreboot in this case) and we are providing path to coreboot so
 that it can be included in coreboot. In my original post I only said that I
 copied .fd to a path expected  by coreboot configuration. May I know how
 did you conclude that I am using it directly? May be that can give me some
 pointer.
  3. I had checked the bsf file in the FSP kit with BCT tool and it is
 configured for non-ECC RAM, so I believe that no change is required in .fd.
 Am I wrong?
  4. Yes, I agree that there is no documentation available on how to create
 entire 8MB binary with Firmware Description, TXE, coreboot etc so for safe
 route I only touched upper 2 MB as recommended in one of the initial commit
 for baytrail FSP integration and some posts related to similar discussion.



 On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil seanmcne...@gmail.com wrote:

 Coreboot and FSP are not as easy to understand as you can see. I also
 would suggest that you seek assistance from either Sage (who has good
 experience that I understand serves the USA and Europe markets and
 contributed the current Coreboot+FSP code) or perhaps a company in Asia
 such as Zien Solutions (of Vietnam). There are a number of issues that you
 are failing to understand:

 1) As stated, the first serial port is actually connected to a
 USB-Serial converter and delivered out of the microUSB connector on the
 CRB.
 2) You need to configure the FSP with Intels program to create a ROMable
 image and not use the .fd file directly.
 3) BayleyBay needs to be configured for non-ECC RAM whereas Bakersport
 needs to be configured for ECC.
 4) You don't necessarily need the TXE security module, but you could very
 well cause problems if it is partially overwritten. Best is to create a
 correct 8MB image to flash that has the proper Intel Firmware Description
 block at the beginning.

 Regards,
 Sean


 On 11/02/2014 02:25 AM, Gaumless via coreboot wrote:

 First, the serial ports:  The serial console is on the first serial port
 on the micro-USB connection.

 The 0x on the post code display means that it's not actually
 starting to boot - it's probably hanging in the TXE.  There are known
 issues with upgrading to coreboot from some of the bayleybay roms.  I
 thought Intel was going to document that, but I don't know if they did.

 The Gold 2 FSP doesn't support D0 parts, so if you have a D0, you need
 the Gold 3.  Also, the FSP is targeted at the embedded sku Baytrail-I.  It
 might work with M/D parts, I haven't tested that.

 Assuming all that is ok, you probably need to start from a different
 rom.  It might be failing because of the TXE security.  You'll probably
 need to talk to your Intel contact to get that update.

 Finally, if this is not a personal project, you might be interested in
 contacting Sage and look at purchasing

Re: [coreboot] Coreboot with Intel FSP on BayleyBay Help

[Gailu Singh via coreboot]

Hi Sean,

1. This is not for a real project and we are trying to understand FSP
interaction with coreboot to look at feasibility for considering coreboot
in our future projects. Unfortunately I do not have board documentation so
was not able to determine which one is serial port 0 though I know that
port 0 is specified in coreboot config. That was the reason I was trying on
all 3 available ports.
2. I am not using .fd directly. I believe that FSP need to be included in
bootloader (coreboot in this case) and we are providing path to coreboot so
that it can be included in coreboot. In my original post I only said that I
copied .fd to a path expected  by coreboot configuration. May I know how
did you conclude that I am using it directly? May be that can give me some
pointer.
3. I had checked the bsf file in the FSP kit with BCT tool and it is
configured for non-ECC RAM, so I believe that no change is required in .fd.
Am I wrong?
4. Yes, I agree that there is no documentation available on how to create
entire 8MB binary with Firmware Description, TXE, coreboot etc so for safe
route I only touched upper 2 MB as recommended in one of the initial commit
for baytrail FSP integration and some posts related to similar discussion.



On Sun, Nov 2, 2014 at 3:49 PM, Sean McNeil seanmcne...@gmail.com wrote:

 Coreboot and FSP are not as easy to understand as you can see. I also
 would suggest that you seek assistance from either Sage (who has good
 experience that I understand serves the USA and Europe markets and
 contributed the current Coreboot+FSP code) or perhaps a company in Asia
 such as Zien Solutions (of Vietnam). There are a number of issues that you
 are failing to understand:

 1) As stated, the first serial port is actually connected to a USB-Serial
 converter and delivered out of the microUSB connector on the CRB.
 2) You need to configure the FSP with Intels program to create a ROMable
 image and not use the .fd file directly.
 3) BayleyBay needs to be configured for non-ECC RAM whereas Bakersport
 needs to be configured for ECC.
 4) You don't necessarily need the TXE security module, but you could very
 well cause problems if it is partially overwritten. Best is to create a
 correct 8MB image to flash that has the proper Intel Firmware Description
 block at the beginning.

 Regards,
 Sean


 On 11/02/2014 02:25 AM, Gaumless via coreboot wrote:

 First, the serial ports:  The serial console is on the first serial port
 on the micro-USB connection.

 The 0x on the post code display means that it's not actually starting
 to boot - it's probably hanging in the TXE.  There are known issues with
 upgrading to coreboot from some of the bayleybay roms.  I thought Intel was
 going to document that, but I don't know if they did.

 The Gold 2 FSP doesn't support D0 parts, so if you have a D0, you need
 the Gold 3.  Also, the FSP is targeted at the embedded sku Baytrail-I.  It
 might work with M/D parts, I haven't tested that.

 Assuming all that is ok, you probably need to start from a different
 rom.  It might be failing because of the TXE security.  You'll probably
 need to talk to your Intel contact to get that update.

 Finally, if this is not a personal project, you might be interested in
 contacting Sage and look at purchasing a BSP to get up and running.  Either
 way, let us know whether you make progress or need more help.

 Martin


  On Nov 1, 2014, at 11:48 AM, Gailu Singh via coreboot 
 coreboot@coreboot.org wrote:

 Hi Experts,

 I am trying to boot BayleyBay CRB Rev 3 using coreboot and have no
 success so far. I have serial port (DB9) connected and using 115200 Baud
 Rate. No message comes on serial at all. Here is the procedure I followed.

 1. Pulled latest coreboot from git.
 2. Pulled following from BAY_TRAIL_FSP_KIT. The reason for doing it is
 that  BAYTRAIL_FSP.fd is not in git and .config refers to it. Also .config
 refers to ../intel/cpu/baytrail/microcode
  a) created intel directory parallel to coreboot and copied
 BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd in to
 intel/fsp/baytrail/BAYTRAIL_FSP.fd
  b) Copied *.h from Microcode folder in the kit to
 intel/cpu/baytrail/microcode.
 3. Configured the coreboot for mainboard as intel bayleybay. My .config
 is attached.
 4. Build Coreboot. Below is the prints from cbfstool.
 cmos_layout.bin0x0cmos_layout  1132
 fallback/romstage  0x4c0  stage27813
 fallback/ramstage  0x71c0 stage67431
 fallback/payload   0x17980payload  268859
 config 0x59400raw  4363
 (empty)0x5a540null 744088
 cpu_microcode_blob.bin 0x11   microcode104448
 (empty)0x129840   null 157528
 mrc.cache  0x14ffc0   (unknown)65536
 (empty)0x16   null 393112
 fsp.bin0x1bffc0

[coreboot] Coreboot with Intel FSP on BayleyBay Help

[Gailu Singh via coreboot]

Hi Experts,

I am trying to boot BayleyBay CRB Rev 3 using coreboot and have no success
so far. I have serial port (DB9) connected and using 115200 Baud Rate. No
message comes on serial at all. Here is the procedure I followed.

1. Pulled latest coreboot from git.
2. Pulled following from BAY_TRAIL_FSP_KIT. The reason for doing it is
that  BAYTRAIL_FSP.fd is not in git and .config refers to it. Also .config
refers to ../intel/cpu/baytrail/microcode
a) created intel directory parallel to coreboot and copied
BAYTRAIL_FSP_GOLD_002_10-JANUARY-2014.fd in to
intel/fsp/baytrail/BAYTRAIL_FSP.fd
b) Copied *.h from Microcode folder in the kit to
intel/cpu/baytrail/microcode.
3. Configured the coreboot for mainboard as intel bayleybay. My .config is
attached.
4. Build Coreboot. Below is the prints from cbfstool.
cmos_layout.bin0x0cmos_layout  1132
fallback/romstage  0x4c0  stage27813
fallback/ramstage  0x71c0 stage67431
fallback/payload   0x17980payload  268859
config 0x59400raw  4363
(empty)0x5a540null 744088
cpu_microcode_blob.bin 0x11   microcode104448
(empty)0x129840   null 157528
mrc.cache  0x14ffc0   (unknown)65536
(empty)0x16   null 393112
fsp.bin0x1bffc0   (unknown)229376
(empty)0x1f8000   null 31640
5. Flashed the coreboot.rom in upper 2MB (0X060-0x07F)
6. Reboot the board
7. Nothing comes on Serial Console (DB9). Also tried to connect Micro usb
cable which detects two serial ports but no output to any of them as well.
8. Before flashing coreboot.rom, 4 digit display was displaying something
on two digits and rest two were zero. Now all 4 digits stays at zeros.

Looking for help to get at least serial working so that I can get some logs
to debug it. I do not have copy of original BIOS that was there in Flash
and forgot to make a copy using programmer though I ensured that I only
touch upper 2MB. I am stuck and have no logs to debug it.

Thanks in advance.


my.config
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot