[coreboot] Re: Extended IvyBridge CPU configuration

[Andrey Korolyov]

>
> Do these crashes/freezes look like
> https://ticket.coreboot.org/issues/121?


Sorry for potential thread hijack, did anyone observed vendor's clock
generator setup on these models? I remember seeing exactly the same
behavior with z61t when I borrowed clock generator setup from neighbor
model, everything was fine until OS was booted and idled to C3. Though CPU
are quite different, the problem might lie in the same area :)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Atom C2000 SOC - Do they lack Intel ME?

[Andrey Korolyov]

> investigating a bit with intelmetool and mecleaner non of them could
> found any sign for an ME-region in this board.. so i asking myself if
> there is no ME/SPS on the intel C2000 socs, what would make them a DAMN
> SEXY platform to port coreboot too.
>

I believe that the Intel FSP (firmware support package) has Coreboot
support for c2000 for many years, though it has never been upstreamed.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] ACPI error booting Windows

[Andrey Korolyov]

On Thu, Apr 26, 2018 at 1:59 AM, Alex Feinman  wrote:
> I've built a Coreboot image (from the HEAD) for my custom Kaby Lake board.
> The build uses Chrome EC and is based on kblrvp3 mainboard configuration.
> Linux runs fine, but when I attempt to install Windows 10 (or boot a
> preinstalled Windows image from USB) I instantly get ACPI_BIOS_ERROR
> (0xC0A5). There is a Microsoft document that provides a large amount of
> possible reasons for this error, however I can't even narrow it down because
> cleverly Windows 10 no longer prints the bug check parameters, at least not
> in this case.
>
> I would appreciate some pointers if possible.
>

If you are able to obtain debug build of the failing O/S (or earlier
version, if it runs on KBL), it would be possible to find a clue why
exactly Windows ACPI parser is nagging.

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

Re: [coreboot] ast2400 / ast2500

[Andrey Korolyov]

> 4. Using same firmware on x86 and bmc means, what ever infra we develop for
> board bring up and ops (as coreboot payload) works on both.
> 5. Same thing for secure booting.
>

While I borrow not much expertise there, these points are applicable
at this moment only if you are planning to run UEFI on both ARM and
x86 devices at once, all other things are pretty less generic and not
replaceable. UEFI is mentioned, but it could be u-boot or something
else which works as cross-platform bootloader and could be inserted
within a boot sequence stack on both IMC and host - on certain
hardware you would manage to get identical software stack on different
architectures for a small effort but for most times this is not true
and significant work needs to be done.

The second major point is a lack of host board signaling unification,
you would not even have a guarantee that same BMC-side GPIO pins are
responsible for same action types across boards of a single vendor
(true for generations of Supermicro removable BMCs), so each board or
board family would probably need additional work to create signaling
descriptions. I`m not sure if coreboot is an appropriate replacement
for OpenBMC efforts right there, as it was said before in this thread
because real positive outcome is barely imaginable from this
description.

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

Re: [coreboot] Recommendation for Flashing Clips / mass order

[Andrey Korolyov]

On Wed, Oct 18, 2017 at 3:35 PM, Peter Stuge  wrote:
> [799] via coreboot wrote:
>> Do you have any recommendations if it makes sense to invest a bit
>> more budget and buy a more expensive clip or will the quality be
>> the same?
>>
>> The Pomona 5250 Clip:
>> https://www.tme.eu/gb/details/pom-5250/test-clips/pomona/5250/
>
> I have no idea about the clip you used before, but the Pomona 5250
> plastic compound is not very hard and contacts are not very robust,
> so after some (ab)use it will certainly also wear out.
>
> These clips are test tools for occasional use, not development tools.
>
> You can obvioulys use them for development anyway, but keep in mind
> what they are designed for, so that you have the right expectations.
>

Pogo-pin adapters are little bit more robust but they would require
holding arm and they require precise pin positioning while clip
grabbers do most of self-adjustment job. AFAICS SOIC-8 variants are
available on eBay at this moment.

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

Re: [coreboot] FYI: Reverse Engineering x86 Processor Microcode

[Andrey Korolyov]

> In this paper, we reverse engineer the microcode semantics
> and inner workings of its update mechanism of conventional
> COTS CPUs on the example of AMD’s K8 and
> K10 microarchitectures.
>

Still wondering what was engineering reasons for these families behind
such a practice as non-verified microcode updates. Also these families
had very interesting uop-update behavior that could be called 'mu-ops
cache', where under certain conditions malicious micro-ops could be
cached forever, even if the 'good' update has been loaded afterwards.

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

Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC

[Andrey Korolyov]

On Fri, Aug 4, 2017 at 4:21 PM, Аладышев Константин  wrote:
> Does a windows driver (for host PC where I want to see coreboot log) exist 
> for this solution with BeagleBone?

If you are asking about bbb connectivity, there is a 'real' ethernet
PHY on chip opposed to RPI where dwc2 breaks usb-connected ethernet
when enabled, for these cases I may recommend to either set up
cdc-ether (available on Windows as well), use UART on board with SLIP
or just use UART with tty. Non-wireless RPI Zero, for example, may
suffer from lack of available ports being set up as dongle but still
usable as remote log viewers. For debugging purposes involving gdb
something like bbb with separate ethernet PHY is strongly preferred.

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

Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC

[Andrey Korolyov]

On Fri, Aug 4, 2017 at 3:14 PM, Аладышев Константин  wrote:
> What is the easiest and most stable way to do debug through EHCI USB port
> instead of COM port? Is there any EHCI dongles on market that supports both
> Linux and Windows as a host PC?
>

The answer varies depending on your exact needs. If you are targeting
only on coreboot log obtainment, the RaspberryPI/BeagleBone with dwc2
is probably cheapest cross-platform thing to use. For kgdb, this setup
*should* work, but this would add another level of complexity due to
gdbserver spatial localization :) I`ve never tried working with
combination of the RPI and usb-ip to pass dwc2 port over cdc-ethernet
connection, this is the only major difference between 'real' dongle
and cheap board-based setup.

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

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

