Re: [coreboot] New addendums to INTEL FSP family (ron minnich)

[Patrick Georgi]

Am 2014-05-07 23:57, schrieb Jiming Sun:

If open source community is meant for collaboration and innovation, do
you think there can be silicon specific code that only a few people
can understand, therefore whether it is open or not really does not
matter?
It matters in that it can be checked. It also matters that fixes are 
possible: I had to binary patch an Intel bug in Google's MRC binary, it 
would have been easier to find in source code (in particular because 
I've been told that the comment above the point I fixed actually said 
the right thing. I had no comments in the binary to work with).
In an open source process (with feedback loop) I could even have pushed 
that fix your way. As-is I have no idea who's still affected by that 
bug.


Also, this argument only works because the data sheets are locked down. 
I still have some vain hope that this will change at some point, too. 
:-)
The PC space thrived because/despite (pick your favorite) open data 
sheets, and the embedded space still does (see also: Quark).




One more advantage open source brings is that it provides standardized 
licensing (and this issue is more important to commercial integrators 
that want to sell their work than to private developers): Mainstream 
open source licenses are well-known, battle-tested in courts around the 
world, and companies tend to have (simple) policies on using code under 
open source terms in products.


I was recently told that the FSP license is different from the 
click-through license on www.intel.com/fsp (the one shown when trying to 
download the files).


So here's how I understand the FSP license situation: There's the 
click-through license on the web site, the FSP license (shown by the 
self-extracting archive), the intersection of both that actually applies 
to me when using FSP, and the application of these resulting terms in 
jurisdictions world-wide. And every single-letter change to the license 
in future releases restarts the license evaluation process from scratch.


This may not be a problem for Intel - it's huge so these things don't 
matter much, but please keep in mind that Intel's legal department alone 
is probably larger than many of the companies that integrate Intel's 
chips.


So custom licensing is certainly a great scheme to keep lots of lawyers 
employed. But it's not so great if you're just trying to get chipset 
initialization code (and by extension: chipsets) into the hands of 
integrators.




ARM has a Boot ROM inside their SOC, should the code inside the Boot
ROM be open? or does it matter?  
Those tend to be small, in the 4-8kb range, and focused on a single 
purpose: getting the next stage into iRAM.
For the Allwinner CPU we support, one developer in our community checked 
that the signed binary-only part (that we can't replace) is harmless.


This isn't so easy with a multi-100kb binary affecting pretty much 
everything across multiple chips.




I know this view point is not going to be popular, but Intel is trying
hard to open as much code as possible (tianocore.org [1], Linux
drivers, and Quark firmware are a few examples; I am sure more will
come in the future).  

I'm certainly looking forward to that!


We believe encapsulating basic silicon code is a good idea
regardless if it is completely open.

It sure is. But it's even better when it's open :-)


Regards,
Patrick

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

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]Thanks, that's a great explanation. Generally, we've tried to avoid
]too much hardware setup in coreboot; that's the job of the kernel.

The PIC mode interrupt routing configuration must be done by
BIOS because proprietary southbridge registers are used. The
register definitions are not even consistent across different
AMD southbridge models. An OEM BIOS does this configuration.

]I'm not really happy that we're doing all this PIC setup for one OS,
]written in assembly.

This is needed for all operating systems that support PIC mode.
For example, Ubuntu 13.10 with boot option acpi=off fails. With
the attached revised patch, it works.

]It's been quite some time since I've had to use PIC mode at all.
]
]Why can't the Kolibrios just use modern standards? And why all this
]effort for an OS written in assembly anyway?
]
]Unix v6 kernels were the same size as Kolibrios. They were written in
]C. That was 40 years ago. It's bizarre, to say the least, to be
]booting a kernel written in assembly from firmware written in C.
]
]Hence, I find it hard to believe that we want this patch. But I'm
]wrong a lot, so if I am here too, just let me know.

It is OK with me to take no action on the patch. The reason is
that the patch is here in the mailing list archives, and anyone
who really wants PIC mode will find it. The patch probably needs
sanitization and additional testing anyway.

]ron

