Send coreboot mailing list submissions to
coreboot@coreboot.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.coreboot.org/mailman/listinfo/coreboot
or, via email, send a message with subject or body 'help' to
coreboot-request@coreboot.org

You can reach the person managing the list at
coreboot-owner@coreboot.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of coreboot digest..."


Today's Topics:

1. Re: Hardware diagnostic (yanvasilij yan)
2. New Defects reported by Coverity Scan for coreboot
(scan-admin@coverity.com)
3. Re: How to get correct memory params for FSP (Alex Feinman)
4. Re: How to get correct memory params for FSP (R S)
5. Re: How to get correct memory params for FSP (Alex Feinman)
6. Can we please remove the FSP TempRamInit option (where
applicable) (Nico Huber)
7. Re: How to get correct memory params for FSP (R S)
8. Use VBIOS from vendor's original bin file (Zvi Vered)
9. Re: How to get correct memory params for FSP (Alex Feinman)
10. Re: Can we please remove the FSP TempRamInit option (where
applicable) (Lance Zhao)
11. Re: Use VBIOS from vendor's original bin file (Mike Banon)


----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Nov 2018 16:51:49 +0500
From: yanvasilij yan <yanvasilij@gmail.com>
To: nico.h@gmx.de
Cc: peter@stuge.se, coreboot@coreboot.org
Subject: Re: [coreboot] Hardware diagnostic
Message-ID:
<CAATv5Wb7yg3u6OLJjXr5E_iCXSn_2uXeB58_Fo-=KghN0ZAPEQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thank lot too all!

Sory for last response!

You were right, the problem was in power up sequence. After fixing all
become correct. The 0x8086/0x0000 device disappeared, and payload
succesfuly downloaded.

Peter Stuge, thank you for detailed comments!

Nico Huber, thank you for active participation!



??, 28 ???. 2018 ?. ? 4:18, Nico Huber <nico.h@gmx.de>:

On 10/28/18 12:25 AM, Peter Stuge wrote:
> Why are there no RAM regions? I don't know.

Quite simple, because the code that adds them is tied to 8086:0f00.

>> nico_h in the IRC chat noticed that in non-working board appears a
starnge
>> device with vid/did PCI: 00:00.0 [8086/0000].
>
> The 0000 is a HUGE red sign, screaming to be thoroughly investigated.
>
> This also hints that the power up changes may be the problem.

