coreboot June 2014

coreboot@coreboot.org

45 participants
77 discussions

Re: [coreboot] smi handler support for fsp baytrail
by jstkf2012＠126.com 10 Jun '14

10 Jun '14

Hi Jiming, I can find mrc.cache now.But when I restart the system(pci reset),it will also cause a restart again in fspinit api . log: All threads complete. Scan for option roms Press F12 for boot menu. Select boot device: 1. AHCI/1: ST3160813AS ATA-8 Hard-Disk (149 GiBytes) In resume (status=0) In 32bit resume Attempting a hard reboot WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! WARNING - Timeout at i8042_wait_write:50! coreboot-4.0-6196-gf5bde44-dirty Tue Jun 10 03:30:25 EAT 2014 starting... RTC Init POST: 0x44 POST: 0x47 POST: 0x48 Starting the Intel FSP (early_init) Configure Default UPD Data SPD Addr1: 0xa0 SPD Addr2: 0xa2 Tseg Size: 8 MB MMIO Size: 2048 MB IGD Memory Size: 64 MB Aperture Size: 256 MB GTT Size: 2 MB MIPI/ISP: Enabled Sdio: Enabled Sdcard: Enabled Sata: Enabled SATA Mode: AHCI Lpe: Disabled Lpe mode: PCI SIO Dma 0: Enabled SIO I2C0: Enabled SIO I2C1: Enabled SIO I2C2: Enabled SIO I2C3: Enabled SIO I2C4: Enabled SIO I2C5: Enabled SIO I2C6: Enabled Azalia: Enabled SIO Dma1: Enabled Pwm0 Enabled Pwm1: Enabled Hsuart0: Enabled Hsuart1: Enabled Spi: Enabled eMMC 4.1: Disabled eMMC 4.5: Enabled Xhci: Disabled .. coreboot-4.0-6196-gf5bde44-dirty Tue Jun 10 03:30:25 EAT 2014 starting... RTC Init POST: 0x44 POST: 0x47 POST: 0x48 Starting the Intel FSP (early_init) Configure Default UPD Data SPD Addr1: 0xa0 SPD Addr2: 0xa2 Tseg Size: 8 MB MMIO Size: 2048 MB IGD Memory Size: 64 MB Aperture Size: 256 MB GTT Size: 2 MB MIPI/ISP: Enabled Sdio: Enabled Sdcard: Enabled Sata: Enabled SATA Mode: AHCI Lpe: Disabled Lpe mode: PCI SIO Dma 0: Enabled SIO I2C0: Enabled SIO I2C1: Enabled SIO I2C2: Enabled SIO I2C3: Enabled SIO I2C4: Enabled SIO I2C5: Enabled SIO I2C6: Enabled Azalia: Enabled SIO Dma1: Enabled Pwm0 Enabled Pwm1: Enabled Hsuart0: Enabled Hsuart1: Enabled Spi: Enabled eMMC 4.1: Disabled eMMC 4.5: Enabled Xhci: Disabled POST: 0x4a romstage_main_continue status: 0 hob_list_ptr: 7ae20000 FSP Status: 0x0 Baytrail Chip Variant: Bay Trail-D (Desktop) MRC v0.90 1 channels of DDR3 @ 1333MHz POST: 0x4b POST: 0x4c POST: 0x4d CBMEM: root @ 7adff000 254 entries. POST: 0x4e Thanks, Tank From: Sun, Jiming Date: 2014-06-10 01:31 To: jstkf2012(a)126.com; coreboot CC: martin.roth; ron minnich Subject: RE: [coreboot] smi handler support for fsp baytrail Hi, Tank, Can you share your log? Thanks, Jiming From: jstkf2012(a)126.com [mailto:jstkf2012@126.com] Sent: Sunday, June 08, 2014 11:59 PM To: Sun, Jiming; coreboot Cc: martin.roth; ron minnich Subject: Re: [coreboot] smi handler support for fsp baytrail Hi Jiming, It's ok with configure MrcInitTsegSize = 8M.I can boot ubuntu and windows now ! But when I set MrcInitTsegSize = 8M, anthoer issue happened:we can't find mrc.cache which will cause a restart again in fspinit api when I restart the system(pci reset). Thanks, Tank EXT:8051 From: Sun, Jiming Date: 2014-06-07 00:15 To: jstkf2012(a)126.com; coreboot CC: martin.roth; rminnich Subject: Re: [coreboot] smi handler support for fsp baytrail Hi, Tank, It might be the TSEG size configuration. In devicetree.cb: register "MrcInitTsegSize" = "TSEG_SIZE_DEFAULT" By default TSEG_SIZE_DEFAULT is 0. It needs to be set to none 0, such as 8 (TSEG_SIZE_8_MB). Let us know if this helps. Jiming From: jstkf2012(a)126.com [mailto:jstkf2012@126.com] Sent: Thursday, June 05, 2014 11:48 PM To: coreboot Cc: martin.roth; rminnich Subject: [coreboot] smi handler support for fsp baytrail Hi all, What about the smi support for fsp baytrail?When I select HAVE_SMI_HANDLER for fsp baytrail,it will halt at: ERROR: Could not find FSP HOB pointer in CBFS! POST: 0x79 POST: 0x9c ACPI: Writing ACPI tables at f0000. ACPI: * FACS @ 000f0210 Length 40ACPI: * DSDT @ 000f0250 Length 2a89SCI is IRQ9 ACPI: added table 1/32, length now 40 ACPI: * FADT @ 000f2ce0 Length f4ACPI: added table 2/32, length now 44 ACPI: * HPET @ 000f2de0 Length 38 ACPI: added table 3/32, length now 48 ACPI: * MADT @ 000f2e20 Length 6c ACPI: added table 4/32, length now 52 ACPI: * MCFG @ 000f2e90 Length 3c ACPI: Could not find CBMEM GNVS ACPI: Patching up global NVS in DSDT at offset 0x009f -> 000f2ed0 Thanks, Tank