On Sun, Jul 9, 2017 at 2:56 AM, Andrey Korolyov <and...@xdel.ru> wrote:
>>
>> I'd expect the clockgen to be the culprit too. But this C-state number
>> could be a typo and also be the reason for your trouble (though, I'd
>> wonder why it works on the T60). This number is used to map ACPI C-state
>> semantics to the states presented in _CST. ACPI knows three C states and
>> those rarely match the actual C states of the hardware. Basically, a 3
>> instead of a 2 tells ACPI to flush caches before entering this state.
>> Also, ACPI C3 is to be avoided if bus-master activity is expected.
>>
>
> It turned out to be again very simple thing: by some reason yet to be
> found, write within ics954309_init could succeed only for first eight
> data addresses on this board, it would ultimately return nothing for
> higher data addresses within 0x69 so boot which is trying to write
> smbus-type-width block will hang as it has been reported earlier.
> Magically, cutting chip initialization in this crude way appears to
> work against C3 behavour. I would take a look on the exact PLL chip
> model upon next disassembly and also would dump i2c data with vendor
> BIOS to get this properly (vendor BIOS does prevent access to clock
> generator bits, as well to SPD data, just to mention).
>
> Forgot to mention that I`ve of course tried straightforward _CST fix
> before, with no success at all. Someone with working T60/X60 could try
> to check 'fixed' cst_entries ordering in mainboard.c and post the
> results, right now all mine X60s are far away from the working state.

As expected, vendor bios sets up the PLL with completely different
parameters, though setting lower eight bytes from x60-based setup was
'good enough' to make C3 work. As vendor does not allow allow clockgen
bits to be accessed programmatically, most complex part was to solder
two unshielded wires on neighbor pins of the MLF64 package. There are
a few issues remaining (certain regression with i915 consolefb while
using binary vgabios on newest kernels and interrupt assignment issue
with iw3945 in Win7), I would resolve them before pushing the board
supporting code.

Thanks again for useful hints!

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

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

>
> I'd expect the clockgen to be the culprit too. But this C-state number
> could be a typo and also be the reason for your trouble (though, I'd
> wonder why it works on the T60). This number is used to map ACPI C-state
> semantics to the states presented in _CST. ACPI knows three C states and
> those rarely match the actual C states of the hardware. Basically, a 3
> instead of a 2 tells ACPI to flush caches before entering this state.
> Also, ACPI C3 is to be avoided if bus-master activity is expected.
>

It turned out to be again very simple thing: by some reason yet to be
found, write within ics954309_init could succeed only for first eight
data addresses on this board, it would ultimately return nothing for
higher data addresses within 0x69 so boot which is trying to write
smbus-type-width block will hang as it has been reported earlier.
Magically, cutting chip initialization in this crude way appears to
work against C3 behavour. I would take a look on the exact PLL chip
model upon next disassembly and also would dump i2c data with vendor
BIOS to get this properly (vendor BIOS does prevent access to clock
generator bits, as well to SPD data, just to mention).

Forgot to mention that I`ve of course tried straightforward _CST fix
before, with no success at all. Someone with working T60/X60 could try
to check 'fixed' cst_entries ordering in mainboard.c and post the
results, right now all mine X60s are far away from the working state.

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

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

> From git logs it looks like configuring the clockgen was needed for the
> x60/t60 port for deeper c-states to work. I'd try to dump the clockgen
> configuration on smbus with block operations ('i2cdump #smbus 0x69 s')
> and configure it using block write operations either in romstage (look
> at thinkpad x201 romstage.c) or in ramstage like is done for the x60
> (might need some tweaking).
>

I see, thanks. Previously write to i2c-0/0x69 has been stuck at
romstage, so I kicked it out without looking at the log and therefore
not getting reasons why is was there at first place, Now it is obvious
that C3 is not working correctly without fixing up clock generator.
Previously, also, I blamed incorrect _CST package generation from
copy-paste from T60 for a moment - state descriptions has been
enumerated as 0x1/0x2/0x2 while vendor BIOS has sequentially
enumerated descriptions, still wondering what was the reason to do so.

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

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

On Thu, Jul 6, 2017 at 8:47 PM, Zoran Stojsavljevic
 wrote:
>> The simplest and most obvious explanation turned out to be true, the
>> register is encoded as multiples of 16MiB.
>
> You say (in other words) the following: Coreboot prepares the whole
> populated 32 bit (physical layout) DRAM2 space for some OS, don't you?
>
> TOLUD = d000h, and the next 256MiB are reserved for MM PCI + MM PCIe
> (Yonah is Y2006, so PCIe came in Y2004), so somewhere above there will be
> PCI configuration space (minimum 64K x 256 = 16MiB, maybe more, since some
> ports are PCIe), Then HSEG, after boot FLASH.
> ___
>
> Well, Andrey, if Nico is right, you have reduced options... Dracut stays as
> one of very seldom options to try, don't you agree?
>
> Zoran
>
> On Thu, Jul 6, 2017 at 5:44 PM, Nico Huber  wrote:
>>
>> On 06.07.2017 07:20, Zoran Stojsavljevic wrote:
>> > Top of Low Usable RAM 00d0h??? Any explanation for that?
>>
>> The simplest and most obvious explanation turned out to be true, the
>> register is encoded as multiples of 16MiB.
>>
>> Nico
>
>


Thanks everyone, the explanation was pretty simple - the _CST package
generated for model 6ex does not fit this exact CPU (6e8), as soon as
stuff under CONFIG_ACPI_PROCESSOR has been loaded, system dies,
sometimes with visible screen mess. Workaround for now is to use
processor.nocst=1 and for Windows to use UP boot.