I agree, but note that in the datasheet (or EDS at least), the DID is
not read-only. A strap (that I coudn't find more about) is supposed to
set the initial value plus there is a message mentioned (to be sent to
sth. I didn't look into) that may change it.

So alternatively to diagnosing the hardware changes, you could also
follow the bread crumbs in the documentation.

Nico

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/7b65b1c7/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 06 Nov 2018 14:41:09 +0000 (UTC)
From: scan-admin@coverity.com
To: coreboot@coreboot.org
Subject: [coreboot] New Defects reported by Coverity Scan for coreboot
Message-ID: <5be1a805686ef_84f72b08291e2f60744ba@node1.mail>
Content-Type: text/plain; charset=UTF-8

Hi,

Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.

6 new defect(s) introduced to coreboot found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 6 of 6 defect(s)


** CID 1396579: (STRAY_SEMICOLON)
/src/soc/mediatek/mt8183/auxadc.c: 46 in auxadc_get_rawdata()
/src/soc/mediatek/mt8183/auxadc.c: 49 in auxadc_get_rawdata()
/src/soc/mediatek/mt8183/auxadc.c: 53 in auxadc_get_rawdata()


________________________________________________________________________________________________________
*** CID 1396579: (STRAY_SEMICOLON)
/src/soc/mediatek/mt8183/auxadc.c: 46 in auxadc_get_rawdata()
40 assert(!expired); \
41 })
42
43 static uint32_t auxadc_get_rawdata(int channel)
44 {
45 setbits_le32(&mt8183_infracfg->module_sw_cg_1_clr, 1 << 10);

CID 1396579: (STRAY_SEMICOLON)
A "while" statement with no block followed by a stand-alone block is suspicious.

46 wait_ms(!(read32(&mtk_auxadc->con2) & 0x1), 300);
47
48 clrbits_le32(&mtk_auxadc->con1, 1 << channel);
49 wait_ms(!(read32(&mtk_auxadc->data[channel]) & (1 << 12)), 300);
50
51 setbits_le32(&mtk_auxadc->con1, 1 << channel);
/src/soc/mediatek/mt8183/auxadc.c: 49 in auxadc_get_rawdata()
43 static uint32_t auxadc_get_rawdata(int channel)
44 {
45 setbits_le32(&mt8183_infracfg->module_sw_cg_1_clr, 1 << 10);
46 wait_ms(!(read32(&mtk_auxadc->con2) & 0x1), 300);
47
48 clrbits_le32(&mtk_auxadc->con1, 1 << channel);

CID 1396579: (STRAY_SEMICOLON)
A "while" statement with no block followed by a stand-alone block is suspicious.

49 wait_ms(!(read32(&mtk_auxadc->data[channel]) & (1 << 12)), 300);
50
51 setbits_le32(&mtk_auxadc->con1, 1 << channel);
52 udelay(25);
53 wait_ms(read32(&mtk_auxadc->data[channel]) & (1 << 12), 300);
54
/src/soc/mediatek/mt8183/auxadc.c: 53 in auxadc_get_rawdata()
47
48 clrbits_le32(&mtk_auxadc->con1, 1 << channel);
49 wait_ms(!(read32(&mtk_auxadc->data[channel]) & (1 << 12)), 300);
50
51 setbits_le32(&mtk_auxadc->con1, 1 << channel);
52 udelay(25);

CID 1396579: (STRAY_SEMICOLON)
A "while" statement with no block followed by a stand-alone block is suspicious.

53 wait_ms(read32(&mtk_auxadc->data[channel]) & (1 << 12), 300);
54
55 uint32_t value = read32(&mtk_auxadc->data[channel]) & 0x0FFF;
56
57 setbits_le32(&mt8183_infracfg->module_sw_cg_1_set, 1 << 10);
58

** CID 1396578: (UNINIT)
/src/arch/riscv/trap_handler.c: 98 in interrupt_handler()
/src/arch/riscv/trap_handler.c: 100 in interrupt_handler()
/src/arch/riscv/trap_handler.c: 102 in interrupt_handler()
/src/arch/riscv/trap_handler.c: 104 in interrupt_handler()
/src/arch/riscv/trap_handler.c: 106 in interrupt_handler()
/src/arch/riscv/trap_handler.c: 107 in interrupt_handler()


________________________________________________________________________________________________________
*** CID 1396578: (UNINIT)
/src/arch/riscv/trap_handler.c: 98 in interrupt_handler()
92
93 clear_csr(mie, MIP_MTIP);
94 set_csr(mip, MIP_STIP);
95
96 break;
97 case IRQ_M_SOFT:

CID 1396578: (UNINIT)
Using uninitialized value "sp".

98 if (HLS()->ipi_pending & IPI_SOFT) {
99 set_csr(mip, MIP_SSIP);
100 } else if (HLS()->ipi_pending & IPI_FENCE_I) {
101 asm volatile("fence.i");
102 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
103 asm volatile("sfence.vma");
/src/arch/riscv/trap_handler.c: 100 in interrupt_handler()
94 set_csr(mip, MIP_STIP);
95
96 break;
97 case IRQ_M_SOFT:
98 if (HLS()->ipi_pending & IPI_SOFT) {
99 set_csr(mip, MIP_SSIP);

CID 1396578: (UNINIT)
Using uninitialized value "sp".

100 } else if (HLS()->ipi_pending & IPI_FENCE_I) {
101 asm volatile("fence.i");
102 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
103 asm volatile("sfence.vma");
104 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
105 asm volatile("sfence.vma");
/src/arch/riscv/trap_handler.c: 102 in interrupt_handler()
96 break;
97 case IRQ_M_SOFT:
98 if (HLS()->ipi_pending & IPI_SOFT) {
99 set_csr(mip, MIP_SSIP);
100 } else if (HLS()->ipi_pending & IPI_FENCE_I) {
101 asm volatile("fence.i");

CID 1396578: (UNINIT)
Using uninitialized value "sp".

102 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
103 asm volatile("sfence.vma");
104 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
105 asm volatile("sfence.vma");
106 } else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
107 while (HLS()->ipi_pending & IPI_SHUTDOWN)
/src/arch/riscv/trap_handler.c: 104 in interrupt_handler()
98 if (HLS()->ipi_pending & IPI_SOFT) {
99 set_csr(mip, MIP_SSIP);
100 } else if (HLS()->ipi_pending & IPI_FENCE_I) {
101 asm volatile("fence.i");
102 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
103 asm volatile("sfence.vma");

CID 1396578: (UNINIT)
Using uninitialized value "sp".

104 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
105 asm volatile("sfence.vma");
106 } else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
107 while (HLS()->ipi_pending & IPI_SHUTDOWN)
108 asm volatile("wfi");
109 }
/src/arch/riscv/trap_handler.c: 106 in interrupt_handler()
100 } else if (HLS()->ipi_pending & IPI_FENCE_I) {
101 asm volatile("fence.i");
102 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
103 asm volatile("sfence.vma");
104 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
105 asm volatile("sfence.vma");

CID 1396578: (UNINIT)
Using uninitialized value "sp".

106 } else if (HLS()->ipi_pending & IPI_SHUTDOWN) {
107 while (HLS()->ipi_pending & IPI_SHUTDOWN)
108 asm volatile("wfi");
109 }
110 break;
111 default:
/src/arch/riscv/trap_handler.c: 107 in interrupt_handler()
101 asm volatile("fence.i");
102 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA) {
103 asm volatile("sfence.vma");
104 } else if (HLS()->ipi_pending & IPI_SFENCE_VMA_ASID) {
105 asm volatile("sfence.vma");
106 } else if (HLS()->ipi_pending & IPI_SHUTDOWN) {

CID 1396578: (UNINIT)
Using uninitialized value "sp".

107 while (HLS()->ipi_pending & IPI_SHUTDOWN)
108 asm volatile("wfi");
109 }
110 break;
111 default:
112 printk(BIOS_EMERG, "======================================\n");

** CID 1396577: (UNINIT)
/src/arch/riscv/smp.c: 35 in smp_pause()
/src/arch/riscv/smp.c: 41 in smp_pause()
/src/arch/riscv/smp.c: 48 in smp_pause()
/src/arch/riscv/smp.c: 52 in smp_pause()
/src/arch/riscv/smp.c: 53 in smp_pause()
/src/arch/riscv/smp.c: 58 in smp_pause()
/src/arch/riscv/smp.c: 61 in smp_pause()
/src/arch/riscv/smp.c: 62 in smp_pause()


________________________________________________________________________________________________________
*** CID 1396577: (UNINIT)
/src/arch/riscv/smp.c: 35 in smp_pause()
29 int hartid = read_csr(mhartid);
30
31 if (hartid != working_hartid) {
32 /* waiting for work hart */
33 do {
34 barrier();

CID 1396577: (UNINIT)
Using uninitialized value "sp".

35 } while (SYNCA != 0x01234567);
36
37 clear_csr(mstatus, MSTATUS_MIE);
38 write_csr(mie, MIP_MSIP);
39
40 /* count how many cores enter the halt */
/src/arch/riscv/smp.c: 41 in smp_pause()
35 } while (SYNCA != 0x01234567);
36
37 clear_csr(mstatus, MSTATUS_MIE);
38 write_csr(mie, MIP_MSIP);
39
40 /* count how many cores enter the halt */

CID 1396577: (UNINIT)
Using uninitialized value "sp".

41 __sync_fetch_and_add(&SYNCB, 1);
42
43 do {
44 barrier();
45 __asm__ volatile ("wfi");
46 } while ((read_csr(mip) & MIP_MSIP) == 0);
/src/arch/riscv/smp.c: 48 in smp_pause()
42
43 do {
44 barrier();
45 __asm__ volatile ("wfi");
46 } while ((read_csr(mip) & MIP_MSIP) == 0);
47 set_msip(hartid, 0);

CID 1396577: (UNINIT)
Using uninitialized value "sp".

48 HLS()->entry.fn(HLS()->entry.arg);
49 } else {
50 /* Initialize the counter and
51 * mark the work hart into smp_pause */
52 SYNCB = 0;
53 SYNCA = 0x01234567;
/src/arch/riscv/smp.c: 52 in smp_pause()
46 } while ((read_csr(mip) & MIP_MSIP) == 0);
47 set_msip(hartid, 0);
48 HLS()->entry.fn(HLS()->entry.arg);
49 } else {
50 /* Initialize the counter and
51 * mark the work hart into smp_pause */

CID 1396577: (UNINIT)
Using uninitialized value "sp".

52 SYNCB = 0;
53 SYNCA = 0x01234567;
54
55 /* waiting for other Hart to enter the halt */
56 do {
57 barrier();
/src/arch/riscv/smp.c: 53 in smp_pause()
47 set_msip(hartid, 0);
48 HLS()->entry.fn(HLS()->entry.arg);
49 } else {
50 /* Initialize the counter and
51 * mark the work hart into smp_pause */
52 SYNCB = 0;

CID 1396577: (UNINIT)
Using uninitialized value "sp".

53 SYNCA = 0x01234567;
54
55 /* waiting for other Hart to enter the halt */
56 do {
57 barrier();
58 } while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
/src/arch/riscv/smp.c: 58 in smp_pause()
52 SYNCB = 0;
53 SYNCA = 0x01234567;
54
55 /* waiting for other Hart to enter the halt */
56 do {
57 barrier();

CID 1396577: (UNINIT)
Using uninitialized value "sp".

58 } while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
59
60 /* initialize for the next call */
61 SYNCA = 0;
62 SYNCB = 0;
63 }
/src/arch/riscv/smp.c: 61 in smp_pause()
55 /* waiting for other Hart to enter the halt */
56 do {
57 barrier();
58 } while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
59
60 /* initialize for the next call */

CID 1396577: (UNINIT)
Using uninitialized value "sp".

61 SYNCA = 0;
62 SYNCB = 0;
63 }
64 #undef SYNCA
65 #undef SYNCB
66 }
/src/arch/riscv/smp.c: 62 in smp_pause()
56 do {
57 barrier();
58 } while (SYNCB + 1 < CONFIG_RISCV_HART_NUM);
59
60 /* initialize for the next call */
61 SYNCA = 0;