1 1

(no subject)
by KOLANICH 09 Jun '14

09 Jun '14

Hi. I wanna know is it possible to add my motherboard without lot of effort. 1 motherboard specs http://www.msi.com/product/mb/P965_Neo.html#hero-specification http://www.manualslib.com/manual/293475/Msi-Ms-72bios35.html and a picture http://content.hwigroup.net/images/products/xl/001617/msi_p965_neof.jpg 2 datasheet to rom microscheme http://www.spansion.com/Support/Datasheets/S25FL008A_00.pdf 3 I use cpu Intel Core 2 Duo E6600. 4 Needed files are included. (i have cut all unneeded info from them) 5 I had found some information ( in Russian, in comments http://www.rom.by/forum/Ispolzovanie_SPI-interfejsa_dlja_pereshivki_biosa_n… ) that it is possible to connect an additional ROM chip to motherboard using SPI and use it instead of main one. May be it could be possible to flash it using flashrom. Have you tried this?

3 3

[RFC] Extend `board_info.txt` to include comments
by Paul Menzel 09 Jun '14

09 Jun '14

Dear coreboot folks, the patch set [1] hp/abm: Adds the new mainboard extends `board_info.txt` to include comments about the board [2]. 1 +Board name: hp/abm (I think, the official name belongs into board name.) 2 +Category: customer 3 +ROM protocol: SPI 4 +ROM socketed: n 5 +Flashrom support: y 6 + 7 +The hp/abm board is used in network/server applications. 8 + 9 +Notes: 10 +» 1) The hp/abm board is headless and therefore does not define 11 +» CONFIG_GFXUMA, and does not require a video bios. 12 +» 2) The micro USB connector on the board edge is connected to COM4 13 +» (i.e. I/O=2E8h). Coreboot needs to be configured to use Index=3. 14 +» 3) If you are using SeaBIOS it would also need to be configured to 15 +» use the UART at I/O=2E8h. 16 +» 3) This board has been tested with headless installed versions of 17 +» Ubuntu 12.10 and Fedora 19. Is everyone fine with the used format? Should we use YAML or JSON to make parsing easier? Thanks, Paul [1] http://review.coreboot.org/5948/ [2] http://review.coreboot.org/#/c/5948/2/src/mainboard/hp/abm/board_info.txt

1 0

Re: [coreboot] smi handler support for fsp baytrail
by jstkf2012＠126.com 09 Jun '14

09 Jun '14

