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 [email protected]
<mailto:[email protected]>:
> Send coreboot mailing list submissions to
> > [email protected] <mailto:[email protected]>
>
> 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
> > [email protected] <mailto:[email protected]>
>
> You can reach the person managing the list at
> > [email protected] <mailto:[email protected]>
>
> 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
> (> [email protected] <mailto:[email protected]>> )
> 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 <> [email protected] <mailto:[email protected]>> >
> To: > [email protected] <mailto:[email protected]>
> Cc: > [email protected] <mailto:[email protected]>> , > [email protected]
> <mailto:[email protected]>
> Subject: Re: [coreboot] Hardware diagnostic
> Message-ID:
> <> CAATv5Wb7yg3u6OLJjXr5E_iCXSn_2uXeB58_Fo-=kghn0za...@mail.gmail.com
> <mailto:CAATv5Wb7yg3u6OLJjXr5E_iCXSn_2uXeB58_Fo-=kghn0za...@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 <> [email protected]
> <mailto:[email protected]>> >:
>
>> 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: > [email protected] <mailto:[email protected]>
> To: > [email protected] <mailto:[email protected]>
> Subject: [coreboot] New Defects reported by Coverity Scan for coreboot
> Message-ID: <[email protected]>
> 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 <> [email protected]
> <mailto:[email protected]>> >
> To: "> [email protected] <mailto:[email protected]>> " <>
> [email protected] <mailto:[email protected]>> >, Alexey Borovikov
> <> [email protected] <mailto:[email protected]>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> <>
> by2pr15mb0741ba3ccdd2161d735aa069b9...@by2pr15mb0741.namprd15.prod.outlook.com
>
> <mailto:by2pr15mb0741ba3ccdd2161d735aa069b9...@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 <> [email protected]
> <mailto:[email protected]>> > on behalf of Alexey Borovikov via
> coreboot <> [email protected] <mailto:[email protected]>> >
> Sent: Saturday, November 3, 2018 5:38 AM
> To: > [email protected] <mailto:[email protected]>
> 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 <> [email protected] <mailto:[email protected]>> >
> To: > [email protected] <mailto:[email protected]>
> Cc: > [email protected] <mailto:[email protected]>> , >
> [email protected] <mailto:[email protected]>
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> <> cadtu-knuw8vyhsnlrvz-m7nkddbv3vf-krqhf7xt050mwgx...@mail.gmail.com
> <mailto:cadtu-knuw8vyhsnlrvz-m7nkddbv3vf-krqhf7xt050mwgx...@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 <> [email protected]
> <mailto:[email protected]>> >
> 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 <>> [email protected]
>> <mailto:[email protected]>>> > on behalf of Alexey
>> Borovikov via coreboot <>> [email protected]
>> <mailto:[email protected]>>> >
>> *Sent:* Saturday, November 3, 2018 5:38 AM
>> *To:* >> [email protected] <mailto:[email protected]>
>> *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: >> [email protected]
>> <mailto:[email protected]>
>> 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 <> [email protected]
> <mailto:[email protected]>> >
> To: R S <> [email protected] <mailto:[email protected]>> >
> Cc: "> [email protected] <mailto:[email protected]>> " <>
> [email protected] <mailto:[email protected]>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> <>
> by2pr15mb0741162048df7f78fbfa3cb8b9...@by2pr15mb0741.namprd15.prod.outlook.com
>
> <mailto:by2pr15mb0741162048df7f78fbfa3cb8b9...@by2pr15mb0741.namprd15.prod.outlook.com>>
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Guilty as charged :)
>
> ________________________________
> From: R S <> [email protected] <mailto:[email protected]>> >
> Sent: Tuesday, November 6, 2018 9:30 AM
> To: > [email protected] <mailto:[email protected]>
> Cc: > [email protected] <mailto:[email protected]>> ; >
> [email protected] <mailto:[email protected]>
> 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 <> [email protected]
> <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >> 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 <> [email protected]
> <mailto:[email protected]>> <>
> mailto:[email protected]
> <mailto:mailto:[email protected]>> >> on behalf of Alexey
> Borovikov via coreboot <> [email protected]
> <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >>
> Sent: Saturday, November 3, 2018 5:38 AM
> To: > [email protected] <mailto:[email protected]>> <>
> mailto:[email protected] <mailto:mailto:[email protected]>> >
> 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: > [email protected]
> <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >
> 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 <> [email protected] <mailto:[email protected]>> >
> To: "> [email protected] <mailto:[email protected]>> " <>
> [email protected] <mailto:[email protected]>> >, Praveen hodagatta
> pranesh <> [email protected]
> <mailto:[email protected]>> >, Boon Tiong Teo
> <> [email protected] <mailto:[email protected]>> >,
> Subrata Banik <> [email protected] <mailto:[email protected]>> >,
> Aaron Durbin <> [email protected] <mailto:[email protected]>> >
> Subject: [coreboot] Can we please remove the FSP TempRamInit option
> (where applicable)
> Message-ID: <> [email protected]
> <mailto:[email protected]>> >
> 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 <> [email protected] <mailto:[email protected]>> >
> To: > [email protected] <mailto:[email protected]>
> Cc: > [email protected] <mailto:[email protected]>
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> <> cadtu-km5r3p4aba_sgzmowqa4bpyps-47mr23afdijzgtwq...@mail.gmail.com
> <mailto:cadtu-km5r3p4aba_sgzmowqa4bpyps-47mr23afdijzgtwq...@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 <> [email protected]
> <mailto:[email protected]>> >
> wrote:
>
>> Guilty as charged :)
>>
>> ------------------------------
>> *From:* R S <>> [email protected]
>> <mailto:[email protected]>>> >
>> *Sent:* Tuesday, November 6, 2018 9:30 AM
>> *To:* >> [email protected] <mailto:[email protected]>
>> *Cc:* >> [email protected] <mailto:[email protected]>>> ; >>
>> [email protected] <mailto:[email protected]>
>> *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 <>> [email protected]
>> <mailto:[email protected]>>> >
>> 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 <>> [email protected]
>> <mailto:[email protected]>>> > on behalf of Alexey
>> Borovikov via coreboot <>> [email protected]
>> <mailto:[email protected]>>> >
>> *Sent:* Saturday, November 3, 2018 5:38 AM
>> *To:* >> [email protected] <mailto:[email protected]>
>> *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: >> [email protected]
>> <mailto:[email protected]>
>> 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 <> [email protected] <mailto:[email protected]>> >
> To: > [email protected] <mailto:[email protected]>
> Subject: [coreboot] Use VBIOS from vendor's original bin file
> Message-ID:
> <> cabrndgxjqfefkvxmueiyroj9udbt+jfdohlnnm2ypk9pmvr...@mail.gmail.com
> <mailto:cabrndgxjqfefkvxmueiyroj9udbt+jfdohlnnm2ypk9pmvr...@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 <> [email protected]
> <mailto:[email protected]>> >
> To: Alexey Borovikov <> [email protected] <mailto:[email protected]>> >, R S
> <> [email protected] <mailto:[email protected]>> >
> Cc: "> [email protected] <mailto:[email protected]>> " <>
> [email protected] <mailto:[email protected]>> >
> Subject: Re: [coreboot] How to get correct memory params for FSP
> Message-ID:
> <>
> by2pr15mb0741216cbc670e46ea3e581db9...@by2pr15mb0741.namprd15.prod.outlook.com
>
> <mailto:by2pr15mb0741216cbc670e46ea3e581db9...@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 <> [email protected] <mailto:[email protected]>> >
> Sent: Tuesday, November 6, 2018 11:06 AM
> To: R S; > [email protected] <mailto:[email protected]>
> Cc: > [email protected] <mailto:[email protected]>
> 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:[email protected]
> <mailto:mailto:[email protected]>> >
> Sent: Tuesday, November 06, 2018 8:30 PM
> To: > [email protected] <mailto:[email protected]>> <>
> mailto:[email protected] <mailto:mailto:[email protected]>> >
> Cc: > [email protected] <mailto:[email protected]>> <>
> mailto:[email protected] <mailto:mailto:[email protected]>> > ; >
> [email protected] <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >
> 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 <> [email protected]
> <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >> 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 <> [email protected]
> <mailto:[email protected]>> <>
> mailto:[email protected]
> <mailto:mailto:[email protected]>> >> on behalf of Alexey
> Borovikov via coreboot <> [email protected]
> <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >>
> Sent: Saturday, November 3, 2018 5:38 AM
> To: > [email protected] <mailto:[email protected]>> <>
> mailto:[email protected] <mailto:mailto:[email protected]>> >
> 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: > [email protected]
> <mailto:[email protected]>> <> mailto:[email protected]
> <mailto:mailto:[email protected]>> >
> 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 <> [email protected] <mailto:[email protected]>> >
> To: Nico Huber <> [email protected] <mailto:[email protected]>> >
> Cc: "> [email protected] <mailto:[email protected]>> " <>
> [email protected] <mailto:[email protected]>> >, Praveen
> hodagatta pranesh <> [email protected]
> <mailto:[email protected]>> >, Boon Tiong
> Teo <> [email protected] <mailto:[email protected]>> >,
> Subrata Banik
> <> [email protected] <mailto:[email protected]>> >, Aaron
> Durbin <> [email protected] <mailto:[email protected]>> >
> Subject: Re: [coreboot] Can we please remove the FSP TempRamInit
> option (where applicable)
> Message-ID:
> <> cao1knfheu-dbkjvxeg80cw3fhekww-k0pwkmqc3y-k1elgz...@mail.gmail.com
> <mailto:cao1knfheu-dbkjvxeg80cw3fhekww-k0pwkmqc3y-k1elgz...@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 <> [email protected]
> <mailto:[email protected]>> > 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: >> [email protected]
>> <mailto:[email protected]>
>> 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 <> [email protected] <mailto:[email protected]>> >
> To: > [email protected] <mailto:[email protected]>
> Cc: coreboot <> [email protected] <mailto:[email protected]>> >
> Subject: Re: [coreboot] Use VBIOS from vendor's original bin file
> Message-ID:
> <> CAK7947mUG4k_z=g1LyjPLJiOs=chvnwarmavthkymybbxmh...@mail.gmail.com
> <mailto:CAK7947mUG4k_z=g1LyjPLJiOs=chvnwarmavthkymybbxmh...@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 <> [email protected]
> <mailto:[email protected]>> > 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: >> [email protected]
>> <mailto:[email protected]>
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>> <https://mail.coreboot.org/mailman/listinfo/coreboot>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> coreboot mailing list
> [email protected] <mailto:[email protected]>
> https://mail.coreboot.org/mailman/listinfo/coreboot
> <https://mail.coreboot.org/mailman/listinfo/coreboot>
>
>
> ------------------------------
>
> End of coreboot Digest, Vol 165, Issue 9
> ****************************************--
coreboot mailing list: [email protected]
https://mail.coreboot.org/mailman/listinfo/coreboot