CID 1396577: (UNINIT)
Using uninitialized value "sp".

62 SYNCB = 0;
63 }
64 #undef SYNCA
65 #undef SYNCB
66 }
67

** CID 1396576: (UNINIT)
/src/arch/riscv/smp.c: 76 in smp_resume()
/src/arch/riscv/smp.c: 77 in smp_resume()
/src/arch/riscv/smp.c: 84 in smp_resume()


________________________________________________________________________________________________________
*** CID 1396576: (UNINIT)
/src/arch/riscv/smp.c: 76 in smp_resume()
70 int hartid = read_csr(mhartid);
71
72 if (fn == NULL)
73 die("must pass a non-null function pointer\n");
74
75 for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++) {

CID 1396576: (UNINIT)
Using uninitialized value "sp".

76 OTHER_HLS(i)->entry.fn = fn;
77 OTHER_HLS(i)->entry.arg = arg;
78 }
79
80 for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++)
81 if (i != hartid)
82 set_msip(i, 1);
83
84 HLS()->entry.fn(HLS()->entry.arg);
/src/arch/riscv/smp.c: 77 in smp_resume()
71
72 if (fn == NULL)
73 die("must pass a non-null function pointer\n");
74
75 for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++) {
76 OTHER_HLS(i)->entry.fn = fn;

CID 1396576: (UNINIT)
Using uninitialized value "sp".

77 OTHER_HLS(i)->entry.arg = arg;
78 }
79
80 for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++)
81 if (i != hartid)
82 set_msip(i, 1);
83
84 HLS()->entry.fn(HLS()->entry.arg);
/src/arch/riscv/smp.c: 84 in smp_resume()
78 }
79
80 for (int i = 0; i < CONFIG_RISCV_HART_NUM; i++)
81 if (i != hartid)
82 set_msip(i, 1);
83

