Hello
Yes I have included this patch 17389 in my build. Unfortunately, it gave me
the raminit logs failures attached before. I will try to see what's stored
in the MRC cache. I would like to make the ram init conditional on the boot
status, which means having 2 mrc cache: one for normal, one for fallback.
This way, I flush one and debug ram issues with less fear (because the W520
I am porting coreboot to is my main laptop)
For native video, I have 2 memory segments:
Memory at f1400000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I guess I should always read from the first one.
It seems to work, but I am always getting the same result at different
addresses
$ ./iotools mem_read32 f14C7200
0xf000ff53
$ ./iotools mem_read32 f14C7201
0xf000ff53
$ ./iotools mem_read32 f14C7202
0xf000ff53
$ ./iotools mem_read32 f14C7203
0xf000ff53
$ ./iotools mem_read32 f1400000
0xf000ff53
Here is the romstage that I tried using with non native raminit. It gave me
no video, but besides that it goes to payload and work fine. I wonder if I
should declare the HD4000 in the peidata. It seems the video was just not
initialized at all.
For brightness in the payloads, if it cause security issues, I guess I can
do without it.
Charlotte
On Wed, Nov 16, 2016 at 7:32 AM, Nico Huber <nico.hu...@secunet.com> wrote:
> On 16.11.2016 06:08, Charlotte Plusplus wrote:
> > Hello
> >
> > On Tue, Nov 15, 2016 at 6:46 PM, Nico Huber <nic...@gmx.de> wrote:
> >
> >> I've seen a garbled image, too, lately. When I built with native
> >> raminit by chance but with a completely different gfx init code
> >> (3rdparty/libgfxinit). So it might still be some problem in the
> >> raminit. This was also on an Ivy Bridge system with four DIMMs,
> >> btw. I suspected that the native raminit just wasn't tested in that
> >> configuration.
> >>
> >
> > Interesting, I noticed some patterns with raminit too. Most of my
> problems
> > with the native raminit happen with 4x 8Gb DIMMS. The more sticks I have,
> > the less likely native ram training is to succeed. I have logged a few of
> > the failed attempt in case anyone else is interested (attached).
> >
> > Basically, the training can fail several times with the exact same
> > parameters that it later succeeds with. Also, failure is a function of
> > speed. All the attempts I have done but not attached can be summed up
> like
> > this: failure of the native ram training is also more likely with a MCU
> > over 666MHz. But whenever the raminit succeed, the memory is stable in
> > memtests (I did several passes to check.
> >
> > Now that I can use Windows 10 with Coreboot, I decided to experiment a
> bit
> > more. First, I tried changing the SPD settings with Thaiphoon Burner. The
> > sticks I have advertise they supported both 1.35 and 1.5V profiles (SPD:
> > 006=03) which I feared might cause issue. Changing that to 1.5V only
> (SPD:
> > 006=00) did not help, even if it did help with another computer that I
> > borrowed to do some comparisons with (I was afraid my sticks were at
> fault)
> >
> > Then I tried manually filling XMP profile 1 with known to be working
> values
> > (either published, or found during native raminit training). It seemed to
> > help but the results were inconsistent. Between my tests for different
> > value, I was clearing the MRC cache.
> >
> > Then I had a weird idea: what if the ram training or the MRC cache
> clearing
> > was the cause of the problem? I changed my protocol to do: clear cache,
> > train after changing the SPD/MCU frequency/etc, then when it succeeds
> > disable the MRC cache clearing hook, and do a few reboots or a power off
> > before doing the memtest. And this was sufficient to get stabilility at
> > 666Mhz and frequencies above without having to tweak the SPD anymore
> (like
> > adding some latency to the detected values)
> >
> > Currently 800Mhz is validated, I haven't tested 933 MHz because ram
> > training success seems to be a probability that goes down with the
> > frequency, and pressing on the power button every time it fails quickly
> > gets boring!
> >
> > I have no way to prove that, but I believe that the ram training by
> itself
> > interferes with the stability of the RAM, or that there is some non
> > deterministic part in the code. I don't know why or how, it's a lot of
> code
> > that I haven't read in detail, but it's what my tests suggests. I would
> > love to compare these results to ones the blob raminit would give. But
> blob
> > raminit causes video issues. So I'm trying to focus on native video init
> > first, in case it helps me to use mrc.bin.
>
> I can't recall if Patrick or you mentioned this already, there's a rela-
> ted patch up for review:
> https://review.coreboot.org/#/c/17389/
> Do you have that already applied locally?
>
> >
> > Well, I don't see any setting that could really break something. The
> >> code might just be buggy. I'll go through the settings anyway, taking
> >> src/mainboard/lenovo/t520/devicetree.cb as example:
> >>
> >
> > I used this code as a source, as I figured the screen was likely to be
> the
> > same.
> >
> > That's about ACPI, let's not care (the last appendix in the ACPI spec if
> >> you want to have a look).
> >>
> >
> > I will check that too because Fn Home and Fn end (brightness + and -)
> don't
> > work in memtest86, even if they work in linux and windows
>
> That's expected. coreboot does the brightness control through ACPI.
> And ACPI is something for bloated OSs not for payloads (it comes with
> a whole bunch of code including a byte-code interpreter).
>
> A workaround would be to do the EC event handling in SMM until ACPI
> takes over. But that's usually discouraged as SMM has security issues.
> So we want as little code as possible in SMM.
>
> >
> >
> >> Those are real register settings, you can dump the whole GMA MMIO
> >> space with `inteltool -f` (hoping that your system doesn't hang). The
> >> registers are described in [1, chapter 2.4].
> >>
> >
> > Sorry, but it did hang. I couldn't even ssh to it. Any alternative to
> get
> > the info?
>
> Look up the base address of the gfx MMIO space:
> $ lspci -vs 00:02.0 | grep Memory
> or
> $ head -1 /sys/devices/pci0000:00/0000:00:02.0/resource
>
> Grab a copy of iotools: https://github.com/adurbin/iotools.git
> You should be able to read single registers with the mem_read32 command:
> # ./iotools mem_read32 $((base+register_offset))
>
> Nico
>
>
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2007-2010 coresystems GmbH
* Copyright (C) 2011 The ChromiumOS Authors. All rights reserved.
* Copyright (C) 2014 Vladimir Serbinenko
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
#include <stdint.h>
#include <string.h>
#include <lib.h>
#include <timestamp.h>
#include <arch/byteorder.h>
#include <arch/io.h>
#include <device/pci_def.h>
#include <device/pnp_def.h>
#include <cpu/x86/lapic.h>
#include <pc80/mc146818rtc.h>
#include <arch/acpi.h>
#include <cbmem.h>
#include <console/console.h>
#include <northbridge/intel/sandybridge/sandybridge.h>
#include <northbridge/intel/sandybridge/raminit.h>
#include <northbridge/intel/sandybridge/raminit_native.h>
#include <southbridge/intel/bd82x6x/pch.h>
#include <southbridge/intel/common/gpio.h>
#include <arch/cpu.h>
#include <cpu/x86/msr.h>
#include <cbfs.h>
void pch_enable_lpc(void)
{
/* W520 EC Decode Range Port60/64, Port62/66 */
/* Enable EC, PS/2 Keyboard/Mouse */
pci_write_config16(PCH_LPC_DEV, LPC_EN,
CNF2_LPC_EN | CNF1_LPC_EN | MC_LPC_EN | KBC_LPC_EN |
COMA_LPC_EN);
pci_write_config32(PCH_LPC_DEV, LPC_GEN1_DEC, 0x7c1601);
pci_write_config32(PCH_LPC_DEV, LPC_GEN2_DEC, 0xc15e1);
pci_write_config32(PCH_LPC_DEV, LPC_GEN4_DEC, 0x0c06a1);
pci_write_config16(PCH_LPC_DEV, LPC_IO_DEC, 0x10);
pci_write_config32(PCH_LPC_DEV, 0xac, 0x80010000);
}
void rcba_config(void)
{
/* Disable unused devices (board specific) */
/* Charlotte: FIXME: update this with inteltool output from native bios */
// gives USB3
RCBA32(FD) = 0x1ea51fe3;
// previous working value: 0x1ee51fe3;
RCBA32(BUC) = 0;
}
/*
* for non native raminit, based on kontron/ktqm77
* read intel/sandybridge/pei_data.h
*/
int mainboard_should_reset_usb(int s3resume)
{
return !s3resume;
}
void mainboard_fill_pei_data(struct pei_data *pei_data)
{
struct pei_data pei_data_template = {
.pei_version = PEI_VERSION,
.mchbar = (uintptr_t)DEFAULT_MCHBAR,
.dmibar = (uintptr_t)DEFAULT_DMIBAR,
.epbar = DEFAULT_EPBAR,
.pciexbar = CONFIG_MMCONF_BASE_ADDRESS,
.smbusbar = SMBUS_IO_BASE,
.wdbbar = 0x4000000,
.wdbsize = 0x1000,
.hpet_address = CONFIG_HPET_ADDRESS,
.rcba = (uintptr_t)DEFAULT_RCBABASE,
.pmbase = DEFAULT_PMBASE,
.gpiobase = DEFAULT_GPIOBASE,
/* Charlotte: WTF is this magic? */
.thermalbase = 0xfed08000,
.system_type = 0, /* Mobile */
.tseg_size = CONFIG_SMM_TSEG_SIZE,
.spd_addresses = { 0xA0, 0xA4,0xA2, 0xA6 },
/* Charlotte: could be the temperature sensors */
.ts_addresses = { 0x00, 0x00, 0x00, 0x00 },
.ec_present = 1,
.gbe_enable = 1,
/* Charlotte: not possible on the W520, even with a ivy bridge
* CPU: As Nico found, cf page 86 in the Kendo-3 schematics.
* The TPS51916 provides the voltage VCC1R5A which is VDD for
* the DIMMs. It is controlled by REFIN generated by dividing
* VTTREF (1.8V) by the resistors R1056 (10K) and R843 (48K7).
* We need to update R2 to support that, cf equation 6 of
* http://www.ti.com/lit/ds/symlink/tps51916.pdf
*/
.ddr3lv_support = 0,
/* 2 dimms per channel on the W520 */
.dimm_channel0_disabled = 0,
.dimm_channel1_disabled = 0,
/* from intel specs only: 800, 1067, 1333, 1600, XMP will do more */
.max_ddr3_freq = 1600,
.usb_port_config = {
/* Charlotte : 0x0040 vs 0x0080 is not clear */
/* enabled oc_pin length */
{ 1, 0, 0x0040 }, /* P0: left dual conn, OC 0 */
{ 1, 1, 0x0040 }, /* P1: eSATA combo USB, (EHCI debug), OC 1 */
{ 1, -1, 0x0040 }, /* P2: WLAN slot with PCIE2 */
{ 1, -1, 0x0040 }, /* P3: WWAN slot with PCIE3, no OC */
{ 1, -1, 0x0040 }, /* P4: smartcard, no OC */
{ 1, -1, 0x0040 }, /* P5: ExpressCard with PCIE4, no OC */
{ 0, -1, 0x0040 }, /* P6: empty */
{ 0, -1, 0x0040 }, /* P7: touchscreen, no OC */
{ 1, 4, 0x0040 }, /* P8: color sensor, OC 4 */
{ 1, 5, 0x0040 }, /* P9: usb2.0 back right, (EHCI debug), OC 5 */
{ 1, -1, 0x0040 }, /* P10: fingerprint, no OC */
{ 1, -1, 0x0040 }, /* P11: bluetooth, no OC. */
{ 1, -1, 0x0040 }, /* P12: docking, no OC */
{ 1, -1, 0x0040 }, /* P13: webcam, no OC */
},
/* Charlotte: not connected, is on PCIE Port #7 by uPD7020200 */
/* 3=smart auto, mask=4 ports, preboot for driver, xhci=1 enable */
//.usb3 = {
// .mode = 3,
// .hs_port_switch_mask = 0xf,
// .preboot_support = 1,
// .xhci_streams = 1,
//},
/* Messes up with the video regardless */
.pcie_init = 0,
};
*pei_data = pei_data_template;
}
const struct southbridge_usb_port mainboard_usb_ports[] = {
/* Charlotte: CH0 and CH6 not found in spec*/
{ 1, 1, 0 }, /* ?? P0 left dual conn, OC 0 */
{ 1, 1, 1 }, /* P1: eSATA combo USB, (EHCI debug), OC 1 */
{ 1, 2, -1 }, /* P2: WLAN slot with PCIE2*/
{ 1, 1, -1 }, /* P3: WWAN slot with PCIE3, no OC */
{ 1, 1, -1 }, /* P4: smartcard, no OC */
{ 1, 1, -1 }, /* P5: ExpressCard with PCIE4, no OC */
{ 0, 2, -1 }, /* P6: empty */
{ 0, 2, -1 }, /* P7: touchscreen, no OC */
{ 1, 1, 4 }, /* P8: color sensor, OC 4 */
{ 1, 4, 5 }, /* P9: usb2.0 back right, (EHCI debug), OC 5 */
{ 1, 1, -1 }, /* P10: fingerprint, no OC */
{ 1, 2, -1 }, /* P11: bluetooth, no OC. */
{ 1, 1, -1 }, /* P12: docking, no OC */
{ 1, 1, -1 }, /* P13: webcam, no OC */
};
void mainboard_get_spd(spd_raw_data *spd) {
/* Charlotte: main difference from t520 is 4 ports.
* Specs say:
* CH-A Primary: 50h: under the keyboard
* CH-B Primary: 51h: bottom, side of the ultrabay
* CH-A Secondary: 52h: under CH-A P and under the keyboard
* CH-B Secondary: 53h: bottom, side of the VGA
*/
read_spd (&spd[0], 0x50);
read_spd (&spd[1], 0x52);
read_spd (&spd[2], 0x51);
read_spd (&spd[3], 0x53);
}
void mainboard_early_init(int s3resume) {
// Resume bugs: seems to lose synclient configuration, like buttons config from:
// synclient TapButton1=0
// Maybe we can heelp here
}
void mainboard_config_superio(void)
{
}
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