Hi Jiming, It's ok with configure MrcInitTsegSize = 8M.I can boot ubuntu and windows now ! But when I set MrcInitTsegSize = 8M, anthoer issue happened:we can't find mrc.cache which will cause a restart again in fspinit api when I restart the system(pci reset). Thanks, Tank EXT:8051 From: Sun, Jiming Date: 2014-06-07 00:15 To: jstkf2012(a)126.com; coreboot CC: martin.roth; rminnich Subject: RE: [coreboot] smi handler support for fsp baytrail Hi, Tank, It might be the TSEG size configuration. In devicetree.cb: register "MrcInitTsegSize" = "TSEG_SIZE_DEFAULT" By default TSEG_SIZE_DEFAULT is 0. It needs to be set to none 0, such as 8 (TSEG_SIZE_8_MB). Let us know if this helps. Jiming From: jstkf2012(a)126.com [mailto:jstkf2012@126.com] Sent: Thursday, June 05, 2014 11:48 PM To: coreboot Cc: martin.roth; rminnich Subject: [coreboot] smi handler support for fsp baytrail Hi all, What about the smi support for fsp baytrail?When I select HAVE_SMI_HANDLER for fsp baytrail,it will halt at: ERROR: Could not find FSP HOB pointer in CBFS! POST: 0x79 POST: 0x9c ACPI: Writing ACPI tables at f0000. ACPI: * FACS @ 000f0210 Length 40ACPI: * DSDT @ 000f0250 Length 2a89SCI is IRQ9 ACPI: added table 1/32, length now 40 ACPI: * FADT @ 000f2ce0 Length f4ACPI: added table 2/32, length now 44 ACPI: * HPET @ 000f2de0 Length 38 ACPI: added table 3/32, length now 48 ACPI: * MADT @ 000f2e20 Length 6c ACPI: added table 4/32, length now 52 ACPI: * MCFG @ 000f2e90 Length 3c ACPI: Could not find CBMEM GNVS ACPI: Patching up global NVS in DSDT at offset 0x009f -> 000f2ed0 Thanks, Tank

2 1

Re: [coreboot] Intel native graphics init: Questions about GTT setup: Decode error on Lenovo X60
by ron minnich 09 Jun '14

09 Jun '14

BTW, as you'e seen, the data sheets are less than helpful. But the driver is usually worth looking at. My contact at Intel tells me he's not seeing what you're seeing, so we need a way to reproduce your setup and see what's going on. ron On Mon, Jun 9, 2014 at 7:15 AM, ron minnich <rminnich(a)gmail.com> wrote: > It's painful and awful to do, but when you get that error, I suggest you > mod the driver to hexdump the ENTIRE gtt. You need to see what's going on > there. > > It's possible that somehow the gtt and gsm are living in the same place > and the chipset is corrupting its own gtts. > > ron >

1 0

Intel native graphics init: Questions about GTT setup
by Paul Menzel 09 Jun '14

09 Jun '14

Dear coreboot folks, since Linux 3.12+ graphics stolen memory seems to be used, which causes a regression with coreboot and native graphics init at least on the Intel 945 based Lenovo X60 [1]. This seems to be solved by properly setting register `PGETBL_CTL` [2], but the Linux kernel Intel graphics driver still reports a GTT (Graphics Translation Table) related error during start-up, but everything else seems to work. [ 1.235640] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 1.236583] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 1.236583] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 1.236583] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 1.236583] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 1.236583] i915: render error detected, EIR: 0x00000010 [ 1.236583] i915: page table error [ 1.236583] i915: PGTBL_ER: 0x00000013 [ 1.236583] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking [ 1.236583] i915: render error detected, EIR: 0x00000010 [ 1.236583] i915: page table error [ 1.236583] i915: PGTBL_ER: 0x00000013 Looking further into the native graphics init code for Intel IGDs, I wonder what `setgtt()` does. Looking at Google Link, where this was introduced, there is the code below. $ nl -ba src/mainboard/google/link/i915.c […] 95 void io_i915_WRITE32(unsigned long val, unsigned long addr) 96 { 97 if (verbose & vio) 98 printk(BIOS_SPEW, "%s: outl %08lx\n", regname(addr), val); 99 outl(addr, addrport); 100 outl(val, dataport); 101 } 102 103 104 /* 105 2560 106 4 words per 107 4 *p 108 10240 109 4k bytes per page 110 4096/p 111 2.50 112 1700 lines 113 1700 * p 114 4250.00 115 PTEs 116 */ 117 static void 118 setgtt(int start, int end, unsigned long base, int inc) 119 { 120 int i; 121 122 for(i = start; i < end; i++){ 123 u32 word = base + i*inc; 124 WRITE32(word|1,(i*4)|1); 125 } 126 } […] 349 /* GTT is the Global Translation Table for the graphics pipeline. 350 * It is used to translate graphics addresses to physical 351 * memory addresses. As in the CPU, GTTs map 4K pages. 352 * There are 32 bits per pixel, or 4 bytes, 353 * which means 1024 pixels per page. 354 * There are 4250 GTTs on Link: 355 * 2650 (X) * 1700 (Y) pixels / 1024 pixels per page. 356 * The setgtt function adds a further bit of flexibility: 357 * it allows you to set a range (the first two parameters) to point 358 * to a physical address (third parameter);the physical address is 359 * incremented by a count (fourth parameter) for each GTT in the 360 * range. 361 * Why do it this way? For ultrafast startup, 362 * we can point all the GTT entries to point to one page, 363 * and set that page to 0s: 364 * memset(physbase, 0, 4096); 365 * setgtt(0, 4250, physbase, 0); 366 * this takes about 2 ms, and is a win because zeroing 367 * the page takes a up to 200 ms. We will be exploiting this 368 * trick in a later rev of this code. 369 * This call sets the GTT to point to a linear range of pages 370 * starting at physbase. 371 */ 372 setgtt(0, FRAME_BUFFER_PAGES, physbase, 4096); 373 printk(BIOS_SPEW, "memset %p to 0 for %d bytes\n", 374 (void *)graphics, FRAME_BUFFER_BYTES); […] $ git grep FRAME_BUFFER src/mainboard/google/link/i915io.h src/mainboard/google/link/i915io.h:#define FRAME_BUFFER_PAGES ((2560*1700)/1024) src/mainboard/google/link/i915io.h:#define FRAME_BUFFER_BYTES (FRAME_BUFFER_PAGES*4096) Looking at the code of the Lenovo X60 with the resolution of 1024×768, instead of `FRAME_BUFFER_PAGES` = 768 it is the higher number 800. Otherwise there are graphical corruptions on the GRUB screen. Furthermore Vladimir’s native graphics patch up for review in Gerrit [3] uses the code below [3]. /* Setup GTT. */ for (i = 0; i < 0x2000; i++) { outl((i << 2) | 1, piobase); outl(pphysbase + (i << 12) + 1, piobase + 4); } This is equivalent to `setgtt(0, 8192, physbase, 4096)`. As the code should be not hardcoded to one resolution (for example the Lenovo T60 has a different one than the Lenovo X60), the code should be dynamic. Unfortunately, I did not find anything in the datasheet [4][5] explaining, why this `setgtt()` is needed at all. I guess this was figured out by tracing the Video BIOS? Ron, Denis, Peter, Vladimir, it’d be great if you could explain that to me? At least on Intel 945, the GTT is 256 KB big and is placed below TOLUD into the graphics stolen memory, which is currently hardcoded to 8 MB. So how should the pages be setup then? Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=79038 [2] http://review.coreboot.org/5927 [3] http://review.coreboot.org/#/c/5320/9/src/northbridge/intel/i945/gma.c [4] http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobi… [5] https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_…