For now, I may simply disable the _CST entirely leaving only frequency
scaling options, though this is far from being appropriate for the
public port.

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

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

On Thu, Jul 6, 2017 at 8:20 AM, Zoran Stojsavljevic
 wrote:
> OK, both Andrjusas,
>
> I am a bit ignorant, and I read beginning of the Coreboot log:
>
> DIMM 0 side 0 = 1024 MB
> DIMM 0 side 1 = 1024 MB
> DIMM 2 side 0 = 1024 MB
> DIMM 2 side 1 = 1024 MB
> tRFC = 43 cycles
> Setting Graphics Frequency...
> FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz
> Setting Memory Frequency... CLKCFG = 0x00010023, CLKCFG = 0x00010043, ok
> Setting mode of operation for memory channels...Dual Channel Interleaved.
> Programming Clock Crossing...MEM=667 FSB=667... ok
> Setting RAM size...
> C0DRB = 0x40404020
> C1DRB = 0x40404020
> TOLUD = 0x00d0 <<==???
>
> 4GB (two channel) memory, in two slots out of 4... ?!
>
> Top of Low Usable RAM 00d0h??? Any explanation for that?
@Zoran

Thanks, that could be the point, though it seem to be same low for
X/T60 [0]. I would check if reading PCI space in Linux would result to
same small address and may be this is the point (also I could quickly
run completely headless kernel to verify that).

>
> Andy (Korolev),
>
> Did you manage to get to Linux emergency mode called Dracut?

I think that you meant dracut-produced initrd and try it against SMP
kernel, right? If I could get your idea, you are possibly suggesting
to cut off every device from being initalized except SuperIO, get to
ramdisk and try to work things out from there? I didn`t tried this
yet, mainly because I don`t want to spend much time with blind efforts
on very old laptop whose support has almost no real value... If I am
wrong, please explain what you`ve suggested in there.

>
> So you are after memory contents? Freeze DIMMS, turn off memory scrambling
> and flash firmware that dumps memory contents. In essence, cold boot attack.

@Andrey
That`s what I meant under 'spending few days', getting memory access
during both cold-boot run and DMA-assisted run is a matter of tens of
minutes, but the analysis of the dump would take much more time. The
main problem is that I am losing dynamic picture for memory contents
if I would do only post-mortem analysis and (with cold-boot attack)
I`ll lose small portion of the memory state anyway, due to
bootloader`s needs to initialize PCI devices (though I could imagine
very slow and boring transfer using CAR and USB debug port and there`s
bit of code need to be written for that). The fastest way to get close
to the point of failure and see at least a dynamic stuff is, probably,
a timer-based non-preemptible hack within ieee1394 driver which would
literally freeze system to allow me to take snapshots without risk of
hitting crash in the middle. Anyway, this closes down to analysis of
what is going on within the dump and with Linux mm it`s not an easy
task if you are not searching for something specific like LUKS key :)

0. https://mail.coreboot.org/pipermail/coreboot/2014-October/078752.html

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

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

On Thu, Jul 6, 2017 at 12:27 AM, Nico Huber  wrote:
> I'd start with examining the coreboot console log. Are there resource
> conflicts? Are all APs initialized? Was the microcode updated for all
> of them? etc... If you don't have it already, you can grab the log from
> your running non-smp OS with `cbmem -c` (see util/cbmem/ in the coreboot
> tree). Feel free to attach it, if you want somebody else to look through
> it.
>