Patch revisions:
1) With the current code, CONFIG_GENERATE_ACPI_TABLES=1 causes
the PCI interrupts to be omitted from the mptable. With the
revised patch, the mptable always includes PCI interrupts. This
solves the Ubuntu acpi=off problem of "can't find IRQ for PCI
INT A; probably buggy MP table".
2) Add PIC mode PCI interrupt values for SATA and IDE devices.
Without this, Ubuntu setup cannot read the CD-ROM.
3) Use 00 for unused PIC mode routing entries rather than 1F.
This is for consistency with the APIC mode table.

Thanks,
Scott

diff --git a/src/mainboard/asrock/e350m1/mptable.c 
b/src/mainboard/asrock/e350m1/mptable.c
index 6444be5..f45385e 100644
--- a/src/mainboard/asrock/e350m1/mptable.c
+++ b/src/mainboard/asrock/e350m1/mptable.c
@@ -35,6 +35,7 @@ extern u32 apicid_sb800;
 extern u32 bus_type[256];
 extern u32 sbdn_sb800;
 
+// SB800 interrupt routing register values: APIC mode
 u8 intr_data[] = {
   [0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */
   [0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT 
from Serial irq */
@@ -45,6 +46,20 @@ u8 intr_data[] = {
   0x10,0x11,0x12,0x13
 };
 
+// SB800 interrupt routing register values: PIC mode
+u8 intr_data_pic[] = {
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x00
+0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x08
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00,   // 0x10
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x18
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00, 0x00,   // 0x20
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x28
+0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x00,   // 0x30
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x38
+0x0A, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x40
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x48
+0x0B, 0x0A, 0x0B, 0x0A};  // 0x50
+
 static void *smp_write_config_table(void *v)
 {
   struct mp_config_table *mc;
@@ -75,6 +90,12 @@ static void *smp_write_config_table(void *v)
 outb(intr_data[byte], 0xC01);
   }
 
+  // program the SB800 PIC mode interrupt routing register values
+  for (byte = 0x0; byte < sizeof(intr_data_pic); byte ++) {
+outb(byte, 0xC00);
+outb(intr_data_pic[byte], 0xC01);
+  }
+
   /* I/O Ints:TypePolarityTrigger Bus ID   IRQAPIC ID PIN# 
*/
 #define IO_LOCAL_INT(type, intr, apicid, pin) \
   smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, 
bus_isa, (intr), (apicid), (pin));
@@ -84,12 +105,8 @@ static void *smp_write_config_table(void *v)
   /* PCI interrupts are level triggered, and are
* associated with a specific bus/device/function tuple.
*/
-#if !CONFIG_GENERATE_ACPI_TABLES
 #define PCI_INT(bus, dev, fn, pin) \
-smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 
(bus), (((dev)<<2)|(fn)), apicid_sb800, (pin))
-#else
-#define PCI_INT(bus, dev, fn, pin)
-#endif
+  smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 
(bus), (((dev)<<2)|(fn)), apicid_sb800, (pin))
 
   /* APU Internal Graphic Device*/
   PCI_INT(0x0, 0x01, 0x0, intr_data[0x02]);
@@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v)
   IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
   /* There is no extension information... */
 
+  // program interrupt line registers for legacy OS use
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B);
+  pci_write_config

Re: [coreboot] New addendums to INTEL FSP family (ron minnich)

[Jiming Sun]

Hi, Ron,

I am hesitant to respond because I am afraid that this is a philosophical
discussion that will stir a lot of strong opinions and debates.  :-)

If open source community is meant for collaboration and innovation, do you
think there can be silicon specific code that only a few people can
understand, therefore whether it is open or not really does not matter?
 Besides, if the code is meant to be part of SOC someday, does it matter
whether or not it is completely open?  For example, ARM has a Boot ROM
inside their SOC, should the code inside the Boot ROM be open? or does it
matter?

I think it is a balancing act that every silicon vendor needs to decide on.
 Some are more careful than the others.