3 6

Re: [coreboot] Intel native graphics init: Questions about GTT setup
by Paul Menzel 09 Jun '14

09 Jun '14

Dear Ron, thanks a lot for taking the time to write such a detailed answer! Am Sonntag, den 08.06.2014, 16:07 -0700 schrieb ron minnich: > Paul, many good questions. The problem is I did all this over 2 years ago > and the answers won't be as good. Vladimir and Peter will likely do better. > And, to reiterate, the 'replay attack' code for Link is not a good example > of how to start graphics. It Just Worked, but not well. I am aware of that. The replay code also works on the Lenovo X60, but since Linux 3.12+ 3D is broken, which we try to fix. Also the GTT code is more or less identical in master and in Vladimir’s patch set [1]. Please also note, that at least since Linux 3.11, Linux is not able anymore to set up graphics without the Video ROM or native graphics init. Unfortunately, nobody bisected this yet or notified the Linux folks of this regression. As I do not have the hardware, I won’t report that as it takes too much time to relay information. > The second iteration Furquan and I did on Falco and Pepper is really > what we need to use. That graphics code is not upstream yet, is it? $ git grep MAINBOARD_DO_NATIVE src/mainboard/google/ src/mainboard/google/link/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += i915.c src/mainboard/google/link/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += i915io.c src/mainboard/google/link/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += intel_dp.c src/mainboard/google/pit/Kconfig: select MAINBOARD_DO_NATIVE_VGA_INIT src/mainboard/google/slippy/Kconfig: select MAINBOARD_DO_NATIVE_VGA_INIT src/mainboard/google/slippy/Makefile.inc:ramstage-$(CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT) += gma.c i915io.c src/mainboard/google/snow/Kconfig: select MAINBOARD_DO_NATIVE_VGA_INIT $ git grep i915lightup src/northbridge/intel/haswell/ src/mainboard/google/{falco,peppy} src/northbridge/intel/haswell/gma.c: int i915lightup(u32 physbase, u32 iobase, u32 mmiobase, u32 gfx); src/northbridge/intel/haswell/gma.c: lightup_ok = i915lightup(physbase, iobase, mmiobase, graphics_base); > So let's take it a bit at a time. > > The GTT is a page table used by the graphics hardware to address memory. It > translates graphics addresses to physical addresses. > > Part of the hardcoding of size is because in some cases the chipset has a > limited choice of sizes -- you set a bit, it takes a certain fixed size. 8 > MiB is common to the older chipsets. At the same time, once the kernel > starts, it's going to change the GTT anyway -- we're mainly doing GTT setup > here to make it easy to paint the boot splash screens. That's it. > > Note that GTT allows the graphics hardware to address anything in the low 4 > GiB, and even more on some chipsets, where another set of address bits is > stashed in the low 12 bits. > > You can address the memory pointed to by the GTT. Use the address in one of > the BARs -- IIRC, bar 0? I don't recall, maybe BAR2 -- as your address. > Your references are then mapped back to physical memory addresses via the > GTT mappings. And does `setgtt()` reserves that memory? I am still missing, why `setgtt()` is needed and why we write stuff in there. static void setgtt(int start, int end, unsigned long base, int inc) { int i; for(i = start; i < end; i++){ u32 word = base + i*inc; WRITE32(word|1,(i*4)|1); } } > GSM is an odd duck. […] Where does GSM come into plays I think, I meant BSM and not GSM. ;-) > Also note that the GTT is just a way to map graphics chipset references to > physical addresses, and again is not really related to resolution or depth, > except in two ways: > - if you don't create enough entries for the resolution, you have a problem > - if you create too many, you might waste memory > > The second problem is not as serious as the first. So we just grab a lot of > memory and map it, because the coreboot mappings will be replaced anyway by > the driver. Yes, that second problem has to be solved generically, when writing native graphics code, that is generic for all mainboards with that chipset. > The GTT settings are fairly safe and I think you're on the wrong track in > terms of your debugging, but I could be wrong. > > You should not assume that it's NOT a Linux driver problem. The Linux > drivers are not well tested against coreboot, and we know of cases where > they worked against the BIOS, but only by mostly luck. Sound familiar :-) ? > It's the problem we've always had. That is indeed still a possibility. > I would question this change: > > - PGETBL_CTL: 0x3ffc0001 > + PGETBL_CTL: 0x3f800001 > > > because it doesn't come with an explanation of what it's supposed to > fix. As far as I understand it, it points to the GTT, which sits directly below TOLUD. And with that change 3D at least works under Linux 3.12+. I have no idea, if since some versions the Linux Intel graphics driver dependents more on firmware initialization and does not replace the GTT setup anymore. […] Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=79038 [2] http://review.coreboot.org/5927 [3] http://review.coreboot.org/#/c/5320/9/src/northbridge/intel/i945/gma.c [4] http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobi… [5] https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_…