Unfortunately nothing obvious pops in the log, at least for my sight.
Please don`t mind invalid PNP mappings from both SIOs and
corresponding Linux warnings, these are leftovers from using t60
skeleton. I am attaching combined log from coreboot, SeaBIOS and Linux
with UP kernel for the reference.
coreboot-4.6-dirty Sun Apr 30 23:08:47 UTC 2017 romstage starting...

Mobile Intel(R) 82945GM/GME Express Chipset
(G)MCH capable of up to FSB 800 MHz
(G)MCH capable of up to DDR2-667
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Waiting for MCHBAR to come up...ok
PM1_CNT: 1c00
SMBus controller enabled.
Setting up RAM controller.
This mainboard supports Dual Channel Operation.
DDR II Channel 0 Socket 0: x8DDS
DDR II Channel 0 Socket 1: N/A
DDR II Channel 1 Socket 0: x8DDS
DDR II Channel 1 Socket 1: N/A
Memory will be driven at 667MHz with CAS=5 clocks
tRAS = 15 cycles
tRP = 5 cycles
tRCD = 5 cycles
Refresh: 7.8us
tWR = 5 cycles
DIMM 0 side 0 = 1024 MB
DIMM 0 side 1 = 1024 MB
DIMM 2 side 0 = 1024 MB
DIMM 2 side 1 = 1024 MB
tRFC = 43 cycles
Setting Graphics Frequency...
FSB: 667 MHz Voltage: 1.05V Render: 250MHz Display: 200MHz
Setting Memory Frequency... CLKCFG = 0x00010023, CLKCFG = 0x00010043, ok
Setting mode of operation for memory channels...Dual Channel Interleaved.
Programming Clock Crossing...MEM=667 FSB=667... ok
Setting RAM size...
C0DRB = 0x40404020
C1DRB = 0x40404020
TOLUD = 0x00d0
Setting row attributes...
C0DRA = 0x0033
C1DRA = 0x0033
DIMM0 has 8 banks.
DIMM2 has 8 banks.
one dimm per channel config..
Initializing System Memory IO...
Programming Dual Channel RCOMP
Table Index: 18
Programming DLL Timings...
Enabling System Memory IO...
jedec enable sequence: bank 0
jedec enable sequence: bank 1
bankaddr from bank size of rank 0
jedec enable sequence: bank 4
jedec enable sequence: bank 5
bankaddr from bank size of rank 4
receive_enable_autoconfig() for channel 0
  find_strobes_low()
set_receive_enable() medium=0x3, coarse=0x5
  find_strobes_edge()
set_receive_enable() medium=0x3, coarse=0x5
  add_quarter_clock() mediumcoarse=17 fine=36
  find_preamble()
set_receive_enable() medium=0x3, coarse=0x4
set_receive_enable() medium=0x3, coarse=0x3
  add_quarter_clock() mediumcoarse=0f fine=b6
set_receive_enable() medium=0x1, coarse=0x4
  normalize()
receive_enable_autoconfig() for channel 1
  find_strobes_low()
set_receive_enable() medium=0x3, coarse=0x5
set_receive_enable() medium=0x1, coarse=0x5
  find_strobes_edge()
set_receive_enable() medium=0x1, coarse=0x5
set_receive_enable() medium=0x3, coarse=0x5
  add_quarter_clock() mediumcoarse=17 fine=10
  find_preamble()
set_receive_enable() medium=0x3, coarse=0x4
set_receive_enable() medium=0x3, coarse=0x3
  add_quarter_clock() mediumcoarse=0f fine=90
set_receive_enable() medium=0x1, coarse=0x4
  normalize()
RAM initialization finished.
Setting up Egress Port RCRB
Loading port arbitration table ...ok
Wait for VC1 negotiation ...ok
Setting up DMI RCRB
Wait for VC1 negotiation ...done..
Internal graphics: enabled
Waiting for DMI hardware...ok
Enabling PCI Express x16 Link
SLOTSTS: 
Disabling PCI Express x16 Link
Wait for link to enter detect state... ok
Setting up Root Complex Topology
CBMEM:
IMD: root @ cf7ff000 254 entries.
IMD: root @ cf7fec00 62 entries.
MTRR Range: Start=ffe0 End=0 (Size 20)
MTRR Range: Start=0 End=100 (Size 100)
MTRR Range: Start=cf40 End=cf80 (Size 40)
MTRR Range: Start=cf00 End=cf40 (Size 40)
CBFS: 'Master Header Locator' located CBFS at [100:1fffc0)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 32b80 size 11828
Decompressing stage fallback/ramstage @ 0xcf7a0fc0 (227312 bytes)
Loading module at cf7a1000 with entry cf7a1000. filesize: 0x2ccc8 memsize: 0x377b0
Processing 2332 relocs. Offset value of 0xcf6a1000


coreboot-4.6-dirty Sun Apr 30 23:08:47 UTC 2017 ramstage starting...
Normal boot.
BS: BS_PRE_DEVICE times (us): entry 0 run 2 exit 0
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 3 exit 0
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
DOMAIN: : enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:02.0: enabled 1
PCI: 00:02.1: enabled 1
PCI: 00:1b.0: enabled 1
PCI: 00:1c.0: enabled 1
PCI: 00:1c.1: enabled 1
PCI: 00:1c.2: enabled 1
PCI: 00:1c.3: enabled 1
PCI: 00:1d.0: enabled 1
PCI: 00:1d.1: enabled 1
PCI: 00:1d.2: enabled 1
PCI: 

Re: [coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

> [1] Platform T2400/i945 ->
> http://ark.intel.com/products/27235/Intel-Core-Duo-Processor-T2400-2M-Cache-1_83-GHz-667-MHz-FSB
> ... Am I correct?

Yup.
> [2] What is GEODE in this context? 500 Mhz i486AMD Geode processor (Single
> HW threaded, one core, no HT)?

Just a remark about how I got warning that late - I went through usual
test routines on a non-SMP kernel because my basic test image does use
it by default, primarily it is designated to a DB800 dev board.
> [3] And what are the Linux distro and the distro kernel you are using
> (version and size ? 32 : 64, please)?

This is 32-bit CPU, so answer is obvious :) I think that I`m hitting
the problem independent of the kernel version I am running, but I`ve
tried few stable versions from 3.2 to 4.9 without spotting any
noticeable difference. Windows hangs as well as soon as it finishes
driver loading procedure, this is visible from safe mode.
> [4] Am I reading that you are not able to produce dmesg? If YES, please,
> post failing dmesg here!

Nope, this is not the case. May be initial text is not clear enough,
but I`m getting a 'dead' hang of the board itself - I mentioned that
SMI handler is not chewing anything after this point, all the
peripherals seem to be pretty dead as well, at least I was unable to
see anything past the failure via usb debug and serial console.
> [5] I assume that you have SeaBIOS as payload, don't you?
> [6] Are you booting via GRUB?

Yes, I am using SeaBIOS and GRUB for local boots. I could share a
successful non-SMP dmesg as well as part of SMP dmesg before hang, but
there are virtually zero points to take on. May be the only difference
between dmesg contents over stock one aside complaining about missing
hard-coded battery slot is the snip below, just because I didn`t fixed
this yet (specific to native gfxinit, but board also happily hangs
with stock vbios and smp kernel, just for the case)

[drm] failed to find VBIOS tables
vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm] initialized overlay support
[drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
>
>> - sometimes video memory is corrupted, screen displaying periodical
>> flickering pattern
>> (even if almost all late-stage linux drivers are disabled),
>
> [7] Are you able to produce Xorg.0.log messages? If yes, could you post 'em
> here?

I honestly don`t think that this is the case - for non-SMP boot, the
Xorg log absolutely resembles everything that I`m getting with vendor
bios and for SMP boot system hangs a bit earlier. Video memory
garbling is not a persistent but rather floating effect, forgot to
mention that.
>
> I have also other ideas how to debug this all, but lets go with these for
> starters, shall we??? ;-)

I thought about hidden interrupt storm which could possibly manifest
itself in that way, but I`ve never seen IS being *that* bad. Honestly
I`m out of ideas why turning on SMP results in a horrible memory
corruption/overlap, SMP-ed Memtest was able to pass few rounds without
any warning. Even if all platform and peripheral drivers blacklisted,
the problem still shows up, so it does not limit itself, at least
obviously, to one single device whose DMA region(s) splats over areas
where it shouldn`t be.

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

