coreboot November 2018

coreboot@coreboot.org

71 participants
149 discussions

Re: [coreboot] Use VBIOS from vendor's original bin file
by Mike Banon 06 Nov '18

06 Nov '18

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 , 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 Best regards, Mike Banon On Tue, Nov 6, 2018 at 10:18 PM Zvi Vered <veredz72(a)gmail.com> wrote: > > Hello, > > Currently I'm replacing the BIOS in the vendor's bin file with coreboot.bin > Can coreboot use Vendor's VBIOS instead of the serial console ? > How can it find it in the vendor's bin file ? > > Thank you, > Zvika > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Can we please remove the FSP TempRamInit option (where applicable)
by Nico Huber 06 Nov '18

06 Nov '18

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

2 1

Re: [coreboot] How to get correct memory params for FSP
by Alexey Borovikov 06 Nov '18

06 Nov '18

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 Sent: Tuesday, November 06, 2018 8:30 PM To: alexfeinman(a)hotmail.com Cc: coreboot(a)coreboot.org ; alexey_bau(a)mail.ru Subject: Re: [coreboot] How to get correct memory params for FSP Faint memories... are you the ISO recorder author from 15 years ago? On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com> wrote: The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place) Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output ------------------------------------------------------------------------------ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Alexey Borovikov via coreboot <coreboot(a)coreboot.org> Sent: Saturday, November 3, 2018 5:38 AM To: coreboot(a)coreboot.org Subject: [coreboot] How to get correct memory params for FSP Hi. I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters. Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems? Many thanks! -- coreboot mailing list: coreboot(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group ComicSans Awareness Campaign

2 1

Use VBIOS from vendor's original bin file
by Zvi Vered 06 Nov '18

06 Nov '18

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

1 0

Re: [coreboot] How to get correct memory params for FSP
by R S 06 Nov '18

06 Nov '18

Thanks for it after all those years. // end being off-topic On Tue, Nov 6, 2018 at 12:45 PM Alex Feinman <alexfeinman(a)hotmail.com> wrote: > Guilty as charged :) > > ------------------------------ > *From:* R S <rene.shuster(a)bcsemail.org> > *Sent:* Tuesday, November 6, 2018 9:30 AM > *To:* alexfeinman(a)hotmail.com > *Cc:* coreboot(a)coreboot.org; alexey_bau(a)mail.ru > *Subject:* Re: [coreboot] How to get correct memory params for FSP > > Faint memories... are you the ISO recorder author from 15 years ago? > > On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com> > wrote: > > The two major issues with bringing up the memory subsystem on a new board > are SPD parameters and DQ/DQS layout > Specifically, if you look at the apollolake rvp subtree, you can see a > whole bunch of parameters being set in romstage.c. Some of it is fairly > straightforward. Swizzling tables are not and require you to be able to > read schematic (and have access to it in the first place) > Obviously, the problem could be elsewhere. I would start with enabling MRC > debug and perhaps posting the MRC output > > ------------------------------ > *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of Alexey > Borovikov via coreboot <coreboot(a)coreboot.org> > *Sent:* Saturday, November 3, 2018 5:38 AM > *To:* coreboot(a)coreboot.org > *Subject:* [coreboot] How to get correct memory params for FSP > > Hi. > I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP > for the Baytrail family. The result - postcode is 0x2A. From the > descriptions on the Internet, I understand that the problem is in the > incorrect memory parameters. > Question: are there any utilities or methods that will help to get the > correct memory parameters when working a regular BIOS from Linux or Windows > systems? > Many thanks! > -- > coreboot mailing list: coreboot(a)coreboot.org > 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> > -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group ComicSans Awareness Campaign <http://comicsanscriminal.com>

1 0

Re: [coreboot] How to get correct memory params for FSP
by Alex Feinman 06 Nov '18

06 Nov '18

Guilty as charged :) ________________________________ From: R S <rene.shuster(a)bcsemail.org> Sent: Tuesday, November 6, 2018 9:30 AM To: alexfeinman(a)hotmail.com Cc: coreboot(a)coreboot.org; alexey_bau(a)mail.ru Subject: Re: [coreboot] How to get correct memory params for FSP Faint memories... are you the ISO recorder author from 15 years ago? On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com<mailto:alexfeinman@hotmail.com>> wrote: The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place) Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org<mailto:coreboot-bounces@coreboot.org>> on behalf of Alexey Borovikov via coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>> Sent: Saturday, November 3, 2018 5:38 AM To: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Subject: [coreboot] How to get correct memory params for FSP Hi. I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters. Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems? Many thanks! -- coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> 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>

1 0

Re: [coreboot] How to get correct memory params for FSP
by R S 06 Nov '18

06 Nov '18

Faint memories... are you the ISO recorder author from 15 years ago? On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com> wrote: > The two major issues with bringing up the memory subsystem on a new board > are SPD parameters and DQ/DQS layout > Specifically, if you look at the apollolake rvp subtree, you can see a > whole bunch of parameters being set in romstage.c. Some of it is fairly > straightforward. Swizzling tables are not and require you to be able to > read schematic (and have access to it in the first place) > Obviously, the problem could be elsewhere. I would start with enabling MRC > debug and perhaps posting the MRC output > > ------------------------------ > *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of Alexey > Borovikov via coreboot <coreboot(a)coreboot.org> > *Sent:* Saturday, November 3, 2018 5:38 AM > *To:* coreboot(a)coreboot.org > *Subject:* [coreboot] How to get correct memory params for FSP > > Hi. > I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP > for the Baytrail family. The result - postcode is 0x2A. From the > descriptions on the Internet, I understand that the problem is in the > incorrect memory parameters. > Question: are there any utilities or methods that will help to get the > correct memory parameters when working a regular BIOS from Linux or Windows > systems? > Many thanks! > -- > coreboot mailing list: coreboot(a)coreboot.org > 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>