2 1

Re: [coreboot] Intel native graphics init: Questions about GTT setup: Apple MacBook 2, 1 and EFI
by Paul Menzel 09 Jun '14

09 Jun '14

Am Sonntag, den 08.06.2014, 17:57 -0700 schrieb ron minnich: > Does anybody want to have a go at a further interpration of the errors? > That would help. Does this error mean a present bit was not set, or the > address was wrong, or ... That register is not documented in the public Intel 945 datasheet [4]. Using the Intel 965 datasheet [5], page 207, `PGTBL_ER: 0x00000001` means HOST_INVALID_GTT_PTE, „Invalid GTT Entry during Fetch on behalf of the Host“. Please note, the intel-gpu-tools [6] include the program `intel-error-decode`. I’ll decode the error with coreboot on the Lenovo X60 in my reply to the other message. Thanks, Paul [4] http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobi… [5] https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_… [6] http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

1 0

msi wind u100 status
by core user 08 Jun '14

08 Jun '14

Msi Wind U100's specs are mentioned in this web page: http://www.coreboot.org/Laptop But it is not listed in this page: http://www.coreboot.org/Supported_Motherboards#Laptops What is the current status of the msi wind u100 regarding coreboot?

1 0

Re: [coreboot] Investigating the high pitched noise on the x60 tablet
by Patrick Georgi 06 Jun '14

06 Jun '14

Hi Charles, Am 06.06.2014 21:15, schrieb Charles Devereaux: > it be possible to have an autopower on option ? I mean, as soon as the > AC adapter is connecter, start booting - because I don't have a spare > keyboard for this spare motherboard :-) Look for power_on_after__fail. It's a CMOS/nvram option but since you're developing you could hardcode it to your desired value at the places it's used (should be in src/southbridge/intel/i82801gx/*.c) However it's possible that some other component (eg. the EC) does the power sequencing on that board... Good luck on your bug hunt! Patrick

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2014