[coreboot] x86: best approach to debug consumer hardware?

[Andrey Korolyov]

Hi,

since I`ve got em100 few days ago, I decided to test it against one of
my x86 devices and try to put coreboot on it at once. The selection
was Z61m (T2400 CD/i945/82801). After fixing few things in i945 code
borrowed from t60, I noticed severe problem when I tried to use SMP
kernel, because most times I try stuff against non-smp i486 which is
common denominator for Geode. It looks like that all SMP boot-ups will
hang quite soon, just after a few seconds after jumping into
initrd/driver initialization stage.

There are few points:
 - sometimes video memory is corrupted, screen displaying periodical
flickering pattern (even if almost all late-stage linux drivers are
disabled),
 - the hang itself is not accompanied by any SMI assertion or event
otherwise visible in the coreboot log,
 - kernel also is unable to produce any kind of backtrace over all
(easily) available channels,
 - usb port with an active usb stick may become unusable until entire
device is power-cycled with external switch,
 - SMI poweroff handler is not responsive after the failure event.

The fourth/fifth points has very high likeness for the fact that the
regular kernel debugging would not help at all and I hardly imagine
myself spending few more days to manage firewire memory 'sniffer' to
work, though this method has highest successful potential among other
approaches, excluding (unavaiable due to pricing of the counterparting
LA) memory interceptor. What could be a suggestion to move on with
least effort at this point?

Thanks.

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

[coreboot] Out-of spec EC control codes

[Andrey Korolyov]

Hi,

while doing LPC examination for keyboard actions on Getac laptop few
weeks ago, I noticed that the controlling sequence for backlight step
has been put outside of an ACPI spec for no visible reason (therefore
it is not possible to control backlight using unmodified ectool, for
example).

Sample step control sequence when Fn+Backlightxx is pressed looks like
following:

CT   DT
0x80 0x17 // Reading 0x17 for current level, twice (why???)
0x80 0x17
0x86 0xff 0xf9 0x7f // Ok, now that`s weird, Why OEM-ing control
sequences is necessary in there?
0x80 0x17 // Reading updated value

I wonder if some people in list have touched simular kind of
development, is there any real reason behind using non-standard
control commands for EC? There *are* counterexamples in coreboot tree,
but they are using very extensive control command set and stepping
outside of spec looks reasonable. In my case, controller seemingly
uses just as few handles as the spec suggests, but omits standard ones
in favor of 0x85/0x86, could be there any practical reason for doing
this?

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

Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)

[Andrey Korolyov]

> Not sure if I interpret "within an entire family" correctly, but the
> online specs for the 820QM are clearly wrong

Yes, this statement is very blurry - I thought about artificial memory
limitations like ones in C2000 Atom server series - there are almost
identical models (C2530 and C2550 for example) which has different
maximum amount of RAM. For Clarksfield web part of ARK is obviously
wrong, as official third-parties like Lenovo stated 16G support, but
datasheet is no better:

"One or two channels of DDR3 memory with a maximum of one SO-DIMM per channel"

which is certainly not related to widely used Clarksfield four-DIMM setup.

> Definitely not worth it for this 7+ year old hardware (unless someone
> has a suitable scope and the knowledge already... the best scope I have
> access to is an Agilent MSO6104A but no idea where to even start - and
> no interposer obviously) but you seem to imply that the 8GB problem is
> an analogous one... do you think about the 16 GB problem as well?
>

I don`t think of this problem as of 'analogous', there`s simply not
enough data to understand the problem. I have 720QM with 32G, but this
laptop hardly could be called portable, perspective of having >8G of
RAM in Arrandale laptops is brilliant. Regarding issue analysis, I
suppose nothing much could be done with *scopes*, because data
exchange violation seem not to be strict and/or large and it is
impossible to catch this one in a sane time without proper bus
analyzer. Speaking for Agilents, only 1690x chassis are capable to
work with analyzer blades suitable for DDR3 analyzer, but they are
somewhat pricey.

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

Re: [coreboot] 8 GB DIMMs on Nehalem (Arrandale)

[Andrey Korolyov]

> The chipset in the (QC version of the) W510 is actually exactly the same as
> in the X201 and T410s: Ibex Peak.
>

But CPUs we are looking at *are* actually different - scale-down could
mean an exposure of a previously unaccounted design issue which
actually prevented 32nm CPU 'upgrade' to work reliably with >8G of
RAM... And AFAIR nobody ever reported to break official memory limits
within an entire family, I`ll be happy to know that this is not true.

Just to add .02c - DDR3 interposers from tek/futureplus are appearing
on ebay relatively frequently and for moderate price, so if someone
has will to spend some effort on this task, the analyzer coupled with
interposer could provide great help, with regard to unstable behavior
with a single 8G DIMM.

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

Re: [coreboot] Offtopic - tapping TxFP packages with flat cables?

[Andrey Korolyov]

>
> Buy another chip, make a breakout board, remove onboard chip, connect
> probes to breakout board, connect breakout board to mainboard.
>

Thanks, but this is a pretty time-consuming method if I need to tap
four consecutive legs out of one hundred. Also BBs adding extra
crosstalk which could lead to erroneous behavior even for tens of
megahertz when scheme is coupled with high-impedance logic analyzer.



>
> This is documented behavior of the chipset.
>
> "SLP S4# Assertion Width Violation" is the hardware telling the
> firmware (you) that the hardware has not been in S4# long enough,
> and simply isn't ready just yet.
>
> Chipset docs specify how long firmware should wait, before it can try
> to power the platform up again.

Awesome, thank you, I never had a single thought that this could be a
documented behavior - EEPROM read stage takes a plenty of time
(something around sixty milliseconds) and I`ve automatically threw all
time-related chipset initialization stuff out of scope.

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