CID 1396576: (UNINIT)
Using uninitialized value "sp".

84 HLS()->entry.fn(HLS()->entry.arg);

** CID 1396575: Uninitialized variables (UNINIT)
/src/arch/riscv/sbi.c: 44 in sbi_set_timer()


________________________________________________________________________________________________________
*** CID 1396575: Uninitialized variables (UNINIT)
/src/arch/riscv/sbi.c: 44 in sbi_set_timer()
38 }
39
40 static uintptr_t sbi_set_timer(uint64_t when)
41 {
42 clear_csr(mip, MIP_STIP);
43 set_csr(mie, MIP_MTIP);

CID 1396575: Uninitialized variables (UNINIT)
Using uninitialized value "sp".

44 *(HLS()->timecmp) = when;
45 return 0;
46 }
47
48 #if IS_ENABLED(CONFIG_CONSOLE_SERIAL)
49 static uintptr_t sbi_console_putchar(uint8_t ch)

** CID 1396574: Uninitialized variables (UNINIT)
/src/arch/riscv/sbi.c: 31 in send_ipi()


________________________________________________________________________________________________________
*** CID 1396574: Uninitialized variables (UNINIT)
/src/arch/riscv/sbi.c: 31 in send_ipi()
25
26 static uintptr_t send_ipi(uintptr_t *pmask, intptr_t type)
27 {
28 uintptr_t mask = mprv_read_uintptr_t(pmask);
29 for (int i = 0; mask; i++) {
30 if (mask & 1) {

CID 1396574: Uninitialized variables (UNINIT)
Using uninitialized value "sp".

31 OTHER_HLS(i)->ipi_pending |= type;
32 /* send soft interrupt to target hart */
33 set_msip(i, 1);
34 }
35 mask = mask >> 1;
36 }


________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbLuoVetFLSjdonCi1EjfHRqWGQvojmmkYaBE-2BPJiTQvQ-3D-3D_q4bX76XMySz3BXBlWr5fXXJ4cvAsgEXEqC7dBPM7O5a31m51VEsEaxFt1YGbyr6wNWh1JRkzG6iEWnu4wa11R6V6bq3pvRdnRMNLGWgttGAab8saZW-2BgimLNQFi615pGDzotKysOu2G2J4DGnZTtorDLvESCDRCTODv3O77-2B7n1VYt5e-2BYXktmH9OM-2FL42YRQ224IXfqqi-2BMUaEbYo2-2F2Afr5Jd9JHIIEpLZPsm1PcE-3D




------------------------------

Message: 3
Date: Tue, 6 Nov 2018 17:21:09 +0000
From: Alex Feinman <alexfeinman@hotmail.com>
To: "coreboot@coreboot.org" <coreboot@coreboot.org>, Alexey Borovikov
<alexey_bau@mail.ru>
Subject: Re: [coreboot] How to get correct memory params for FSP
Message-ID:
<BY2PR15MB0741BA3CCDD2161D735AA069B9CB0@BY2PR15MB0741.namprd15.prod.outlook.com>

Content-Type: text/plain; charset="iso-8859-1"

The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout
Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place)
Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output