I know some hard-core open source advocates would like to see every
software open including microcode, but from practicality perspective, if
the code cannot be modified by the community without causing adverse
effects, then it is not something that needs to be "collaborated" on; thus
open or not really does not matter.  I think you and some Google people
have provided this view in this forum sometimes in the past, Ron.

I know this view point is not going to be popular, but Intel is trying hard
to open as much code as possible (tianocore.org, Linux drivers, and Quark
firmware are a few examples; I am sure more will come in the future).

This conversation is meant for dialog, and it is my own opinions.  Just a
disclaimer: this is not Intel's official position, and I don't speak for
Intel.  :-)

After that being said, any comments about Intel's FSP are still welcome.
 We believe encapsulating basic silicon code is a good idea regardless if
it is completely open.

Thanks,
Jiming


On Mon, May 5, 2014 at 8:51 AM, ron minnich  wrote:

> Jiming, why doesn't intel just put that more open stuff up on github
> and be done with it?
>
> ron
>



-- 
Blessings,

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

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[ron minnich]

Thanks, that's a great explanation. Generally, we've tried to avoid
too much hardware setup in coreboot; that's the job of the kernel. I'm
not really happy that we're doing all this PIC setup for one OS,
written in assembly. It's been quite some time since I've had to use
PIC mode at all.

Why can't the Kolibrios just use modern standards? And why all this
effort for an OS written in assembly anyway?

Unix v6 kernels were the same size as Kolibrios. They were written in
C. That was 40 years ago. It's bizarre, to say the least, to be
booting a kernel written in assembly from firmware written in C.

Hence, I find it hard to believe that we want this patch. But I'm
wrong a lot, so if I am here too, just let me know.

ron

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

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]So, how would these changes affect other payloads?
]
]ron

The patch adds programming and one reporting
mechanism for PIC mode PCI interrupt routing for
the ASRock E350M1 board only. Without the patch,
PIC mode PCI interrupt routing is not programmed
and not reported. There are several ways an OS can
find PIC mode interrupt routing for PCI devices:
1) $PIR table
2) ACPI
3) PCI config space interrupt line registers
This change adds reporting method 3. Reporting
methods 1 and 2 are incomplete or unimplemented
for this board.

This patch programs PIC mode PCI interrupt routing
to match the OEM BIOS. Without the patch, PIC mode
PCI interrupt routing is unprogrammed. The changes
affect an OS or other code that uses PCI interrupts
in PIC mode. APIC mode is unaffected.

>From what I can remember, older mainstream operating
systems normally use the ACPI method to find PIC mode
interrupt routing. They might fall back to $PIR or 
even the config space line register method I suppose.
I see some coreboot boards support the ACPI method of
reporting (and modifying) PIC mode PCI interrupts.
However I don't see this this code in E350M1 project.
As a result, an OS such as Windows 2000 may or may not
see improvement with this patch. I didn't try it. Linux
still supports PIC mode PCI interrupt routing through
grub options. I did not test that either. It seems
interest in PIC mode interrupts has waned since
multicore processors have become popular. A limitation
of PIC mode interrupts is that all PCI interrupts are
handled by the BSP core and cannot be routed to AP cores.

I know of one application that uses PIC mode PCI 
interrupts and finds them from the config space line
register. It is the interrupt test portion of the
Broadcom b57diag utility.

For operating systems, Windows dropped PIC mode starting
with XP x64 edition if I remember correctly. XP 32-bit
defaults to APIC mode, but can be switched to PIC mode
during installation. After XP, all PIC mode is gone.
For linux, PIC mode is still supported, but the default
was switched to APIC mode several years ago. I believe 
there was a time with 32-bit Linux used PIC mode but
64-bit used APIC mode. This is from memory so I could
be a little off.

Thanks,
Scott



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

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[ron minnich]

So, how would these changes affect other payloads?

ron

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

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[Scott Duplichan]

Scott Duplichan [mailto:sc...@notabs.org] wrote:

[...]

]As for the mouse problem, I think it may be PIC interrupt
]routing related. I see our PIR table is incomplete and also
]the legacy interrupting route reporting registers in PCI
]config space are not filled in. I will look at that tomorrow.

