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