[coreboot] Offtopic - tapping TxFP packages with flat cables?

[Andrey Korolyov]

Hi,

probably several people in the list met the same struggle to tap 0.5mm
pitched packages (almost all SIOs and at least all H8/300 chips) - how
it could be done without using micromanipulator or sticking flat cable
with an equal pitch size on side of a chip? While it is possible to
solder a single wire with regular equipment on a leg, doing the same
for neighboring legs is virtually impossible, so the only somewhat
reliable alternative is to use small LVDS cable.

As an example, I may consider Getac/Mitac A790 [0] - it is based on
i945, so initial porting has been done with very small effort, but
after fixing ACPI tables and polishing a rest of the port I`ve stuck
with EC-related issue where raminit run after first poweron fails
(device turns off within a half of second):

PM1_CNT: 1c00
SMBus controller enabled.
Setting up RAM controller.
This mainboard supports Dual Channel Operation.
DDR II Channel 0 Socket 0: x8DS
DDR II Channel 0 Socket 1: N/A
DDR II Channel 1 Socket 0: x8DS
DDR II Channel 1 Socket 1: N/A
SLP S4# Assertion Width Violation.
Reset required.

when second power-on goes just well (e.g. every second power-on
succeeds). I have made a dump of entire interaction between the EEPROM
and south bridge, but it seems that this idea was bad because it is
based on an assumption that the EEPROM accesses would not be shadowed
after first read. At this moment I am absolutely sure that this weird
behavior is caused by EC, but laptop`s construction does not allow any
kind of access to LPC pins with a regular soldering or top-hat socket
(which is unavailable anyway).

Any suggestions on how tapping of a TFP-100 and simular packages
should be done are greatly welcomed.

[0]. The device itself is pretty interesting, it does contain *three*
SIO chips, W83628F/W83629D and SIO10N268 and detachable PCI bridge in
the extension dock.

Thanks!

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

Re: [coreboot] power controller/serial port mux

[Andrey Korolyov]

> With Schuko plug this ethernet controlled power strip is pretty nice
> (they also have a USB-controlled variant)
> http://energenie.com/item.aspx?id=7557=en
>

I use controllable APC rack outlet for this purpose, they cost almost
nothing, like <5$/socket for used APC AP7957 from ebay.

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

Re: [coreboot] Nehalem not booting with two ram sticks

[Andrey Korolyov]

On Tue, Nov 22, 2016 at 3:35 PM, Federico Amedeo Izzo
 wrote:
> Hello,
>
> I have a problem with my ThinkPad X201 (nehalem)
>
> I have two sticks of Samsung 4GB 2Rx8 PC3-10600S (1333MHz)
> When i use only one of them in one of the two slots, the computer boots
> fine,
> but when i use both of them in the two slots, the computer doesn't boot,
> the screen doens't even turn on.
>
> I dumped the logs via EHCI but they seem normal, in fact both the
> working combination and the broken one make 34 or so iterations of
> Timings dumping,
> but then the working conf. start booting, while the broken one freezes
> without printing error messages on the EHCI.
>
> I have tried adding more `printk` calls in
> `src/northbridge/intel/nehalem/raminit.c`
> but ended up in a brick, probably because i slowed down the
> initialization too much.
>
> I attach three EHCI logs:
> - the first stick in the first slot: working
> - the second stick in the second slot: working
> - both stick inserted: not working
>
> Also i find difficult to understand the code in `raminit.c` of nehalem
> because it lacks almost completely of comments, with respect to
> raminit.c of sandybridge for example.

I`ve seen simular issue on my x201(t), the workaround could be a
hardcoded SPD limitation from above for memory clock speed. Using
different memory sticks (Kingstons rather than Samsungs) is 'solving'
problem as well. I`ve not paid necessary attention to the problem at
the time, so if you have some spare cycles, you could possibly want to
figure out right SPD settings. The simplest way is to use decode-dimms
from i2c-tools or CPU-z and to compare vendor`s settings with single-
and dual-dimm setups and coreboot`s with a single dimm.

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

Re: [coreboot] Compile coreboot 4.3 for Pc Engines Alix2d3

[Andrey Korolyov]

