[coreboot] coreboot Digest, Vol 165, Issue 9

mad.scientist.at.large at tutanota.com mad.scientist.at.large at tutanota.com
Wed Nov 7 00:16:02 CET 2018


Voted, no one tried to run me over this time. daytime definitely helps, though i did wind up talking to a drunken schizophrenic, but he wasn't rude to me (just other people).  and i'm definitely keeping this signature line, how else can i keep more promises than i've made?

"Better dead than red." Famous conservative saying.....



6. Nov 2018 15:43 by coreboot-request at coreboot.org <mailto:coreboot-request at coreboot.org>:


> Send coreboot mailing list submissions to
> 	> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
> or, via email, send a message with subject or body 'help' to
> 	> coreboot-request at coreboot.org <mailto:coreboot-request at coreboot.org>
>
> You can reach the person managing the list at
> 	> coreboot-owner at coreboot.org <mailto:coreboot-owner at coreboot.org>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of coreboot digest..."
>
>
> Today's Topics:
>
>    1. Re: Hardware diagnostic (yanvasilij yan)
>    2. New Defects reported by Coverity Scan for coreboot
>       (> scan-admin at coverity.com <mailto:scan-admin at coverity.com>> )
>    3. Re: How to get correct memory params for FSP (Alex Feinman)
>    4. Re: How to get correct memory params for FSP (R S)
>    5. Re: How to get correct memory params for FSP (Alex Feinman)
>    6. Can we please remove the FSP TempRamInit option (where
>       applicable) (Nico Huber)
>    7. Re: How to get correct memory params for FSP (R S)
>    8. Use VBIOS from vendor's original bin file (Zvi Vered)
>    9. Re: How to get correct memory params for FSP (Alex Feinman)
>   10. Re: Can we please remove the FSP TempRamInit option (where
>       applicable) (Lance Zhao)
>   11. Re: Use VBIOS from vendor's original bin file (Mike Banon)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 6 Nov 2018 16:51:49 +0500
> From: yanvasilij yan <> yanvasilij at gmail.com <mailto:yanvasilij at gmail.com>> >
> To: > nico.h at gmx.de <mailto:nico.h at gmx.de>
> Cc: > peter at stuge.se <mailto:peter at stuge.se>> , > coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> Subject: Re: [coreboot] Hardware diagnostic
> Message-ID:
> 	<> CAATv5Wb7yg3u6OLJjXr5E_iCXSn_2uXeB58_Fo-=KghN0ZAPEQ at mail.gmail.com <mailto:CAATv5Wb7yg3u6OLJjXr5E_iCXSn_2uXeB58_Fo-=KghN0ZAPEQ at mail.gmail.com>> >
> Content-Type: text/plain; charset="utf-8"
>
> Thank lot too all!
>
> Sory for last response!
>
> You were right, the problem was in power up sequence. After fixing all
> become correct. The 0x8086/0x0000 device disappeared, and payload
> succesfuly downloaded.
>
> Peter Stuge,  thank you for detailed comments!
>
> Nico Huber, thank you for active participation!
>
>
>
> ??, 28 ???. 2018 ?. ? 4:18, Nico Huber <> nico.h at gmx.de <mailto:nico.h at gmx.de>> >:
>
>> On 10/28/18 12:25 AM, Peter Stuge wrote:
>> > Why are there no RAM regions? I don't know.
>>
>> Quite simple, because the code that adds them is tied to 8086:0f00.
>>
>> >> nico_h in the IRC chat noticed that in non-working board appears a
>> starnge
>> >> device with vid/did PCI: 00:00.0 [8086/0000].
>> >
>> > The 0000 is a HUGE red sign, screaming to be thoroughly investigated.
>> >
>> > This also hints that the power up changes may be the problem.
>>
>> I agree, but note that in the datasheet (or EDS at least), the DID is
>> not read-only. A strap (that I coudn't find more about) is supposed to
>> set the initial value plus there is a message mentioned (to be sent to
>> sth. I didn't look into) that may change it.
>>
>> So alternatively to diagnosing the hardware changes, you could also
>> follow the bread crumbs in the documentation.
>>
>> Nico
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/7b65b1c7/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/7b65b1c7/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 06 Nov 2018 14:41:09 +0000 (UTC)
> From: > scan-admin at coverity.com <mailto:scan-admin at coverity.com>
> To: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> Subject: [coreboot] New Defects reported by Coverity Scan for coreboot
> Message-ID: <5be1a805686ef_84f72b08291e2f60744ba at node1.mail>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.
>
> 6 new defect(s) introduced to coreboot found with Coverity Scan.
>
>
> New defect(s) Reported-by: Coverity Scan
> Showing 6 of 6 defect(s)
>
>
> ** CID 1396579:    (STRAY_SEMICOLON)
> /src/soc/mediatek/mt8183/auxadc.c: 46 in auxadc_get_rawdata()
> /src/soc/mediatek/mt8183/auxadc.c: 49 in auxadc_get_rawdata()
> /src/soc/mediatek/mt8183/auxadc.c: 53 in auxadc_get_rawdata()
>
>
> ________________________________________________________________________________________________________
> *** CID 1396579:    (STRAY_SEMICOLON)
> /src/soc/mediatek/mt8183/auxadc.c: 46 in auxadc_get_rawdata()
> 40     	assert(!expired);					\
> 41     })
> 42     
> 43     static uint32_t auxadc_get_rawdata(int channel)
> 44     {
> 45     	setbits_le32(&mt8183_infracfg->module_sw_cg_1_clr, 1 << 10);
>>>>     CID 1396579:    (STRAY_SEMICOLON)
>>>>     A "while" statement with no block followed by a stand-alone block is suspicious.
> 46     	wait_ms(!(read32(&mtk_auxadc->con2) & 0x1), 300);
> 47     
> 48     	clrbits_le32(&mtk_auxadc->con1, 1 << channel);
> 49     	wait_ms(!(read32(&mtk_auxadc->data[channel]) & (1 << 12)), 300);
> 50     
> 51     	setbits_le32(&mtk_auxadc->con1, 1 << channel);
> /src/soc/mediatek/mt8183/auxadc.c: 49 in auxadc_get_rawdata()
> 43     static uint32_t auxadc_get_rawdata(int channel)
> 44     {
> 45     	setbits_le32(&mt8183_infracfg->module_sw_cg_1_clr, 1 << 10);
> 46     	wait_ms(!(read32(&mtk_auxadc->con2) & 0x1), 300);
> 47     
> 48     	clrbits_le32(&mtk_auxadc->con1, 1 << channel);
>>>>     CID 1396579:    (STRAY_SEMICOLON)
>>>>     A "while" statement with no block followed by a stand-alone block is suspicious.
> 49     	wait_ms(!(read32(&mtk_auxadc->data[channel]) & (1 << 12)), 300);
> 50     
> 51     	setbits_le32(&mtk_auxadc->con1, 1 << channel);
> 52     	udelay(25);
> 53     	wait_ms(read32(&mtk_auxadc->data[channel]) & (1 << 12), 300);
> 54     
> /src/soc/mediatek/mt8183/auxadc.c: 53 in auxadc_get_rawdata()
> 47     
> 48     	clrbits_le32(&mtk_auxadc->con1, 1 << channel);
> 49     	wait_ms(!(read32(&mtk_auxadc->data[channel]) & (1 << 12)), 300);
> 50     
> 51     	setbits_le32(&mtk_auxadc->con1, 1 << channel);
> 52     	udelay(25);
>>>>     CID 1396579:    (STRAY_SEMICOLON)
>>>>     A "while" statement with no block followed by a stand-alone block is suspicious.
> 53     	wait_ms(read32(&mtk_auxadc->data[channel]) & (1 << 12), 300);
> 54     
> 55     	uint32_t value = read32(&mtk_auxadc->data[channel]) & 0x0FFF;
> 56     
> 57     	setbits_le32(&mt8183_infracfg->module_sw_cg_1_set, 1 << 10);
> 58     
>
> ** CID 1396578:    (UNINIT)
> /src/arch/riscv/trap_handler.c: 98 in interrupt_handler()
> /src/arch/riscv/trap_handler.c: 100 in interrupt_handler()
> /src/arch/riscv/trap_handler.c: 102 in interrupt_handler()
> /src/arch/riscv/trap_handler.c: 104 in interrupt_handler()
> /src/arch/riscv/trap_handler.c: 106 in interrupt_handler()
> /src/arch/riscv/trap_handler.c: 107 in interrupt_handler()
>
>
> ________________________________________________________________________________________________________
> *** CID 1396578:    (UNINIT)
> /src/arch/riscv/trap_handler.c: 98 in interrupt_handler()
> 92     
> 93     		clear_csr(mie, MIP_MTIP);
> 94     		set_csr(mip, MIP_STIP);
> 95     
> 96     		break;
> 97     	case IRQ_M_SOFT:
>>>>     CID 1396578:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 98     		if (HLS()->ipi_pending & IPI_SOFT) {
> 99     			set_csr(mip, MIP_SSIP);
> 100     		} else if (HLS()->ipi_pending & IPI_FENCE_I) {
> 101     			asm volatile("fence.i");
> 102     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
> 103     			asm volatile("sfence.vma");
> /src/arch/riscv/trap_handler.c: 100 in interrupt_handler()
> 94     		set_csr(mip, MIP_STIP);
> 95     
> 96     		break;
> 97     	case IRQ_M_SOFT:
> 98     		if (HLS()->ipi_pending & IPI_SOFT) {
> 99     			set_csr(mip, MIP_SSIP);
>>>>     CID 1396578:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 100     		} else if (HLS()->ipi_pending & IPI_FENCE_I) {
> 101     			asm volatile("fence.i");
> 102     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
> 103     			asm volatile("sfence.vma");
> 104     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
> 105     			asm volatile("sfence.vma");
> /src/arch/riscv/trap_handler.c: 102 in interrupt_handler()
> 96     		break;
> 97     	case IRQ_M_SOFT:
> 98     		if (HLS()->ipi_pending & IPI_SOFT) {
> 99     			set_csr(mip, MIP_SSIP);
> 100     		} else if (HLS()->ipi_pending & IPI_FENCE_I) {
> 101     			asm volatile("fence.i");
>>>>     CID 1396578:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 102     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
> 103     			asm volatile("sfence.vma");
> 104     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
> 105     			asm volatile("sfence.vma");
> 106     		} else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
> 107     			while (HLS()->ipi_pending & IPI_SHUTDOWN)
> /src/arch/riscv/trap_handler.c: 104 in interrupt_handler()
> 98     		if (HLS()->ipi_pending & IPI_SOFT) {
> 99     			set_csr(mip, MIP_SSIP);
> 100     		} else if (HLS()->ipi_pending & IPI_FENCE_I) {
> 101     			asm volatile("fence.i");
> 102     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
> 103     			asm volatile("sfence.vma");
>>>>     CID 1396578:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 104     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
> 105     			asm volatile("sfence.vma");
> 106     		} else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
> 107     			while (HLS()->ipi_pending & IPI_SHUTDOWN)
> 108     				asm volatile("wfi");
> 109     		}
> /src/arch/riscv/trap_handler.c: 106 in interrupt_handler()
> 100     		} else if (HLS()->ipi_pending & IPI_FENCE_I) {
> 101     			asm volatile("fence.i");
> 102     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
> 103     			asm volatile("sfence.vma");
> 104     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
> 105     			asm volatile("sfence.vma");
>>>>     CID 1396578:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 106     		} else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
> 107     			while (HLS()->ipi_pending & IPI_SHUTDOWN)
> 108     				asm volatile("wfi");
> 109     		}
> 110     		break;
> 111     	default:
> /src/arch/riscv/trap_handler.c: 107 in interrupt_handler()
> 101     			asm volatile("fence.i");
> 102     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
> 103     			asm volatile("sfence.vma");
> 104     		} else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
> 105     			asm volatile("sfence.vma");
> 106     		} else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
>>>>     CID 1396578:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 107     			while (HLS()->ipi_pending & IPI_SHUTDOWN)
> 108     				asm volatile("wfi");
> 109     		}
> 110     		break;
> 111     	default:
> 112     		printk(BIOS_EMERG, "======================================\n");
>
> ** CID 1396577:    (UNINIT)
> /src/arch/riscv/smp.c: 35 in smp_pause()
> /src/arch/riscv/smp.c: 41 in smp_pause()
> /src/arch/riscv/smp.c: 48 in smp_pause()
> /src/arch/riscv/smp.c: 52 in smp_pause()
> /src/arch/riscv/smp.c: 53 in smp_pause()
> /src/arch/riscv/smp.c: 58 in smp_pause()
> /src/arch/riscv/smp.c: 61 in smp_pause()
> /src/arch/riscv/smp.c: 62 in smp_pause()
>
>
> ________________________________________________________________________________________________________
> *** CID 1396577:    (UNINIT)
> /src/arch/riscv/smp.c: 35 in smp_pause()
> 29     	int hartid = read_csr(mhartid);
> 30     
> 31     	if (hartid != working_hartid) {
> 32     		/* waiting for work hart */
> 33     		do {
> 34     			barrier();
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 35     		} while (SYNCA != 0x01234567);
> 36     
> 37     		clear_csr(mstatus, MSTATUS_MIE);
> 38     		write_csr(mie, MIP_MSIP);
> 39     
> 40     		/* count how many cores enter the halt */
> /src/arch/riscv/smp.c: 41 in smp_pause()
> 35     		} while (SYNCA != 0x01234567);
> 36     
> 37     		clear_csr(mstatus, MSTATUS_MIE);
> 38     		write_csr(mie, MIP_MSIP);
> 39     
> 40     		/* count how many cores enter the halt */
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 41     		__sync_fetch_and_add(&SYNCB, 1);
> 42     
> 43     		do {
> 44     			barrier();
> 45     			__asm__ volatile ("wfi");
> 46     		} while ((read_csr(mip) & MIP_MSIP) == 0);
> /src/arch/riscv/smp.c: 48 in smp_pause()
> 42     
> 43     		do {
> 44     			barrier();
> 45     			__asm__ volatile ("wfi");
> 46     		} while ((read_csr(mip) & MIP_MSIP) == 0);
> 47     		set_msip(hartid, 0);
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 48     		HLS()->entry.fn(HLS()->entry.arg);
> 49     	} else {
> 50     		/* Initialize the counter and
> 51     		 * mark the work hart into smp_pause */
> 52     		SYNCB = 0;
> 53     		SYNCA = 0x01234567;
> /src/arch/riscv/smp.c: 52 in smp_pause()
> 46     		} while ((read_csr(mip) & MIP_MSIP) == 0);
> 47     		set_msip(hartid, 0);
> 48     		HLS()->entry.fn(HLS()->entry.arg);
> 49     	} else {
> 50     		/* Initialize the counter and
> 51     		 * mark the work hart into smp_pause */
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 52     		SYNCB = 0;
> 53     		SYNCA = 0x01234567;
> 54     
> 55     		/* waiting for other Hart to enter the halt */
> 56     		do {
> 57     			barrier();
> /src/arch/riscv/smp.c: 53 in smp_pause()
> 47     		set_msip(hartid, 0);
> 48     		HLS()->entry.fn(HLS()->entry.arg);
> 49     	} else {
> 50     		/* Initialize the counter and
> 51     		 * mark the work hart into smp_pause */
> 52     		SYNCB = 0;
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 53     		SYNCA = 0x01234567;
> 54     
> 55     		/* waiting for other Hart to enter the halt */
> 56     		do {
> 57     			barrier();
> 58     		} while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
> /src/arch/riscv/smp.c: 58 in smp_pause()
> 52     		SYNCB = 0;
> 53     		SYNCA = 0x01234567;
> 54     
> 55     		/* waiting for other Hart to enter the halt */
> 56     		do {
> 57     			barrier();
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 58     		} while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
> 59     
> 60     		/* initialize for the next call */
> 61     		SYNCA = 0;
> 62     		SYNCB = 0;
> 63     	}
> /src/arch/riscv/smp.c: 61 in smp_pause()
> 55     		/* waiting for other Hart to enter the halt */
> 56     		do {
> 57     			barrier();
> 58     		} while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
> 59     
> 60     		/* initialize for the next call */
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 61     		SYNCA = 0;
> 62     		SYNCB = 0;
> 63     	}
> 64     #undef SYNCA
> 65     #undef SYNCB
> 66     }
> /src/arch/riscv/smp.c: 62 in smp_pause()
> 56     		do {
> 57     			barrier();
> 58     		} while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
> 59     
> 60     		/* initialize for the next call */
> 61     		SYNCA = 0;
>>>>     CID 1396577:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 62     		SYNCB = 0;
> 63     	}
> 64     #undef SYNCA
> 65     #undef SYNCB
> 66     }
> 67     
>
> ** CID 1396576:    (UNINIT)
> /src/arch/riscv/smp.c: 76 in smp_resume()
> /src/arch/riscv/smp.c: 77 in smp_resume()
> /src/arch/riscv/smp.c: 84 in smp_resume()
>
>
> ________________________________________________________________________________________________________
> *** CID 1396576:    (UNINIT)
> /src/arch/riscv/smp.c: 76 in smp_resume()
> 70     	int hartid = read_csr(mhartid);
> 71     
> 72     	if (fn == NULL)
> 73     		die("must pass a non-null function pointer\n");
> 74     
> 75     	for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++) {
>>>>     CID 1396576:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 76     		OTHER_HLS(i)->entry.fn = fn;
> 77     		OTHER_HLS(i)->entry.arg = arg;
> 78     	}
> 79     
> 80     	for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++)
> 81     		if (i != hartid)
> 82     			set_msip(i, 1);
> 83     
> 84     	HLS()->entry.fn(HLS()->entry.arg);
> /src/arch/riscv/smp.c: 77 in smp_resume()
> 71     
> 72     	if (fn == NULL)
> 73     		die("must pass a non-null function pointer\n");
> 74     
> 75     	for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++) {
> 76     		OTHER_HLS(i)->entry.fn = fn;
>>>>     CID 1396576:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 77     		OTHER_HLS(i)->entry.arg = arg;
> 78     	}
> 79     
> 80     	for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++)
> 81     		if (i != hartid)
> 82     			set_msip(i, 1);
> 83     
> 84     	HLS()->entry.fn(HLS()->entry.arg);
> /src/arch/riscv/smp.c: 84 in smp_resume()
> 78     	}
> 79     
> 80     	for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++)
> 81     		if (i != hartid)
> 82     			set_msip(i, 1);
> 83     
>>>>     CID 1396576:    (UNINIT)
>>>>     Using uninitialized value "sp".
> 84     	HLS()->entry.fn(HLS()->entry.arg);
>
> ** CID 1396575:  Uninitialized variables  (UNINIT)
> /src/arch/riscv/sbi.c: 44 in sbi_set_timer()
>
>
> ________________________________________________________________________________________________________
> *** CID 1396575:  Uninitialized variables  (UNINIT)
> /src/arch/riscv/sbi.c: 44 in sbi_set_timer()
> 38     }
> 39     
> 40     static uintptr_t sbi_set_timer(uint64_t when)
> 41     {
> 42     	clear_csr(mip, MIP_STIP);
> 43     	set_csr(mie, MIP_MTIP);
>>>>     CID 1396575:  Uninitialized variables  (UNINIT)
>>>>     Using uninitialized value "sp".
> 44     	*(HLS()->timecmp) = when;
> 45     	return 0;
> 46     }
> 47     
> 48     #if IS_ENABLED(CONFIG_CONSOLE_SERIAL)
> 49     static uintptr_t sbi_console_putchar(uint8_t ch)
>
> ** CID 1396574:  Uninitialized variables  (UNINIT)
> /src/arch/riscv/sbi.c: 31 in send_ipi()
>
>
> ________________________________________________________________________________________________________
> *** CID 1396574:  Uninitialized variables  (UNINIT)
> /src/arch/riscv/sbi.c: 31 in send_ipi()
> 25     
> 26     static uintptr_t send_ipi(uintptr_t *pmask, intptr_t type)
> 27     {
> 28     	uintptr_t mask = mprv_read_uintptr_t(pmask);
> 29     	for (int i = 0; mask; i++) {
> 30     		if (mask & 1) {
>>>>     CID 1396574:  Uninitialized variables  (UNINIT)
>>>>     Using uninitialized value "sp".
> 31     			OTHER_HLS(i)->ipi_pending |= type;
> 32     			/* send soft interrupt to target hart */
> 33     			set_msip(i, 1);
> 34     		}
> 35     		mask = mask >> 1;
> 36     	}
>
>
> ________________________________________________________________________________________________________
> To view the defects in Coverity Scan visit, > https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5a31m51VEsEaxFt1YGbyr6wNWh1JRkzG6iEWnu4wa11R6V6bq3pvRdnRMNLGWgttGAab8saZW-2BgimLNQFi615pGDzotKysOu2G2J4DGnZTtorDLvESCDRCTODv3O77-2B7n1VYt5e-2BYXktmH9OM-2FL42YRQ224IXfqqi-2BMUaEbYo2-2F2Afr5Jd9JHIIEpLZPsm1PcE-3D <https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5a31m51VEsEaxFt1YGbyr6wNWh1JRkzG6iEWnu4wa11R6V6bq3pvRdnRMNLGWgttGAab8saZW-2BgimLNQFi615pGDzotKysOu2G2J4DGnZTtorDLvESCDRCTODv3O77-2B7n1VYt5e-2BYXktmH9OM-2FL42YRQ224IXfqqi-2BMUaEbYo2-2F2Afr5Jd9JHIIEpLZPsm1PcE-3D>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 6 Nov 2018 17:21:09 +0000
> From: Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> >
> To: "> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> " <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >, Alexey Borovikov
> 	<> alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> 	<> BY2PR15MB0741BA3CCDD2161D735AA069B9CB0 at BY2PR15MB0741.namprd15.prod.outlook.com <mailto:BY2PR15MB0741BA3CCDD2161D735AA069B9CB0 at BY2PR15MB0741.namprd15.prod.outlook.com>> >
> 	
> Content-Type: text/plain; charset="iso-8859-1"
>
> The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output
>
> ________________________________
> From: coreboot <> coreboot-bounces at coreboot.org <mailto:coreboot-bounces at coreboot.org>> > on behalf of Alexey Borovikov via coreboot <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >
> Sent: Saturday, November 3, 2018 5:38 AM
> To: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> Subject: [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems?
> Many thanks!
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/481897dd/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/481897dd/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 6 Nov 2018 12:30:45 -0500
> From: R S <> rene.shuster at bcsemail.org <mailto:rene.shuster at bcsemail.org>> >
> To: > alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>
> Cc: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> , > alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> 	<> CADTU-KnUw8vyHsnLrVZ-M7nKDDBv3VF-KRQhf7Xt050mWgxMRQ at mail.gmail.com <mailto:CADTU-KnUw8vyHsnLrVZ-M7nKDDBv3VF-KRQhf7Xt050mWgxMRQ at mail.gmail.com>> >
> Content-Type: text/plain; charset="utf-8"
>
> Faint memories... are you the ISO recorder author from 15 years ago?
>
> On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> >
> wrote:
>
>> The two major issues with bringing up the memory subsystem on a new board
>> are SPD parameters and DQ/DQS layout
>> Specifically, if you look at the apollolake rvp subtree, you can see a
>> whole bunch of parameters being set in romstage.c. Some of it is fairly
>> straightforward. Swizzling tables are not and require you to be able to
>> read schematic (and have access to it in the first place)
>> Obviously, the problem could be elsewhere. I would start with enabling MRC
>> debug and perhaps posting the MRC output
>>
>> ------------------------------
>> *From:* coreboot <>> coreboot-bounces at coreboot.org <mailto:coreboot-bounces at coreboot.org>>> > on behalf of Alexey
>> Borovikov via coreboot <>> coreboot at coreboot.org <mailto:coreboot at coreboot.org>>> >
>> *Sent:* Saturday, November 3, 2018 5:38 AM
>> *To:* >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>> *Subject:* [coreboot] How to get correct memory params for FSP
>>
>> Hi.
>> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP
>> for the Baytrail family. The result - postcode is 0x2A. From the
>> descriptions on the Internet, I understand that the problem is in the
>> incorrect memory parameters.
>> Question: are there any utilities or methods that will help to get the
>> correct memory parameters when working a regular BIOS from Linux or Windows
>> systems?
>> Many thanks!
>> --
>> coreboot mailing list: >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>>
>
>
> -- 
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign <> http://comicsanscriminal.com <http://comicsanscriminal.com>> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/b104872d/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/b104872d/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 6 Nov 2018 17:45:39 +0000
> From: Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> >
> To: R S <> rene.shuster at bcsemail.org <mailto:rene.shuster at bcsemail.org>> >
> Cc: "> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> " <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> 	<> BY2PR15MB0741162048DF7F78FBFA3CB8B9CB0 at BY2PR15MB0741.namprd15.prod.outlook.com <mailto:BY2PR15MB0741162048DF7F78FBFA3CB8B9CB0 at BY2PR15MB0741.namprd15.prod.outlook.com>> >
> 	
> Content-Type: text/plain; charset="iso-8859-1"
>
> Guilty as charged :)
>
> ________________________________
> From: R S <> rene.shuster at bcsemail.org <mailto:rene.shuster at bcsemail.org>> >
> Sent: Tuesday, November 6, 2018 9:30 AM
> To: > alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>
> Cc: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> ; > alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>
> Subject: Re: [coreboot] How to get correct memory params for FSP
>
> Faint memories... are you the ISO recorder author from 15 years ago?
>
> On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> <> mailto:alexfeinman at hotmail.com <mailto:mailto:alexfeinman at hotmail.com>> >> wrote:
> The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output
>
> ________________________________
> From: coreboot <> coreboot-bounces at coreboot.org <mailto:coreboot-bounces at coreboot.org>> <> mailto:coreboot-bounces at coreboot.org <mailto:mailto:coreboot-bounces at coreboot.org>> >> on behalf of Alexey Borovikov via coreboot <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> >>
> Sent: Saturday, November 3, 2018 5:38 AM
> To: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> >
> Subject: [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems?
> Many thanks!
> --
> coreboot mailing list: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> >
> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign<> http://comicsanscriminal.com <http://comicsanscriminal.com>> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/f23a1745/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/f23a1745/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 6 Nov 2018 19:11:22 +0100
> From: Nico Huber <> nico.h at gmx.de <mailto:nico.h at gmx.de>> >
> To: "> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> " <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >, Praveen hodagatta
> 	pranesh <> praveenx.hodagatta.pranesh at intel.com <mailto:praveenx.hodagatta.pranesh at intel.com>> >, Boon Tiong Teo
> 	<> boon.tiong.teo at intel.com <mailto:boon.tiong.teo at intel.com>> >, Subrata Banik <> subrata.banik at intel.com <mailto:subrata.banik at intel.com>> >,
> 	Aaron Durbin <> adurbin at google.com <mailto:adurbin at google.com>> >
> Subject: [coreboot] Can we please remove the FSP TempRamInit option
> 	(where applicable)
> Message-ID: <> 2168f785-b8f3-01f8-700b-f402e4e5cd44 at gmx.de <mailto:2168f785-b8f3-01f8-700b-f402e4e5cd44 at gmx.de>> >
> Content-Type: text/plain; charset=utf-8
>
> Hi coreboot fellows,
>
> I have always been confused that we have the option to use FSP's
> TempRamInit (CAR setup) even when a native coreboot implementation is
> available. Now, what I'm really concerned about is the low quality of
> the code in coreboot surrounding it. There are often Kconfig prompts
> that don't add up, and about every related, merged commit I've been
> looking at today seemed somehow flawed.
>
> So if we can't keep the quality we are used to when trying to maintain
> two (or even more) CAR options, why not focus on a single one? After
> all, coreboot is a firmware framework, not an FSP testing framework.
>
> Here's just one weird example of what I was confronted with today:
>
>         default USE_CANNONLAKE_CAR_NEM_ENHANCED if
> MAINBOARD_HAS_CHROMEOS
>
> I don't understand it, but somehow feel offended. Does that mean I have
> to work with ChromeOS now to get reasonable defaults?
>
> Nico
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 6 Nov 2018 13:24:56 -0500
> From: R S <> rene.shuster at bcsemail.org <mailto:rene.shuster at bcsemail.org>> >
> To: > alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>
> Cc: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> 	<> CADTU-Km5R3P4ABA_SGZMOwqA4BPypS-47mr23aFDiJZGTwQqhA at mail.gmail.com <mailto:CADTU-Km5R3P4ABA_SGZMOwqA4BPypS-47mr23aFDiJZGTwQqhA at mail.gmail.com>> >
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for it after all those years.
> // end being off-topic
>
> On Tue, Nov 6, 2018 at 12:45 PM Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> >
> wrote:
>
>> Guilty as charged :)
>>
>> ------------------------------
>> *From:* R S <>> rene.shuster at bcsemail.org <mailto:rene.shuster at bcsemail.org>>> >
>> *Sent:* Tuesday, November 6, 2018 9:30 AM
>> *To:* >> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>
>> *Cc:* >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>>> ; >> alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>
>> *Subject:* Re: [coreboot] How to get correct memory params for FSP
>>
>> Faint memories... are you the ISO recorder author from 15 years ago?
>>
>> On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <>> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>>> >
>> wrote:
>>
>> The two major issues with bringing up the memory subsystem on a new board
>> are SPD parameters and DQ/DQS layout
>> Specifically, if you look at the apollolake rvp subtree, you can see a
>> whole bunch of parameters being set in romstage.c. Some of it is fairly
>> straightforward. Swizzling tables are not and require you to be able to
>> read schematic (and have access to it in the first place)
>> Obviously, the problem could be elsewhere. I would start with enabling MRC
>> debug and perhaps posting the MRC output
>>
>> ------------------------------
>> *From:* coreboot <>> coreboot-bounces at coreboot.org <mailto:coreboot-bounces at coreboot.org>>> > on behalf of Alexey
>> Borovikov via coreboot <>> coreboot at coreboot.org <mailto:coreboot at coreboot.org>>> >
>> *Sent:* Saturday, November 3, 2018 5:38 AM
>> *To:* >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>> *Subject:* [coreboot] How to get correct memory params for FSP
>>
>> Hi.
>> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP
>> for the Baytrail family. The result - postcode is 0x2A. From the
>> descriptions on the Internet, I understand that the problem is in the
>> incorrect memory parameters.
>> Question: are there any utilities or methods that will help to get the
>> correct memory parameters when working a regular BIOS from Linux or Windows
>> systems?
>> Many thanks!
>> --
>> coreboot mailing list: >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>>
>>
>>
>> --
>> Tech III * AppControl * Endpoint Protection * Server Maintenance
>> Buncombe County Schools Technology Department Network Group
>> ComicSans Awareness Campaign <>> http://comicsanscriminal.com <http://comicsanscriminal.com>>> >
>>
>
>
> -- 
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign <> http://comicsanscriminal.com <http://comicsanscriminal.com>> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/243ef171/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/243ef171/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 8
> Date: Tue, 6 Nov 2018 21:15:30 +0200
> From: Zvi Vered <> veredz72 at gmail.com <mailto:veredz72 at gmail.com>> >
> To: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> Subject: [coreboot] Use VBIOS from vendor's original bin file
> Message-ID:
> 	<> CABRndgxjqFeFkvxmUEiyROJ9UDbt+jFdOHLNNm2Ypk9PmvRYmg at mail.gmail.com <mailto:CABRndgxjqFeFkvxmUEiyROJ9UDbt+jFdOHLNNm2Ypk9PmvRYmg at mail.gmail.com>> >
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> Currently I'm replacing the BIOS in the vendor's bin file with coreboot.bin
> Can coreboot use Vendor's VBIOS instead of the serial console ?
> How can it find it in the vendor's bin file ?
>
> Thank you,
> Zvika
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/9bb26869/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/9bb26869/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 9
> Date: Tue, 6 Nov 2018 22:20:53 +0000
> From: Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> >
> To: Alexey Borovikov <> alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>> >, R S
> 	<> rene.shuster at bcsemail.org <mailto:rene.shuster at bcsemail.org>> >
> Cc: "> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> " <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> 	<> BY2PR15MB0741216CBC670E46EA3E581DB9CB0 at BY2PR15MB0741.namprd15.prod.outlook.com <mailto:BY2PR15MB0741216CBC670E46EA3E581DB9CB0 at BY2PR15MB0741.namprd15.prod.outlook.com>> >
> 	
> Content-Type: text/plain; charset="koi8-r"
>
> This tells us nothing about swizzling - the order in which DQ/DQS lines of the memory address bus are connected to the CPU. Memory connections to the CPU are flexible to simplify PCB routing. As a result in order for the memory controller to be able to use memory you need to provide board-specific mapping. You cannot glean this from looking at the PCB - you need the schematic. And no, off the shelf Tianocore will not automatically do this either - it's a customizable part of the build
>
> ________________________________
> From: Alexey Borovikov <> alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>> >
> Sent: Tuesday, November 6, 2018 11:06 AM
> To: R S; > alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>
> Cc: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> Subject: Re: [coreboot] How to get correct memory params for FSP
>
> Ok, there is no spd on the board. Four memory chips are soldered on the board (Micron DDR3L 4?512MB 1333Mhz). I understand that I need to set the correct memory parameters in the fsp configurator. Even if it works, replacing the memory chips may lead to a stop working of the coreboot.rom. It is necessary to change the parameters of the fsp again and rebuild coreboot.rom.
> How does the proprietary BIOS (TianoCore) work in case of replacing the memory chips on board?
> Are there universal parameters for this memory types and what should I take note for when configuring FSP?
>
> From: R S<> mailto:rene.shuster at bcsemail.org <mailto:mailto:rene.shuster at bcsemail.org>> >
> Sent: Tuesday, November 06, 2018 8:30 PM
> To: > alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> <> mailto:alexfeinman at hotmail.com <mailto:mailto:alexfeinman at hotmail.com>> >
> Cc: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> > ; > alexey_bau at mail.ru <mailto:alexey_bau at mail.ru>> <> mailto:alexey_bau at mail.ru <mailto:mailto:alexey_bau at mail.ru>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
>
> Faint memories... are you the ISO recorder author from 15 years ago?
>
> On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <> alexfeinman at hotmail.com <mailto:alexfeinman at hotmail.com>> <> mailto:alexfeinman at hotmail.com <mailto:mailto:alexfeinman at hotmail.com>> >> wrote:
> The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output
> ________________________________
> From: coreboot <> coreboot-bounces at coreboot.org <mailto:coreboot-bounces at coreboot.org>> <> mailto:coreboot-bounces at coreboot.org <mailto:mailto:coreboot-bounces at coreboot.org>> >> on behalf of Alexey Borovikov via coreboot <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> >>
> Sent: Saturday, November 3, 2018 5:38 AM
> To: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> >
> Subject: [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems?
> Many thanks!
> --
> coreboot mailing list: > coreboot at coreboot.org <mailto:coreboot at coreboot.org>> <> mailto:coreboot at coreboot.org <mailto:mailto:coreboot at coreboot.org>> >
> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign<> http://comicsanscriminal.com <http://comicsanscriminal.com>> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/7c250062/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/7c250062/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 10
> Date: Tue, 6 Nov 2018 14:39:56 -0800
> From: Lance Zhao <> lance.zhao at gmail.com <mailto:lance.zhao at gmail.com>> >
> To: Nico Huber <> nico.h at gmx.de <mailto:nico.h at gmx.de>> >
> Cc: "> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> " <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >,  Praveen
> 	hodagatta pranesh <> praveenx.hodagatta.pranesh at intel.com <mailto:praveenx.hodagatta.pranesh at intel.com>> >,  Boon Tiong
> 	Teo <> boon.tiong.teo at intel.com <mailto:boon.tiong.teo at intel.com>> >, Subrata Banik
> 	<> subrata.banik at intel.com <mailto:subrata.banik at intel.com>> >, Aaron Durbin <> adurbin at google.com <mailto:adurbin at google.com>> >
> Subject: Re: [coreboot] Can we please remove the FSP TempRamInit
> 	option (where applicable)
> Message-ID:
> 	<> CAO1KNFheu-dbkjvXEG80cw3FHEkww-K0pwkmQc3Y-k1eLGzJ2w at mail.gmail.com <mailto:CAO1KNFheu-dbkjvXEG80cw3FHEkww-K0pwkmQc3Y-k1eLGzJ2w at mail.gmail.com>> >
> Content-Type: text/plain; charset="utf-8"
>
> Yes, I believe we should let mainboard to select CAR implementation instead
> of force selection in soc Kconfig. I will suggest to remove that line.
>
> On Tue, Nov 6, 2018 at 10:12 AM Nico Huber <> nico.h at gmx.de <mailto:nico.h at gmx.de>> > wrote:
>
>> Hi coreboot fellows,
>>
>> I have always been confused that we have the option to use FSP's
>> TempRamInit (CAR setup) even when a native coreboot implementation is
>> available. Now, what I'm really concerned about is the low quality of
>> the code in coreboot surrounding it. There are often Kconfig prompts
>> that don't add up, and about every related, merged commit I've been
>> looking at today seemed somehow flawed.
>>
>> So if we can't keep the quality we are used to when trying to maintain
>> two (or even more) CAR options, why not focus on a single one? After
>> all, coreboot is a firmware framework, not an FSP testing framework.
>>
>> Here's just one weird example of what I was confronted with today:
>>
>>         default USE_CANNONLAKE_CAR_NEM_ENHANCED if
>> MAINBOARD_HAS_CHROMEOS
>>
>> I don't understand it, but somehow feel offended. Does that mean I have
>> to work with ChromeOS now to get reasonable defaults?
>>
>> Nico
>>
>> --
>> coreboot mailing list: >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <> http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/675506bb/attachment-0001.html <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/675506bb/attachment-0001.html>> >
>
> ------------------------------
>
> Message: 11
> Date: Wed, 7 Nov 2018 01:43:01 +0300
> From: Mike Banon <> mikebdp2 at gmail.com <mailto:mikebdp2 at gmail.com>> >
> To: > veredz72 at gmail.com <mailto:veredz72 at gmail.com>
> Cc: coreboot <> coreboot at coreboot.org <mailto:coreboot at coreboot.org>> >
> Subject: Re: [coreboot] Use VBIOS from vendor's original bin file
> Message-ID:
> 	<> CAK7947mUG4k_z=g1LyjPLJiOs=CHVNWArmaVThKYmyBbXMhZmw at mail.gmail.com <mailto:CAK7947mUG4k_z=g1LyjPLJiOs=CHVNWArmaVThKYmyBbXMhZmw at mail.gmail.com>> >
> Content-Type: text/plain; charset="UTF-8"
>
> Hello Zvika,
>
>> How can it find [VBIOS] in the vendor's bin file ?
>
> It really depends on the type of vendor's BIOS because they could be
> packed differently. For example, if your vendor's BIOS is Inside then
> you can use Inside H2OEZE utility (sadly its' Windows-only and not
> available officially, but you could find it if really want). But
> please keep in mind that your vendor's BIOS might be patching that
> VBIOS during booting, if that is indeed so - then a "clean" unpatched
> VBIOS extracted with this method, either will not work at all or work
> with errors. So it is always recommended to extract VBIOS from a
> running system, just in case. Usually these instructions are working -
> https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios <https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios>
> , see "Retrieval via Linux kernel" part. But if that's not working at
> your system and you've tried everything else, here is a great
> alternative method -
> https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html <https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html>
>
> Best regards,
> Mike Banon
> On Tue, Nov 6, 2018 at 10:18 PM Zvi Vered <> veredz72 at gmail.com <mailto:veredz72 at gmail.com>> > wrote:
>>
>> Hello,
>>
>> Currently I'm replacing the BIOS in the vendor's bin file with coreboot.bin
>> Can coreboot use Vendor's VBIOS instead of the serial console ?
>> How can it find it in the vendor's bin file ?
>>
>> Thank you,
>> Zvika
>> --
>> coreboot mailing list: >> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
>> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> coreboot mailing list
> coreboot at coreboot.org <mailto:coreboot at coreboot.org>
> https://mail.coreboot.org/mailman/listinfo/coreboot <https://mail.coreboot.org/mailman/listinfo/coreboot>
>
>
> ------------------------------
>
> End of coreboot Digest, Vol 165, Issue 9
> ****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181107/05f3712b/attachment-0001.html>


More information about the coreboot mailing list