I got the USB mouse working by setting up the PIC interrupt
routing and reporting. For now the changes are in mptable.c.
They may need to be relocated to a better place. The NIC
bus number is hard-coded at the moment. This needs fixing
if the NIC bus number can change.

KolibriOS reads PCI config offset 3C to find PIC interrupt
routing, so these must be filled in. The same values must
be programmed into the SB800 PIC mode interrupt routing
registers. In addition, a change to the legacy mode
edge-level control register setting is needed. An updated
archive is here:
http://notabs.org/coreboot/e350m1-kolibri-001.7z

An mptable.c patch is attached.

diff --git a/src/mainboard/asrock/e350m1/mptable.c 
b/src/mainboard/asrock/e350m1/mptable.c
index 6444be5..b6c5b76 100644
--- a/src/mainboard/asrock/e350m1/mptable.c
+++ b/src/mainboard/asrock/e350m1/mptable.c
@@ -35,6 +35,7 @@ extern u32 apicid_sb800;
 extern u32 bus_type[256];
 extern u32 sbdn_sb800;
 
+// SB800 interrupt routing register values: APIC mode
 u8 intr_data[] = {
   [0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */
   [0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT 
from Serial irq */
@@ -45,6 +46,16 @@ u8 intr_data[] = {
   0x10,0x11,0x12,0x13
 };
 
+// SB800 interrupt routing register values: PIC mode
+u8 intr_data_pic[] = {
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x00
+0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x08
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x10
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x18
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x20
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x28
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F};  // 0x30
+
 static void *smp_write_config_table(void *v)
 {
   struct mp_config_table *mc;
@@ -75,6 +86,12 @@ static void *smp_write_config_table(void *v)
 outb(intr_data[byte], 0xC01);
   }
 
+  // progran the SB800 PIC mode interrupt routing register values
+  for (byte = 0x0; byte < sizeof(intr_data_pic); byte ++) {
+outb(byte, 0xC00);
+outb(intr_data_pic[byte], 0xC01);
+  }
+
   /* I/O Ints:TypePolarityTrigger Bus ID   IRQAPIC ID PIN# 
*/
 #define IO_LOCAL_INT(type, intr, apicid, pin) \
   smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, 
bus_isa, (intr), (apicid), (pin));
@@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v)
   IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
   /* There is no extension information... */
 
+  // program interrupt line registers for legacy OS use
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 1)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x04, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x11, 0)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 2)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 2)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 1)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 2)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 5)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 2)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(3, PCI_DEVFN(0x00, 0)), 0x3C, 0x0B);
+
+  // program slave PIC edge-level control register
+  outb (0x0C, 0x4D1);
+
   /* Compute the checksums */
   return mptable_finalize(mc);
 }

Thanks,
Scott




legacy-interrupts.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot Digest, Vol 111, Issue 6

[Mark C. Mason]

I'm planning to build this for an ASROCK IMB-180 this week or next.

I previously had trouble booting until Wim Vervoon 
suggested that it might be dual-ranked dimms.  Replacing the dual-rank
dimm with a single rank did the trick.

I'll test both configurations with the new code and post the results.

Mark Mason
Engineering Design Team



Send coreboot mailing list submissions to
coreboot@coreboot.org

To subscribe or unsubscribe via the World Wide Web, visit
http://www.coreboot.org/mailman/listinfo/coreboot
or, via email, send a message with subject or body 'help' to
coreboot-requ...@coreboot.org

You can reach the person managing the list at
coreboot-ow...@coreboot.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of coreboot digest..."


Today's Topics:

1. Re: Flash access on ASUS F2A85 variants (Rudolf Marek)
2. Re: Flash access on ASUS F2A85 variants (Rudolf Marek)
3. Is there a payload to test SeaBIOS? BIOS mouse interface?
   (Paul Menzel)
4. [RFH] Please test latest cleanups on AGESA boards (Paul Menzel)


--