________________________________
From: coreboot <coreboot-bounces@coreboot.org> on behalf of Alexey Borovikov via coreboot <coreboot@coreboot.org>
Sent: Saturday, November 3, 2018 5:38 AM
To: 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/481897dd/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 6 Nov 2018 12:30:45 -0500
From: R S <rene.shuster@bcsemail.org>
To: alexfeinman@hotmail.com
Cc: coreboot@coreboot.org, alexey_bau@mail.ru
Subject: Re: [coreboot] How to get correct memory params for FSP
Message-ID:
<CADTU-KnUw8vyHsnLrVZ-M7nKDDBv3VF-KRQhf7Xt050mWgxMRQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Faint memories... are you the ISO recorder author from 15 years ago?

On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman@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@coreboot.org> on behalf of Alexey
Borovikov via coreboot <coreboot@coreboot.org>
*Sent:* Saturday, November 3, 2018 5:38 AM
*To:* 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@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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/b104872d/attachment-0001.html>

------------------------------

Message: 5
Date: Tue, 6 Nov 2018 17:45:39 +0000
From: Alex Feinman <alexfeinman@hotmail.com>
To: R S <rene.shuster@bcsemail.org>
Cc: "coreboot@coreboot.org" <coreboot@coreboot.org>
Subject: Re: [coreboot] How to get correct memory params for FSP
Message-ID:
<BY2PR15MB0741162048DF7F78FBFA3CB8B9CB0@BY2PR15MB0741.namprd15.prod.outlook.com>

Content-Type: text/plain; charset="iso-8859-1"

