[coreboot] Baytrail issue to communicate with superios.
Dear Rudolf/All, Today I patched superiotool to add support for Fintek F81803A and dumped both superios, and I found that LPC clock must be set at 24MHz on Fintek global control register #26 from the default 48MHz. So, now I am working on it, looking how to set correctly this register. Thank you, JT. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Baytrail issue to communicate with superios.
Good day Rudolf/All, > OK so it does work. Yesterday I copy/pasted the subroutine and its definitions used to enable SERIRQ and set the mode (sc_enable_serial_irqs) and now I can see serial output but no input on ttyS0. At this point I am trying to understand what you already told me: 1.- To dump ELCR (I/O port register 0x4d0) to check if it is correctly programmed to EDGE 2.- To do some PNP device in ACPI to let linux infer the IRQ. 3.- To try to disable the IRQ from SoC internal UART. For #1 the question is which linux command I can use to dump ELCR registers to check if misconfigured? For #2 the question is if the linux command "dmesg | grep 'tty'" output which shows the irq set on coreboot devicetree is still not evidence that linux is aware of the port IRQs? [2.207098] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [2.208096] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A I am including fintek's superio.asl which tell linux the resources of this device. May be I still dont understand #2 or there is something else. For #3 is straightforward for me and I am working on it. > What I do recall is that those Baytrail and later Apollo lake intel atom CPUs > have some issue and setting LPC to the "continous" will shorten some life of > the transistor driving the LPC bus, thus the system will malfunction sooner > than later. I am aware of this and I have been concerned on this issue for a while, but, I think I need to try to make this system functional and suggest the target user not to use this feature. Thank you, Jose Trujillo. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Baytrail issue to communicate with superios.
Thank you Rudolf, Good day, > Can you get coreboot serial console on your fintek superio? Yes, serial console works fine on fintek. > If yes, then likely something is wrong with interrupts. I am thinking about SERIRQ > You can use isadump to try to obtain UART1 and UART2 configurations (LDN 1 / > LDN 2) sudo isadump -y -k 0x87,0x87 0x4e 0x4f 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: ff ff 00 ff ff ff ff 01 ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: 12 10 10 19 34 00 00 90 e0 6f 8f 0f 8f 28 00 00 30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: 03 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 70: 04 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: 00 ff 00 ff 00 00 00 ff ff ff ff ff ff ff ff ff sudo isadump -y -k 0x87,0x87 0x4e 0x4f 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: ff ff 00 ff ff ff ff 02 ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: 12 10 10 19 34 00 00 90 e0 6f 8f 0f 8f 28 00 00 30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 60: 02 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 70: 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: 00 44 00 ff 00 00 00 ff ff ff ff ff ff ff ff ff > You can also try to setup UART in linux as if those were working, like > setting up baudrate / minicom > but then doing: sudo isaset -y -f 0x3f8 0x42 Data mismatch, wrote 0x42, read 0x00 back. > Should print "B" on the other side on COM1 (check address where your fintek > uart is) Printed "B" on the other side of the RS-232 cable on the ttyS0 port. Do you know if is possible to enable SERIRQ and set SCNT_CONTINUOUS in the actual baytrail code? SERIRQ code was supported in fsp_baytrail but not in baytrail, but now, maybe is supported indirectly in "common" code? Thanks again, Jose Trujillo. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Baytrail issue to communicate with superios.
Hello All: I hope you are doing great. The system: Baytrail E3845, 4GB DDR3, fintek (f81803a) @0x4e and Winbond (w83627dhg) @0x2e, etc... I just built coreboot (master) the last few days, everything works wonderfully except 2 things: - Libgfxinit probably because this board is using the AUX channel instead DDI to communicate with the monitors; seems to me libgfxinit cannot find monitors thru DP ports but I could be wrong because neither VGA gets initialized; and eventually Linux always initialize the video correctly. - SuperIOs not working; "cat /proc/interrupts" shows not activity from any serial port to any processor, but, I set accordingly (konfig, devicetree and superio.asl) I will check on Monday if the route definitions of "irqroute.h" are ok. Using "superiotool" to scan for SIO devices finds Winbond W83627DHG and dumped all its registries but doesn't show Fintek f81803 because of lack of support, so, data exchange between the processor and the SIO chips via LPC port seems to be fine, maybe just need to fix the interrupt issues. Any help will be highly appreciated, Thank you, JT___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [coreboot]: Help request with SMSC SCH3114 superio.
Dear Michal:
Thank you very much for all your guidance.
The problem was resolved.
The code was OK but was not executed at the right time (was executed before LPC
and SIO were initialized).
The attached code did the job
Have a great day.
Jose Trujillo.
‐‐‐ Original Message ‐‐‐
On Tuesday, September 1, 2020 10:02 AM, Michal Zygowski
wrote:
> Hi Jose,
>
> > and I do similar to you under romstage.c -> mainboard_early_init:
> > outb(0x55, 0x2e);
> > outb(0x05, 0x0a3f); /* GP50= RI_2 : in /
> > outb(0x05, 0x0a40); / GP51= DCD_2 : in /
> > outb(0x05, 0x0a41); / GP52= RXD_2 : in /
> > outb(0x04, 0x0a42); / GP53= TXD_2 : out /
> > outb(0x05, 0x0a43); / GP54= DSR_2 : in /
> > outb(0x04, 0x0a44); / GP55= RTS_2 : out /
> > outb(0x05, 0x0a45); / GP56= CTS_2 : in /
> > outb(0x04, 0x0a46); / GP57= DTR_2 : out */outb(0xaa, 0x2e);
> > but It doesn't work.
> > Also I set the same code under mainboard.c -> mainboard_init but
> > neither work.
>
> You should not copy my code for the two major reasons:
>
> 1. SCH5545 and SCH3114 are very different.
> 2. GPIO configuration on SCH5545 is not accessible from SuperIO. The
> code I have written communicates with Environmental Controller (ARC
> coprocessor) which resides inside the SCH5545, because only the EC had
> access to those registers. The SCH5545 did not have GPIO config
> registers in the Runtime Registers block.
>
> This will obviously not work.
>
>
> > Any advice on this? because I cannot find any information on the
> > datasheet on how to set those registers and I suppose I just have to
> > set to the 0xa00 base address + register.
>
> I suggest to look at TABLE 26-3 in the datasheet of your part
> http://ww1.microchip.com/downloads/en/DeviceDoc/1872A.pdf
> and using these runtime registers definitions, write the right code that
> will set the GPIOs up for UARTs. Just use the appropriate 0xa00 base +
> REG OFFSET from the table and you should be allright. For simplicity you
> may also compare these registers to reference values from original
> firmware (but with care! sometimes firmware vendors tend to make stupid
> mistakes).
>
> > Thank you,
> > Jose Trujillo.
>
> Best regards,
>
>
>
> Michał Żygowski
> Firmware Engineer
> https://3mdeb.com | @3mdeb_com
>
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
#include
#include
#include
#include
#include
/* SCH3114 SIO GPIOs. */
#define SIO_RUNTIME_BASE 0x0A00
static const u16 sio_init_table[] = { // nibble: hi = offset, lo = value
// GP5x = COM2 function instead of GPIO
0x3F05, 0x4005, 0x4105, 0x4204, 0x4305, 0x4404, 0x4505, 0x4604,
// GP1x = COM3 function instead of GPIO
0x2305, 0x2404, 0x2505, 0x2605, 0x2705, 0x2904, 0x2A05, 0x2B04,
// GP6x = COM4 function instead of GPIO
0x3405, 0x3704, 0x5405, 0x5505, 0x5605, 0x5704, 0x5805, 0x5904,
};
static void mainboard_init(struct device *dev)
{
int i;
/* Init SCH311x SIO GPIOs. */
printk(BIOS_DEBUG, "Init SIO GPIOs @ 0x%04x\n", SIO_RUNTIME_BASE);
for (i = 0; i < ARRAY_SIZE(sio_init_table); i++) {
u16 val = sio_init_table[i];
outb((u8)val, SIO_RUNTIME_BASE + (val >> 8));
}
}
static void mainboard_enable(struct device *dev)
{
dev->ops->init = mainboard_init;
/* FIXME: fix those values*/
install_intel_vga_int15_handler(GMA_INT15_ACTIVE_LFP_INT_LVDS,
GMA_INT15_PANEL_FIT_DEFAULT,
GMA_INT15_BOOT_DISPLAY_DEFAULT, 0);
}
struct chip_operations mainboard_ops = {
.enable_dev = mainboard_enable,
};
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [coreboot]: Help request with SMSC SCH3114 superio.
Thank you Michal: (you) Just use the appropriate 0xa00 base + REG OFFSET from the table and you should be allright. (Me) This is what I believe I did: 0xa00 + 0x040 = GP51/DCD_2 Function Select. Page (272) top Maybe I am not setting the code in the right place or executing at the right time? I am still looking and testing different things to resolve this issue. Have a good day Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Tuesday, September 1, 2020 10:02 AM, Michal Zygowski michal.zygow...@3mdeb.com wrote: > Hi Jose, > >> and I do similar to you under romstage.c -> mainboard_early_init: >> outb(0x55, 0x2e); >> outb(0x05, 0x0a3f); /* GP50= RI_2 : in / >> outb(0x05, 0x0a40); / GP51= DCD_2 : in / >> outb(0x05, 0x0a41); / GP52= RXD_2 : in / >> outb(0x04, 0x0a42); / GP53= TXD_2 : out / >> outb(0x05, 0x0a43); / GP54= DSR_2 : in / >> outb(0x04, 0x0a44); / GP55= RTS_2 : out / >> outb(0x05, 0x0a45); / GP56= CTS_2 : in / >> outb(0x04, 0x0a46); / GP57= DTR_2 : out */outb(0xaa, 0x2e); >> but It doesn't work. >> Also I set the same code under mainboard.c -> mainboard_init but >> neither work. > > You should not copy my code for the two major reasons: > > - SCH5545 and SCH3114 are very different. > - GPIO configuration on SCH5545 is not accessible from SuperIO. The > code I have written communicates with Environmental Controller (ARC > coprocessor) which resides inside the SCH5545, because only the EC had > access to those registers. The SCH5545 did not have GPIO config > registers in the Runtime Registers block. > This will obviously not work. > >> Any advice on this? because I cannot find any information on the >> datasheet on how to set those registers and I suppose I just have to >> set to the 0xa00 base address + register. > > I suggest to look at TABLE 26-3 in the datasheet of your part > http://ww1.microchip.com/downloads/en/DeviceDoc/1872A.pdf > and using these runtime registers definitions, write the right code that > will set the GPIOs up for UARTs. Just use the appropriate 0xa00 base + > REG OFFSET from the table and you should be allright. For simplicity you > may also compare these registers to reference values from original > firmware (but with care! sometimes firmware vendors tend to make stupid > mistakes). > >> Thank you, >> Jose Trujillo. > > Best regards, > --- > > Michał Żygowski > Firmware Engineer > https://3mdeb.com | @3mdeb_com > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [coreboot]: Help request with SMSC SCH3114 superio.
Dear Michal, I am sorry for the late reply but on Friday something went wrong with my coreboot installation and was unable to boot and I have to reinstall it again and I just resumed this morning on this issue. (you) don't think loading the watchdog module will help in any way, actually the opposite. (Me) I did the modprobe of the watchdog module just to ask linux to give me the base address of the runtime registers "0xa00" of the original bios. (you) I recommend using https://github.com/adurbin/iotools (you) Superiotool will simply dump all registers and may alternatively dump IO too. (Me) Thank you for your great advice I will go by the Superiotool route (patching it) but so far I am dumping using "ioports" in the following way: on root: for i in $(seq 0xa00 0xa7f); do echo -n "$i: "; inb $i; done; $i = $((++i)) (you) I assume you have configured runtime registers IOBASE right? (Me) I found out (because of your advise) that the runtime registers base address was wrong on my devicetree (0xe00 instead 0xa00) I set it correctly then linux was able to "see" this range and dumped the registers with the string shown above. Now I can compare both dumps and I can see the pins for the UART ports 2-4 are all GPIO inputs (1). (Me) I set manually the GPIOs from linux using ioport's function outb and all the 4 ports work correctly. Now I am trying to set from coreboot but I am still unsuccessful. Looking at you dell Optiplex 9010 you set the following runtime registers under romstage.c -> mainboard_early_init /* Disable SMIs and clear SMI status */ outb(0, SCH5545_RUNTIME_REG_BASE + SCH5545_RR_SMI_EN); outb(SCH5545_SMI_GLOBAL_STS, SCH5545_RUNTIME_REG_BASE + SCH5545_RR_SMI_STS); and I do similar to you under romstage.c -> mainboard_early_init: outb(0x55, 0x2e); outb(0x05, 0x0a3f); /* GP50= RI_2 : in */ outb(0x05, 0x0a40); /* GP51= DCD_2 : in */ outb(0x05, 0x0a41); /* GP52= RXD_2 : in */ outb(0x04, 0x0a42); /* GP53= TXD_2 : out */ outb(0x05, 0x0a43); /* GP54= DSR_2 : in */ outb(0x04, 0x0a44); /* GP55= RTS_2 : out */ outb(0x05, 0x0a45); /* GP56= CTS_2 : in */ outb(0x04, 0x0a46); /* GP57= DTR_2 : out */ outb(0xaa, 0x2e); but It doesn't work. Also I set the same code under mainboard.c -> mainboard_init but neither work. Any advice on this? because I cannot find any information on the datasheet on how to set those registers and I suppose I just have to set to the 0xa00 base address + register. Thank you, Jose Trujillo.___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Help request with SMSC SCH3114 superio.
Dear coreboot engineers & enthusiasts:
Doing dmesg:
[X@localhost ~]$ dmesg | grep "tty"
[ 0.336779] printk: console [tty0] enabled
[ 1.521090] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 1.542192] 00:05: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
[ 1.563264] 00:08: ttyS2 at I/O 0x3e8 (irq = 5, base_baud = 115200) is a 16550A
[ 1.584268] 00:09: ttyS4 at I/O 0x2e0 (irq = 6, base_baud = 115200) is a 16550A
The problem I have is that only ttyS0 works (the communication with other PC).
Attached files:
superio.c Slightly modified to initialize 2 more serial ports from 2 to 4.
devicetree.cb Shows the forwarding of the I/O ranges for ttyS2 and ttyS4 also
the smscsuperio tree with addresses and IRQs.
superio.asl The ACPI code.
I suspect is an IRQ issue.
Using minicom trying to send a byte out there is no signal shown on the
oscilloscope.
I asked (on #coreboot) if is required to route IRQs for the serial ports but
nico answered "no but you need to tell the OS if the interrupt is level or
edge" but I don't know how to do that.
Anybody had experience making this kind of superio to work please give me a
hint on how to resolve this.
What additional work do I need to do?
Thank you,
Jose Trujillo/* SPDX-License-Identifier: GPL-2.0-or-later */
/*
* Generic driver for pretty much all known Standard Microsystems Corporation
* (SMSC) Super I/O chips.
*
* Datasheets are available from: http://www.smsc.com/main/datasheet.html
*
* Most of the SMSC Super I/O chips seem to be similar enough (for our
* purposes) so that we can handle them with a unified driver.
*
* So far only the ASUS A8000 has been tested on real hardware!
*
* The floppy disk controller, the parallel port, the serial ports, and the
* keyboard controller should work with all the chips. For the more advanced
* stuff (e.g. HWM, ACPI, SMBus) more work is probably required.
*/
#include
#include
#include
#include
#include
/* The following Super I/O chips are currently supported by this driver: */
#define LPC47M172 0x14
#define FDC37B80X 0x42 /* Same ID: FDC37M70X (a.k.a. FDC37M707) */
#define FDC37B78X 0x44
#define FDC37B72X 0x4c
#define FDC37M81X 0x4d
#define FDC37M60X 0x47
#define LPC47B27X 0x51 /* a.k.a. LPC47B272 */
#define LPC47U33X 0x54
#define LPC47M10X 0x59 /* Same ID: LPC47M112, LPC47M13X */
#define LPC47M15X 0x60 /* Same ID: LPC47M192 */
#define LPC47S45X 0x62
#define LPC47B397 0x6f
#define A8000 0x77 /* ASUS A8000, a rebranded DME1737(?) */
#define DME1737 0x78
#define SCH5504 0x79
#define SCH3112 0x7c
#define SCH3114 0x7d
#define SCH5307 0x81 /* Rebranded LPC47B397(?) */
#define SCH5027D 0x89
#define SCH4304 0x90 /* SCH4304, SCH4307 */
#define SCH5147 0xc1
/* Register defines */
#define DEVICE_ID_REG 0x20 /* Device ID register */
#define DEVICE_REV_REG 0x21 /* Device revision register */
#define DEVICE_TEST7_REG 0x29 /* Device test 7 register */
/* Static variables for the Super I/O device ID and revision. */
static int first_time = 1;
static u8 superio_id = 0;
static u8 superio_rev = 0;
/**
* A list of all possible logical devices which may be supported by at least
* one of the Super I/O chips. These values are used as index into the
* logical_device_table[i].devs array(s).
*
* If you change this enum, you must also adapt the logical_device_table[]
* array and MAX_LOGICAL_DEVICES!
*/
enum {
LD_FDC, /* Floppy disk controller */
LD_PP, /* Parallel port */
LD_SP1, /* Serial port 1 (COM1) */
LD_SP2, /* Serial port 2 (COM2) */
LD_RTC, /* Real-time clock */
LD_KBC, /* Keyboard controller */
LD_AUX, /* Auxiliary I/O */
LD_XBUS, /* X-Bus */
LD_HWM, /* Hardware monitor */
LD_GAME, /* Game port */
LD_PME, /* Power management events */
LD_MPU401, /* MPU-401 MIDI UART */
LD_RT, /* Runtime registers / security key registers */
LD_ACPI, /* ACPI */
LD_SMB, /* SMBus */
LD_SP3, /* Serial port 3 (COM3) */
LD_SP4, /* Serial port 4 (COM4) */
};
/* Note: This value must match the number of items in the enum above! */
#define MAX_LOGICAL_DEVICES 17
/**
* A table describing the logical devices which are present on the
* supported Super I/O chips.
*
* The first entry (superio_id) is the device ID of the Super I/O chip
* as stored in the (read-only) DEVICE_ID_REG register.
*
* The second entry (devs) is the list of logical device IDs which are
* present on that particular Super I/O chip. A value of -1 means the
* device is not present on that chip.
*
* Note: Do _not_ list chips with different name but same device ID twice!
* The result would be that the init code would be executed twice!
*/
static const struct logical_devices {
u8 superio_id;
int devs[MAX_LOGICAL_DEVICES];
} logical_device_table[] = {
/* Chip FDC PP SP1 SP2 RTC KBC AUX XBUS HWM GAME PME MPU RT ACPI SMB SP3 SP4 */
{LPC47M172,{0, 3, 4, 2, -1, 7, -1, -1, -1, -1, -1, -1, 10, -1, -1, -1, -1,}},
{FDC37B80X,{0, 3, 4, 5, -1, 7, 8, -1, -1, -1, -1, -1, -1, -1,
[coreboot] Re: No video output?
Hello Mogens, If you want to use LIBGFXINIT please disable VGA_BIOS and for SeaBIOS choose "Legacy VGA text mode" as framebuffer mode in "Display". Let us know if the problem remains after this. Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Thursday, January 23, 2020 12:41 PM, Mogens Jensen via coreboot wrote: > I have compiled coreboot from master branch (63fd650e2e) and flashed it to a > CompuLab Intense PC following this guide: > > https://watchmysys.com/blog/2017/12/coreboot-compulab-intense-pc-mintbox/ > > My problem is that video ouput is missing during POST, only after Linux > kernel starts booting, video output become available. This problem is > described in the guide and the solution is to include Intel VGA BIOS, which I > have done, but still no video ouput before Linux kernel. > > The guide is two years old, maybe something has changed in coreboot since > then, so more steps are required to get the video working? > > This is my defconfig: > > CONFIG_USE_BLOBS=y > CONFIG_VENDOR_COMPULAB=y > CONFIG_VGA_BIOS=y > CONFIG_VGA_BIOS_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbios.rom" > CONFIG_INTEL_GMA_VBT_FILE="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/ipc_vbt.rom" > CONFIG_ENABLE_MSATA=y > > CONFIG_DRIVERS_INTEL_WIFI is not set > > = > > CONFIG_IFD_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_0_flashdescriptor.bin" > CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_2_intel_me.bin" > CONFIG_GBE_BIN_PATH="3rdparty/blobs/mainboard/$(MAINBOARDDIR)/flashregion_3_gbe.bin" > CONFIG_HAVE_IFD_BIN=y > CONFIG_HAVE_ME_BIN=y > CONFIG_CHECK_ME=y > CONFIG_HAVE_GBE_BIN=y > CONFIG_MAINBOARD_USE_LIBGFXINIT=y > CONFIG_INTEL_GMA_ADD_VBT=y > CONFIG_SEABIOS_BOOTORDER_FILE="bootorder.txt" > > Any ideas on what I could be doing wrong? > > Regards, > Mogens Jensen > > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Sandybridge-M: Unable to compile board on 4.11 but works in 4.10
Happy holidays to all: My project is unable to compile/build on 4.11/master but do well with 4.10. It shows the following error: /home/fw_dev/Program_Files/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/bootblock/southbridge/intel/bd82x6x/early_pch.o: in function `early_pch_init': /home/fw_dev/Program_Files/coreboot/src/southbridge/intel/bd82x6x/early_pch.c:330: undefined reference to `mainboard_gpio_map' make: *** [src/arch/x86/Makefile.inc:125: build/cbfs/fallback/bootblock.debug] Error 1 Looks like `mainboard_gpio_map' is already defined on: #include What can I do to make it build successfully? The build log and project are attached here. I tried to upload the project to gerrit but for some reason failed (maybe needs some cleaning). Thank you, Jose Trujillo. HOSTCC util/sconfig/lex.yy.o HOSTCC util/sconfig/sconfig.tab.o HOSTCC util/sconfig/main.o HOSTCC util/sconfig/sconfig (link) SCONFIGmainboard/kontron/bSC2/devicetree.cb HOSTCC nvramtool/cli/nvramtool.o HOSTCC nvramtool/cli/opts.o HOSTCC nvramtool/cmos_lowlevel.o HOSTCC nvramtool/cmos_ops.o HOSTCC nvramtool/common.o HOSTCC nvramtool/compute_ip_checksum.o HOSTCC nvramtool/hexdump.o HOSTCC nvramtool/input_file.o HOSTCC nvramtool/layout.o HOSTCC nvramtool/accessors/layout-common.o HOSTCC nvramtool/accessors/layout-text.o HOSTCC nvramtool/accessors/layout-bin.o HOSTCC nvramtool/lbtable.o HOSTCC nvramtool/reg_expr.o HOSTCC nvramtool/cbfs.o HOSTCC nvramtool/accessors/cmos-mem.o HOSTCC nvramtool/nvramtool (link) OPTION option_table.h CC bootblock/mainboard/kontron/bSC2/static.o CC bootblock/arch/x86/boot.o CC bootblock/arch/x86/bootblock_crt0.o CC bootblock/arch/x86/cf9_reset.o CC bootblock/arch/x86/cpu_common.o GENbuild.h CC bootblock/arch/x86/id.o CC bootblock/arch/x86/memcpy.o HOSTCC cbfstool/fmaptool.o HOSTCC cbfstool/cbfs_sections.o HOSTCC cbfstool/fmap_from_fmd.o HOSTCC cbfstool/fmd.o HOSTCC cbfstool/fmd_parser.o HOSTCC cbfstool/fmd_scanner.o HOSTCC cbfstool/fmap.o HOSTCC cbfstool/kv_pair.o HOSTCC cbfstool/valstr.o HOSTCC cbfstool/fmaptool (link) FMAP build/util/cbfstool/fmaptool -h build/fmap_config.h build/fmap.fmd build/fmap.fmap SUCCESS: Wrote 266 bytes to file 'build/fmap.fmap' (and generated header) The sections containing CBFSes are: COREBOOT CP bootblock/arch/x86/memlayout.ld CC bootblock/arch/x86/memset.o CC bootblock/arch/x86/mmap_boot.o CC bootblock/arch/x86/timestamp.o CC bootblock/arch/x86/walkcbfs.o CC bootblock/commonlib/cbfs.o CC bootblock/commonlib/iobuf.o CC bootblock/commonlib/lz4_wrapper.o CC bootblock/commonlib/mem_pool.o CC bootblock/commonlib/region.o CC bootblock/console/console.o CC bootblock/console/die.o CC bootblock/console/init.o CC bootblock/console/post.o CC bootblock/console/printk.o CC bootblock/console/vsprintf.o CC bootblock/console/vtxprintf.o CC bootblock/cpu/intel/car/bootblock.o CC bootblock/cpu/intel/car/non-evict/cache_as_ram.o CC bootblock/cpu/intel/common/fsb.o CC bootblock/cpu/intel/microcode/microcode.o CC bootblock/cpu/intel/microcode/microcode_asm.o CC bootblock/cpu/intel/model_206ax/bootblock.o CC bootblock/cpu/x86/early_reset.o CC bootblock/cpu/x86/lapic/boot_cpu.o CC bootblock/cpu/x86/mtrr/debug.o CC bootblock/cpu/x86/mtrr/earlymtrr.o CC bootblock/cpu/x86/pae/pgtbl.o CC bootblock/cpu/x86/tsc/delay_tsc.o CC bootblock/device/device_const.o CC bootblock/device/i2c.o CC bootblock/device/mmio.o CC bootblock/device/pci_early.o CC bootblock/device/pci_ops.o CC bootblock/drivers/pc80/pc/i8254.o CC bootblock/drivers/pc80/rtc/mc146818rtc.o CC bootblock/drivers/pc80/rtc/mc146818rtc_boot.o CC bootblock/drivers/spi/adesto.o CC bootblock/drivers/spi/amic.o CC bootblock/drivers/spi/atmel.o CC bootblock/drivers/spi/bitbang.o CC bootblock/drivers/spi/eon.o CC bootblock/drivers/spi/gigadevice.o CC bootblock/drivers/spi/macronix.o CC bootblock/drivers/spi/spansion.o CC bootblock/drivers/spi/spi-generic.o CC bootblock/drivers/spi/spi_flash.o CC bootblock/drivers/spi/sst.o CC bootblock/drivers/spi/stmicro.o CC bootblock/drivers/spi/winbond.o CC
[coreboot] Re: Extended IvyBridge CPU configuration
Hello: I am also interested and will help test and I think it will be the best to leave it as CMOS option. Thank you Jose. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, December 17, 2019 5:12 PM, Evgeny Zinoviev via coreboot wrote: > Hi. > > As for HT, there's this patch: > https://review.coreboot.org/c/coreboot/+/29669 but it needs polishing > and testing. Last time I touched it, it worked good (or so it seemed to > me) on X220. If you have an interest and wish help to test, we could > finish it. > > (We also need to decide, whether to leave it as a CMOS option or turn > into a Kconfig option.) > > On 15.12.2019 15:57, Lars Hochstetter wrote: > > > Hi everyone, > > I'm looking for an option to configure my Intel IvyBridge CPU (enable > > / disable Hyperthreading, TurboBoost, set configurable TDP level etc.) > > using coreboot / nvramcui. My board is a Lenovo Thinkpad T430. So far, > > "only virtualization" is configurable and can not be enabled / > > disabled "in flight" but requires a rebuild of coreboot. > > Is anyone currently working on something similar? > > Is anything planned in that regard? > > Kind regards > > lhochstetter > > > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Tianocore: Long time to boot / Menu.
Hello All: I am sorry about the delay. > are you able to tell what's reading/writing the EFI variables? > what are the few lines right before the loop starts? Loading driver at 0x0007FB1B000 EntryPoint=0x0007FB1E34A EmuVariableRuntimeDxei InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7F8AC018 ProtectUefiImageCommon - 0x7F8AD640 - 0x7FB1B000 - 0x4FC0 PROGRESS CODE: V03040002 I0 Initialize buffer from 0x4 bytes of flash Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 > You probably have the edk2 side smmstore support added? > And maybe not the very latest coreboot side driver installed (Arthur pushed > some important fixes recently)? SMMSTORE was one of the reasons Patrick, thank you, I am glad to see this has been merged. Also the Tianocore smmstore patches were added into MrChromebox repository... Thank you Matt. I am using the default old smmstore driver from coreboot's 4.10 because this project has compilation errors in 4.11. This problem has been resolved. 3 issues were preventing tianocore from booting correctly: 1.- A driverless ATA device. 2.- SMMSTORE was disabled. 3.- LPC had issues and must be running continously. Now I got a reliable and fast booting to UEFI with persistent settings. Thank you for your help. Jose Trujillo. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Tianocore: Long time to boot / Menu.
Dear Patrick: I was thinking when I saw the EDK2 maillist that this is only for developers, not support. Also they kicked us the corebooters out early this year deprecating the coreboot dxe. I will delay the request to EDK2 maillist until I investigate and add the smmstore support. I will check the documentation on Monday and try to enable it. Thank you, Have an excellent weekend. Jose Trujillo ‐‐‐ Original Message ‐‐‐ On Friday, December 6, 2019 7:36 PM, Patrick Georgi wrote: > Am Fr., 6. Dez. 2019 um 17:23 Uhr schrieb Jose Trujillo via coreboot > : > >> Added variable: 0x0, val size: 0 >> Found variable: key size: 0x0, val size: 0 >> >> Several minutes later boots normal. >> If someone here knows how to fix it or suspect which could be the reason >> please let me know. >> I will ask for help in the EDK2 mail list too. > > You probably have the edk2 side smmstore support added? And maybe not the > very latest coreboot side driver installed (Arthur pushed some important > fixes recently)? > > I'm not sure if the edk2 mailing list is willing or able to help here, given > that this is a third-party addition from their point of view. > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Tianocore: Long time to boot / Menu.
Dear Matt/All: I enabled Tianocore debug in coreboot and the serial debug dump showed me Tianocore was trying to open a ATA / ATAPI device and was getting stuck there, so, i disabled a still driverless "ATA" device devicetree until I attach some driver. After flashing this change, the first boot/reboot will go without delay (normal fast tianocore boot) but after the second boot/reboot the serial dump shows the following long and repeated loop of the following: Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Added variable: 0x0, val size: 0 Found variable: key size: 0x0, val size: 0 Several minutes later boots normal. If someone here knows how to fix it or suspect which could be the reason please let me know. I will ask for help in the EDK2 mail list too. Thank you, Jose Trujillo. > are you getting serial output via it from coreboot? If not, enabling > Tianocore debug output is just going to make that boot time longer. > > I'd recommend disabling all serial output and seeing what your boot > time is then. If normal, then you know it's the culprit and can start > debugging the coreboot side of things > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.
Dear Nico: I am not a programmer to understand what you are saying. I will analize the involved code to try to understand. But I understand the general idea. I will do the changes and perform the tests and send you my proposal as soon as I can. Thank you, Jose. > Hi Jose (sorry for the name mixup earlier), > > On 04.12.19 15:01, Jose Trujillo wrote: > > > The libgfxinit solution works! > > Nice! > > > What to do next? > > I have a rough idea for an upstream solution: > > 1. Extend libgfxinit's API: > Scan_Ports() could get an optional parameter with predefined > configs, e.g. > > Static_Configs : in Pipe_Configs := All_Off_Configs; > > It should then mix these with auto-detected displays. > > 2. Extend GMA.Mainboard to provide the predefined configs. Not sure > here, it would need an update of all `gma-mainboard.ads` files > in coreboot. Probably could be done with some sed-foo. > > You can give that a shot, if you want. I won't have the time to look > into it by myself soon. > > Nico > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Tianocore: Long time to boot / Menu.
Hello Matt. I also remember when I was working with a baytrail system I had to attach something to the LPC device in order to prevent this... Once I correctly set the SIO under LPC the problem was gone. In this case I don't have a board's schematic available to see what is attached but I will start probing to try to find un-initialized hardware. This board was created by autoport. It's a Sandybridge based board and what I know is it has a Winbond w83627hg attached to LPC which driver I already added under LPC in devicetree. But this move didn't fixed this issue this time. I will choose the Tianocore debug to try to see debug information from it. Thank you, Jose Trujillo. > hi Jose, > > a long boot time in Tianocore usually means that you have serial output > enabled to a port that doesn't exist. Is this with a debug build? What board, > what serial port config? > > When I was first testing this years ago, it took 8 mins to boot on one board > because of this > > cheers, > Matt > > On Wed, Dec 4, 2019, 8:33 AM Jose Trujillo via coreboot > wrote: > >> Hello All: >> >> I am using the default Tianocore stable (Mr. Chromebox Matt version?) but is >> taking: >> 2minutes 30seconds from the appearance of the logo to the Tiano menu / grub >> bootloader. >> >> After entering the payload there is no more serial debug output. >> >> Anyone had this issue and knows the fix. >> Anyone of you know how to enable the serial debug output to Tiano. >> >> Any help will be very much appreciated. >> >> Thank you, >> Jose Trujillo. >> >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Tianocore: Long time to boot / Menu.
Hello All: I am using the default Tianocore stable (Mr. Chromebox Matt version?) but is taking: 2minutes 30seconds from the appearance of the logo to the Tiano menu / grub bootloader. After entering the payload there is no more serial debug output. Anyone had this issue and knows the fix. Anyone of you know how to enable the serial debug output to Tiano. Any help will be very much appreciated. Thank you, Jose Trujillo.___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.
Dear Nico: The libgfxinit solution works! Thank you very much What to do next? > If you get that working, we can try to design a reasonable API for pre- > defined modes. For instance, the `gma-mainboard.ads` could provide a > set of Pipe_Configs and we'd only scan for additional displays. That > would also be useful to skip EDID reading to speed things up ;) Jose Trujillo. > Hi Jorge, > > On 03.12.19 15:13, Jose Trujillo wrote: > > > > > This is my first try in booting coreboot on a LVDS panel. > > > > This is a Sandybridge-M system using video option ROM and VBT extracted > > > > from the original FW. > > > > > > if you ever want to get open-source gfx init running instead, let me > > > know. It would only need a few more lines to force a specific mode with > > > libgfxinit, maybe that is enough. And as you run the VBIOS ROM within > > > coreboot, you are probably not interested in a resident VBIOS, are you? > > > [JT]->[Nico] I would prefer to do it with just libgfxinit but I don't > > > have a remote idea in how to initialize the LVDS panel. > > > [JT]->[Nico] With a desktop monitor libgfxinit just work in this system > > > but not a sign of activity on the panel. > > > [JT]->[Nico] I would like to know how to initialize the panel with just > > > coreboot, so, please show me how. > > first, you have to > > select GFX_GMA_INTERNAL_IS_LVDS > > in your mainboard's Kconfig. > > As you mentioned, your panel doesn't have an EDID EEPROM. Hence, you'll > have to hard-code your panel's native mode. Below is a POC patch how > that could look like (allows combinations with LVDS and additional auto- > detected displays). You'll have to find your own panel's timings. Either > from the datasheet, or you can try to fetch them from the VBT, e.g. > > $ intel_vbt_decode lenovo/t430s/variants/t431s/data.vbt | grep timings > Underscan support for VGA timings: no > timings: 1600 1648 1680 1940 900 903 908 926 107800.00 (good) > > Note: The clock is given in kHz in the VBT, but libgfxinit expects Hz. > BPC (bits per color) is almost always 6 for LVDS panels, and I guess > sync high/low doesn't matter for LVDS. > > If you get that working, we can try to design a reasonable API for pre- > defined modes. For instance, the `gma-mainboard.ads` could provide a > set of Pipe_Configs and we'd only scan for additional displays. That > would also be useful to skip EDID reading to speed things up ;) > > Nico > > diff --git a/src/drivers/intel/gma/hires_fb/gma-gfx_init.adb > b/src/drivers/intel/gma/hires_fb/gma-gfx_init.adb > index 1393784d7b..b828e4ba28 100644 > --- a/src/drivers/intel/gma/hires_fb/gma-gfx_init.adb > +++ b/src/drivers/intel/gma/hires_fb/gma-gfx_init.adb > @@ -73,7 +73,32 @@ is > > if success then > ports := Mainboard.ports; > > - HW.GFX.GMA.Display_Probing.Scan_Ports (configs, ports); > > > > - HW.GFX.GMA.Display_Probing.Scan_Ports > > > - (Configs => configs, > > > - Ports=> ports, > > > - Max_Pipe => Secondary); -- limit to 2 auto-detected displays > > > - > - -- move auto-detected displays > > > - configs (Tertiary) := configs (Secondary); > > > - configs (Secondary) := configs (Primary); > > > - -- and use primary pipe for LVDS > > > - configs (Primary) := > > > - (Port=> Internal, > > > - Framebuffer => Default_FB, -- will be overridden below > > > - Cursor => Default_Cursor, > > > - Mode=> -- this matters > > > -(H_Visible => 1920, > > > - H_Sync_Begin => 2008, > > > - H_Sync_End => 2052, > > > - H_Total=> 2185, > > > - V_Visible => 1080, > > > - V_Sync_Begin => 1084, > > > - V_Sync_End => 1089, > > > - V_Total=> 1135, > > > - Dotclock => 60 * 2185 * 1135, -- 60Hz * H_Total * > > > > V_Total > > - BPC=> 6, > > > - H_Sync_Active_High => False, > > > - V_Sync_Active_High => False)); > > > > if configs (Primary).Port /= Disabled then > for i in Pipe_Index loop > > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.
I have no idea bro may be I am doing something wrong. This original FW of this embedded system is FULL OF BUGS... even the latest release. I can guess many of you don't have problems doing it this way. Maybe I have an early release of VBIOS which doesn't work with coreboot as expected. The libgfxinit solution given by our friend Nico today works. Later I will try another panel and variant of embedded system. Thank you, Jose Trujillo. > [Got it.] > > Does that mean coreboot+tianocore where it has to install GOP protocol and > can’t really working with VBIOS/OpRom? > > Thanks, > > Subrata > > From: Jose Trujillo [mailto:ce.au...@protonmail.com] > Sent: Wednesday, December 4, 2019 5:27 PM > To: Banik, Subrata > Subject: RE: [coreboot] Sandybridge-M help request in setting up LVDS panel. > > Dear Subrata: > > I got the pdf. > > I already tested all modes and even video mode 105 is showing only vertical > lines. > > 101 = 640x480 256 colors = vertical lines. > > 103 = 800x600 256 colors = vertical lines. > > 105 = 1024x768 256 colors = vertical lines. > > 111 = 640x480 64k colors = vertical lines. > > 112 = 640x480 16M colors = vertical lines. > > 114 = 800x600 64k colors = vertical lines. > > 115 = 800x600 16M colors = vertical lines. > > 117 = 1024x768 64k colors = vertical lines. > > 118 = 1024x768 16M colors = vertical lines. > > But in some modes when the system boots to linux it does with good video on > the panel. > > Just never good video on coreboot-tianocore. > > Jose. > >> >> >> FYI >> >> https://pdos.csail.mit.edu/6.828/2018/readings/hardware/vbe3.pdf >> >> Thanks, >> >> Subrata >> >> -Original Message- >> From: Banik, Subrata >> Sent: Wednesday, December 4, 2019 2:13 PM >> To: 'Jose Trujillo' >> Subject: RE: [coreboot] Sandybridge-M help request in setting up LVDS panel. >> >> HI Jose, >> >> I believe first you should try one off below mode to see if your display is >> working proper. >> >> Supported Video Mode list for OpRom: >> >> 105 >> >> 117 >> >> 118 >> >> 112 >> >> 114 >> >> 115 >> >> 101 >> >> 103 >> >> 111 >> >> I guess if you download VESA spec you might know about all those mode more >> and know what is supported X, Y and bit width. >> >> Thanks, >> >> Subrata >> >> -Original Message- >> >> From: Jose Trujillo [mailto:ce.au...@protonmail.com] >> >> Sent: Wednesday, December 4, 2019 2:10 PM >> >> To: Banik, Subrata >> >> Subject: RE: [coreboot] Sandybridge-M help request in setting up LVDS panel. >> >> Good morning Subrata: >> >> You were right! >> >> #116 doesn't appear on the list. >> >> Then how the original FW support it? >> >> I am even working (building and flashing) on this panel. >> >> Also remember even at video mode #118 the system halts with vertical lines. >> >> Any workaround for this? >> >> This panel is 1024x768@18bit and I will test another one 1024x768@24bit to >> see... >> >> CBFS: Locating 'pci8086,0116.rom' >> >> CBFS: Found @ offset 2d440 size 1 >> >> In CBFS, ROM address for PCI: 00:02.0 = ffe3d688 Copying VGA ROM Image from >> ffe3d688 to 0xc, 0xf200 bytes Calling Option ROM... >> >> intel_vga_int15_handler: AX=5f34 BX=c000 CX=0002 DX=03da >> >> intel_vga_int15_handler: AX=5f52 BX= CX=0002 DX=0008 Unknown INT15 >> function 5f52! >> >> int15 call returned error. >> >> intel_vga_int15_handler: AX=5f14 BX=078f CX=000a DX=fde8 Unknown INT15 >> function 5f14! >> >> int15 call returned error. >> >> intel_vga_int15_handler: AX=5f35 BX=c000 CX=0002 DX=03da >> >> intel_vga_int15_handler: AX=5f70 BX=c003 CX=0002 DX=0303 ... Option ROM >> returned. >> >> Supported Video Mode list for OpRom: >> >> 105 >> >> 117 >> >> 118 >> >> 112 >> >> 114 >> >> 115 >> >> 101 >> >> 103 >> >> 111 >> >> VBE: Getting information about VESA mode 4116 >> >> VBE: Function call failed! >> >> Error: In vbe_get_mode_info function >> >> Thank you, >> >> Jose Trujillo. >> >>> Hi Jose, >> >>> >> >>> Can you please try below code changes ? >> >>> >> >>> diff --git a/src/device/oprom/realmode/x86.c >> >>> b/src/device/oprom/realmode/x86.c index 0a5ede3..12c70cb 100644 >> >>> --- a/src/device/oprom/realmode/x86.c >> >>> +++ b/src/device/oprom/realmode/x86.c >> >>> @@ -437,6 +437,7 @@ void run_bios(struct device *dev, unsigned long >> >>> addr) realmode_call(addr + 0x0003, num_dev, 0x, 0x, 0x, >> >>> 0x0, 0x0); printk(BIOS_DEBUG, "... Option ROM returned.\n"); >> >>> >> >>> - vbe_oprom_supported_mode_list(); >> >>> >> >>> >> >>> >> >>> #if CONFIG(FRAMEBUFFER_SET_VESA_MODE) >> >>> if ((dev->class >> 8)== PCI_CLASS_DISPLAY_VGA) >> >>> >> >>> vbe_set_graphics(); >> >>> >> >>> >> >>> Thanks, >> >>> Subrata >> >>>___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Sandybridge-M help request in setting up LVDS panel.
Hello Friends > > Hello All! > > This is my first try in booting coreboot on a LVDS panel. > > This is a Sandybridge-M system using video option ROM and VBT extracted > > from the original FW. > > if you ever want to get open-source gfx init running instead, let me know. It > would only need a few more lines to force a specific mode with libgfxinit, > maybe that is enough. And as you run the VBIOS ROM within coreboot, you are > probably not interested in a resident VBIOS, are you? [JT]->[Nico] I would prefer to do it with just libgfxinit but I don't have a remote idea in how to initialize the LVDS panel. [JT]->[Nico] With a desktop monitor libgfxinit just work in this system but not a sign of activity on the panel. [JT]->[Nico] I would like to know how to initialize the panel with just coreboot, so, please show me how. [JT]->[Subrata] But also would like to know how to do it the right way with the blob. > > > VBE: Getting information about VESA mode 4116 > > What mode is this 4116? Are you sure, you need this specific mode? Are you > sure, your panel supports it? Sometimes, you need to specify a VBIOS (maybe > even VBT) specific code to use the panel's native resolution. > > [Subrata] VBE: resolution for 4116: 1024x768@16. Its depends on your panel > support and VBIOS support. > [JT] I just set at menuconfig 1024x768 1-5-5-5 and I have not idea why is reporting 4116-16 bit the intended is 18 bit. [JT]->[Subrata] Do I need to configure something else or create some code for this? > > VBE: Function call failed! > > Error: In vbe_get_mode_info function > > I don't think coreboot should halt here. Problems with the graphics are > non-fatal. > > [Subrata] Please have a look at > https://review.coreboot.org/c/coreboot/+/34284. What I found was sometime > Coreboot tries to fixed a mode which might not be supported by that VBIOS > hence we might see issue during payload and further because it would try to > map display to 0 resolution if mode set is not correct. Hence I had listed > the supported VESA mode in debug print. If you could try to use supported > one, it might work. [JT] Halts with a "die" function because anyway if is not halted it will be halted by Tianocore with division by zero. [JT]->[Subrata] The LVDS panel supports 1024x768 18 and 24 bit but the LVDS cable only can transfer 18 bits. [JT]->[Subrata] The original FW support those LVDS resolutions too and I suppose VBIOS too. [JT]->[Subrata] At 1024x768 1-5-5-5 is the only setting that shows signs of panel initialization and shows output on the panel but halts. [JT] The other 2 1024x768 variants shows vertical stripes on the panel and gets halted anyway. [JT] This system doesn't dump the list of supported VESA modes even if I comment the "die" function. Thank you, Jose Trujillo. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Sandybridge-M help request in setting up LVDS panel.
Hello All! This is my first try in booting coreboot on a LVDS panel. This is a Sandybridge-M system using video option ROM and VBT extracted from the original FW. The coreboot source was created using autoport. This same project boots to the OS using regular external DVI display. The panel doesn't have i2c ROM (DDC). Using the LCD LVDS panel shows the following in the screen and halts with post code 75 "Intel(R)Sandybridge Mobile PCI Accelerated SVGA BIOS" "DECOMPILATION OR DISASSEMBLY PROHIBITED" On the serial console shows the following: CBFS: 'Master Header Locator' located CBFS at [610200:80) CBFS: Locating 'pci8086,0116.rom' CBFS: Found @ offset 2d440 size 1 In CBFS, ROM address for PCI: 00:02.0 = ffe3d688 Copying VGA ROM Image from ffe3d688 to 0xc, 0xf200 bytes Calling Option ROM... intel_vga_int15_handler: AX=5f34 BX=c000 CX=0002 DX=03da intel_vga_int15_handler: AX=5f52 BX= CX=0002 DX=0008 Unknown INT15 function 5f52! int15 call returned error. intel_vga_int15_handler: AX=5f14 BX=078f CX=000a DX=fde8 Unknown INT15 function 5f14! int15 call returned error. intel_vga_int15_handler: AX=5f35 BX=c000 CX=0002 DX=03da intel_vga_int15_handler: AX=5f70 BX=c003 CX=0002 DX=0303 ... Option ROM returned. VBE: Getting information about VESA mode 4116 VBE: Function call failed! Error: In vbe_get_mode_info function -- Attached is the full serial debug dump. Any advise on what to do next? Any additional information do I need to provide? Thank you, any help will be very much appreciated. JTcoreboot-4.10-ae317695e3f03d55fbba1805ff06e004383e67c8 Mon Dec 2 16:05:12 UTC . Setting up static northbridge registers... done Initializing Graphics... Back from systemagent_early_init() POST: 0x38 SMBus controller enabled. POST: 0x39 POST: 0x3a Intel ME early init Intel ME firmware is ready ME: Requested 8MB UMA Starting native Platform init DMI: Running at X4 @ 5000MT/s FMAP: Found "FLASH" version 1.1 at 61. FMAP: base = ff80 size = 80 #areas = 4 FMAP: area RW_MRC_CACHE found @ 60 (65536 bytes) MRC: no data in 'RW_MRC_CACHE' SPD probe channel0, slot0 SPD probe channel0, slot1 SPD probe channel0, slot0 Rowaddr bits : 14 Column addr bits : 10 Number of ranks : 2 DIMM Capacity : 2048 MB CAS latencies : 6 7 8 9 tCKmin: 1.500 ns tAAmin: 13.125 ns tWRmin: 15.000 ns tRCDmin : 13.125 ns tRRDmin : 6.000 ns tRPmin: 13.125 ns tRASmin : 36.000 ns tRCmin: 49.125 ns tRFCmin : 110.000 ns tWTRmin : 7.500 ns tRTPmin : 7.500 ns tFAWmin : 30.000 ns channel[0] rankmap = 0x3 SPD probe channel0, slot1 SPD probe channel1, slot0 SPD probe channel1, slot1
Re: [coreboot] Coreboot and Kabylake FSP-M
Hello Roman, You need to provide the serial dump logs because I think very little amount of people here has access to the list of FSP post codes for every processor family (may be I am wrong but so far I don't know of someone who has them). Which coreboot platform are you using? Jose Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, November 29, 2018 6:09 PM, roman perepelitsin wrote: > Hi! > I'm try to run Coreboot on Intel Xeon1505L with C236 and DDR4 memory down > using kabylake FSP GOLD. I setup UART0 for coreboot console out and try to > set UART0 for FSP-M debug out, but have only POST codes to port80/81 from > FSP-M. In FSP integration guide I didn't find full POST-codes describe. > So - can some body help with this? My lasts post codes: DD46h DD30h DD32h > DD35h DD45h DD36h DD37h DD41h DD4Dh DD3fh. I think it MRC codes, but that > they mean - don't know. I see in oscilloscope, that DDR try to start in this > stage, but after all I have error from FSP-M 8007h. > > -- > regards, > Perepelitsin Roman-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Skylake (XHCI): System self start just after suspend S3.
Hello Naresh: > Just to add thought in HW perspective, Is VBUS to USB ports are stable > during S3 transition. Do you see any OC# lines getting asserted ? I do not have an oscilloscope on hand until Monday BUT I just borrowed from my programmer's colleagues another model of COM express carrier board and works stable (as it should). So, it's certain that is a hardware flaw and probably cause a glitch on +5V_SBY (just looking and comparing the schematics of both). Not a coreboot's fault... Sorry about that, let's move on and thank you very much for your support and showing me the right way. BTW: This interesting debug information you provided me I will keep on hand for future issues. Jose Trujillo. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Skylake (XHCI): System self start just after suspend S3.
Hello Naresh, Sorry for the delay, I had to rebuild the Linux kernel with the following flags disabled in order to get access to /dev/mem. CONFIG_STRICT_DEVMEM=n CONFIG_X86_PAT=n [root@localhost user]# ./iotools mmio_dump 0xd1220500 0x80 0xd1220500: 0x0603 0x 0x 0x 0xd1220510: 0x02a0 0x 0x 0x 0xd1220520: 0x02a0 0x 0x 0x 0xd1220530: 0x02a0 0x 0x 0x 0xd1220540: 0x02a0 0x 0x 0x 0xd1220550: 0x02a0 0x 0x 0x 0xd1220560: 0x02a0 0x 0x 0x 0xd1220570: 0x02a0 0x 0x 0x Just tell me if you need additional information. Thank you, Jose.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Skylake (XHCI): System self start just after suspend S3.
Naresh: > Can you provide kernel logs Partial kernel logs are attached showing failed and successful s3. > Also can you provided MMIO dump of PORTSC before & after S3 entry. I still don't know how to dump memory from fedora (could you suggest some tool?). > XHCI MMIO base can be found using command: > lspci -s 00:14.0 -vvvk # I guess bus 0, device 0x14, func 0 is XHCI ctrl. > region 0 is MMIO base Region 0: Memory at d122 (64-bit, non-prefetchable) [size=64K] > PORTSC for USB3 is in offset range 0x500-0x580. Still pending because I need a memory dumping tool/command... (I am investigating /dev/crash memory dump) please advise. Thank you, Jose. Suspend_OK_Kernel_Log Description: Binary data Failed_S3_Kernel_Log Description: Binary data XHCI_MMIO_base Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Skylake (XHCI): System self start just after suspend S3.
Hello Naresh, > You mean connecting device to USB3 cause wake immediately after S3 entry? No, if I use only USB mouse and keyboard connected to USB2 ports the computer will suspend correctly (if I click or execute the S3 command) and will not wake up (I did 60hour test) unless I push the power button or press any key on the USB keyboard. But, If I populate any USB3 port (XHCI) with any USB device (no matter if is USB2 or 3 compliant) the system will not go to suspension, just start again and resume the OS where it was. Connecting any USB device in a USB3 port is not waking up the system once the system is suspended. > Can you provide kernel logs Yes, I will do it today. > What device are you using? I am using Nico Huber's bSL6 COMe module from coreboot's Gerrit on a Kabylake bKL6 (with the same PCB layout) with of course KabyLake microcode and configuration in Kconfig. https://review.coreboot.org/c/coreboot/+/29480 I just added the bitmap for wake enable and other small things in devicetree. > Does behaviour changes if different device on USB3 is used ? No, anything connected on USB3 port will prevent suspension (USB2/3 thumb drive or keyboard/mouse)... > Also can you provided MMIO dump of PORTSC before & after S3 entry. I am working on it. Thank you, Jose Trujillo. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Skylake (XHCI): System self start just after suspend S3.
Dear coreboot engineers: My Skylake system S3 suspension fails because it wakes up immediately. If I connect the keyboard and mouse to USB2 ports and remove all USB devices from the USB3 ports then USB wake up works correctly until I connect something in the USB3 ports. If I disable XHCI as wake up source in linux can go to S3 state but USB wake up no longer works. Could it be missing configuration / ASL code?... a bug? Do somebody knows how to make it work correctly? Thank you, Jose Trujillo.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] uefi_nvs.bin in coreboot
Hello Ranga: From where you got this information / guide because I will try to do it myself. Jose. ‐‐‐ Original Message ‐‐‐ On Wednesday, November 21, 2018 7:28 PM, galla rao wrote: > Hi All, > > am trying to save NVRAM variables which are modifed in Uefi Payload, but i > could not save it. > > what is the role of uefi_nvs.bin file? > > coreboot/intel/mainboard/intel/bayleybay_fsp/uefi_nvs.bin > > Even the boot order does not save into NVRAM variables > > Can some one help me on this, Base address is given below > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase | 0xFFF6 > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase | 0xFFF7E000 > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase | 0xFFF8 > > In coreboot, i have given the same address > > [image.png] > > Thanks & Regards > Ranga-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
I agree.
‐‐‐ Original Message ‐‐‐
On Monday, November 19, 2018 3:35 PM, Zaolin wrote:
> Hey folks,
>
> I guess this is an integration option. IMHO Chipset lockdown should be a
> kconfig
>
> option and not be defined as part of the device tree.
>
> Maybe we should do a follow up and fix this issue. BTW same goes for SPI
> flash
>
> protection which should be interfaced globally, platform independent.
>
> BR, Zaolin
>
> On 19.11.18 13:04, Jose Trujillo via coreboot wrote:
>
> > Thank you Christian,
> > Works in my system too, Kabilake FSP2 issue?
> > The only small drawback is the disabled ability to upgrade coreboot from
> > itself which correct me if I am wrong is great in terms of security.
> > Do you know if there is still the possibility to enable HECI to flash SPI
> > in SMM mode even in CHIPSET_LOCKDOWN?
> > But now this system boots fast.
> > I owe you one bro.
> > Jose Trujillo
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, November 19, 2018 1:15 PM, Christian Gmeiner
> > christian.gmei...@gmail.com wrote:
> >
> > > Hi
> > > Am Fr., 16. Nov. 2018 um 15:57 Uhr schrieb Jose Trujillo via coreboot
> > > coreboot@coreboot.org:
> > >
> > > > Hello coreboot engineers:
> > > > My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp"
> > > > platforms with properly configured I/O failed to save Memory training
> > > > data to the SPI cache 'RW_MRC_CACHE'.
> > > > FMAP: Found "FLASH" version 1.1 at d0.
> > > > FMAP: base = ff00 size = 100 #areas = 4
> > > > FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes)
> > > > MRC: Checking cached data update for 'RW_MRC_CACHE'.
> > > > SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total
> > > > 0x10
> > > > MRC: no data in 'RW_MRC_CACHE'
> > > > MRC: cache data 'RW_MRC_CACHE' needs update.
> > > > SPI Transaction Error at Flash Offset d1 HSFSTS = 0x01046003
> > > > REGF metadata allocation failed: 392 data blocks 4096 total blocks
> > > > MRC: Could not find region 'UNIFIED_MRC_CACHE'
> > > > FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes)
> > > > MRC: NOT enabling PRR for 'RW_MRC_CACHE'
> > > > As a consequence fast boot never works. (fast boot works correctly on
> > > > my coffeelake system).
> > > > Nico helped me to test the system ability to save data to the MRC_CACHE
> > > > block from linux booting coreboot and I wrote random data to the
> > > > 'RW_MRC_CACHE' block with the "flashrom" tool succesfully.
> > > > Maybe someone that had experience with this issue or have some idea how
> > > > to fix it can give me advise on how to resolve this problem.
> > > > I run into the same
> > > > problem:https://review.coreboot.org/c/coreboot/+/29159
> > >
> > > Make sure you have this block in your devicetree.cb
> > >
> > > Lock Down
> > >
> > > ==
> > >
> > > register "common_soc_config" = "{
> > > .chipset_lockdown = CHIPSET_LOCKDOWN_COREBOOT,
> > > }"
> > >
> > > greets
> > >
> > > Christian Gmeiner, MSc
> > > https://christian-gmeiner.info
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
Thank you Christian,
Works in my system too, Kabilake FSP2 issue?
The only small drawback is the disabled ability to upgrade coreboot from itself
which correct me if I am wrong is great in terms of security.
Do you know if there is still the possibility to enable HECI to flash SPI in
SMM mode even in CHIPSET_LOCKDOWN?
But now this system boots fast.
I owe you one bro.
Jose Trujillo
‐‐‐ Original Message ‐‐‐
On Monday, November 19, 2018 1:15 PM, Christian Gmeiner
wrote:
> Hi
>
> Am Fr., 16. Nov. 2018 um 15:57 Uhr schrieb Jose Trujillo via coreboot
> coreboot@coreboot.org:
>
> > Hello coreboot engineers:
> > My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp" platforms
> > with properly configured I/O failed to save Memory training data to the SPI
> > cache 'RW_MRC_CACHE'.
> > FMAP: Found "FLASH" version 1.1 at d0.
> > FMAP: base = ff00 size = 100 #areas = 4
> > FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes)
> > MRC: Checking cached data update for 'RW_MRC_CACHE'.
> > SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total
> > 0x10
> > MRC: no data in 'RW_MRC_CACHE'
> > MRC: cache data 'RW_MRC_CACHE' needs update.
> > SPI Transaction Error at Flash Offset d1 HSFSTS = 0x01046003
> > REGF metadata allocation failed: 392 data blocks 4096 total blocks
> > MRC: Could not find region 'UNIFIED_MRC_CACHE'
> > FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes)
> > MRC: NOT enabling PRR for 'RW_MRC_CACHE'
> > As a consequence fast boot never works. (fast boot works correctly on my
> > coffeelake system).
> > Nico helped me to test the system ability to save data to the MRC_CACHE
> > block from linux booting coreboot and I wrote random data to the
> > 'RW_MRC_CACHE' block with the "flashrom" tool succesfully.
> > Maybe someone that had experience with this issue or have some idea how to
> > fix it can give me advise on how to resolve this problem.
>
> I run into the same problem:https://review.coreboot.org/c/coreboot/+/29159
>
> Make sure you have this block in your devicetree.cb
>
> # Lock Down
> register "common_soc_config" = "{
> .chipset_lockdown = CHIPSET_LOCKDOWN_COREBOOT,
> }"
>
> ---
>
> greets
>
> ---
>
> Christian Gmeiner, MSc
>
> https://christian-gmeiner.info
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Kabylake H: SPI Transaction Error at Flash Offset d10000
Hello coreboot engineers: My Kabylake H system "HM175" with coreboot "bsl6" and "kblrvp" platforms with properly configured I/O failed to save Memory training data to the SPI cache 'RW_MRC_CACHE'. FMAP: Found "FLASH" version 1.1 at d0. FMAP: base = ff00 size = 100 #areas = 4 FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes) MRC: Checking cached data update for 'RW_MRC_CACHE'. SF: Detected FAST_SPI Hardware Sequencer with sector size 0x1000, total 0x10 MRC: no data in 'RW_MRC_CACHE' MRC: cache data 'RW_MRC_CACHE' needs update. SPI Transaction Error at Flash Offset d1 HSFSTS = 0x01046003 REGF metadata allocation failed: 392 data blocks 4096 total blocks MRC: Could not find region 'UNIFIED_MRC_CACHE' FMAP: area RW_MRC_CACHE found @ d1 (65536 bytes) MRC: NOT enabling PRR for 'RW_MRC_CACHE' As a consequence fast boot never works. (fast boot works correctly on my coffeelake system). Nico helped me to test the system ability to save data to the MRC_CACHE block from linux booting coreboot and I wrote random data to the 'RW_MRC_CACHE' block with the "flashrom" tool succesfully. Maybe someone that had experience with this issue or have some idea how to fix it can give me advise on how to resolve this problem. I attached the full log. Thank you, Jose Trujillo. KL-H_dump Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Video not seen with BayTrail-I platform Board which has DVI/HDMI interface
I never needed to make changes to vga.dat on my E3845 system. The vga.dat was taken from the FSP package the same as you. The coreboot version that I used was 4.7. ‐‐‐ Original Message ‐‐‐ On Thursday, November 8, 2018 2:02 PM, galla rao wrote: > Hi Jose, > > Thanks for a quick response > > Enabled framebuffer in Config as given in inserted picture and am using > uefipayload but not seabios > > [image.png] > > To add more to this > > MinnowMax + VGA -> Display is seen > BayleyBay + VGA -> Display is not seen > > Does the FSP-master\FSP-master\BayTrailFspBinPkg\Vbios\vga.dat needs any > change? > > Do you think in the hardware the DDI0, DDI1 pins and clk/data can have an > impact and needs to be measured > > Regards > Ranga > > On Thu, Nov 8, 2018 at 10:16 AM Jose Trujillo wrote: > >> Hello Ranga: >> >> If you are using tianocore as payload you should choose vesa framebuffer >> option and text mode in seabios >> JT >> >> ‐‐‐ Original Message ‐‐‐ >> On Thursday, November 8, 2018 1:08 PM, galla rao >> wrote: >> >>> Hi All, >>> >>> Am facing Gfx Enablement failure, i don't see any Video output on my screen >>> >>> Config file has below settings >>> >>> CONFIG_VGA_BIOS_ID="8086,0f31" >>> CONFIG_DRIVERS_PS2_KEYBOARD is not set >>> CONFIG_ONBOARD_VGA_IS_PRIMARY=y >>> CONFIG_VGA_BIOS=y >>> CONFIG_UDELAY_IO is not set >>> CONFIG_DCACHE_RAM_BASE=0xfef0 >>> CONFIG_DCACHE_RAM_SIZE=0x4000 >>> CONFIG_ACPI_SSDTX_NUM=0 >>> CONFIG_VGA_BIOS_FILE="../intel/cpu/baytrail/vbios/Vga.dat" >>> CONFIG_PCI_64BIT_PREF_MEM is not set >>> >>> BIOS log specific to Video output onto terminal >>> >>> VLV SSA Platform Policy dump Begin --- >>> Graphics Configuration: >>> GttSize : 2 MB >>> IgdDvmt50PreAlloc : 2 >>> PrimaryDisplay : 0 >>> ApertureSize : 2 >>> Turbo Enable : 1 >>> >>> IGD enabled. >>> >>> dGFXBase = 0x7BE0 >>> >>> Do i need to configure any setting in >>> \FSP-master\FSP-master\BayTrailFspBinPkg\Vbios\vga.bsf file from BCT? >>> >>> Please let me know what could be the reason and if anyone has seen such >>> behavior earlier >>> >>> Best Regards >>> Ranga-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoffeeLake RVP master: Code changed... How to enable SATA and LAN?
Dear Lance: Yesterday I managed to make internal GbE to work with the following: # Enable Root port 4 (PCIe port 5) for GbE register "PcieRpEnable[4]" = "1" register "PcieClkSrcUsage[0]" = "PCIE_CLK_LAN" register "PcieClkSrcClkReq[0]" = "0" Works fine But I am trying to enable NVMe and PCIe slots with the following: # Enable Root port 8 (PCIe port 9) for NVMe register "PcieRpEnable[8]" = "1" register "PcieClkSrcUsage[2]" = "8" register "PcieClkSrcClkReq[2]" = "2" # Enable Root port 12 (PCIe port 13) for x1 Slot register "PcieRpEnable[12]" = "1" register "PcieClkSrcUsage[1]" = "12" register "PcieClkSrcClkReq[1]" = "1" Neither NVMe and PCIe works. What could be still missing? Also I still have problems with SATA unable to partition, format neither install an OS. Tomorrow I will update coreboot to see if there is some improvement. Any Idea or hint will be appreciated. Thank you, Jose.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Video not seen with BayTrail-I platform Board which has DVI/HDMI interface
Check the GPIOs in your schematic. maybe you need to enable something. ‐‐‐ Original Message ‐‐‐ On Thursday, November 8, 2018 2:02 PM, galla rao wrote: > Hi Jose, > > Thanks for a quick response > > Enabled framebuffer in Config as given in inserted picture and am using > uefipayload but not seabios > > [image.png] > > To add more to this > > MinnowMax + VGA -> Display is seen > BayleyBay + VGA -> Display is not seen > > Does the FSP-master\FSP-master\BayTrailFspBinPkg\Vbios\vga.dat needs any > change? > > Do you think in the hardware the DDI0, DDI1 pins and clk/data can have an > impact and needs to be measured > > Regards > Ranga > > On Thu, Nov 8, 2018 at 10:16 AM Jose Trujillo wrote: > >> Hello Ranga: >> >> If you are using tianocore as payload you should choose vesa framebuffer >> option and text mode in seabios >> JT >> >> ‐‐‐ Original Message ‐‐‐ >> On Thursday, November 8, 2018 1:08 PM, galla rao >> wrote: >> >>> Hi All, >>> >>> Am facing Gfx Enablement failure, i don't see any Video output on my screen >>> >>> Config file has below settings >>> >>> CONFIG_VGA_BIOS_ID="8086,0f31" >>> CONFIG_DRIVERS_PS2_KEYBOARD is not set >>> CONFIG_ONBOARD_VGA_IS_PRIMARY=y >>> CONFIG_VGA_BIOS=y >>> CONFIG_UDELAY_IO is not set >>> CONFIG_DCACHE_RAM_BASE=0xfef0 >>> CONFIG_DCACHE_RAM_SIZE=0x4000 >>> CONFIG_ACPI_SSDTX_NUM=0 >>> CONFIG_VGA_BIOS_FILE="../intel/cpu/baytrail/vbios/Vga.dat" >>> CONFIG_PCI_64BIT_PREF_MEM is not set >>> >>> BIOS log specific to Video output onto terminal >>> >>> VLV SSA Platform Policy dump Begin --- >>> Graphics Configuration: >>> GttSize : 2 MB >>> IgdDvmt50PreAlloc : 2 >>> PrimaryDisplay : 0 >>> ApertureSize : 2 >>> Turbo Enable : 1 >>> >>> IGD enabled. >>> >>> dGFXBase = 0x7BE0 >>> >>> Do i need to configure any setting in >>> \FSP-master\FSP-master\BayTrailFspBinPkg\Vbios\vga.bsf file from BCT? >>> >>> Please let me know what could be the reason and if anyone has seen such >>> behavior earlier >>> >>> Best Regards >>> Ranga-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Video not seen with BayTrail-I platform Board which has DVI/HDMI interface
Hello Ranga: If you are using tianocore as payload you should choose vesa framebuffer option and text mode in seabios JT ‐‐‐ Original Message ‐‐‐ On Thursday, November 8, 2018 1:08 PM, galla rao wrote: > Hi All, > > Am facing Gfx Enablement failure, i don't see any Video output on my screen > > Config file has below settings > > CONFIG_VGA_BIOS_ID="8086,0f31" > CONFIG_DRIVERS_PS2_KEYBOARD is not set > CONFIG_ONBOARD_VGA_IS_PRIMARY=y > CONFIG_VGA_BIOS=y > CONFIG_UDELAY_IO is not set > CONFIG_DCACHE_RAM_BASE=0xfef0 > CONFIG_DCACHE_RAM_SIZE=0x4000 > CONFIG_ACPI_SSDTX_NUM=0 > CONFIG_VGA_BIOS_FILE="../intel/cpu/baytrail/vbios/Vga.dat" > CONFIG_PCI_64BIT_PREF_MEM is not set > > BIOS log specific to Video output onto terminal > > VLV SSA Platform Policy dump Begin --- > Graphics Configuration: > GttSize : 2 MB > IgdDvmt50PreAlloc : 2 > PrimaryDisplay : 0 > ApertureSize : 2 > Turbo Enable : 1 > > IGD enabled. > > dGFXBase = 0x7BE0 > > Do i need to configure any setting in > \FSP-master\FSP-master\BayTrailFspBinPkg\Vbios\vga.bsf file from BCT? > > Please let me know what could be the reason and if anyone has seen such > behavior earlier > > Best Regards > Ranga-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] CoffeeLake RVP master: Code changed... How to enable SATA and LAN?
Hello coreboot developers: Looks that coreboot development has been very active lately integrating FSP, adding new platforms and getting ready for the 4.9 release. And also I can see new payloads "WOW" (like LinuxBoot, Yabits)... what a revolution of features and code. I am using coreboot "master" from yesterday and using CoffeeLake RVP tree on my CoffeeLake H (non RVP) system and reconfiguring . I am in the process of testing the functionality of coreboot on my devices and I know I need to wait for the release. I am trying to figure out how is going to be the way of enabling SATA and LAN (and other devices) on the platforms with renewed code. 1.- In "device pci" list of devicetree.cb file (that previously had issues). 2.- As register in devicetree.cb (EnableLan and EnableSata no longer works). 3.- Kconfig or somewere else. I am trying several ways to enable LAN and SATA in the "user domain" code but failed. Unless I still have something not configured correctly I would like to know the right way of enable those devices. Thank you all, Jose.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
Lance: I followed your advice and fetched coreboot master today and now entered into the payload domain "0xF8" Still have problems because tianocore does not load the operating system and other issues but this is another story for tomorrow. Thank you, Jose. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 31, 2018 4:08 AM, Lance Zhao wrote: > Feels like CoffeeLake RVP11 still been actively uploaded with newer changes. > But at least your coreboot code seems to be outdated, all of those > coffeelake-h related ID(CPUID and MCH/PCHID) had been up-streamed recently. I > will suggest you to sync up your code base and try again. > > Lance > > On Tue, Oct 30, 2018 at 7:10 AM Jose Trujillo via coreboot > wrote: > >> Hello coreboot engineers: >> >> I am using the "coffeelake RVP11" to test the code on my "non RVP" system. >> The payload doesn't load. >> >> I found several errors in the attached log: >> >> 1.- Device ID's of the system are still not existant in coreboot. >> 2.- Misconfigured # of MAX CPU CORES. >> 3.- Maybe memory is still not properly initialized because RVP platform uses >> LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD >> channel. >> >> Please help me to identify the root of the problem that causes RAM "Failed >> Segment" >> Thank you in advance. >> Jose Trujillo. >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
XIP was already selected, the FSP headers updated and the right platform chosen... so, i didn't know what to do, that was the reason I decided to test on previous version. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 31, 2018 9:13 AM, Lance Zhao wrote: > The "Invalid FSPM signature" at this stage, if FspUpd.h for coffeelake > already there. maybe "XIP mode" had not been selected in config file? > > On Tue, Oct 30, 2018 at 10:42 PM Jose Trujillo > wrote: > >> Thank you Lance; >> >> I got back to 4.8.1 because on master of 2 weeks ago I was getting post code >> 0x34 "Invalid FSPM signature"; but I will try again. >> Coreboot engineers have been doing much work on integrating FSP to coreboot >> and may be the reason has been unstable. >> >> Jose. >> >> ‐‐‐ Original Message ‐‐‐ >> On Wednesday, October 31, 2018 4:08 AM, Lance Zhao >> wrote: >> >>> Feels like CoffeeLake RVP11 still been actively uploaded with newer >>> changes. But at least your coreboot code seems to be outdated, all of those >>> coffeelake-h related ID(CPUID and MCH/PCHID) had been up-streamed recently. >>> I will suggest you to sync up your code base and try again. >>> >>> Lance >>> >>> On Tue, Oct 30, 2018 at 7:10 AM Jose Trujillo via coreboot >>> wrote: >>> >>>> Hello coreboot engineers: >>>> >>>> I am using the "coffeelake RVP11" to test the code on my "non RVP" system. >>>> The payload doesn't load. >>>> >>>> I found several errors in the attached log: >>>> >>>> 1.- Device ID's of the system are still not existant in coreboot. >>>> 2.- Misconfigured # of MAX CPU CORES. >>>> 3.- Maybe memory is still not properly initialized because RVP platform >>>> uses LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD >>>> channel. >>>> >>>> Please help me to identify the root of the problem that causes RAM "Failed >>>> Segment" >>>> Thank you in advance. >>>> Jose Trujillo. >>>> -- >>>> coreboot mailing list: coreboot@coreboot.org >>>> https://mail.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
Thank you Lance; I got back to 4.8.1 because on master of 2 weeks ago I was getting post code 0x34 "Invalid FSPM signature"; but I will try again. Coreboot engineers have been doing much work on integrating FSP to coreboot and may be the reason has been unstable. Jose. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 31, 2018 4:08 AM, Lance Zhao wrote: > Feels like CoffeeLake RVP11 still been actively uploaded with newer changes. > But at least your coreboot code seems to be outdated, all of those > coffeelake-h related ID(CPUID and MCH/PCHID) had been up-streamed recently. I > will suggest you to sync up your code base and try again. > > Lance > > On Tue, Oct 30, 2018 at 7:10 AM Jose Trujillo via coreboot > wrote: > >> Hello coreboot engineers: >> >> I am using the "coffeelake RVP11" to test the code on my "non RVP" system. >> The payload doesn't load. >> >> I found several errors in the attached log: >> >> 1.- Device ID's of the system are still not existant in coreboot. >> 2.- Misconfigured # of MAX CPU CORES. >> 3.- Maybe memory is still not properly initialized because RVP platform uses >> LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD >> channel. >> >> Please help me to identify the root of the problem that causes RAM "Failed >> Segment" >> Thank you in advance. >> Jose Trujillo. >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] CoffeeLake RVP11: Post code 0x7A "SELF Payload doesn't target RAM:
Hello coreboot engineers: I am using the "coffeelake RVP11" to test the code on my "non RVP" system. The payload doesn't load. I found several errors in the attached log: 1.- Device ID's of the system are still not existant in coreboot. 2.- Misconfigured # of MAX CPU CORES. 3.- Maybe memory is still not properly initialized because RVP platform uses LPDDR4 and use SPD.bin VS my system that use DDR4 SO-UDIMM on SMB SPD channel. Please help me to identify the root of the problem that causes RAM "Failed Segment" Thank you in advance. Jose Trujillo. CL_serial_dump Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Basic bios info
Corrected link: http://opensecuritytraining.info/IntroBIOS.html ‐‐‐ Original Message ‐‐‐ On Wednesday, October 24, 2018 1:07 PM, wrote: > Can any one recommend a source for basic pc bios info? There's a lot to > learn and some good links would be greatly appreciated. I'm a geek but I > don't know much about bios code, data structures relevant to bioses, etc.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Basic bios info
Hello: opensecuritytraining.info/introBIOS.html Good day. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 24, 2018 1:07 PM, wrote: > Can any one recommend a source for basic pc bios info? There's a lot to > learn and some good links would be greatly appreciated. I'm a geek but I > don't know much about bios code, data structures relevant to bioses, etc.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
Zvika: The microcode you downloaded doesn't include the binary for your system... read the release notes. 6, 55, 9 = 06-37-09 Download this: https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu30679_plat0F_ver090A_2018-01-10_PRD_252563C5.bin Rename this bin to:06-37-09 Add the path in "Microcode binary path and filename" And try again! Jose ‐‐‐ Original Message ‐‐‐ On Wednesday, October 17, 2018 12:06 AM, Zvi Vered wrote: > Hi Jose, > > In menuconfig I have the following options in "Include CPU microcode in CBFS" > 1. Generate from tree (current selection) > 2. Include external microcode header files > 3. Do not include microcode updates > > I downloaded the file: microcode-20180807a.tgz > > The output of /proc/cpuinfo is: > processor: 0 > vendor_id: GenuineIntel > cpu family: 6 > model: 55 > model name: Intel(R) Atom(TM) CPU E3845 @ 1.91GHz > stepping: 9 > microcode: 0x90a > ... > > But the folder intel-ucode has no file named: 06-55-09 > Does it mean that my CPU does not require micocode ? > > Thank you in advance, > Zvika > > On Tue, Oct 16, 2018 at 8:49 AM Jose Trujillo wrote: > >> Good day Zvika: >> >> Looks typical the configuration >> But for DIMM Density to get this information you should run the command I >> told you yesterday or check the memory chip datasheet. >> >> About the 0xCE postcode you need to set the microcode (or the correct one, >> or the correct path) in menuconfig. >> >> Jose. >> >> ‐‐‐ Original Message ‐‐‐ >> On Tuesday, October 16, 2018 6:41 AM, Zvi Vered wrote: >> >>> Hi Jose, All, >>> >>> According to the following outputs, it seems my target has SPD EEPROM. >>> If I understand correctly from your reply, I should modify only: >>> DRAM Type: DDR3 >>> DRAM Speed: 1333 MT/s >>> DIMM 0 Enable: Enabled >>> DIMM 1 Enable: Disabled >>> DIMM_DWidth: x8 >>> DIMM_Density: ??? (Default is 2Gbit) >>> DIMM_BusWidth: 64 >>> DIMM_Sides: 1 Ranks >>> >>> Am I right ? >>> >>> I tried booting the target with the modified FSP and got post code : 0xCE >>> There is nothing on the 232 console. >>> There is no such post code in coreboot code. >>> Is it possible that FSP is sending post code ? >>> How can I proceed from here? >>> >>> Thank you very much, >>> Zvika >>> >>> ** sensors-detect >>> >>> >>> Probing for `SPD EEPROM'... Yes >>> (confidence 8, not a hardware monitoring chip) >>> . >>> ** dmidecode >>> *** >>> . >>> Handle 0x0009, DMI type 17, 34 bytes >>> Memory Device >>> Array Handle: 0x0008 >>> Error Information Handle: Not Provided >>> Total Width: 72 bits >>> Data Width: 64 bits >>> Size: 4096 MB >>> Form Factor: SODIMM >>> Set: None >>> Locator: DIMM0 >>> Bank Locator: BANK 0 >>> Type: DDR3 >>> Type Detail: Synchronous >>> Speed: 1333 MHz >>> Manufacturer: 00 >>> Serial Number: >>> Asset Tag: Unknown >>> Part Number: >>> Rank: Unknown >>> Configured Clock Speed: 1333 MHz >>> >>> Handle 0x000B, DMI type 17, 34 bytes >>> Memory Device >>> Array Handle: 0x0008 >>> Error Information Handle: Not Provided >>> Total Width: Unknown >>> Data Width: Unknown >>> Size: No Module Installed >>> Form Factor: SODIMM >>> Set: None >>> Locator: DIMM1 >>> Bank Locator: BANK 1 >>> Type: Unknown >>> Type Detail: None >>> Speed: Unknown >>> Manufacturer: Not Specified >>> Serial Number: Not Specified >>> Asset Tag: Unknown >>> Part Number: Not Specified >>> Rank: Unknown >>> Configured Clock Speed: Unknown >>> >>> ***decode-dimms** >>> # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) >>> >>> Memory Serial Presence Detect Decoder >>> By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, >>> Jean Delvare, Trent Piepho and others >>> >>> Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/8-0050 >>> Guessing DIMM is in bank 1 >>> >>> ---=== SPD EEPROM Information ===--- >>> EEPROM CRC of bytes 0-116 OK (0x59A6) >>> # of bytes written to SDRAM EEPROM 176 >>> Total number of bytes in EEPROM 256 >>> Fundamental Memory type DDR3 SDRAM >>> Module Type 72b-SO-UDIMM >>> >>> ---=== Memory Characteristics ===--- >>> Fine time base 1.000 ps >>> Medium time base0.125 ns >>> Maximum module speed1333 MHz (PC3-10600) >>> Size4096 MB >>> Banks x Rows x Columns x Bits 8 x 16 x 10 x 64 >>> Ranks 1 >>> SDRAM Device Width 8 bits >>> Bus Width Extension 8 bits >>> tCL-tRCD-tRP-tRAS
Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
Good day Zvika: Looks typical the configuration But for DIMM Density to get this information you should run the command I told you yesterday or check the memory chip datasheet. About the 0xCE postcode you need to set the microcode (or the correct one, or the correct path) in menuconfig. Jose. ‐‐‐ Original Message ‐‐‐ On Tuesday, October 16, 2018 6:41 AM, Zvi Vered wrote: > Hi Jose, All, > > According to the following outputs, it seems my target has SPD EEPROM. > If I understand correctly from your reply, I should modify only: > DRAM Type: DDR3 > DRAM Speed: 1333 MT/s > DIMM 0 Enable: Enabled > DIMM 1 Enable: Disabled > DIMM_DWidth: x8 > DIMM_Density: ??? (Default is 2Gbit) > DIMM_BusWidth: 64 > DIMM_Sides: 1 Ranks > > Am I right ? > > I tried booting the target with the modified FSP and got post code : 0xCE > There is nothing on the 232 console. > There is no such post code in coreboot code. > Is it possible that FSP is sending post code ? > How can I proceed from here? > > Thank you very much, > Zvika > > ** sensors-detect > > > Probing for `SPD EEPROM'... Yes > (confidence 8, not a hardware monitoring chip) > . > ** dmidecode > *** > . > Handle 0x0009, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0008 > Error Information Handle: Not Provided > Total Width: 72 bits > Data Width: 64 bits > Size: 4096 MB > Form Factor: SODIMM > Set: None > Locator: DIMM0 > Bank Locator: BANK 0 > Type: DDR3 > Type Detail: Synchronous > Speed: 1333 MHz > Manufacturer: 00 > Serial Number: > Asset Tag: Unknown > Part Number: > Rank: Unknown > Configured Clock Speed: 1333 MHz > > Handle 0x000B, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0008 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: No Module Installed > Form Factor: SODIMM > Set: None > Locator: DIMM1 > Bank Locator: BANK 1 > Type: Unknown > Type Detail: None > Speed: Unknown > Manufacturer: Not Specified > Serial Number: Not Specified > Asset Tag: Unknown > Part Number: Not Specified > Rank: Unknown > Configured Clock Speed: Unknown > > ***decode-dimms** > # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) > > Memory Serial Presence Detect Decoder > By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, > Jean Delvare, Trent Piepho and others > > Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/8-0050 > Guessing DIMM is in bank 1 > > ---=== SPD EEPROM Information ===--- > EEPROM CRC of bytes 0-116 OK (0x59A6) > # of bytes written to SDRAM EEPROM 176 > Total number of bytes in EEPROM 256 > Fundamental Memory type DDR3 SDRAM > Module Type 72b-SO-UDIMM > > ---=== Memory Characteristics ===--- > Fine time base 1.000 ps > Medium time base0.125 ns > Maximum module speed1333 MHz (PC3-10600) > Size4096 MB > Banks x Rows x Columns x Bits 8 x 16 x 10 x 64 > Ranks 1 > SDRAM Device Width 8 bits > Bus Width Extension 8 bits > tCL-tRCD-tRP-tRAS 9-9-9-24 > Supported CAS Latencies (tCL) 10T, 9T, 8T, 7T, 6T > > ---=== Timing Parameters ===--- > Minimum Write Recovery time (tWR) 15.000 ns > Minimum Row Active to Row Active Delay (tRRD) 6.000 ns > Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns > Minimum Recovery Delay (tRFC) 260.000 ns > Minimum Write to Read CMD Delay (tWTR) 7.500 ns > Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns > Minimum Four Activate Window Delay (tFAW) 30.000 ns > > ---=== Optional Features ===--- > Operable voltages 1.5V, 1.35V > RZQ/6 supported?Yes > RZQ/7 supported?Yes > DLL-Off Mode supported? Yes > Operating temperature range 0-95 degrees C > Refresh Rate in extended temp range 1X > Auto Self-Refresh? No > On-Die Thermal Sensor readout? No > Partial Array Self-Refresh? No > Thermal Sensor Accuracy Not implemented > SDRAM Device Type Standard Monolithic > > ---=== Manufacturer Data ===--- > Module Manufacturer Invalid > Part Number Undefined > > Number of SDRAM
Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
Zvika: In my experience with my Baytrail system I can tell you my system is "really" memory down because has soldered memory chips on the motherboard BUT has also a soldered SPD memory so, if keep "Enable Memory Down = Disabled" in BCT the system fetch memory timings from SPD so, no need to edit memory timings but other things like "DRAM Speed" and "DRAM Type" and other settings (not timings) needs to be edited. but if still needed to edit timings extract them from SPD with "i2c-tools-perl" I alredy sent you this information in previous emails and attachments so, look for this. Good luck, Jose. ‐‐‐ Original Message ‐‐‐ On Friday, October 12, 2018 7:29 PM, Zvi Vered wrote: > Hello, > > The BCT has a "Memory Down" section. > Can you please advise how can I know the right values for my board ? > > DIMM 0/1 Enable: > DIMM DWidth: > DIMM Density: > DIMM_BusWidth: > DIMM Sides: > tCL: > tRP_tRCD: > tWR: > tWTR: > tRRD: > tRTP: > tFAW: > > Thank you in advance, > Zvika > > --- > > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Change superio in "Bayley Bay FSP-based CRB"
Hello Zvika, Add your device in Konfig and configure it under devicetree. Look for examples and/or previous threads in this mail list. Jose. ‐‐‐ Original Message ‐‐‐ On Monday, October 8, 2018 12:02 AM, Zvi Vered wrote: > Hello, > > I have to port coreboot to a "Bay Trail" board (KONTRON). > I selected "Bayley Bay FSP-based CRB" as a reference. > > In my board, the output of superiotool is: > Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x41) at 0x2e > > But the configuration of the reference board is: > *** Super I/O *** > > How can I change it ? > > I wish there was a basic configuration that could be easily modified. > > Thank you, > Zvika > > -- > > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
I have no idea bro I cannot help you with that. I am just curious Which brand and model of board are you using? ‐‐‐ Original Message ‐‐‐ On Friday, October 5, 2018 6:05 AM, Zvi Vered wrote: > Hi Jose, Mariusz,All, > > The vendor's rom file size is: 5,242,880 bytes > > After running: > dd if=coreboot.rom of=coreboot.rom.new bs=1M skip=3 > > I got a new file with the same size. > > I tried to program this new file and got the following message from the > vendor's utlity: > > WARNING ! > This Image file doesn't match current System design! > Force update it will destroy the System's Activation Key. > We do not recommend flashing your BIOS. > Press "Y" to force update BIOS. > Press "N" to quit flash. > - Please select one of the options: > > I ignored the warning and programmed the BIOS. > > After reset, I got nothing. > > What is "System's Activation Key" ? > I'm sure that FSP (and other files) for my board are not properly configured > yet. > But I suspect this is not the reason for the message. > > Thank you, > Zvika > > On Thu, Oct 4, 2018 at 9:47 PM Zvi Vered wrote: > >> Hi Jose, >> >> I probably made a mistake and erased the main BIOS chip (and also the >> secondary one) >> Currently my target is not booting OS at all. >> So I can not try Mariusz procedure. >> Hope to have an identical target soon. >> >> Thank you very much for your help, >> Zvika >> >> On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo wrote: >> >>> Zvika: >>> Doing a full flash doesn't work for you, this is what I been doing. >>> Try to use flashrom from linux if you want to do the full flash (may be it >>> will work). >>> >>> An external programmer would be the optimal choice. >>> >>> Did you tried what Mariusz said? >>> Jose. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Thursday, October 4, 2018 6:20 PM, Zvi Vered wrote: >>> >>>> Hi Mariusz, Jose, All, >>>> >>>> Mariusz - Thank you very much for the solution. >>>> Jose - You wrote "I have never done this way...". >>>> Can you please suggest a better alternative ? >>>> >>>> Thank you, >>>> Zvika >>>> >>>> On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot >>>> wrote: >>>> >>>>> Hi Jose, >>>>> >>>>> In your case set: >>>>> ROM chip size = 8MB (your case) >>>>> CBFS_SIZE <= 5MB (your specific case) >>>>> >>>>> This will build 8M file. After that just cut last 5M of this 8M file >>>>> (using any hexeditor) or use something like below from command line: >>>>> >>>>> dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 >>>>> >>>>> (before doing that double check if original vendor`s rom file size is >>>>> 5242880 bytes long) >>>>> >>>>> Mariusz >>>>> >>>>> W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: >>>>> >>>>>> You can do that but I have never done this way and I cannot help you >>>>>> with that. >>>>>> >>>>>> Someone else can advise on this? >>>>>> >>>>>> ‐‐‐ Original Message ‐‐‐ >>>>>> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered >>>>>> [](mailto:vered...@gmail.com) wrote: >>>>>> >>>>>>> Hi Jose, All, >>>>>>> >>>>>>> Highly appreciate your answers. >>>>>>> It seems the vital information in your replies are not documented. >>>>>>> >>>>>>> The original vendor's rom file size is 5MB. >>>>>>> Do you think I can create a 5MB coreboot.rom ? >>>>>>> >>>>>>> It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom >>>>>>> file like the original one. For any other file size, AfuEfix64 fails. >>>>>>> >>>>>>> Thank you, >>>>>>> Zvika >>>>>>> >>>>>>> On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo >>>>>>> wrote: >>>>>>> >>>>>>>> Zvika: >>>>>>>> >>>>>>>> There are 2 ways to build coreboot: (choo
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Zvika: Doing a full flash doesn't work for you, this is what I been doing. Try to use flashrom from linux if you want to do the full flash (may be it will work). An external programmer would be the optimal choice. Did you tried what Mariusz said? Jose. ‐‐‐ Original Message ‐‐‐ On Thursday, October 4, 2018 6:20 PM, Zvi Vered wrote: > Hi Mariusz, Jose, All, > > Mariusz - Thank you very much for the solution. > Jose - You wrote "I have never done this way...". > Can you please suggest a better alternative ? > > Thank you, > Zvika > > On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot > wrote: > >> Hi Jose, >> >> In your case set: >> ROM chip size = 8MB (your case) >> CBFS_SIZE <= 5MB (your specific case) >> >> This will build 8M file. After that just cut last 5M of this 8M file (using >> any hexeditor) or use something like below from command line: >> >> dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 >> >> (before doing that double check if original vendor`s rom file size is >> 5242880 bytes long) >> >> Mariusz >> >> W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: >> >>> You can do that but I have never done this way and I cannot help you with >>> that. >>> >>> Someone else can advise on this? >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered >>> [](mailto:vered...@gmail.com) wrote: >>> >>>> Hi Jose, All, >>>> >>>> Highly appreciate your answers. >>>> It seems the vital information in your replies are not documented. >>>> >>>> The original vendor's rom file size is 5MB. >>>> Do you think I can create a 5MB coreboot.rom ? >>>> >>>> It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom file >>>> like the original one. For any other file size, AfuEfix64 fails. >>>> >>>> Thank you, >>>> Zvika >>>> >>>> On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo >>>> wrote: >>>> >>>>> Zvika: >>>>> >>>>> There are 2 ways to build coreboot: (choose one) >>>>> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS. >>>>> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash >>>>> and just rewrite coreboot on top of the BIOS block. >>>>> >>>>> Your original computer Firmware = Intel FW + "BIOS" >>>>> >>>>> Intel FW = IFD +PD+ME/TXE+GBE >>>>> BIOS=AMI-Phoenix etc... >>>>> >>>>> IFD=Intel Firmware Descriptor Table. >>>>> PD=Parameters >>>>> ME=Management Engine (For "Core" kind of processors). >>>>> TXE=Trusted Execution Engine (For "Atom" kind of processors). >>>>> GBE=Network card firmware. >>>>> >>>>> Zvika said: >>>>> "After creating coreboot.rom should I always use the original BIOS with >>>>> ifdtool to convert rom to bin ?" >>>>> Answer: >>>>> No, there are other methods and tools that can do the merge (ifdtool >>>>> and Intel's FIT are working fine for me) >>>>> >>>>> After the creation of the coreboot build you have 2 ways of doing the >>>>> flashing for your case: (with fpt). >>>>> 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or >>>>> have unknown firmware. >>>>> Use IFDTool in this case to inject coreboot to Intel FW. then >>>>> flash it with fpt . >>>>> 2.- Flash only the BIOS block (5MB your specific case) in this case ask >>>>> someone else how to do it with fpt >>>>> >>>>> I hope this answered your questions. >>>>> Jose.. >>>>> >>>>> ‐‐‐ Original Message ‐‐‐ >>>>> On Saturday, September 29, 2018 12:24 AM, Zvi Vered >>>>> wrote: >>>>> >>>>>> Hi Jose, >>>>>> >>>>>> You wrote: >>>>>> "My recommended approach is using the original Intel FW with already >>>>>> included the FD, TXE". >>>>>> >>>>>> What is "original intel FW" ? >>>>>> What is FD, TXE ? >>>>>> >>>&
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Thank you Mariusz. ‐‐‐ Original Message ‐‐‐ On Wednesday, October 3, 2018 12:46 PM, Mariusz Szafrański via coreboot wrote: > Hi Jose, > > In your case set: > ROM chip size = 8MB (your case) > CBFS_SIZE <= 5MB (your specific case) > > This will build 8M file. After that just cut last 5M of this 8M file (using > any hexeditor) or use something like below from command line: > > dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 > > (before doing that double check if original vendor`s rom file size is 5242880 > bytes long) > > Mariusz > > W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: > >> You can do that but I have never done this way and I cannot help you with >> that. >> >> Someone else can advise on this? >> >> ‐‐‐ Original Message ‐‐‐ >> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered >> [](mailto:vered...@gmail.com) wrote: >> >>> Hi Jose, All, >>> >>> Highly appreciate your answers. >>> It seems the vital information in your replies are not documented. >>> >>> The original vendor's rom file size is 5MB. >>> Do you think I can create a 5MB coreboot.rom ? >>> >>> It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom file >>> like the original one. For any other file size, AfuEfix64 fails. >>> >>> Thank you, >>> Zvika >>> >>> On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo >>> wrote: >>> >>>> Zvika: >>>> >>>> There are 2 ways to build coreboot: (choose one) >>>> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS. >>>> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash >>>> and just rewrite coreboot on top of the BIOS block. >>>> >>>> Your original computer Firmware = Intel FW + "BIOS" >>>> >>>> Intel FW = IFD +PD+ME/TXE+GBE >>>> BIOS=AMI-Phoenix etc... >>>> >>>> IFD=Intel Firmware Descriptor Table. >>>> PD=Parameters >>>> ME=Management Engine (For "Core" kind of processors). >>>> TXE=Trusted Execution Engine (For "Atom" kind of processors). >>>> GBE=Network card firmware. >>>> >>>> Zvika said: >>>> "After creating coreboot.rom should I always use the original BIOS with >>>> ifdtool to convert rom to bin ?" >>>> Answer: >>>> No, there are other methods and tools that can do the merge (ifdtool >>>> and Intel's FIT are working fine for me) >>>> >>>> After the creation of the coreboot build you have 2 ways of doing the >>>> flashing for your case: (with fpt). >>>> 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or >>>> have unknown firmware. >>>> Use IFDTool in this case to inject coreboot to Intel FW. then >>>> flash it with fpt . >>>> 2.- Flash only the BIOS block (5MB your specific case) in this case ask >>>> someone else how to do it with fpt >>>> >>>> I hope this answered your questions. >>>> Jose.. >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Saturday, September 29, 2018 12:24 AM, Zvi Vered >>>> wrote: >>>> >>>>> Hi Jose, >>>>> >>>>> You wrote: >>>>> "My recommended approach is using the original Intel FW with already >>>>> included the FD, TXE". >>>>> >>>>> What is "original intel FW" ? >>>>> What is FD, TXE ? >>>>> >>>>> After creating coreboot.rom should I always use the original BIOS with >>>>> ifdtool to convert rom to bin ? >>>>> >>>>> Thank you, >>>>> Zvika >>>>> >>>>> On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo >>>>> wrote: >>>>> >>>>>> You are right Nico, >>>>>> >>>>>> I just forgot the troubles this caused me. >>>>>> I am sorry Vika... My mistake. >>>>>> >>>>>> I can confirm with Nico: >>>>>> ROM chip size = 8MB (your case) >>>>>> CBFS_SIZE = 2 to 5MB (your specific case) >>>>>> >>>>>> My recommended approach is using the original Intel FW with already >>>>>> included the FD, TXE.
Re: [coreboot] microcode blob or ascii
Sorry, I cannot help you with this maybe I still don't understand. The only thing I can tell you that I use for this same SOC processor all the header files ".h" included in the kit and they work without problems. It would be good if you can enable the serial debug console and dump the log if you have problems. Good luck, Jose. Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, October 2, 2018 5:23 PM, galla rao wrote: > Thanks Jose, > > My actual query is FSP Binary also has below ucode update which is same to > coreboot\src\cpu\intel\microcode\microcode.c > > msr.lo = (unsigned long)m + sizeof(struct microcode); > msr.hi = 0; > wrmsr(0x79, msr); > > Atom E3845 BayTrail with D-Stepping never returns after writing uCode, tried > different ucode revisions > > On Mon, Oct 1, 2018 at 1:49 PM Jose Trujillo wrote: > >> Hello Ranga: >> It is ASCII just not properly formatted >> >> Just remove the text from this: >> >> 0x0001, /* Header Version */ >> 0x0901, /* Patch ID */ >> 0x04212014, /* DATE */ >> 0x00030679, /* CPUID */ >> 0x69c4e6f1, /* Checksum */ >> 0x0001, /* Loader Version */ >> 0x0001, /* Platform ID*/ >> 0xcbd0, /* Data size */ >> 0xcc00, /* Total size */ >> 0x, /* reserved */ >> 0x, /* reserved */ >> 0x, /* reserved */ >> >> to this format: >> >> 0x0001, \ >> 0x0901, \ >> 0x04212014, \ >> 0x00030679, \ >> 0x69c4e6f1, \ >> 0x0001, \ >> 0x0001, \ >> 0xcbd0, \ >> 0xcc00, \ >> 0x, \ >> 0x, \ >> 0x, >> >> And try again... >> Jose Trujillo. >> >> ‐‐‐ Original Message ‐‐‐ >> On Friday, September 28, 2018 7:28 PM, galla rao >> wrote: >> >>> Hi , >>> >>> How does the coreboot picks the cpu microcodes >>> >>> as a blob or ASCII ? >>> >>> Tried both option GENERATE FROM TREE and INCLUDE EXTERNAL HEADER >>> >>> In Memory it appears it picks the ASCII file, but not a blob >>> >>> intel/cpu/baytrail/microcode/M0130679901.h >>> >>> 0x0001, /* Header Version */ >>> 0x0901, /* Patch ID */ >>> 0x04212014, /* DATE */ >>> 0x00030679, /* CPUID */ >>> 0x69c4e6f1, /* Checksum */ >>> 0x0001, /* Loader Version */ >>> 0x0001, /* Platform ID*/ >>> 0xcbd0, /* Data size */ >>> 0xcc00, /* Total size */ >>> 0x, /* reserved */ >>> 0x, /* reserved */ >>> 0x, /* reserved */ >>> >>> Help me out in understanding this issue >>> >>> Regards >>> Ranga-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
You can do that but I have never done this way and I cannot help you with that. Someone else can advise on this? ‐‐‐ Original Message ‐‐‐ On Tuesday, October 2, 2018 9:39 PM, Zvi Vered wrote: > Hi Jose, All, > > Highly appreciate your answers. > It seems the vital information in your replies are not documented. > > The original vendor's rom file size is 5MB. > Do you think I can create a 5MB coreboot.rom ? > > It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom file > like the original one. For any other file size, AfuEfix64 fails. > > Thank you, > Zvika > > On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo wrote: > >> Zvika: >> >> There are 2 ways to build coreboot: (choose one) >> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS. >> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash and >> just rewrite coreboot on top of the BIOS block. >> >> Your original computer Firmware = Intel FW + "BIOS" >> >> Intel FW = IFD +PD+ME/TXE+GBE >> BIOS=AMI-Phoenix etc... >> >> IFD=Intel Firmware Descriptor Table. >> PD=Parameters >> ME=Management Engine (For "Core" kind of processors). >> TXE=Trusted Execution Engine (For "Atom" kind of processors). >> GBE=Network card firmware. >> >> Zvika said: >> "After creating coreboot.rom should I always use the original BIOS with >> ifdtool to convert rom to bin ?" >> Answer: >> No, there are other methods and tools that can do the merge (ifdtool and >> Intel's FIT are working fine for me) >> >> After the creation of the coreboot build you have 2 ways of doing the >> flashing for your case: (with fpt). >> 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or have >> unknown firmware. >> Use IFDTool in this case to inject coreboot to Intel FW. then flash >> it with fpt . >> 2.- Flash only the BIOS block (5MB your specific case) in this case ask >> someone else how to do it with fpt >> >> I hope this answered your questions. >> Jose.. >> >> ‐‐‐ Original Message ‐‐‐ >> On Saturday, September 29, 2018 12:24 AM, Zvi Vered >> wrote: >> >>> Hi Jose, >>> >>> You wrote: >>> "My recommended approach is using the original Intel FW with already >>> included the FD, TXE". >>> >>> What is "original intel FW" ? >>> What is FD, TXE ? >>> >>> After creating coreboot.rom should I always use the original BIOS with >>> ifdtool to convert rom to bin ? >>> >>> Thank you, >>> Zvika >>> >>> On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo >>> wrote: >>> >>>> You are right Nico, >>>> >>>> I just forgot the troubles this caused me. >>>> I am sorry Vika... My mistake. >>>> >>>> I can confirm with Nico: >>>> ROM chip size = 8MB (your case) >>>> CBFS_SIZE = 2 to 5MB (your specific case) >>>> >>>> My recommended approach is using the original Intel FW with already >>>> included the FD, TXE. >>>> >>>> I never tested adding regions to coreboot but you can try. >>>> >>>> To have better chances of success you should be dumping hardware settings >>>> booting with your original "BIOS" (look for the attached file). >>>> >>>> Check if the system is "Memory down"or/and ECC because it will be needed >>>> to edit FSP (if using it). >>>> Dump memory settings with the following commands: >>>> >>>> sudo dnf install i2c-tools-perl >>>> sudo modprobe eeprom >>>> decode-dimms >>>> >>>> If you have not done this already there is still a long way to go. >>>> Don't get intimidated, just do it, if you have questions just ask I >>>> will try to help >>>> >>>> Good luck, >>>> Jose. >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Wednesday, September 26, 2018 6:28 PM, Nico Huber wrote: >>>> >>>>> Hi, >>>>> >>>>> On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote: >>>>> >>>>> > No, don't change it, you change the size of coreboot only if during the >>>>> > building process "make" complain that there is not enough space but in >>>>> > your case
Re: [coreboot] microcode blob or ascii
Hello Ranga: It is ASCII just not properly formatted Just remove the text from this: 0x0001, /* Header Version */ 0x0901, /* Patch ID */ 0x04212014, /* DATE */ 0x00030679, /* CPUID */ 0x69c4e6f1, /* Checksum */ 0x0001, /* Loader Version */ 0x0001, /* Platform ID*/ 0xcbd0, /* Data size */ 0xcc00, /* Total size */ 0x, /* reserved */ 0x, /* reserved */ 0x, /* reserved */ to this format: 0x0001, \ 0x0901, \ 0x04212014, \ 0x00030679, \ 0x69c4e6f1, \ 0x0001, \ 0x0001, \ 0xcbd0, \ 0xcc00, \ 0x, \ 0x, \ 0x, And try again... Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Friday, September 28, 2018 7:28 PM, galla rao wrote: > Hi , > > How does the coreboot picks the cpu microcodes > > as a blob or ASCII ? > > Tried both option GENERATE FROM TREE and INCLUDE EXTERNAL HEADER > > In Memory it appears it picks the ASCII file, but not a blob > > intel/cpu/baytrail/microcode/M0130679901.h > > 0x0001, /* Header Version */ > 0x0901, /* Patch ID */ > 0x04212014, /* DATE */ > 0x00030679, /* CPUID */ > 0x69c4e6f1, /* Checksum */ > 0x0001, /* Loader Version */ > 0x0001, /* Platform ID*/ > 0xcbd0, /* Data size */ > 0xcc00, /* Total size */ > 0x, /* reserved */ > 0x, /* reserved */ > 0x, /* reserved */ > > Help me out in understanding this issue > > Regards > Ranga-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Porting coreboot to another Intel's bay-trail
Zvika: You are lucky If the model of your board appears in the list of supported nodels because you have to do not much, but, if not, you have to do a "motherboard porting" for your specific system. Is essential you add the correct microcode and configure correctly FSP on memory settings otherwise the system will not boot. Get focused into the "mainboard" tree in the folder where devicetree for your board is located. The most notable files are: devicetree.cb gpio.h Kconfig Makefile.inc and the ACPI folder. Remember: you also need to initialize EC or superio. You need to select the right video framebuffer depending of the payload. etc... To edit devicetree.cb you need to understand the specific architecture of your board and you can enable/disable and add devices there (you can see examples from another boards). To edit gpio.h you need to dump from ypur original "BIOS" the GPIO settings using inteltool (find more details in the text document I already sent you). To edit Kconfig to enable features. To edit Makefile.inc to enable code. To edit ACPI files to provide hardware information to the OS and tell the processor what to do in case of a power event and other many things. This is generally what you have to do to port to your board. Maybe someone else can add something else or correct me if Iam wrong. Good luck, Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Saturday, September 29, 2018 9:46 AM, Zvi Vered wrote: > Hello, > > I created a new mainboard based on "Bayley Bay FSP-based CRB" > It seems that (at least) the following files are mandatory for build: > > cmos.layout > devicetree.cb > romstage.c > > Am I right ? > If yes - what info required to write those files ? > Can I use coreboot default files instead ? > > Honestly - I thought that FSP binary configuration is all I have to do. > And few changes in menuconfig (e.g ROM size). > > Thank you, > Zvika-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Zvika:
There are 2 ways to build coreboot: (choose one)
1.- Including IFD, TXE, GBE etc inside coreboot CBFS.
2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash and
just rewrite coreboot on top of the BIOS block.
Your original computer Firmware = Intel FW + "BIOS"
Intel FW = IFD +PD+ME/TXE+GBE
BIOS=AMI-Phoenix etc...
IFD=Intel Firmware Descriptor Table.
PD=Parameters
ME=Management Engine (For "Core" kind of processors).
TXE=Trusted Execution Engine (For "Atom" kind of processors).
GBE=Network card firmware.
Zvika said:
"After creating coreboot.rom should I always use the original BIOS with ifdtool
to convert rom to bin ?"
Answer:
No, there are other methods and tools that can do the merge (ifdtool and
Intel's FIT are working fine for me)
After the creation of the coreboot build you have 2 ways of doing the flashing
for your case: (with fpt).
1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or have
unknown firmware.
Use IFDTool in this case to inject coreboot to Intel FW. then flash it
with fpt .
2.- Flash only the BIOS block (5MB your specific case) in this case ask someone
else how to do it with fpt
I hope this answered your questions.
Jose..
‐‐‐ Original Message ‐‐‐
On Saturday, September 29, 2018 12:24 AM, Zvi Vered wrote:
> Hi Jose,
>
> You wrote:
> "My recommended approach is using the original Intel FW with already included
> the FD, TXE".
>
> What is "original intel FW" ?
> What is FD, TXE ?
>
> After creating coreboot.rom should I always use the original BIOS with
> ifdtool to convert rom to bin ?
>
> Thank you,
> Zvika
>
> On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo wrote:
>
>> You are right Nico,
>>
>> I just forgot the troubles this caused me.
>> I am sorry Vika... My mistake.
>>
>> I can confirm with Nico:
>> ROM chip size = 8MB (your case)
>> CBFS_SIZE = 2 to 5MB (your specific case)
>>
>> My recommended approach is using the original Intel FW with already included
>> the FD, TXE.
>>
>> I never tested adding regions to coreboot but you can try.
>>
>> To have better chances of success you should be dumping hardware settings
>> booting with your original "BIOS" (look for the attached file).
>>
>> Check if the system is "Memory down"or/and ECC because it will be needed to
>> edit FSP (if using it).
>> Dump memory settings with the following commands:
>>
>> sudo dnf install i2c-tools-perl
>> sudo modprobe eeprom
>> decode-dimms
>>
>> If you have not done this already there is still a long way to go.
>> Don't get intimidated, just do it, if you have questions just ask I will
>> try to help
>>
>> Good luck,
>> Jose.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, September 26, 2018 6:28 PM, Nico Huber wrote:
>>
>>> Hi,
>>>
>>> On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote:
>>>
>>> > No, don't change it, you change the size of coreboot only if during the
>>> > building process "make" complain that there is not enough space but in
>>> > your case your build was already successful leave it like that.
>>>
>>> this advice seems very weird to me. I'm not experienced with Bay Trail.
>>> But unless there is a bug in the Bay Trail code, you should always set
>>> the correct ROM_SIZE (to the full flash chip size). Otherwise you may
>>> introduce bugs in code that relies on this setting (e.g. saving the
>>> MRC cache might fail and so would S3 resume).
>>>
>>> CBFS_SIZE however is the setting to adjust according to your needs. It
>>> should be at most the size of the BIOS region.
>>>
>>> > In the rare circumstance that more space is required you can increase
>>> > coreboot size to 4MB and istill will fit into your system 5MB of space
>>> > available.
>>> > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save
>>> > as BYT_orig.bin.new that you can flash to your system.
>>>
>>> I assume this doesn't work oob if you set ROM_SIZE correctly. But it is
>>> unnecessary to craft a single file by hand. You can either only flash
>>> the BIOS region (recommended) or add the other regions in coreboot's
>>> config (HAVE_{IFD,ME,GBE}_BIN).
>>>
>>> Nico--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
You are right Nico,
I just forgot the troubles this caused me.
I am sorry Vika... My mistake.
I can confirm with Nico:
ROM chip size = 8MB (your case)
CBFS_SIZE = 2 to 5MB (your specific case)
My recommended approach is using the original Intel FW with already included
the FD, TXE.
I never tested adding regions to coreboot but you can try.
To have better chances of success you should be dumping hardware settings
booting with your original "BIOS" (look for the attached file).
Check if the system is "Memory down"or/and ECC because it will be needed to
edit FSP (if using it).
Dump memory settings with the following commands:
sudo dnf install i2c-tools-perl
sudo modprobe eeprom
decode-dimms
If you have not done this already there is still a long way to go.
Don't get intimidated, just do it, if you have questions just ask I will
try to help
Good luck,
Jose.
‐‐‐ Original Message ‐‐‐
On Wednesday, September 26, 2018 6:28 PM, Nico Huber wrote:
> Hi,
>
> On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote:
>
> > No, don't change it, you change the size of coreboot only if during the
> > building process "make" complain that there is not enough space but in
> > your case your build was already successful leave it like that.
>
> this advice seems very weird to me. I'm not experienced with Bay Trail.
> But unless there is a bug in the Bay Trail code, you should always set
> the correct ROM_SIZE (to the full flash chip size). Otherwise you may
> introduce bugs in code that relies on this setting (e.g. saving the
> MRC cache might fail and so would S3 resume).
>
> CBFS_SIZE however is the setting to adjust according to your needs. It
> should be at most the size of the BIOS region.
>
> > In the rare circumstance that more space is required you can increase
> > coreboot size to 4MB and istill will fit into your system 5MB of space
> > available.
> > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save
> > as BYT_orig.bin.new that you can flash to your system.
>
> I assume this doesn't work oob if you set ROM_SIZE correctly. But it is
> unnecessary to craft a single file by hand. You can either only flash
> the BIOS region (recommended) or add the other regions in coreboot's
> config (HAVE_{IFD,ME,GBE}_BIN).
>
> Nico
Motherboard Porting Guide
Description: Binary data
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
You are welcome, No, don't change it, you change the size of coreboot only if during the building process "make" complain that there is not enough space but in your case your build was already successful leave it like that. In the rare circumstance that more space is required you can increase coreboot size to 4MB and istill will fit into your system 5MB of space available. "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save as BYT_orig.bin.new that you can flash to your system. Please follow Nico's recommendations and be aware that is highly likely that the system will not boot the first time and you will need an external programmer for restoring the system. Have a good day, Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Tuesday, September 25, 2018 11:59 PM, Zvi Vered wrote: > Hi Jose, > > Thank you very much for the detail information. > The output of ifdtool in layout.txt is: > :0fff fd > 0030:007f bios > 1000:002f me > > So the original bios size is 0x50 = 5MB > > You wrote: > if the size of the original BIOS is bigger or equal than coreboot build you > are good to go ahead. > > The original "ROM chip size" in menuconfig is 2MB. Should I change it to 8MB ? > > I'm aware my board is not identical to the "Bayley Bay FSP-based CRB" > Should I use another board as reference ? > > Best regards, > Zvika > > On Tue, Sep 25, 2018 at 10:16 AM Jose Trujillo > wrote: > >> Hello Zvika: >> >> First get the correct original full 8MB FW from the manufacturer or dump it >> from the board with the command in EFI: >> "ftp -d BYT_orig.bin" and double save it. >> >> 2.- in coreboot/util/ifdtool do make and sudo make install. >> 3.- in terminal go to the FW directory and do:"ifdtool BYT_orig.bin -f >> fw_layout.txt" >> a).- in "fw_layout.txt" you will get the BIOS area size from the >> original FW (just substract). >> b).- if the size of the original BIOS is bigger or equal than coreboot >> build you are good to go ahead. >> 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot >> folder (not inside the coreboot folder) and do: >> ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin >> 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. >> >> If the build was correctly done and followed accurately those steps the >> system should boot. >> >> Good luck, >> Jose Trujillo. >> >> ‐‐‐ Original Message ‐‐‐ >> On Monday, September 24, 2018 10:18 PM, Zvi Vered wrote: >> >>> Hello, >>> >>> I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: >>> >>> CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 >>> Northbridge: 8086:0f00 (Bay Trail) >>> Southbridge: 8086:0f1c (Bay Trail) >>> IGD: 8086:0f31 (unknown) >>> >>> In coreboot configuration I selected: >>> Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB >>> The default ROM chip size is 2MB. >>> This is also the size of coreboot.rom created after "make" >>> >>> The board has 8MB BIOS flash. >>> It's delivered with a BIOS programming utility that runs under EFI shell. >>> >>> The original BIOS has 2 versions: rom (5MB) and bin (8MB) >>> I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. >>> >>> I got: >>> 3 - Error: ROM file size does not match existing BIOS size. >>> Should I convert coreboot.rom to coreboot.bin ? How ? >>> If not, how can I program coreboot.rom ? >>> >>> Thank you, >>> Zvika-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Zvika: Sorry I Forgot: "CB_baytrail.bin" is just a renamed copy of "BYT_orig.bin". After that command a new file will be named: "BYT_orig.bin.new" Jose. ‐‐‐ Original Message ‐‐‐ On Tuesday, September 25, 2018 10:16 AM, Jose Trujillo wrote: > Hello Zvika: > > First get the correct original full 8MB FW from the manufacturer or dump it > from the board with the command in EFI: > "ftp -d BYT_orig.bin" and double save it. > > 2.- in coreboot/util/ifdtool do make and sudo make install. > 3.- in terminal go to the FW directory and do:"ifdtool BYT_orig.bin -f > fw_layout.txt" > a).- in "fw_layout.txt" you will get the BIOS area size from the > original FW (just substract). > b).- if the size of the original BIOS is bigger or equal than coreboot > build you are good to go ahead. > 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot > folder (not inside the coreboot folder) and do: > ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin > 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. > > If the build was correctly done and followed accurately those steps the > system should boot. > > Good luck, > Jose Trujillo. > > ‐‐‐ Original Message ‐‐‐ > On Monday, September 24, 2018 10:18 PM, Zvi Vered wrote: > >> Hello, >> >> I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: >> >> CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 >> Northbridge: 8086:0f00 (Bay Trail) >> Southbridge: 8086:0f1c (Bay Trail) >> IGD: 8086:0f31 (unknown) >> >> In coreboot configuration I selected: >> Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB >> The default ROM chip size is 2MB. >> This is also the size of coreboot.rom created after "make" >> >> The board has 8MB BIOS flash. >> It's delivered with a BIOS programming utility that runs under EFI shell. >> >> The original BIOS has 2 versions: rom (5MB) and bin (8MB) >> I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. >> >> I got: >> 3 - Error: ROM file size does not match existing BIOS size. >> Should I convert coreboot.rom to coreboot.bin ? How ? >> If not, how can I program coreboot.rom ? >> >> Thank you, >> Zvika-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hello Zvika: First get the correct original full 8MB FW from the manufacturer or dump it from the board with the command in EFI: "ftp -d BYT_orig.bin" and double save it. 2.- in coreboot/util/ifdtool do make and sudo make install. 3.- in terminal go to the FW directory and do:"ifdtool BYT_orig.bin -f fw_layout.txt" a).- in "fw_layout.txt" you will get the BIOS area size from the original FW (just substract). b).- if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot folder (not inside the coreboot folder) and do: ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. If the build was correctly done and followed accurately those steps the system should boot. Good luck, Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Monday, September 24, 2018 10:18 PM, Zvi Vered wrote: > Hello, > > I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: > > CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 > Northbridge: 8086:0f00 (Bay Trail) > Southbridge: 8086:0f1c (Bay Trail) > IGD: 8086:0f31 (unknown) > > In coreboot configuration I selected: > Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB > The default ROM chip size is 2MB. > This is also the size of coreboot.rom created after "make" > > The board has 8MB BIOS flash. > It's delivered with a BIOS programming utility that runs under EFI shell. > > The original BIOS has 2 versions: rom (5MB) and bin (8MB) > I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. > > I got: > 3 - Error: ROM file size does not match existing BIOS size. > Should I convert coreboot.rom to coreboot.bin ? How ? > If not, how can I program coreboot.rom ? > > Thank you, > Zvika-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
Hi Alex, I will keep in mind this but before I will check about the EC on my system because this is not an RVP board. Thank you for your advise, I'll do that. Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Monday, September 24, 2018 4:46 PM, Alex Feinman wrote: > Keep in mind that Intel RVP boards ship with Intel EC code, which is not > compatible with Coreboot. You need to reflash it with Google EC - it's built > as a part of Coreboot, or it can be built separately as well. > > --- > > From: coreboot on behalf of Nico Huber > > Sent: Thursday, September 20, 2018 1:16 PM > To: Jose Trujillo; Naresh G. Solanki > Cc: coreboot > Subject: Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: > pre-conditions not met" > > Hi Jose, > > On 20.09.2018 15:58, Jose Trujillo via coreboot wrote: >> I will follow your advise of checking EC and about the base FW I am >> using the original UEFI AMI FW but, if still doesn't boot I will replace >> ME and descriptor as you suggested. > > Better don't. The Firmware Descriptor and ME are orthogonal to coreboot. > It's best to leave them in flash as they are once you have them working > with the original firmware. If you use flashrom, you can use a layout > file or the --ifd option and include only the BIOS region when writing. > > Nico > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
Dear Naresh, I choose the RVP8 board because is the only match in terms of CPU and memory, other templates made by google supports kabylake U/Y only processors and no DDR4. My system has differences and I will check them after I finish GPIO. I already determined the proper VR settings and set them in devicetree (the default voltage setting was 0V -power was shutdown??-) and I will see if after the corrections of VR and GPIO the system boots. I will follow your advise of checking EC and about the base FW I am using the original UEFI AMI FW but, if still doesn't boot I will replace ME and descriptor as you suggested. Thank you, Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Thursday, September 20, 2018 4:03 PM, Naresh G. Solanki wrote: > RVP8 is known to boot. GPIO config should be fine unless you are modifying HW. > > In logs you provided, ec communication seems to fail. Thus can you > make sure right EC is flashed in the RVP8. > In my board, it looks like this: > recv_ec_data: 0x10 > recv_ec_data: 0x69 > > Also make sure that you have right descriptor & ME are for RVP8 > > Attached is config I've tried & it executed till end of ramstage. > > On Thu, Sep 20, 2018 at 1:25 PM Jose Trujillo via coreboot > coreboot@coreboot.org wrote: > > > Hello Nico, > > Yes, I am using Intel Kabylake DDR4 RVP8 board. > > > > > Never use another board's GPIO settings. > > > Reading the mail list yesterday I saw that warning maybe from you and I > > > will do the correct changes to GPIO just after editing VR settings. > > > > I am just started coreboot several months ago and there is still a lot of > > road to go for me and still don't understand many things; but I am doing my > > best to get aligned with the coreboot project. > > After the GPIO changes I will check my schematics to check for hardware > > differences before I flash it into my device. > > Thank you ALL for your help. > > Jose Trujillo > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, September 19, 2018 10:15 PM, Nico Huber nic...@gmx.de wrote: > > > > > Hi Jose, > > > On 12.09.2018 15:12, Jose Trujillo via coreboot wrote: > > > > > > > To begin with the system didn't find memory attached... > > > > but there is memory attached, SPD address mismatch? I will check. > > > > > > > > ...Timeout while sending command 0x0d to EC! > > > > > > I'm not sure what this is about. Did you try to talk to your board's > > > EC? Can you share the code? Or do you run another board's code on your > > > board? That would explain why things go wrong. Also, my usual warning: > > > Never use another board's GPIO settings. > > > Nico > > > > -- > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > > Best regards, > Naresh G. Solanki -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
Hello Nico, Yes, I am using Intel Kabylake DDR4 RVP8 board. > Never use another board's GPIO settings. Reading the mail list yesterday I saw that warning maybe from you and I will do the correct changes to GPIO just after editing VR settings. I am just started coreboot several months ago and there is still a lot of road to go for me and still don't understand many things; but I am doing my best to get aligned with the coreboot project. After the GPIO changes I will check my schematics to check for hardware differences before I flash it into my device. Thank you ALL for your help. Jose Trujillo ‐‐‐ Original Message ‐‐‐ On Wednesday, September 19, 2018 10:15 PM, Nico Huber wrote: > Hi Jose, > > On 12.09.2018 15:12, Jose Trujillo via coreboot wrote: > > > To begin with the system didn't find memory attached... > > but there is memory attached, SPD address mismatch? I will check. > > > > ...Timeout while sending command 0x0d to EC! > > I'm not sure what this is about. Did you try to talk to your board's > EC? Can you share the code? Or do you run another board's code on your > board? That would explain why things go wrong. Also, my usual warning: > Never use another board's GPIO settings. > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake unable to boot with post code 0x71
Hi Haresh,
I am working on it, but before making changes into VR parameters i need to
understand each one of them and make sure they are correct.
VrVoltageLimit is 1.52V according to Kabylake EDS.
I found icc_max values for SA and GT but not for IA and GT Unsliced on my board
schematics.
But I still don't have idea where to get psixthreshold values.
You mentioned to get the parameters from the descriptor you meant with FIT tool
or how?
Also I wanted to ask you if is possible to dump those parameters from the
original FW with a coreboot/intel tool or linux commands?
About the previous SLP state when hangs is S5 and S0 and when hangs it looks
awake S0 otherwise I would see the state change in the post code.
Thank you,
Jose Trujillo.
‐‐‐ Original Message ‐‐‐
On Tuesday, September 18, 2018 6:09 PM, Naresh G. Solanki
wrote:
> Hi Jose,
>
> Ideally, FSP silicon init returns if there is error & error code is displayed.
> Since return has not happended then it is most likely that input to
> FSPS UPD which comes from devicetree.cb might have gone wrong.
> In other word, can you match devicetree.cb setting with descriptor &
> board schematics.
> Especially check: domain_vr_config
>
> Additionally can you provide info like when the hang happens, what is
> state of SLP_S0/3/4/5.
> Also check voltage level for VCC_CORE/GT/SA
>
> Regards,
> Naresh G Solanki
> On Tue, Sep 18, 2018 at 3:01 PM Jose Trujillo via coreboot
> coreboot@coreboot.org wrote:
>
> > Dear Naresh / All:
> > I added their corresponding FSP headers but still the system never returns
> > from the FSP function (fsp_silicon_init) post 0x71.
> > My question is if somebody can tell me how to enable (if possible) FSP port
> > 80 post codes and/or FSP serial debug from SIO (non SOC) UART.
> > Thank you,
> > Jose Trujillo
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, September 17, 2018 6:14 PM, Naresh G. Solanki
> > naresh.solanki.2...@gmail.com wrote:
> >
> > > Location in coreboot folder:
> > > https://review.coreboot.org/cgit/coreboot.git/tree/src/vendorcode/intel/fsp/fsp2_0/skykabylake
> > > Header Files can be taken from location:
> > > https://github.com/IntelFsp/FSP/tree/master/KabylakeFspBinPkg/Include
> > > FSP binary can be taken from:
> > > https://github.com/IntelFsp/FSP/blob/master/KabylakeFspBinPkg/Fsp.fd
> > > This file needs to be split into fspm.bin fsps.bin . For this refer:
> > > https://github.com/tianocore/edk2/blob/master/IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md
> > > On Mon, Sep 17, 2018 at 7:51 PM Jose Trujillo ce.au...@protonmail.com
> > > wrote:
> > >
> > > > Thank you Naresh,
> > > > How to do the copy?
> > > > Could you give me some details?
> > > > You too have an excellent day.
> > > > Jose.
> > > > Sent with ProtonMail Secure Email.
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Monday, September 17, 2018 5:17 PM, Naresh G. Solanki
> > > > naresh.solanki.2...@gmail.com wrote:
> > > > I guess the FSP version you have is 3.5.0
> > > > You should have received fsp header along with fsp binary in single
> > > > package.
> > > > However you can get FSP binaries and header from
> > > > https://github.com/IntelFsp/FSP
> > > > Also make sure you copy FSP header version equal fsp binary version.
> > > > All the best!
> > > > On Mon 17 Sep, 2018, 3:34 PM Jose Trujillo via coreboot,
> > > > coreboot@coreboot.org wrote:
> > > >
> > > > > Dear Naresh:
> > > > > You are right; it never returns from the FSP function
> > > > > (fsp_silicon_init).
> > > > > chip_fsp20.c Ln.169
> > > > > void soc_init_pre_device(void chip_info)
> > > > > {
> > > > > printk(BIOS_INFO, "Entering: fsp_silicon_init"); // Added
> > > > > / Perform silicon specific init. /
> > > > > fsp_silicon_init(romstage_handoff_is_resume());
> > > > > / swap enabled PCI ports in device tree if needed */printk(BIOS_INFO,
> > > > > "Entering: pcie_override_devicetree"); // Added
> > > > > pcie_override_devicetree_after_silicon_init();
> > > > > printk(BIOS_INFO, "Exit: soc_init_pre_device"); // Added
> > > > > }
> > > > > Serial dump.
> > > > >
> > > > > Enabling SMIs.
> > > > > Locking SMM.
> > > > > VMX : param.enable = 0
> > > > > VMX: pre-
Re: [coreboot] Kabylake unable to boot with post code 0x71
Dear Naresh / All:
I added their corresponding FSP headers but still the system never returns from
the FSP function (fsp_silicon_init) post 0x71.
My question is if somebody can tell me how to enable (if possible) FSP port 80
post codes and/or FSP serial debug from SIO (non SOC) UART.
Thank you,
Jose Trujillo
‐‐‐ Original Message ‐‐‐
On Monday, September 17, 2018 6:14 PM, Naresh G. Solanki
wrote:
> Location in coreboot folder:
> https://review.coreboot.org/cgit/coreboot.git/tree/src/vendorcode/intel/fsp/fsp2_0/skykabylake
>
> Header Files can be taken from location:
> https://github.com/IntelFsp/FSP/tree/master/KabylakeFspBinPkg/Include
>
> FSP binary can be taken from:
> https://github.com/IntelFsp/FSP/blob/master/KabylakeFspBinPkg/Fsp.fd
>
> This file needs to be split into fspm.bin fsps.bin . For this refer:
> https://github.com/tianocore/edk2/blob/master/IntelFsp2Pkg/Tools/UserManuals/SplitFspBinUserManual.md
> On Mon, Sep 17, 2018 at 7:51 PM Jose Trujillo ce.au...@protonmail.com wrote:
>
> > Thank you Naresh,
> > How to do the copy?
> > Could you give me some details?
> > You too have an excellent day.
> > Jose.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, September 17, 2018 5:17 PM, Naresh G. Solanki
> > naresh.solanki.2...@gmail.com wrote:
> > I guess the FSP version you have is 3.5.0
> > You should have received fsp header along with fsp binary in single package.
> > However you can get FSP binaries and header from
> > https://github.com/IntelFsp/FSP
> > Also make sure you copy FSP header version equal fsp binary version.
> > All the best!
> > On Mon 17 Sep, 2018, 3:34 PM Jose Trujillo via coreboot,
> > coreboot@coreboot.org wrote:
> >
> > > Dear Naresh:
> > > You are right; it never returns from the FSP function (fsp_silicon_init).
> > > chip_fsp20.c Ln.169
> > > void soc_init_pre_device(void chip_info)
> > > {
> > > printk(BIOS_INFO, "Entering: fsp_silicon_init"); // Added
> > > / Perform silicon specific init. /
> > > fsp_silicon_init(romstage_handoff_is_resume());
> > > / swap enabled PCI ports in device tree if needed */printk(BIOS_INFO,
> > > "Entering: pcie_override_devicetree"); // Added
> > > pcie_override_devicetree_after_silicon_init();
> > > printk(BIOS_INFO, "Exit: soc_init_pre_device"); // Added
> > > }
> > > Serial dump.
> > >
> > > Enabling SMIs.
> > > Locking SMM.
> > > VMX : param.enable = 0
> > > VMX: pre-conditions not met
> > > VMX: pre-conditions not met
> > > VMX: pre-conditions not met
> > > SGX: pre-conditions not met
> > > VMX: pre-conditions not met
> > > SGX: pre-conditions not met
> > > POST: 0x71
> > > SGX: pre-conditions not met
> > > SGX: pre-conditions not met
> > > Entering: fsp_silicon_init <-- never returns from FSP.
> > >
> > > About the FSP header version I am not sure how exactly to obtain it but
> > > getting the binary decription from BCT I got:
> > > Header Revision: 0x3
> > > Image Revision: 0x305
> > > 3.0.5
> > > See the attached file for more details about the FSP binary.
> > > Please advise.
> > > Thank you,
> > > Jose Trujillo.
> > > ‐‐‐ Original Message ‐‐‐
> > > On Friday, September 14, 2018 6:58 PM, Naresh G. Solanki
> > > naresh.solanki.2...@gmail.com wrote:
> > >
> > > > With available data. It is most likely that it might have stuck
> > > > somewhere in function
> > > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/chip_fsp20.c#n169
> > > > You can add printk in that function & other functions called by it to
> > > > bisect & confirm the exact position of hang..
> > > > Also can you please check FSP binary version you are using versus FSP
> > > > header version checked-out in coreboot(which is currently 2.9.2).
> > > > They should be
> > > > On Fri, Sep 14, 2018 at 7:55 PM Jose Trujillo via coreboot
> > > > coreboot@coreboot.org wrote:
> > > >
> > > > > Here is Naresh
> > > > > ‐‐‐ Original Message ‐‐‐
> > > > > On Friday, September 14, 2018 4:49 PM, Naresh G. Solanki
> > > > > naresh.solanki.2...@gmail.com wrote:
> > > > > Can you also provide latest complete log.
> > > > > On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via cor
Re: [coreboot] Kabylake unable to boot with post code 0x71
Dear Naresh:
You are right; it never returns from the FSP function (fsp_silicon_init).
chip_fsp20.c Ln.169
void soc_init_pre_device(void *chip_info)
{
printk(BIOS_INFO, "Entering: fsp_silicon_init");// Added
/* Perform silicon specific init. */
fsp_silicon_init(romstage_handoff_is_resume());
/* swap enabled PCI ports in device tree if needed */
printk(BIOS_INFO, "Entering: pcie_override_devicetree");// Added
pcie_override_devicetree_after_silicon_init();
printk(BIOS_INFO, "Exit: soc_init_pre_device"); // Added
}
Serial dump.
Enabling SMIs.
Locking SMM.
VMX : param.enable = 0
VMX: pre-conditions not met
VMX: pre-conditions not met
VMX: pre-conditions not met
SGX: pre-conditions not met
VMX: pre-conditions not met
SGX: pre-conditions not met
POST: 0x71
SGX: pre-conditions not met
SGX: pre-conditions not met
Entering: fsp_silicon_init <-- never returns from FSP.
About the FSP header version I am not sure how exactly to obtain it but getting
the binary decription from BCT I got:
Header Revision: 0x3
Image Revision: 0x305
3.0.5
See the attached file for more details about the FSP binary.
Please advise.
Thank you,
Jose Trujillo.
‐‐‐ Original Message ‐‐‐
On Friday, September 14, 2018 6:58 PM, Naresh G. Solanki
wrote:
> With available data. It is most likely that it might have stuck
> somewhere in function
> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/chip_fsp20.c#n169
> You can add printk in that function & other functions called by it to
> bisect & confirm the exact position of hang..
> Also can you please check FSP binary version you are using versus FSP
> header version checked-out in coreboot(which is currently 2.9.2).
> They should be
>
> On Fri, Sep 14, 2018 at 7:55 PM Jose Trujillo via coreboot
> coreboot@coreboot.org wrote:
>
> > Here is Naresh
> > ‐‐‐ Original Message ‐‐‐
> > On Friday, September 14, 2018 4:49 PM, Naresh G. Solanki
> > naresh.solanki.2...@gmail.com wrote:
> > Can you also provide latest complete log.
> > On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via coreboot,
> > coreboot@coreboot.org wrote:
> >
> > > Thank you Naresh,
> > > I added the missing PCH device id following your advise, also enabled
> > > DEBUG_BOOT_STATE but I am still not able to get more information via
> > > serial debug about the exact location of the problem (but now I am
> > > certain is in the coreboot code not in FSP).
> > > I suspect the code involved aound this issue is hardwaremain.c and
> > > device.c
> > > Only the first "boot" just after flash I notice that the ethernet and
> > > SATA LEDs blink for a fraction of a second then reboots.
> > > After that, the following attempts to boot I don't see LED activity
> > > neither reboots, just halted in some kind of loop.
> > > According to the serial dump the las printed text is "0x71" but my
> > > question is if the serial port gets broken still during
> > > "BS_DEV_INIT_CHIPS" or is already doing "BS_DEV_ENUMERATE".
> > > As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to
> > > the list; I added it but may be is needed to do something else to make it
> > > work.
> > > Or istill is misconfigured (attached my .config file for your review)...
> > > I someone has a similar system working and want to share its
> > > configuration files to compare them myself I will be grateful.
> > > Jose Trujillo.
> > > ‐‐‐ Original Message ‐‐‐
> > > On Wednesday, 12 September 2018 19:33, Naresh G. Solanki
> > > naresh.solanki.2...@gmail.com wrote:
> > > Hi
> > >
> > > > PCH: device id a152 (rev 31) is Unknown
> > >
> > > This indicates that LPCID 0xa152 is not added.
> > > The #define should be added in source path:
> > > https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_ids.h#n2721
> > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/block/lpc/lpc.c#n131
> > > &
> > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bootblock/report_platform.c#n73
> > > as well.
> > > Additionally you can enable config DEBUG_BOOT_STATE to understand where
> > > exactly its stuck.
> > > Regards,
> > > Naresh G. Solanki
> > > On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot
> > > coreboot@coreboot.org wrote:
> > >
> > >
Re: [coreboot] Kabylake unable to boot with post code 0x71
Here is Naresh ‐‐‐ Original Message ‐‐‐ On Friday, September 14, 2018 4:49 PM, Naresh G. Solanki wrote: > Can you also provide latest complete log. > > On Fri 14 Sep, 2018, 2:10 PM Jose Trujillo via coreboot, > wrote: > >> Thank you Naresh, >> >> I added the missing PCH device id following your advise, also enabled >> DEBUG_BOOT_STATE but I am still not able to get more information via serial >> debug about the exact location of the problem (but now I am certain is in >> the coreboot code not in FSP). >> >> I suspect the code involved aound this issue is hardwaremain.c and >> device.c >> >> Only the first "boot" just after flash I notice that the ethernet and SATA >> LEDs blink for a fraction of a second then reboots. >> After that, the following attempts to boot I don't see LED activity neither >> reboots, just halted in some kind of loop. >> >> According to the serial dump the las printed text is "0x71" but my question >> is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" or is >> already doing "BS_DEV_ENUMERATE". >> >> As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the >> list; I added it but may be is needed to do something else to make it work. >> Or istill is misconfigured (attached my .config file for your review)... I >> someone has a similar system working and want to share its configuration >> files to compare them myself I will be grateful. >> >> Jose Trujillo. >> >> ‐‐‐ Original Message ‐‐‐ >> On Wednesday, 12 September 2018 19:33, Naresh G. Solanki >> wrote: >> >>> Hi >>> >>>>PCH: device id a152 (rev 31) is Unknown >>> >>> This indicates that LPCID 0xa152 is not added. >>> >>> The #define should be added in source path: >>> https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_ids.h#n2721 >>> >>> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/block/lpc/lpc.c#n131 >>> >>> & >>> >>> https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bootblock/report_platform.c#n73 >>> >>> as well. >>> >>> Additionally you can enable config DEBUG_BOOT_STATE to understand where >>> exactly its stuck. >>> >>> Regards, >>> >>> Naresh G. Solanki >>> >>> On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot >>> wrote: >>> >>>> Dear All, >>>> About the memory I just changed the dimm to address A0 and now coreboot is >>>> reporting correctly 1 dimm detected. >>>> >>>> But still no luck on the 0x71 post code loop (looks it is in some kind of >>>> loop because is still responsive to power and reset buttons). >>>> I don't know where this loop could be located (coreboot or FSP). >>>> The description on the post_codes.h file shows the following: >>>> >>>> /** >>>> * \brief Initializing Chips >>>> * >>>> * Boot State Machine: bs_dev_init_chips() >>>> */ >>>> #define POST_BS_DEV_INIT_CHIPS 0x71 >>>> >>>> >>>> Any advice on this issue? >>>> Attached is the serial dump with extra information. >>>> >>>> Thank you >>>> Jose Trujillo >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Wednesday, 12 September 2018 16:12, Jose Trujillo >>>> wrote: >>>> >>>>> To begin with the system didn't find memory attached... >>>>> but there is memory attached, SPD address mismatch? I will check. >>>>> >>>>> ...Timeout while sending command 0x0d to EC! >>>>> recv_ec_data: 0xff >>>>> recv_ec_data: 0xff >>>>> SPD index 7 >>>>> No memory dimm at address A0 >>>>> No memory dimm at address A2 >>>>> No memory dimm at address A6 >>>>> >>>>> 0 DIMMs found >>>>> >>>>> >>>>> ‐‐‐ Original Message ‐‐‐ >>>>> On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot >>>>> wrote: >>>>> >>>>>> Dear coreboot engineers: >>>>>> >>>>>> Right now I am stuck with a Kabylake system with the following message: >&
Re: [coreboot] Kabylake unable to boot with post code 0x71
Thank you Naresh, I added the missing PCH device id following your advise, also enabled DEBUG_BOOT_STATE but I am still not able to get more information via serial debug about the exact location of the problem (but now I am certain is in the coreboot code not in FSP). I suspect the code involved aound this issue is hardwaremain.c and device.c Only the first "boot" just after flash I notice that the ethernet and SATA LEDs blink for a fraction of a second then reboots. After that, the following attempts to boot I don't see LED activity neither reboots, just halted in some kind of loop. According to the serial dump the las printed text is "0x71" but my question is if the serial port gets broken still during "BS_DEV_INIT_CHIPS" or is already doing "BS_DEV_ENUMERATE". As Naresh pointed my PCH H chipset "Kabylake-H HM175" was not added to the list; I added it but may be is needed to do something else to make it work. Or istill is misconfigured (attached my .config file for your review)... I someone has a similar system working and want to share its configuration files to compare them myself I will be grateful. Jose Trujillo. ‐‐‐ Original Message ‐‐‐ On Wednesday, 12 September 2018 19:33, Naresh G. Solanki wrote: > Hi > >>PCH: device id a152 (rev 31) is Unknown > > This indicates that LPCID 0xa152 is not added. > > The #define should be added in source path: > https://review.coreboot.org/cgit/coreboot.git/tree/src/include/device/pci_ids.h#n2721 > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/common/block/lpc/lpc.c#n131 > > & > > https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/bootblock/report_platform.c#n73 > > as well. > > Additionally you can enable config DEBUG_BOOT_STATE to understand where > exactly its stuck. > > Regards, > > Naresh G. Solanki > > On Wed, Sep 12, 2018 at 9:24 PM Jose Trujillo via coreboot > wrote: > >> Dear All, >> About the memory I just changed the dimm to address A0 and now coreboot is >> reporting correctly 1 dimm detected. >> >> But still no luck on the 0x71 post code loop (looks it is in some kind of >> loop because is still responsive to power and reset buttons). >> I don't know where this loop could be located (coreboot or FSP). >> The description on the post_codes.h file shows the following: >> >> /** >> * \brief Initializing Chips >> * >> * Boot State Machine: bs_dev_init_chips() >> */ >> #define POST_BS_DEV_INIT_CHIPS 0x71 >> >> >> Any advice on this issue? >> Attached is the serial dump with extra information. >> >> Thank you >> Jose Trujillo >> >> ‐‐‐ Original Message ‐‐‐ >> On Wednesday, 12 September 2018 16:12, Jose Trujillo >> wrote: >> >>> To begin with the system didn't find memory attached... >>> but there is memory attached, SPD address mismatch? I will check. >>> >>> ...Timeout while sending command 0x0d to EC! >>> recv_ec_data: 0xff >>> recv_ec_data: 0xff >>> SPD index 7 >>> No memory dimm at address A0 >>> No memory dimm at address A2 >>> No memory dimm at address A6 >>> >>> 0 DIMMs found >>> >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot >>> wrote: >>> >>>> Dear coreboot engineers: >>>> >>>> Right now I am stuck with a Kabylake system with the following message: >>>> >>>> CPU #1 initialized >>>> apic_id: 0x06 done. >>>> microcode: updated to revision 0x8d date=2018-01-21 >>>> CPU #3 initialized >>>> bsp_do_flight_plan done after 220 msecs. >>>> CPU: frequency set to 3600 MHz >>>> Enabling SMIs. >>>> Locking SMM. >>>> VMX : param.enable = 0 >>>> VMX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> VMX: pre-conditions not met >>>> VMX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> VMX: pre-conditions not met >>>> SGX: pre-conditions not met >>>> POST: 0x71 >>>> >>>> >>>> May be some configuration is missing and I am trying to find this out >>>> myself but if someone of you can give a hint on how to resolve it I will >>>> be grateful. >>>> >>>> Attached is the full serial dump. >>>> >>>> Thank you, >>>> Jose Trujillo >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > Best regards, > Naresh G. Solanki .config Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
Dear All, About the memory I just changed the dimm to address A0 and now coreboot is reporting correctly 1 dimm detected. But still no luck on the 0x71 post code loop (looks it is in some kind of loop because is still responsive to power and reset buttons). I don't know where this loop could be located (coreboot or FSP). The description on the post_codes.h file shows the following: /** * \brief Initializing Chips * * Boot State Machine: bs_dev_init_chips() */ #define POST_BS_DEV_INIT_CHIPS 0x71 Any advice on this issue? Attached is the serial dump with extra information. Thank you Jose Trujillo ‐‐‐ Original Message ‐‐‐ On Wednesday, 12 September 2018 16:12, Jose Trujillo wrote: > To begin with the system didn't find memory attached... > but there is memory attached, SPD address mismatch? I will check. > > ...Timeout while sending command 0x0d to EC! > recv_ec_data: 0xff > recv_ec_data: 0xff > SPD index 7 > No memory dimm at address A0 > No memory dimm at address A2 > No memory dimm at address A6 > > 0 DIMMs found > > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot > wrote: > >> Dear coreboot engineers: >> >> Right now I am stuck with a Kabylake system with the following message: >> >> CPU #1 initialized >> apic_id: 0x06 done. >> microcode: updated to revision 0x8d date=2018-01-21 >> CPU #3 initialized >> bsp_do_flight_plan done after 220 msecs. >> CPU: frequency set to 3600 MHz >> Enabling SMIs. >> Locking SMM. >> VMX : param.enable = 0 >> VMX: pre-conditions not met >> SGX: pre-conditions not met >> VMX: pre-conditions not met >> VMX: pre-conditions not met >> SGX: pre-conditions not met >> SGX: pre-conditions not met >> VMX: pre-conditions not met >> SGX: pre-conditions not met >> POST: 0x71 >> >> >> May be some configuration is missing and I am trying to find this out myself >> but if someone of you can give a hint on how to resolve it I will be >> grateful. >> >> Attached is the full serial dump. >> >> Thank you, >> Jose Trujillo coreboot-4.8-1408-gc76e53ce30 Thu Sep 6 05:07:08 UTC 2018 bootblock starting... CPU: Intel(R) Core(TM) i5-7440EQ CPU @ 2.90GHz CPU: ID 906e9, Kabylake H B0, ucode: 008d CPU: AES supported, TXT supported, VT supported MCH: device id 5910 (rev 05) is Kabylake-H PCH: device id a152 (rev 31) is Unknown IGD: device id 591b (rev 04) is Kabylake HALO GT2 CBFS: 'Master Header Locator' located CBFS at [12:3fffc0) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 98fc coreboot-4.8-1408-gc76e53ce30 Thu Sep 6 05:07:08 UTC 2018 romstage starting... pm1_sts: 0900 pm1_en: pm1_cnt: gpe0_sts[0]: gpe0_en[0]: gpe0_sts[1]: gpe0_en[1]: gpe0_sts[2]: gpe0_en[2]: gpe0_sts[3]: gpe0_en[3]: TCO_STS: GEN_PMCON: e081 1808 GBLRST_CAUSE: 0002 prev_sleep_state 0 CBFS: 'Master Header Locator' located CBFS at [12:3fffc0) CBFS: Locating 'fspm.bin' CBFS: Found @ offset 4ffc0 size 62000 Spec version: v2.0 Revision: 3.5.0, Build Number 0 Type: release/test image ID: $KBLFSP$, base 0xffd7 + 0x62000 Config region0x5ea0c + 0x648 Memory init offset 0x1c8 POST: 0x34
Re: [coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
To begin with the system didn't find memory attached... but there is memory attached, SPD address mismatch? I will check. ...Timeout while sending command 0x0d to EC! recv_ec_data: 0xff recv_ec_data: 0xff SPD index 7 No memory dimm at address A0 No memory dimm at address A2 No memory dimm at address A6 0 DIMMs found ‐‐‐ Original Message ‐‐‐ On Wednesday, 12 September 2018 13:29, Jose Trujillo via coreboot wrote: > Dear coreboot engineers: > > Right now I am stuck with a Kabylake system with the following message: > > CPU #1 initialized > apic_id: 0x06 done. > microcode: updated to revision 0x8d date=2018-01-21 > CPU #3 initialized > bsp_do_flight_plan done after 220 msecs. > CPU: frequency set to 3600 MHz > Enabling SMIs. > Locking SMM. > VMX : param.enable = 0 > VMX: pre-conditions not met > SGX: pre-conditions not met > VMX: pre-conditions not met > VMX: pre-conditions not met > SGX: pre-conditions not met > SGX: pre-conditions not met > VMX: pre-conditions not met > SGX: pre-conditions not met > POST: 0x71 > > > May be some configuration is missing and I am trying to find this out myself > but if someone of you can give a hint on how to resolve it I will be grateful. > > Attached is the full serial dump. > > Thank you, > Jose Trujillo-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Kabylake unable to boot with post code 0x71 "SGX: pre-conditions not met"
Dear coreboot engineers: Right now I am stuck with a Kabylake system with the following message: CPU #1 initialized apic_id: 0x06 done. microcode: updated to revision 0x8d date=2018-01-21 CPU #3 initialized bsp_do_flight_plan done after 220 msecs. CPU: frequency set to 3600 MHz Enabling SMIs. Locking SMM. VMX : param.enable = 0 VMX: pre-conditions not met SGX: pre-conditions not met VMX: pre-conditions not met VMX: pre-conditions not met SGX: pre-conditions not met SGX: pre-conditions not met VMX: pre-conditions not met SGX: pre-conditions not met POST: 0x71 May be some configuration is missing and I am trying to find this out myself but if someone of you can give a hint on how to resolve it I will be grateful. Attached is the full serial dump. Thank you, Jose Trujillo coreboot-4.8-1408-gc76e53ce30 Thu Sep 6 05:07:08 UTC 2018 bootblock starting... CPU: Intel(R) Core(TM) i5-7440EQ CPU @ 2.90GHz CPU: ID 906e9, Kabylake H B0, ucode: 008d CPU: AES supported, TXT supported, VT supported MCH: device id 5910 (rev 05) is Kabylake-H PCH: device id a152 (rev 31) is Unknown IGD: device id 591b (rev 04) is Kabylake HALO GT2 CBFS: 'Master Header Locator' located CBFS at [12:3fffc0) CBFS: Locating 'fallback/romstage' CBFS: Found @ offset 80 size 8c7c coreboot-4.8-1408-gc76e53ce30 Thu Sep 6 05:07:08 UTC 2018 romstage starting... pm1_sts: pm1_en: pm1_cnt: gpe0_sts[0]: gpe0_en[0]: gpe0_sts[1]: gpe0_en[1]: gpe0_sts[2]: gpe0_en[2]: gpe0_sts[3]: gpe0_en[3]: TCO_STS: GEN_PMCON: d0040200 700a GBLRST_CAUSE: prev_sleep_state 5 CBFS: 'Master Header Locator' located CBFS at [12:3fffc0) CBFS: Locating 'fspm.bin' CBFS: Found @ offset 4efc0 size 62000 POST: 0x34 FMAP: Found "FLASH" version 1.1 at 10. FMAP: base = ffc0 size = 40 #areas = 4 FMAP: area RW_MRC_CACHE found @ 11 (65536 bytes) MRC: no data in 'RW_MRC_CACHE' bootmode is set to :0 ...Timeout while sending command 0x0d to EC! recv_ec_data: 0xff recv_ec_data: 0xff SPD index 7 No memory dimm at address A0 No memory dimm at address A2 No memory dimm at address A6 POST: 0x92 POST: 0x98 FSP: handling reset type 4001 hard_reset() called! coreboot-4.8-1408-gc76e53ce30 Thu Sep 6 05:07:08 UTC 2018 bootblock starting... CPU: Intel(R) Core(TM) i5-7440EQ CPU @ 2.90GHz CPU: ID 906e9, Kabylake H B0, ucode: 008d CPU: AES supported, TXT supported, VT supported MCH: device id 5910 (rev 05) is Kabylake-H PCH: device id a152 (rev 31) is Unknown
Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA
Just press ESC key during booting for Seabios and if everything in the video interface is properly configured by default you should see the boot menu. ‐‐‐ Original Message ‐‐‐ On August 14, 2018 4:35 PM, wrote: > I wrote the way i had build coreboot. Tianocore is not the default > payload. The default payload recently is (i checked now) SeaBIOS 1.11.2 > . > I have not touched anything at the payload. I just leave everything > default and would like to be able to see the output of coreboot so that > i can choose for example to boot from a usb-pendrive. > > What should i do now to get the to show > output on the screen? > > On 2018-08-14 11:53, Jose Trujillo via coreboot wrote: > > > Hello h42 > > If you are using Tianocore you must use VESA framebuffer > > If Seabios use text mode > > Jose > > ‐‐‐ Original Message ‐‐‐ > > On August 14, 2018 2:41 PM, h...@memeware.net wrote: > > > > > I dont get anything on the screen from coreboot. The later os is > > > displaying fine. > > > How i build the image: ran on a fresh git cloned (from today) 'make > > > menuconfig', chose just the mainboard manufacturer and the model, > > > press > > > esc, confirmed saving, ran 'make'. I installed this image and dont get > > > any coreboot output on the screen. When i wait long enough, i get the > > > output from the Linux OS on the screen. > > > From the coreboot logfile: > > > coreboot-4.8-1195-gb75a08b199 > > > [...] > > > FMAP: Found "FLASH" version 1.1 at 0. > > > FMAP: base = fff0 size = 10 #areas = 4 > > > FMAP: area RW_MRC_CACHE found @ 1 (65536 bytes) > > > MRC: No data in cbmem for 'RW_MRC_CACHE'. > > > BS: BS_DEV_ENUMERATE times (us): entry 0 run 150329 exit 16016 > > > found VGA at PCI: 00:02.0 > > > Setting up VGA for PCI: 00:02.0 > > > Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: > > > Setting PCI_BRIDGE_CTL_VGA for bridge Root Device > > > Allocating resources... > > > Reading resources... > > > TOUUD 0x8000 TOLUD 0x8000 TOM 0x8000 > > > IGD decoded, subtracting 64M UMA and 4M GTT > > > TSEG decoded, subtracting 8M > > > Available memory below 4GB: 1972M > > > Adding UMA memory area base=0x7b40 size=0x04c0 > > > Adding PCIe config bar base=0xe000 size=0x1000 > > > Done reading resources. > > > [...] > > > [21.707417] CONFIG => > > > [21.709411] (Primary => > > > [21.711924] (Port => Analog , > > > [21.715130] Framebuffer => > > > [21.718076] (Width => 640, > > > [21.721542] Height => 400, > > > [21.725008] Start_X => 0, > > > [21.728301] Start_Y => 0, > > > [21.731594] Stride => 1, > > > [21.734886] V_Stride => 1, > > > [21.738179] Tiling => Linear , > > > [21.741993] Rotation => No_Rotation, > > > [21.746153] Offset => 0x, > > > [21.749966] BPC => 8), > > > [21.753085] Mode => > > > [21.755424] (Dotclock => 14850, > > > [21.760192] H_Visible => 1920, > > > [21.764524] H_Sync_Begin => 2008, > > > [21.768857] H_Sync_End => 2052, > > > [21.773190] H_Total => 2200, > > > [21.777523] V_Visible => 1080, > > > [21.781857] V_Sync_Begin => 1084, > > > [21.786189] V_Sync_End => 1089, > > > [21.790522] V_Total => 1125, > > > [21.794855] H_Sync_Active_High => True, > > > [21.799189] V_Sync_Active_High => True, > > > [21.803521] BPC => 5)), > > > [21.807767] Secondary => > > > [21.810281] (Port => Disabled, > > > [21.813487] Framebuffer => > > > [21.816433] (Width => 1, > > > [21.819727] Height => 1, > > > [21.823020] Start_X => 0, > > > [21.826313] Start_Y => 0, > > > [21.829605] Stride => 1, > > > [21.832899] V_Stride => 1, > > > [21.836193] Tiling => Linear , > > > [21.840006] Rotation => No_Rotation, > > > [21.844166] Offset => 0x, > > > [21.847979] BPC => 8), > > > [21.851098] Mode => > > > [21.853438] (Dotclock => 2400, > > > [21.858118] H_Visible => 1, > > > [21.862191] H_Sync_Begin => 1, > > > [21.866263] H_Sync_End => 1, > > > [21.870336] H_Total => 1, > > > [21.874409] V_Visible => 1, > > > [21.878482] V_Sync_Begin => 1, > > > [21.882555] V_Sync_End => 1, > > > [21.886629] V_Total =&
Re: [coreboot] Intel G41 - Asrock G41M-GS: no coreboot screen output from Intel GPU on VGA
Hello h42 If you are using Tianocore you must use VESA framebuffer If Seabios use text mode Jose ‐‐‐ Original Message ‐‐‐ On August 14, 2018 2:41 PM, wrote: > I dont get anything on the screen from coreboot. The later os is > displaying fine. > > How i build the image: ran on a fresh git cloned (from today) 'make > menuconfig', chose just the mainboard manufacturer and the model, press > esc, confirmed saving, ran 'make'. I installed this image and dont get > any coreboot output on the screen. When i wait long enough, i get the > output from the Linux OS on the screen. > > From the coreboot logfile: > > coreboot-4.8-1195-gb75a08b199 > [...] > FMAP: Found "FLASH" version 1.1 at 0. > FMAP: base = fff0 size = 10 #areas = 4 > FMAP: area RW_MRC_CACHE found @ 1 (65536 bytes) > MRC: No data in cbmem for 'RW_MRC_CACHE'. > BS: BS_DEV_ENUMERATE times (us): entry 0 run 150329 exit 16016 > found VGA at PCI: 00:02.0 > Setting up VGA for PCI: 00:02.0 > Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: > Setting PCI_BRIDGE_CTL_VGA for bridge Root Device > Allocating resources... > Reading resources... > TOUUD 0x8000 TOLUD 0x8000 TOM 0x8000 > IGD decoded, subtracting 64M UMA and 4M GTT > TSEG decoded, subtracting 8M > Available memory below 4GB: 1972M > Adding UMA memory area base=0x7b40 size=0x04c0 > Adding PCIe config bar base=0xe000 size=0x1000 > Done reading resources. > [...] > [21.707417] CONFIG => > [21.709411] (Primary => > [21.711924] (Port => Analog , > [21.715130] Framebuffer => > [21.718076] (Width => 640, > [21.721542] Height => 400, > [21.725008] Start_X => 0, > [21.728301] Start_Y => 0, > [21.731594] Stride => 1, > [21.734886] V_Stride => 1, > [21.738179] Tiling => Linear , > [21.741993] Rotation => No_Rotation, > [21.746153] Offset => 0x, > [21.749966] BPC => 8), > [21.753085] Mode => > [21.755424] (Dotclock => 14850, > [21.760192] H_Visible => 1920, > [21.764524] H_Sync_Begin => 2008, > [21.768857] H_Sync_End => 2052, > [21.773190] H_Total => 2200, > [21.777523] V_Visible => 1080, > [21.781857] V_Sync_Begin => 1084, > [21.786189] V_Sync_End => 1089, > [21.790522] V_Total => 1125, > [21.794855] H_Sync_Active_High => True, > [21.799189] V_Sync_Active_High => True, > [21.803521] BPC => 5)), > [21.807767] Secondary => > [21.810281] (Port => Disabled, > [21.813487] Framebuffer => > [21.816433] (Width => 1, > [21.819727] Height => 1, > [21.823020] Start_X => 0, > [21.826313] Start_Y => 0, > [21.829605] Stride => 1, > [21.832899] V_Stride => 1, > [21.836193] Tiling => Linear , > [21.840006] Rotation => No_Rotation, > [21.844166] Offset => 0x, > [21.847979] BPC => 8), > [21.851098] Mode => > [21.853438] (Dotclock => 2400, > [21.858118] H_Visible => 1, > [21.862191] H_Sync_Begin => 1, > [21.866263] H_Sync_End => 1, > [21.870336] H_Total => 1, > [21.874409] V_Visible => 1, > [21.878482] V_Sync_Begin => 1, > [21.882555] V_Sync_End => 1, > [21.886629] V_Total => 1, > [21.890702] H_Sync_Active_High => False, > [21.895121] V_Sync_Active_High => False, > [21.899541] BPC => 5)), > [21.903787] Tertiary => > [21.906300] (Port => Disabled, > [21.909507] Framebuffer => > [21.912453] (Width => 1, > [21.915746] Height => 1, > [21.919039] Start_X => 0, > [21.922331] Start_Y => 0, > [21.925624] Stride => 1, > [21.928918] V_Stride => 1, > [21.932211] Tiling => Linear , > [21.936023] Rotation => No_Rotation, > [21.940183] Offset => 0x, > [21.943996] BPC => 8), > [21.947116] Mode => > [21.949455] (Dotclock => 2400, > [21.954135] H_Visible => 1, > [21.958207] H_Sync_Begin => 1, > [21.962280] H_Sync_End => 1, > [21.966353] H_Total => 1, > [21.970427] V_Visible => 1, > [21.974499] V_Sync_Begin => 1, > [21.978572] V_Sync_End => 1, > [21.982646] V_Total => 1, > [21.986719] H_Sync_Active_High => False, > [21.991138] V_Sync_Active_High => False, > [21.995557] BPC => 5))); > > PCI: 00:02.0 init finished in 307222 usecs > PCI: 00:02.1 init ... > PCI: 00:02.1 init finished in 2009 usecs > PCI: 00:1b.0 init ... > [...] > > So it seems to have detected that my screen is 1920*1080. GPU + screen > detection seems to be working. But i dont get any coreboot output on the > screen. > The output had worked fine on this screen with the OEM BIOS. > > > > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] fsp_broadwell_de: USB keyboard and mouse doesn't work.
Dear coreboot developers: I am trying to create CB firmware for Broadwell-D 1559 system using CamelBack Mountain CRB as mainboard selection, and the system boots Windows and Linux operating systems but USB keyboard and mouse doesn't work. I already enable/disabled EHCI/xHCI devices in devicetree without success. I tried Seabios and Tianocore without success. Anyone had experience this issue? Any advise will be appreciated. Thank you, Jose Trujillo.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] How to enable DisplayPort audio for Windows in Baytrail?
My system Baytrail E3845: DisplayPort audio in Linux works fine but in Windows is not detected. I am sure that the OS has the proper graphics drivers because DP Audio works with original BIOS in the same HDD Windows OS. Anyone could give me a hint? Thank you, J. Trujillo.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Thinkpad SD card controller DMA
If you don't enable a device in devicetree the initialization routine will not be executed. To test just insert a SD card and use DMESG or other command to see if device ID is found, also in device manager in Windows. JT. ‐‐‐ Original Message ‐‐‐ On June 21, 2018 2:06 PM, Thomasheidler via coreboot wrote: > That's what I'm thinking about, but I am not able to test a build with it > removed from the devicetree to see if that does the trick, so I was wondering > if anybody knows. > - > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Thinkpad SD card controller DMA
Hello Thomas, It is not enough just to disable it from the devicetree ? JT. ‐‐‐ Original Message ‐‐‐ On June 21, 2018 1:43 PM, Thomasheidler via coreboot wrote: > Thanks for your response and suggestions. > > Luckily I don’t need the SD card reader and would rather completely disable > it to protect against any DMA attack before the kernel initializes IOMMU. The > problem is that I don’t know how to prevent the controller from initializing > at all, short of actually desoldering the chip from the mainboard, which is > risky. > > Regarding the EC, are you aware of any working libre replacement for the EC > on any Lenovo Thinkpad? > > > - > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bayley Bay FSP-based CRB
Hello Zvika, Look for the list of Linux commands to dump many of the information from your original BIOS running, maybe there you will find this information. Also, some configuration can be seen from your original BIOS running Intel FIT for Baytrail in Windows. About configuring those settings in coreboot look for other examples in the coreboot tree about configuring PCI devices in devicetree.cb and other places. I Am new to coreboot too and please correct me if I Am wrong. Good Luck! J. Trujillo ‐‐‐ Original Message ‐‐‐ On June 21, 2018 3:34 AM, Zvi Vered wrote: > Hello, > > Thank you very much for the detailed reply. > Vendor's BIOS contains few peripherals initialization. > For example: PCIe enumeration, SATA controller, USB etc. > In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. > Should vendor supply code for this ? or any other information ? > How can I write it from scratch ? Can Intel provide information on how to > implement this initialization ? > > Thank you, > Zvika > > On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot > wrote: > >> Hello Zvika: >> 1.- Usually it is not necessary to change the CBFS size unless the compiler >> complain of lack of space. >> 2.- You should not worry about this setting to make your system to work. >> 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO >> because it will enable SOC internal COM1, instead (if your plan is to use >> FSP) enable FSP and add a VGA bios bin manually (The use of FSP is >> optional but I never tried without FSP). >> 4.- You need to add them yourself, there are examples to follow in this mail >> list. >> Good luck! >> J.Trujillo >> >> ‐‐‐ Original Message ‐‐‐ >> On June 18, 2018 6:24 AM, Zvi Vered wrote: >> >>> Hello, >>> I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make >>> distclean I chose: >>> Mainboard vendor: Intel >>> Mainboard model: Bayley Bay FSP-based CRB >>> 1. The size of CBFS is: 0x20. Is it a fix size or should I change it >>> according to my board (which is also bay trail) ? >>> 2. According to "dmidecode" I ran on my target, "Address: 0xE" >>> Should I set this address in coreboot configuration ? How ? >>> >>> 3. In this board default configuration, "Configure defaults for the Intel >>> FSP package" is not selected. Is it possible that this board does not use >>> Intel FSP at all ? >>> Under "Generic Drivers", "Use Intel firmware Support Package' is also not >>> selected. >>> >>> 4. Under "chipset", there is no option to set "Super I/O". Can you please >>> tell why ? >>> 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of >>> coreboot.rom is also 4MB. >>> >>> Thank you in advance, >>> Zvika >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Dear coreboot developers:
The problems with SIO devices were resolved:
I will give you a brief explanation of what I did after my previous mail just
for the record, thinking this might be useful for someone else in the future.
The problem was that ttyS0 from W83627DHG was not working properly (details on
previous mail).
I did the following:
1.- Did some fixes on my superio.asl that I use. (Did not fixed my
problem)
2.- Remove IRQs 3 and 4 from irqlinks.asl devices. (Did not fixed my
problem)
After this I gave up on this issue and decided to add my second SIO on 0x4e
FINTEK_F81803 that I modified based on F81866D.
3.- Added FINTEK_F81803 on 0x4e and compiled it.(Those ports didn't even
appear in the OS and I didn't know why)
I ran superiotool to check the state of the registers and discovered that the
Fintek SIO had the default values.
4.- Checked the code in devicetree, and superio.c of both SIO devices but
everything looked fine.
5.- In terminal I entered into "make menuconfig" and without making any change
to the configuration I selected "Save" then enter, exit, exit and recompiled
again and flashed and Voila! Fintek UART ports worked fine and ttyS0 from
Winbond is just working fine too.
I just need to do some fine tuning on the UART ports and configure correctly
HWMon and Fan control in Fintek.
Thank you All,
J. Trujillo
‐‐‐ Original Message ‐‐‐
On June 15, 2018 6:30 PM, Jose Trujillo via coreboot
wrote:
> Dear All,
>
> After following the recommendations from Rudolf and other people on this mail
> list I was able to make the following to make my LPC SIO to work (with
> issues).
>
> 1.- Enable SERIRQ in CONTINUOUS_MODE
>
> 2.- Add SUPERIO_WINBOND_W83627DHG driver to the Konfig file.
>
> 3.- Add the SIO parametrization in devicetree with 0x3f8,4 and 0x2f8,3 for
> UARTS.
>
> 4.- Add the PNP-ACPI information for SIO.
>
> 5.- Change SOC's 8259 trigger to EDGE.
>
> 6.- Disable internal (SOC) COM1 with the following code in romstage:
>
> void late_mainboard_romstage_entry()
>
> {
>
> /* Disable the internal COM1 */
>
> pci_write_config32(PCI_DEV(0, LPC_DEV, 0), UART_CONT, 0);
>
> u32 *irqen = (u32 )(ILB_BASE_ADDRESS + 0x88);write32(irqen, 0); / Unbind IRQ4
> */
>
> }
>
> 7.- Release IRQ4 from the PIRQ_PIC_ROUTES in irqroute.h and set IRQ6 instead.
>
> After all this:
>
> COM2 (0x2f8,3) works fine
>
> But:
>
> I still have an issue:
>
> COM1 (0x3f8,4) can transmit data correctly but at receiving the port hangs
> and not showing received string.
>
> When I make DMESG in terminal i get:
>
> "do_IRQ: 2.39 No irq handler for vector"
>
> "serial8250: too much work for irq4"
>
> What could be wrong?
>
> What could be missing?
>
> Let me know if you require more info,
>
> Any advise on the issue will be highly appreciated,
>
> Thank you,
>
> J. Trujillo
>
> ‐‐‐ Original Message ‐‐‐
>
> On June 6, 2018 11:46 PM, Rudolf Marek r.ma...@assembler.cz wrote:
>
> > Hi,
> >
> > In general I would check ELCR (I/O port register 0x4d0) to check if it is
> > correctly programmed to EDGE/LEVEL (it should be edge)
> >
> > Also, how the Linux is supposed to detect the I/O port irq? I think you
> > need some PNP device in ACPI to let linux infer the IRQ.
> >
> > I would also try to disable the IRQ from SoC, you just need to check how
> > they are enabled (sorry not an expert here)
> >
> > and also I would use the legacy 0x3f8 instead.
> >
> > Thanks
> >
> > Rudolf
>
> --
>
> coreboot mailing list: coreboot@coreboot.org
>
> https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bayley Bay FSP-based CRB
Hello Zvika: 1.- Usually it is not necessary to change the CBFS size unless the compiler complain of lack of space. 2.- You should not worry about this setting to make your system to work. 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO because it will enable SOC internal COM1, instead (if your plan is to use FSP) enable FSP and add a VGA bios bin manually (The use of FSP is optional but I never tried without FSP). 4.- You need to add them yourself, there are examples to follow in this mail list. Good luck! J.Trujillo ‐‐‐ Original Message ‐‐‐ On June 18, 2018 6:24 AM, Zvi Vered wrote: > Hello, > I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make > distclean I chose: > Mainboard vendor: Intel > Mainboard model: Bayley Bay FSP-based CRB > 1. The size of CBFS is: 0x20. Is it a fix size or should I change it > according to my board (which is also bay trail) ? > 2. According to "dmidecode" I ran on my target, "Address: 0xE" > Should I set this address in coreboot configuration ? How ? > > 3. In this board default configuration, "Configure defaults for the Intel FSP > package" is not selected. Is it possible that this board does not use Intel > FSP at all ? > Under "Generic Drivers", "Use Intel firmware Support Package' is also not > selected. > > 4. Under "chipset", there is no option to set "Super I/O". Can you please > tell why ? > 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of > coreboot.rom is also 4MB. > > Thank you in advance, > Zvika-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Dear All,
After following the recommendations from Rudolf and other people on this mail
list I was able to make the following to make my LPC SIO to work (with issues).
1.- Enable SERIRQ in CONTINUOUS_MODE
2.- Add SUPERIO_WINBOND_W83627DHG driver to the Konfig file.
3.- Add the SIO parametrization in devicetree with 0x3f8,4 and 0x2f8,3 for
UARTS.
4.- Add the PNP-ACPI information for SIO.
5.- Change SOC's 8259 trigger to EDGE.
6.- Disable internal (SOC) COM1 with the following code in romstage:
void late_mainboard_romstage_entry()
{
/* Disable the internal COM1 */
pci_write_config32(PCI_DEV(0, LPC_DEV, 0), UART_CONT, 0);
u32 *irqen = (u32 *)(ILB_BASE_ADDRESS + 0x88);
write32(irqen, 0); /* Unbind IRQ4 */
}
7.- Release IRQ4 from the PIRQ_PIC_ROUTES in irqroute.h and set IRQ6 instead.
After all this:
COM2 (0x2f8,3) works fine
But:
I still have an issue:
COM1 (0x3f8,4) can transmit data correctly but at receiving the port hangs and
not showing received string.
When I make DMESG in terminal i get:
"do_IRQ: 2.39 No irq handler for vector"
"serial8250: too much work for irq4"
What could be wrong?
What could be missing?
Let me know if you require more info,
Any advise on the issue will be highly appreciated,
Thank you,
J. Trujillo
‐‐‐ Original Message ‐‐‐
On June 6, 2018 11:46 PM, Rudolf Marek wrote:
> Hi,
>
> In general I would check ELCR (I/O port register 0x4d0) to check if it is
> correctly programmed to EDGE/LEVEL (it should be edge)
>
> Also, how the Linux is supposed to detect the I/O port irq? I think you need
> some PNP device in ACPI to let linux infer the IRQ.
>
> I would also try to disable the IRQ from SoC, you just need to check how they
> are enabled (sorry not an expert here)
>
> and also I would use the legacy 0x3f8 instead.
>
> Thanks
>
> Rudolf
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Dear Rudolf/All, Today I tried several things to try to make COM1 to work unsuccessfully. In my last test today I crossed the COM configuration from: COM1 (not working)COM2 (OK) 0x3f8, IRQ4 0x2f8, IRQ3 to: 0x3f8, IRQ3 0x2f8, IRQ4 (Both not working) My conclusion (I coudl be wrong) on this is that both resources 0x3f8, IRQ4 (COM1) are being used by coreboot or FSP. Anyone could give me a hint how to release those resources to be used by my LPC SIO chip. Thank you. J. Trujillo ‐‐‐ Original Message ‐‐‐ On June 6, 2018 11:46 PM, Rudolf Marek wrote: > Hi, > > In general I would check ELCR (I/O port register 0x4d0) to check if it is > correctly programmed to EDGE/LEVEL (it should be edge) > > Also, how the Linux is supposed to detect the I/O port irq? I think you need > some PNP device in ACPI to let linux infer the IRQ. > > I would also try to disable the IRQ from SoC, you just need to check how they > are enabled (sorry not an expert here) > > and also I would use the legacy 0x3f8 instead. > > Thanks > > Rudolf -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Thank you Rudolf for your advise, I checked the interrupts in Linux and showed me that the interrupts were already in EDGE mode but anyway I changed the interrupt mode in southcluster.c from quiet to edge. The default PNP configuration for the Winbond SIO was crashing Windows 7 and 10 and then I created a very simple PNP configuration and now both Windows OS boots fine and recognized the UART ports correctly but only COM2 with IRQ3 works correctly. Tomorrow I will keep testing to try to determine the reason but if any of you have any idea how to test or fix I will be glad to hear. I wish all of you to have a nice day. ‐‐‐ Original Message ‐‐‐ On June 6, 2018 11:46 PM, Rudolf Marek wrote: > Hi, > > In general I would check ELCR (I/O port register 0x4d0) to check if it is > correctly programmed to EDGE/LEVEL (it should be edge) > > Also, how the Linux is supposed to detect the I/O port irq? I think you need > some PNP device in ACPI to let linux infer the IRQ. > > I would also try to disable the IRQ from SoC, you just need to check how they > are enabled (sorry not an expert here) > > and also I would use the legacy 0x3f8 instead. > > Thanks > > Rudolf -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Dear coreboot developers: My system is Baytrail FSP E3845 2 LPC SIO WINBOND_W83627DHG and FINTEK_F81803 (disabled at this moment) SERIRQ has been enabled. I have the following issue in the W83627DHG SIO: ttyS2 @ 0x3e8, irq 4 doesn't work. (changing IRQ 4 to 6 does not make any difference) ttyS3 @ 0x2e8, irq 3 works OK. I am not mixing PCI interrupts with PNP ones. irqroute.h * #define PIRQ_PIC_ROUTES \ PIRQ_PIC(A, 5), \ PIRQ_PIC(B, 6), \ PIRQ_PIC(C, 7), \ PIRQ_PIC(D, 10), \ PIRQ_PIC(E, 11), \ PIRQ_PIC(F, 12), \ PIRQ_PIC(G, 14), \ PIRQ_PIC(H, 15) * devicetree.cb * device pci 1f.0 on # 8086 0F1C - LPC bridge chip superio/winbond/w83627dhg device pnp 2e.0 off end # Floppy device pnp 2e.1 off end # Parallel Port device pnp 2e.2 on # Com1 io 0x60 = 0x3e8 irq 0x70 = 4 end device pnp 2e.3 on # Com2 io 0x60 = 0x2e8 irq 0x70 = 3 end device pnp 2e.5 off end # Keyboard device pnp 2e.6 off end # SPI * Mainboard Kconfig * select SOC_INTEL_FSP_BAYTRAIL select SUPERIO_WINBOND_W83627DHG ## select SUPERIO_FINTEK_F81803 select BOARD_ROMSIZE_KB_2048 select HAVE_ACPI_TABLES select HAVE_OPTION_TABLE select TSC_MONOTONIC_TIMER select HAVE_ACPI_RESUME select CONFIG_SERIRQ_CONTINUOUS_MODE * Serial port on SuperIO is disabled in menuconfig ---> Generic Drivers. Coreboot version is 4.8.1. FSP version is Baytrail MR5 superiotool is giving me consistent information about adresses and irqs on the winbond and fintek chips. (but fintek is disabled now) so it means the SOC is communicating correctly with the SIO chips. I still didn't added superio.asl to the winbond SIO because it crash in Windows 7 and 10 with ACPI error. Original AMI firmware works correctly on both SIO chips. There is something I still missing to do? (additional configuration, routing, files like dts?? etc...) Another issue is that no matter I disable SOC legacy COM1 and menuconfig always appear ttyS0 in Linux (A ghost that I am not able to disable yet). Somebody have experience on this issue? Anyone can give me guidance in debugging this? Please tell me if i need to provide you with more information. Thank you in advance, Jose Trujillo.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