On Mon, Mar 7, 2016 at 2:19 AM, Reto Rayen  wrote:
> Hi guys
>
>
>
> I tried now with the latest coreboot 4.3 to run the coreboot bios on a
> Alix2d3. But it always hangs after: «* DRAM Controller init done.». After
> this i do not see any further Output. Does anyone of you have a an idea what
> could be the issue?
>
>
>
> I added a ipxe Rom Image to the coreboot Rom. The layout is as follows:
>
>
>
> Name   Offset Type Size
>
> cbfs master header 0x0cbfs header  32
>
> fallback/romstage  0x80   stage12404
>
> fallback/ramstage  0x3180 stage69972
>
> fallback/payload   0x14340payload  60882
>
> pci1106,3053.rom   0x23180raw  81920
>
> config 0x37200raw  428
>
> revision   0x37400raw  602
>
> payload_config 0x376c0raw  1563
>
> payload_revision   0x37d40raw  219
>
> vsa0x37e80stage57532
>
> (empty)0x45f80null 236568
>
> bootblock  0x7fbc0bootblock768
>
>
>
> The config file with the build Options can be found here:
>
> https://file.youngsolutions.ch/index.php/s/MrXbSGYdS5E8DsH
>
>
>
>
>
> Here a trace of the full Output:
>
>
>
> Setup throttling delays to proper mode
>
> Done cpuRegInit
>
> Ram1.00
>
> Ram2.00
>
> * sdram_set_spd_register
>
> spd_read_byte dev 50 addr 15 returns ff
>
> * Check DIMM 0
>
> * Check DIMM 1
>
> spd_read_byte dev 51 returns 0xff
>
> * Check DDR MAX
>
> spd_read_byte dev 50 addr 09 returns 0a
>
> spd_read_byte dev 51 returns 0xff
>
> * AUTOSIZE DIMM 0
>
> * Check present
>
> spd_read_byte dev 50 addr 02 returns 07
>
> * MODBANKS
>
> spd_read_byte dev 50 addr 05 returns 01
>
> * FIELDBANKS
>
> spd_read_byte dev 50 addr 11 returns 04
>
> * SPDNUMROWS
>
> spd_read_byte dev 50 addr 03 returns 03
>
> spd_read_byte dev 50 addr 04 returns 0a
>
> * SPDBANKDENSITY
>
> spd_read_byte dev 50 addr 1f returns 40
>
> * DIMMSIZE
>
> * BEFORT CTZ
>
> * TEST DIMM SIZE>8
>
> * PAGESIZE
>
> spd_read_byte dev 50 addr 04 returns 0a
>
> * MAXCOLADDR
>
> * >12address test
>
> * RDMSR CF07
>
> * WRMSR CF07
>
> * ALL DONE
>
> * AUTOSIZE DIMM 1
>
> * Check present
>
> spd_read_byte dev 51 returns 0xff
>
> * set cas latency
>
> spd_read_byte dev 50 addr 12 returns 10
>
> spd_read_byte dev 50 addr 17 returns 3c
>
> spd_read_byte dev 50 addr 19 returns 4b
>
> spd_read_byte dev 51 returns 0xff
>
> * set all latency
>
> spd_read_byte dev 50 addr 1e returns 28
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1b returns 0f
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1d returns 0f
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 1c returns 0a
>
> spd_read_byte dev 51 returns 0xff
>
> spd_read_byte dev 50 addr 2a returns 46
>
> spd_read_byte dev 51 returns 0xff
>
> * set emrs
>
> spd_read_byte dev 50 addr 16 returns ff
>
> spd_read_byte dev 51 returns 0xff
>
> * set ref rate
>
> spd_read_byte dev 50 addr 0c returns 3a
>
> spd_read_byte dev 51 returns 0xff
>
> Ram3
>
> * DRAM controller init done.
>
>
>
> Gesendet von Mail für Windows 10
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot

Hi Reto,

I noticed that a month and a half ago [0] on a very simular board and
it turned to be a romcc issue as it was suggested here in ML. Using
very old tree, I was able to boot the board, though there was (still
unsolved, blame to myself) issues with cbfs ELF execution when VSA
blob is presented. If you would try to use some pre-cbfs alix/geode
code you would see the same issue with ELF loader (both cases could be
dirty-hacked for feeding an appropriate beginning of the bios
payload). I barely checked the presence of the endless loop and have
done zero effort yet to research from where it comes and if it
possible to fix it without getting too deep in a romcc code.

0. https://www.coreboot.org/pipermail/coreboot/2016-January/080867.html

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

[coreboot] romcc issue with loop execution?

[Andrey Korolyov]

Hello,

during initial bootstrap of an ancient Geode board I found that the
romstage hangs at

src/northbridge/amd/lx/raminit.c:

750 volatile unsigned long *ptr;
>>>
751 for (i = 0; i < 5; i++) {
752 ptr = (void *)i;
753 *ptr = (unsigned long)i;
754 }

just after declaration of a pointer. I have a little clue of the romcc
internals yet, neither I do possess romulator for fast and painless
rom re-executions in place. Checked against current master and against
4.1 tag with same results. I`ve seen *somehow* simular report at [0]
but there is no hints about which code was executed at a time and what
was a final fix (if any), also I do think that this issue was probably
UART-related.

0. http://www.coreboot.org/pipermail/coreboot/2008-May/034605.html

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

Re: [coreboot] i855GM on laptop - possible or not?

[Andrey Korolyov]

On Mon, Aug 3, 2015 at 4:43 PM, Stefan Reinauer
stefan.reina...@coreboot.org wrote:
 Hi Andrey,

 * Andrey Korolyov and...@xdel.ru [150802 22:22]:
 I am trying to estimate amount of effort to make an old military Getac
 to work with coreboot (currently it runs Insyde with computrace-style
 code). All currently supported boards, lanner/em8510 and
 digitallogic/adl855pc are desktops, which means that I should play
 with EC support almost from scratch. Given the fact that i855G(M) was
 quite popular in P-M era, are there any real issues standing behind
 lack of support of a simular mobile platform in a tree?

 The ADL855PC is an embedded module that is using the i855GME chipset
 (the same as the Getac W130 as far as I remember).

 Last I checked, the 855 port was not very good, but there's probably
 nothing in the way of attempting to write a port for that laptop.

 You should make sure you have some means of recovering your flash chip
 back to something working, because writing a port and getting a system
 booting typically takes a few tries ;)

 Stefan


Thanks, I`ve already ordered PLCC extractor and programmer for this
purpose, PLCC bed is not designed for in-scheme clip reprogramming
anyway. EC looks like not a big deal, though it should implement some
unique bits like HDD heater setting.

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

[coreboot] i855GM on laptop - possible or not?

[Andrey Korolyov]

Hello,

I am trying to estimate amount of effort to make an old military Getac
to work with coreboot (currently it runs Insyde with computrace-style
code). All currently supported boards, lanner/em8510 and
digitallogic/adl855pc are desktops, which means that I should play
with EC support almost from scratch. Given the fact that i855G(M) was
quite popular in P-M era, are there any real issues standing behind
lack of support of a simular mobile platform in a tree?