Guilty as charged :)

________________________________
From: R S <rene.shuster@bcsemail.org>
Sent: Tuesday, November 6, 2018 9:30 AM
To: alexfeinman@hotmail.com
Cc: coreboot@coreboot.org; alexey_bau@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@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@coreboot.org<mailto:coreboot-bounces@coreboot.org>> on behalf of Alexey Borovikov via coreboot <coreboot@coreboot.org<mailto:coreboot@coreboot.org>>
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot@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@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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/f23a1745/attachment-0001.html>

------------------------------

Message: 6
Date: Tue, 6 Nov 2018 19:11:22 +0100
From: Nico Huber <nico.h@gmx.de>
To: "coreboot@coreboot.org" <coreboot@coreboot.org>, Praveen hodagatta
pranesh <praveenx.hodagatta.pranesh@intel.com>, Boon Tiong Teo
<boon.tiong.teo@intel.com>, Subrata Banik <subrata.banik@intel.com>,
Aaron Durbin <adurbin@google.com>
Subject: [coreboot] Can we please remove the FSP TempRamInit option
(where applicable)
Message-ID: <2168f785-b8f3-01f8-700b-f402e4e5cd44@gmx.de>
Content-Type: text/plain; charset=utf-8

Hi coreboot fellows,

I have always been confused that we have the option to use FSP's
TempRamInit (CAR setup) even when a native coreboot implementation is
available. Now, what I'm really concerned about is the low quality of
the code in coreboot surrounding it. There are often Kconfig prompts
that don't add up, and about every related, merged commit I've been
looking at today seemed somehow flawed.

So if we can't keep the quality we are used to when trying to maintain
two (or even more) CAR options, why not focus on a single one? After
all, coreboot is a firmware framework, not an FSP testing framework.

Here's just one weird example of what I was confronted with today:

default USE_CANNONLAKE_CAR_NEM_ENHANCED if
MAINBOARD_HAS_CHROMEOS

I don't understand it, but somehow feel offended. Does that mean I have
to work with ChromeOS now to get reasonable defaults?

Nico



------------------------------

Message: 7
Date: Tue, 6 Nov 2018 13:24:56 -0500
From: R S <rene.shuster@bcsemail.org>
To: alexfeinman@hotmail.com
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] How to get correct memory params for FSP
Message-ID:
<CADTU-Km5R3P4ABA_SGZMOwqA4BPypS-47mr23aFDiJZGTwQqhA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks for it after all those years.
// end being off-topic

On Tue, Nov 6, 2018 at 12:45 PM Alex Feinman <alexfeinman@hotmail.com>
wrote:

Guilty as charged :)

------------------------------
*From:* R S <rene.shuster@bcsemail.org>
*Sent:* Tuesday, November 6, 2018 9:30 AM
*To:* alexfeinman@hotmail.com
*Cc:* coreboot@coreboot.org; alexey_bau@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@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@coreboot.org> on behalf of Alexey
Borovikov via coreboot <coreboot@coreboot.org>
*Sent:* Saturday, November 3, 2018 5:38 AM
*To:* 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@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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/243ef171/attachment-0001.html>

------------------------------

Message: 8
Date: Tue, 6 Nov 2018 21:15:30 +0200
From: Zvi Vered <veredz72@gmail.com>
To: coreboot@coreboot.org
Subject: [coreboot] Use VBIOS from vendor's original bin file
Message-ID:
<CABRndgxjqFeFkvxmUEiyROJ9UDbt+jFdOHLNNm2Ypk9PmvRYmg@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>

------------------------------

Message: 9
Date: Tue, 6 Nov 2018 22:20:53 +0000
From: Alex Feinman <alexfeinman@hotmail.com>
To: Alexey Borovikov <alexey_bau@mail.ru>, R S
<rene.shuster@bcsemail.org>
Cc: "coreboot@coreboot.org" <coreboot@coreboot.org>
Subject: Re: [coreboot] How to get correct memory params for FSP
Message-ID:
<BY2PR15MB0741216CBC670E46EA3E581DB9CB0@BY2PR15MB0741.namprd15.prod.outlook.com>

Content-Type: text/plain; charset="koi8-r"