1 0

How to get correct memory params for FSP
by Alexey Borovikov 06 Nov '18

06 Nov '18

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!

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 06 Nov '18

06 Nov '18

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-2BfV0V0…

1 0

Re: [coreboot] Hardware diagnostic
by Peter Stuge 06 Nov '18

06 Nov '18

yanvasilij yan wrote: > I have two Intel Atom E3800 based boards. The first one is older version, > which woks properly, .. > The second one is modernized version, we added 89HPES5T5 PCIe I/O > expansion switch. And WGI210IT based Ethernet ports are connected > to switch. So the good news is that your log clearly shows the PCIe switch working correctly and both NICs behind reachable by software. > Further we rebuild a bit a power up circuit of the E3800 SOC. This is quite possibly the root cause, but I wouldn't exclude any other possibilities. > Launching stops when starts payload loading. The launch log of this board > see in attached “not_working_board_log.txt”. The log is very clear about why: (down near the end) --8<-- SELF segment doesn't target RAM: 0x00800000, 4259840 bytes -->8-- Looking at the coreboot table a little further up, we see: --8<-- Writing coreboot table at 0x3add3000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000e00000-0000000000e39fff: RAMSTAGE 2. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES 3. 00000000feb00000-00000000fec00fff: RESERVED 4. 00000000fed01000-00000000fed01fff: RESERVED 5. 00000000fed03000-00000000fed03fff: RESERVED 6. 00000000fed05000-00000000fed05fff: RESERVED 7. 00000000fed08000-00000000fed08fff: RESERVED 8. 00000000fed0c000-00000000fed0ffff: RESERVED 9. 00000000fed1c000-00000000fed1cfff: RESERVED 10. 00000000fef00000-00000000feffffff: RESERVED -->8-- Compare that with your working board: --8<-- Writing coreboot table at 0x3add3000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000dfffff: RAM 4. 0000000000e00000-0000000000e39fff: RAMSTAGE 5. 0000000000e3a000-000000003ad9dfff: RAM 6. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES 7. 000000003ae00000-000000003fffffff: RESERVED 8. 00000000e0000000-00000000efffffff: RESERVED 9. 00000000feb00000-00000000fec00fff: RESERVED 10. 00000000fed01000-00000000fed01fff: RESERVED 11. 00000000fed03000-00000000fed03fff: RESERVED 12. 00000000fed05000-00000000fed05fff: RESERVED 13. 00000000fed08000-00000000fed08fff: RESERVED 14. 00000000fed0c000-00000000fed0ffff: RESERVED 15. 00000000fed1c000-00000000fed1cfff: RESERVED 16. 00000000fee00000-00000000fee00fff: RESERVED 17. 00000000fef00000-00000000feffffff: RESERVED -->8-- The new board ends up with no RAM regions in the coreboot table. That results in the payload loader not finding RAM where the payload is to be loaded, so boot stops. Why are there no RAM regions? I don't know. Looking near the beginning of the log about FSP memory init: --8<-- Memory Down Data Existed : Enabled - Speed (0: 800, 1: 1066, 2: 1333, 3: 1600): 1 - Type (0: DDR3, 1: DDR3L) : 1 - DIMM0 : Enabled - DIMM1 : Disabled - Width : x16 - Density : 2Gbit - BudWidth : 64bit - Rank # : 1 - tCL : 0B - tRPtRCD : 0B - tWR : 0C - tWTR : 06 - tRRD : 06 - tRTP : 06 - tFAW : 14 Using 1066 MHz DDR3 settings. 1 GB Minnowboard Max detected. romstage_main_continue status: 0 hob_list_ptr: 3ae20000 FSP Status: 0x0 PM1_STS = 0x1 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808 romstage_main_continue: prev_sleep_state = S0 Baytrail Chip Variant: Bay Trail-I (ISG/embedded) MRC v0.102 1 channels of DDR3 @ 1066MHz -->8-- It appears OK - but do check that those numbers actually match the DRAM chips assembled on the board. Are DRAM parts identical between old and new? Were there *any* hardware changes between SoC and RAM? That's worth checking, but.. > 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. It's VERY unlikely that Intel has suddenly released a variant of this particular SoC with PCI DID=0000 when it used to be DID=0f00. In fact it's really unlikely that 0000 would be used in correct operation at all. Very likely on the other hand is that the SoC isn't being powered on correctly, and so it ends up in some half-initialized state, with the memory controller not working, and while some part of coreboot seems to notice (because no RAM regions in coreboot table) clearly that isn't causing a fatal error, which I think is a bug. Oh well. If you go through every single powerup hardware change together with a hardware engineer, starting with the previous circuit and manually applying one change at a time, maybe you can find one or even more changes causing that device ID symptom. It depends on how many changes you have there, but with a good hardware engineer you could perhaps go through them all in a couple days, which would be really fast results for a problem like this. Maybe even simpler, hack this into some early part of the code, maybe even console_init() works, if pci_early is available there. while (1) if (0x0f00 == pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID)) printk(BIOS_INFO, "PASS\n"); else printk(BIOS_INFO, "FAIL: want 0f00 is %04x\n", pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID)); Then hardware engineering can do analysis on their own. But make sure to confirm that your test is reliable, using the hardware you have (old and new) before you give a flash image to them. Oh, and test on multiple new boards, a single unit in a new batch isn't representative. New PCB; potentially the process has to be tuned. I don't know how early in bringup you are. Good luck and have fun! :) //Peter

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2018