Message: 1
Date: Sun, 04 May 2014 13:56:03 +0200
From: Rudolf Marek 
To: coreboot@coreboot.org
Cc: flash...@flashrom.org
Subject: Re: [coreboot] Flash access on ASUS F2A85 variants
Message-ID: <53662ad3.3030...@assembler.cz>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hi Stefan,
  > I could not find any details but the error message one receives:

"ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full
access."

Found ITE Super I/O, ID 0x8603 on port 0x2e
Found chipset "AMD FCH" with PCI ID 1022:780e. Enabling flash write... SPI base
address is at 0xfec1
Hudson-2/3/4 detected.
SpiRomEnable=1, PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1
(0x6f4c2105) SpiArbEnable=1, SpiAccessMacRomEn=1, SpiHostAccessRomEn=0,
ArbWaitCount=7, SpiBridgeDisable=1, SpiBusy=0
ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full access.


If I read the documentation of SpiHostAccessRomEn correctly then it
should not bother us at all. It indicates it the ethernet firmware can
access the host partition of the flash chip. If however the other bit
(SpiAccessMacRomEn) is reset to 0 then we indeed have a problem.

Yes I tried to disable the check and got following (I was testing BIOS version 
6502)

Found Winbond flash chip "W25Q64.V" (8192 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
coreboot last image size (not ROM size) is 8388608 bytes.
Manufacturer: ASUS
Mainboard ID: F2A85-M
Reading old flash chip contents... FIFO pointer corruption! Pointer is 0, 
wanted 3
Something else is accessing the flash chip and causes random corruption.
Please stop all applications and drivers and IPMI which access the flash chip.
FAILED.

Can someone please send me the verbose output of flashrom to confirm
which one it is? And I am also looking for testers with these boards,
because I think the abort on SpiHostAccessRomEn is a bug in flashrom.

Hm looks like something will happen, becuase it does not work. This board has
external ethernet chip. So the only master accessing the chip could be USB 3.0
firmware. But, this works fine with coreboot and also removing the XHCI drivers
did not help.

Maybe some protection bits are set elsewhere.

This is dump of MMIO space:

hexdump -C a.bin
  05 21 4c 6f 00 00 00 00  00 06 00 00 00 70 00 02  |.!Lo.p..|
0010  06 20 04 04 06 04 9f 05  03 0b 0a 02 ff 88 00 3b  |. .;|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*

It looks like (look to 48751 Rev 3.00 - May 30, 2013 BKDG for AMD Family 16h
Models 00h-0Fh Processors)

SPIx1D Alt_SPI_CS  0x88

SpiProtectEn0. IF (SPIx1D[SpiProtectLock]==1) THEN Read-only. ELSE Read-write.
ENDIF.

Reset: 0. 1=Enable SPI read/write protection ranges specified by
D14F3x[5C,58,54,50].

Funny is that the SPiProtectLock is not set to 1

00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11)
00: 22 10 0e 78 0f 00 20 02 11 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 85
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 04 00 00 00 d5 ff 03 ff 07 ff 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And all protection ranges are 0 anyway...

60: 00 00 00 00 30 02 00 00 00 00 0f 00 00 ff ff ff
70: 67 45 23 00 00 00 00 00 9c 00 00 00 05 0b 00 00
80: 08 00 03 a8 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 c1 fe 2f 01 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 e9 45 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 17 00 82 ff
d0: 02 00 0

Re: [coreboot] #201: Error building coreboot for Samsung Exynos5 Google Snow

[coreboot]

#201: Error building coreboot for Samsung Exynos5 Google Snow
---+-
Reporter:  Pete   | Owner:  stepan@…
Type:  defect  |Status:  new
Priority:  major   | Milestone:
   Component:  coreboot|Resolution:
Keywords:  |  Dependencies:
Patch Status:  there is no patch   |
---+-

Comment (by ratnikov.ev@…):

 It seems you have undefined CONFIG_BOOTMODE_STRAPS.
 Search for CONFIG_BOOTMODE_STRAPS in .config in coreboot directory.
 grep CONFIG_BOOTMODE_STRAPS .config

 The result should be smth like this:
 CONFIG_BOOTMODE_STRAPS=y

--
Ticket URL: 
coreboot 

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