This tells us nothing about swizzling - the order in which DQ/DQS lines of the memory address bus are connected to the CPU. Memory connections to the CPU are flexible to simplify PCB routing. As a result in order for the memory controller to be able to use memory you need to provide board-specific mapping. You cannot glean this from looking at the PCB - you need the schematic. And no, off the shelf Tianocore will not automatically do this either - it's a customizable part of the build

________________________________
From: Alexey Borovikov <alexey_bau@mail.ru>
Sent: Tuesday, November 6, 2018 11:06 AM
To: R S; alexfeinman@hotmail.com
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] How to get correct memory params for FSP

Ok, there is no spd on the board. Four memory chips are soldered on the board (Micron DDR3L 4?512MB 1333Mhz). I understand that I need to set the correct memory parameters in the fsp configurator. Even if it works, replacing the memory chips may lead to a stop working of the coreboot.rom. It is necessary to change the parameters of the fsp again and rebuild coreboot.rom.
How does the proprietary BIOS (TianoCore) work in case of replacing the memory chips on board?
Are there universal parameters for this memory types and what should I take note for when configuring FSP?

From: R S<mailto:rene.shuster@bcsemail.org>
Sent: Tuesday, November 06, 2018 8:30 PM
To: alexfeinman@hotmail.com<mailto:alexfeinman@hotmail.com>
Cc: coreboot@coreboot.org<mailto:coreboot@coreboot.org> ; alexey_bau@mail.ru<mailto:alexey_bau@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@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@coreboot.org<mailto:coreboot-bounces@coreboot.org>> on behalf of Alexey Borovikov via coreboot <coreboot@coreboot.org<mailto:coreboot@coreboot.org>>
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot@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@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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181106/7c250062/attachment-0001.html>

------------------------------

Message: 10
Date: Tue, 6 Nov 2018 14:39:56 -0800
From: Lance Zhao <lance.zhao@gmail.com>
To: Nico Huber <nico.h@gmx.de>
Cc: "coreboot@coreboot.org" <coreboot@coreboot.org>, Praveen
hodagatta pranesh <praveenx.hodagatta.pranesh@intel.com>, Boon Tiong
Teo <boon.tiong.teo@intel.com>, Subrata Banik
<subrata.banik@intel.com>, Aaron Durbin <adurbin@google.com>
Subject: Re: [coreboot] Can we please remove the FSP TempRamInit
option (where applicable)
Message-ID:
<CAO1KNFheu-dbkjvXEG80cw3FHEkww-K0pwkmQc3Y-k1eLGzJ2w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Yes, I believe we should let mainboard to select CAR implementation instead
of force selection in soc Kconfig. I will suggest to remove that line.

On Tue, Nov 6, 2018 at 10:12 AM Nico Huber <nico.h@gmx.de> wrote:

Hi coreboot fellows,

I have always been confused that we have the option to use FSP's
TempRamInit (CAR setup) even when a native coreboot implementation is
available. Now, what I'm really concerned about is the low quality of
the code in coreboot surrounding it. There are often Kconfig prompts
that don't add up, and about every related, merged commit I've been
looking at today seemed somehow flawed.

So if we can't keep the quality we are used to when trying to maintain
two (or even more) CAR options, why not focus on a single one? After
all, coreboot is a firmware framework, not an FSP testing framework.

Here's just one weird example of what I was confronted with today:

default USE_CANNONLAKE_CAR_NEM_ENHANCED if
MAINBOARD_HAS_CHROMEOS

I don't understand it, but somehow feel offended. Does that mean I have
to work with ChromeOS now to get reasonable defaults?

Nico

--
coreboot mailing list: coreboot@coreboot.org
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>

------------------------------

Message: 11
Date: Wed, 7 Nov 2018 01:43:01 +0300
From: Mike Banon <mikebdp2@gmail.com>
To: veredz72@gmail.com
Cc: coreboot <coreboot@coreboot.org>
Subject: Re: [coreboot] Use VBIOS from vendor's original bin file
Message-ID:
<CAK7947mUG4k_z=g1LyjPLJiOs=CHVNWArmaVThKYmyBbXMhZmw@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
, 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@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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

------------------------------

Subject: Digest Footer

_______________________________________________
coreboot mailing list
coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot


------------------------------

End of coreboot Digest, Vol 165, Issue 9
****************************************