Thanks in advance!

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

Re: [coreboot] Interrupt mapping with NetBSD

[Andrey Korolyov]

On Sat, Jun 27, 2015 at 4:58 PM, Andrey Korolyov and...@xdel.ru wrote:
 On Sat, Jun 27, 2015 at 4:28 PM, Jonathan A. Kollasch
 jakll...@kollasch.net wrote:
 On Sat, Jun 27, 2015 at 04:09:08PM +0300, Andrey Korolyov wrote:
 Hello,

 can anyone please provide a solid pointer for a 'patch' mentioned in
 http://www.coreboot.org/NetBSD#Interrupt_routing? It looks like that
 the even recent MPBIOS code in NetBSD kernel is not able to place all
 interrupts correctly if coreboot is used with SeaBIOS payload, my
 82577 does not work exactly because of that under this OS. The target
 hardware is a well-supported X201 platform, if this can add more
 sense.

 The patch is unnecessary if the payload is SeaBIOS, which is the payload
 you want to use to boot NetBSD anyway.  I barely remember the details of
 the patch at this point, and I have no idea if I still have it laying
 around.

 Anyway, you almost certainly don't want to be relying on anything other
 than the DSDT for interrupt routing on a modern machine with a modern OS.


 Thanks, disabling MPBIOS and therefore relying purely on what was
 populated by ACPI didn`t help with issue. Just to mention - Linux
 kernel works just fine with same device numbers, so the nature of the
 problem is a bit unclear to me (driver`s code for 'unable to map
 interrupt' suggests that there was no interrupt number provided at
 all). Sadly the wireless driver behaves very poorly with 6250, leaving
 no alternative for remote connection than a temporarily broken
 ethernet link:

 64 bytes from 192.168.1.36: icmp_seq=2 ttl=255 time=14.0 ms
 64 bytes from 192.168.1.36: icmp_seq=5 ttl=255 time=3.50 ms
 64 bytes from 192.168.1.36: icmp_seq=7 ttl=255 time=13.5 ms

Ultra-short post-mortem: out of three top BSDs only FreeBSD stable was
able to handle all hardware from very beginning, OpenBSD decided to
not work with media layer of 82577 as well as NetBSD, though OpenBSD
reported no driver issues. Hopefully I`ll have enough time to figure
out and patch the difference.

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

Re: [coreboot] Interrupt mapping with NetBSD

[Andrey Korolyov]

On Sat, Jun 27, 2015 at 4:28 PM, Jonathan A. Kollasch
jakll...@kollasch.net wrote:
 On Sat, Jun 27, 2015 at 04:09:08PM +0300, Andrey Korolyov wrote:
 Hello,

 can anyone please provide a solid pointer for a 'patch' mentioned in
 http://www.coreboot.org/NetBSD#Interrupt_routing? It looks like that
 the even recent MPBIOS code in NetBSD kernel is not able to place all
 interrupts correctly if coreboot is used with SeaBIOS payload, my
 82577 does not work exactly because of that under this OS. The target
 hardware is a well-supported X201 platform, if this can add more
 sense.

 The patch is unnecessary if the payload is SeaBIOS, which is the payload
 you want to use to boot NetBSD anyway.  I barely remember the details of
 the patch at this point, and I have no idea if I still have it laying
 around.

 Anyway, you almost certainly don't want to be relying on anything other
 than the DSDT for interrupt routing on a modern machine with a modern OS.


Thanks, disabling MPBIOS and therefore relying purely on what was
populated by ACPI didn`t help with issue. Just to mention - Linux
kernel works just fine with same device numbers, so the nature of the
problem is a bit unclear to me (driver`s code for 'unable to map
interrupt' suggests that there was no interrupt number provided at
all). Sadly the wireless driver behaves very poorly with 6250, leaving
no alternative for remote connection than a temporarily broken
ethernet link:

64 bytes from 192.168.1.36: icmp_seq=2 ttl=255 time=14.0 ms
64 bytes from 192.168.1.36: icmp_seq=5 ttl=255 time=3.50 ms
64 bytes from 192.168.1.36: icmp_seq=7 ttl=255 time=13.5 ms

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

[coreboot] Interrupt mapping with NetBSD

[Andrey Korolyov]

Hello,

can anyone please provide a solid pointer for a 'patch' mentioned in
http://www.coreboot.org/NetBSD#Interrupt_routing? It looks like that
the even recent MPBIOS code in NetBSD kernel is not able to place all
interrupts correctly if coreboot is used with SeaBIOS payload, my
82577 does not work exactly because of that under this OS. The target
hardware is a well-supported X201 platform, if this can add more
sense.

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

[coreboot] Fwd: coreboot Kconfig missing deps on x201 board

[Andrey Korolyov]

Hi list,

unfortunately Vladimir who probably is a right person to talk about
this issue did not responded yet, so I am reposting my issue for a
wider audience:

both master and classic-2014.10 are not able to fulfill config
dependencies when this particular board is selected:

warning: (CPU_AMD_AGESA  CPU_AMD_PI  CPU_SPECIFIC_OPTIONS 
CPU_SPECIFIC_OPTIONS  CPU_SPECIFIC_OPTIONS  CPU_SPECIFIC_OPTIONS
 CPU_SPECIFIC_OPTIONS  NORTHBRIDGE_SPECIFIC_OPTIONS) selects
LAPIC_MONOTONIC_TIMER which has unmet direct dependencies
(UDELAY_LAPIC)

Should I simply fix the conditions to match timer settings for ones in
x220 model, as they are probably the same?

Please find sample config attached (default one, just board was
selected). Also there is a clear difference b/w x201 and x220 configs
for CONFIG_MMX which should be set for x201 board almost for sure.

Thanks!


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