Re: [coreboot] How to understand register address on x86?

[Zoran Stojsavljevic]

Hello  김유석,

Here is the alghoritm how you'll calculate the address: SLOTCAP
address (B0:D1-4:F0:Offset 0x54[31:19]).

There are 16 bits for PCIe space:
[1] 8 most significant bits for buses (256 maximum);
[2] 5 bits for device ids (32 maximum) per bus;
[3] 3 bits for functions (8 maximum) per device!

Gives maximum number od 2^16 (65536) different functions, each
function has 2^12 (4096 Bytes) configuration space. In total, 256MB
space near TOM for PCIe configuration space.

Now, you can calculate your physical address as such: BASE address +
bus0 + devices 1 to 4 + Function 0 => Physical BASE PCIe address
holding config space (4 most significant bits) + 0x00080054.

I strongly advise you to execute the following command: lspci --help
and review the options (this is very helpful command).

Interesting options for you are:
-xxx Show hex-dump of the whole config space (dangerous; root only)
- Show hex-dump of the 4096-byte extended config space (root only)

You can also do: lspci -xxx and see what are the BAR addresses for
00:01.0, 00:02.0, 00:03.0 and 00:04.0 (where the data memory is
physically mapped for the device, per function).

You can also use the following options:

-xxx Show hex-dump of the whole config space (dangerous; root only)
- Show hex-dump of the 4096-byte extended config space (root only)

Interesting pointer to read (for clarification):
https://forums.xilinx.com/t5/PCI-Express/PCI-express-Base-Address-Register/td-p/685289

Good Luck,
Zoran
___

On 1/13/17, Alexander Böcken  wrote:
> Hello,
>
> this is a PCI related notation. It means Bus 0, Device 1-4, Function 0 of
> your board’s PCI bus. Then register offset 0x54, bits 31 to 19.
>
> Regards,
> Alex
>
> Von: coreboot [mailto:coreboot-boun...@coreboot.org] Im Auftrag von ???
> Gesendet: Freitag, 13. Januar 2017 07:35
> An: coreboot
> Betreff: [coreboot] How to understand register address on x86?
>
>
> Dear Sir.
>
>
>
> This time, I try to read the "V2_Avoton_BWG_Rev1_6_review.pdf" Page 169. Is
> see below.
>
> [cid:image001.jpg@01D26D74.F2F9B250]
>
> But I don't understand the SLOTCAP address (B0:D1-4:F0:Offset 0x54[31:19]).
>
>
>
> Could you explain this mean to me?
>
>
>
> Thank you.
>
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SMBIOS table enablement in coreboot

[David Hendricks via coreboot]

Hi Mayuri,
Do you have GENERATE_SMBIOS_TABLES enabled in your config?

On Fri, Jan 13, 2017 at 12:56 AM, Mayuri Tendulkar <
mayuri.tendul...@aricent.com> wrote:

> Hi
>
> We are using coreboot for our board based on Intel Baytrail 3845.
>
>
>
> When we use *dmidecode –t *to get DDR details, we get empty. It means
> data is missing in SMBIOS.
>
>
>
> Are there any settings in coreboot to enable this?
>
>
>
> Regards
>
> Mayuri
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of
> this message. Aricent accepts no responsibility for loss or damage arising
> from the use of the information transmitted by this email including damage
> from virus."
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about PCIe separate reference clock

[Kyösti Mälkki]

On Fri, Jan 13, 2017 at 6:01 PM, Zheng Bao  wrote:

> About "Asynchronous clock mode on mainboard side", I guess.
>
>
> Both the device and bridge have the fields "slot clock configuration" and
> "common clock configuration".
>
Again assuming the mainboard side is CPU (some AMD SoC) and you are running
coreboot and can bodify binaryPI / AGESA firmware.

You can spoof this in the firmware and leave "Common Clock Configuration"
bit unset on both sides, even if they report "Slot Clock Configuration =
1". This affects the ASPM L0s and L1 latencies devices report in the Link
Capabilities register, but may also change hardware behaviour since specs
require link retraining after bit is set.

On our board, both the"slot clock configuration" of device (E8860)  and
> bridge are 1.
>
>
> Does it mean the "on mainboard"  side it does not support "Asynchronous
> clock mode"?
>
So, any specs from the mainboard or CPU side of the link? Ultimately your
100MHz clock stability and jitter is affected by the choice of your 25MHz
crystal part and PCB layout, right?

Kyösti



> --
> *From:* Predrag Vidic 
> *Sent:* Friday, January 13, 2017 10:29 AM
>
> *To:* Zheng Bao
> *Cc:* Zoran Stojsavljevic; coreboot@coreboot.org
> *Subject:* Re: [coreboot] Question about PCIe separate reference clock
>
> Hi Zheng,
>
> Schematic is simple and OK. I assume you are trying to run Wolf
> VPXxx-E8860- or similar GPU borad. You can't do much there if there is
> a hardware problem but it is most possibly a software setup problem.
>
> VPX does not have incomming clock so it is by default in async_clock mode.
> The question is did you allowed that mode on the main board side?
>
> Asynchronous clock mode is not default mode for a motherboard. Check if
> the mode is allowed. Second, check if the other PCIe device can work on the
> motherboard PCIe slot.
>
> Regards,
> Predrag
>
>
> On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao  wrote:
>
>> Here is the ref clk part. Please review.
>>
>> No refclk routes to VPX connector.
>>
>>
>> Thanks.
>>
>>
>> Zheng
>> --
>> *From:* Predrag Vidic 
>> *Sent:* Thursday, January 12, 2017 6:53 PM
>> *To:* Zheng Bao
>> *Cc:* Zoran Stojsavljevic; coreboot@coreboot.org
>>
>> *Subject:* Re: [coreboot] Question about PCIe separate reference clock
>>
>> Hi Zheng,
>>
>> Without knowing the particular solution for the PCIe transmitter you have
>> on your board, I'd check refclk pins on your design for the proper
>> termination. The problem can be in irregular readings from the pins.
>>
>> Reragds,
>> Predrag
>>
>> On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao  wrote:
>>
>>> Q: do you use local xtal attached to   Si52111-B5 to generate local PCIe
>>> 25MHz clock?
>>>
>>> Zheng: yes
>>>
>>>
>>> Q: If you dothis, my next question is how you synchronize these two
>>> clocks: Local
>>> PCIe 25 MHz and common reference clock from CPU?
>>>
>>> Zheng: We do NOT sync these two.
>>>
>>>
>>> Q: Since these two clocks, as I understand above scenario, are
>>> asynchronous to each other?!
>>>
>>> Zheng: yes. Asynchronous.
>>>
>>>
>>> The VPX connector does not have a PCIe ref clock signal, so we can not
>>> send CPU PCIe ref clock to
>>>
>>> device.  The PCIe spec says if the separate refclk on devices should be
>>> 100MHz ± 300PPM, with SSC
>>>
>>> off.  We believe our board meet this requirement. So we doubt the
>>> problem lies in PCI configration space.
>>>
>>>
>>> Zheng
>>>
>>>
>>>
>>> --
>>> *From:* Zoran Stojsavljevic 
>>> *Sent:* Thursday, January 12, 2017 9:22 AM
>>> *To:* Zheng Bao; Predrag Vidic
>>> *Cc:* coreboot@coreboot.org
>>> *Subject:* Re: [coreboot] Question about PCIe separate reference clock
>>>
>>> Hello Zheng,
>>>
>>> For decades, I've been FW/SW engineer, but I do understand a little
>>> bit of a HW. I have looked into the Si52111-B5 data sheet for
>>> clarification.
>>>
>>> My problem here is to understand, your use case: do you use local xtal
>>> attached to   Si52111-B5 to generate local PCIe 25MHz clock? If you do
>>> this, my next question is how you synchronize these two clocks: Local
>>> PCIe 25 MHz and common reference clock from CPU?
>>>
>>> Since these two clocks, as I understand above scenario, are
>>> asynchronous to each other?!
>>>
>>> Please, clarify for us your use case.
>>>
>>> Thank you,
>>> Zoran
>>> ___
>>>
>>> On 1/12/17, Zheng Bao  wrote:
>>> > Our VPX design uses separate reference clock source, which is
>>> Si52111-B5 (No
>>> > spread), instead of common ref clock from CPU.
>>> > Now The system is unstable. Reading PCIE configuration space is
>>> unstable
>>> > too. (If we add some fly wire to make it work with common ref clock,
>>> the
>>> > system becomes stable.)
>>> >
>>> > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit
>>> indicates
>>> > that the
>>> > component uses the same physical reference clock that the
>>> > platform provides on the connector. If the device uses an
>>> > indep

Re: [coreboot] Question about PCIe separate reference clock

[Zheng Bao]

About "Asynchronous clock mode on mainboard side", I guess.


Both the device and bridge have the fields "slot clock configuration" and 
"common clock configuration".

On our board, both the"slot clock configuration" of device (E8860)  and bridge 
are 1.


Does it mean the "on mainboard"  side it does not support "Asynchronous clock 
mode"?


Zheng




From: Predrag Vidic 
Sent: Friday, January 13, 2017 10:29 AM
To: Zheng Bao
Cc: Zoran Stojsavljevic; coreboot@coreboot.org
Subject: Re: [coreboot] Question about PCIe separate reference clock

Hi Zheng,

Schematic is simple and OK. I assume you are trying to run Wolf 
VPXxx-E8860- or similar GPU borad. You can't do much there if there is a 
hardware problem but it is most possibly a software setup problem.

VPX does not have incomming clock so it is by default in async_clock mode. The 
question is did you allowed that mode on the main board side?

Asynchronous clock mode is not default mode for a motherboard. Check if the 
mode is allowed. Second, check if the other PCIe device can work on the 
motherboard PCIe slot.

Regards,
Predrag


On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao 
mailto:fishb...@hotmail.com>> wrote:

Here is the ref clk part. Please review.

No refclk routes to VPX connector.


Thanks.


Zheng


From: Predrag Vidic mailto:pvi...@gmail.com>>
Sent: Thursday, January 12, 2017 6:53 PM
To: Zheng Bao
Cc: Zoran Stojsavljevic; coreboot@coreboot.org

Subject: Re: [coreboot] Question about PCIe separate reference clock

Hi Zheng,

Without knowing the particular solution for the PCIe transmitter you have on 
your board, I'd check refclk pins on your design for the proper termination. 
The problem can be in irregular readings from the pins.

Reragds,
Predrag

On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao 
mailto:fishb...@hotmail.com>> wrote:

Q: do you use local xtal attached to   Si52111-B5 to generate local PCIe 25MHz 
clock?

Zheng: yes


Q: If you dothis, my next question is how you synchronize these two clocks: 
Local
PCIe 25 MHz and common reference clock from CPU?

Zheng: We do NOT sync these two.

Q: Since these two clocks, as I understand above scenario, are
asynchronous to each other?!

Zheng: yes. Asynchronous.


The VPX connector does not have a PCIe ref clock signal, so we can not send CPU 
PCIe ref clock to

device.  The PCIe spec says if the separate refclk on devices should be 100MHz 
± 300PPM, with SSC

off.  We believe our board meet this requirement. So we doubt the problem lies 
in PCI configration space.


Zheng



From: Zoran Stojsavljevic 
mailto:zoran.stojsavlje...@gmail.com>>
Sent: Thursday, January 12, 2017 9:22 AM
To: Zheng Bao; Predrag Vidic
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Question about PCIe separate reference clock

Hello Zheng,

For decades, I've been FW/SW engineer, but I do understand a little
bit of a HW. I have looked into the Si52111-B5 data sheet for
clarification.

My problem here is to understand, your use case: do you use local xtal
attached to   Si52111-B5 to generate local PCIe 25MHz clock? If you do
this, my next question is how you synchronize these two clocks: Local
PCIe 25 MHz and common reference clock from CPU?

Since these two clocks, as I understand above scenario, are
asynchronous to each other?!

Please, clarify for us your use case.

Thank you,
Zoran
___

On 1/12/17, Zheng Bao mailto:fishb...@hotmail.com>> wrote:
> Our VPX design uses separate reference clock source, which is Si52111-B5 (No
> spread), instead of common ref clock from CPU.
> Now The system is unstable. Reading PCIE configuration space is unstable
> too. (If we add some fly wire to make it work with common ref clock, the
> system becomes stable.)
>
> (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit indicates
> that the
> component uses the same physical reference clock that the
> platform provides on the connector. If the device uses an
> independent clock irrespective of the presence of a reference
> clock on the connector, this bit must be clear.
> For a multi-Function device, each Function must report the
> same value for this bit.)
>
> Based on my understanding, the BIOS need to read bit "Slot Clock
> Configurationclear" to see if
> separate ref clock is used.  BIOS then write bit "Common Clock
> Configuration".
>
> On our board, the bit "Slot Clock Configuration" is always 1, which I assume
> should be 0.
>
> My question is, how the hardware affect the bit "Slot Clock Configuration"?
> How do we need to design our board to make the bit "Slot Clock
> Configuration" be 0?
>
> Thanks.
>
> Zheng
>
>


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Question about PCIe separate reference clock

[Predrag Vidic]

Hi Zheng,

Schematic is simple and OK. I assume you are trying to run Wolf
VPXxx-E8860- or similar GPU borad. You can't do much there if there is
a hardware problem but it is most possibly a software setup problem.

VPX does not have incomming clock so it is by default in async_clock mode.
The question is did you allowed that mode on the main board side?

Asynchronous clock mode is not default mode for a motherboard. Check if the
mode is allowed. Second, check if the other PCIe device can work on the
motherboard PCIe slot.

Regards,
Predrag


On Fri, Jan 13, 2017 at 6:44 AM, Zheng Bao  wrote:

> Here is the ref clk part. Please review.
>
> No refclk routes to VPX connector.
>
>
> Thanks.
>
>
> Zheng
> --
> *From:* Predrag Vidic 
> *Sent:* Thursday, January 12, 2017 6:53 PM
> *To:* Zheng Bao
> *Cc:* Zoran Stojsavljevic; coreboot@coreboot.org
>
> *Subject:* Re: [coreboot] Question about PCIe separate reference clock
>
> Hi Zheng,
>
> Without knowing the particular solution for the PCIe transmitter you have
> on your board, I'd check refclk pins on your design for the proper
> termination. The problem can be in irregular readings from the pins.
>
> Reragds,
> Predrag
>
> On Thu, Jan 12, 2017 at 3:26 PM, Zheng Bao  wrote:
>
>> Q: do you use local xtal attached to   Si52111-B5 to generate local PCIe
>> 25MHz clock?
>>
>> Zheng: yes
>>
>>
>> Q: If you dothis, my next question is how you synchronize these two
>> clocks: Local
>> PCIe 25 MHz and common reference clock from CPU?
>>
>> Zheng: We do NOT sync these two.
>>
>>
>> Q: Since these two clocks, as I understand above scenario, are
>> asynchronous to each other?!
>>
>> Zheng: yes. Asynchronous.
>>
>>
>> The VPX connector does not have a PCIe ref clock signal, so we can not
>> send CPU PCIe ref clock to
>>
>> device.  The PCIe spec says if the separate refclk on devices should be
>> 100MHz ± 300PPM, with SSC
>>
>> off.  We believe our board meet this requirement. So we doubt the problem
>> lies in PCI configration space.
>>
>>
>> Zheng
>>
>>
>>
>> --
>> *From:* Zoran Stojsavljevic 
>> *Sent:* Thursday, January 12, 2017 9:22 AM
>> *To:* Zheng Bao; Predrag Vidic
>> *Cc:* coreboot@coreboot.org
>> *Subject:* Re: [coreboot] Question about PCIe separate reference clock
>>
>> Hello Zheng,
>>
>> For decades, I've been FW/SW engineer, but I do understand a little
>> bit of a HW. I have looked into the Si52111-B5 data sheet for
>> clarification.
>>
>> My problem here is to understand, your use case: do you use local xtal
>> attached to   Si52111-B5 to generate local PCIe 25MHz clock? If you do
>> this, my next question is how you synchronize these two clocks: Local
>> PCIe 25 MHz and common reference clock from CPU?
>>
>> Since these two clocks, as I understand above scenario, are
>> asynchronous to each other?!
>>
>> Please, clarify for us your use case.
>>
>> Thank you,
>> Zoran
>> ___
>>
>> On 1/12/17, Zheng Bao  wrote:
>> > Our VPX design uses separate reference clock source, which is
>> Si52111-B5 (No
>> > spread), instead of common ref clock from CPU.
>> > Now The system is unstable. Reading PCIE configuration space is unstable
>> > too. (If we add some fly wire to make it work with common ref clock, the
>> > system becomes stable.)
>> >
>> > (abstracted from PCIe spec: 12 Slot Clock Configuration - This bit
>> indicates
>> > that the
>> > component uses the same physical reference clock that the
>> > platform provides on the connector. If the device uses an
>> > independent clock irrespective of the presence of a reference
>> > clock on the connector, this bit must be clear.
>> > For a multi-Function device, each Function must report the
>> > same value for this bit.)
>> >
>> > Based on my understanding, the BIOS need to read bit "Slot Clock
>> > Configurationclear" to see if
>> > separate ref clock is used.  BIOS then write bit "Common Clock
>> > Configuration".
>> >
>> > On our board, the bit "Slot Clock Configuration" is always 1, which I
>> assume
>> > should be 0.
>> >
>> > My question is, how the hardware affect the bit "Slot Clock
>> Configuration"?
>> > How do we need to design our board to make the bit "Slot Clock
>> > Configuration" be 0?
>> >
>> > Thanks.
>> >
>> > Zheng
>> >
>> >
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Using as default external monitor for booting in x230

[Car.cuevas via coreboot]

Hi all,

First thanks to all for such an amazing job, I just realized that Coreboot is 
already working in the lenovo x230, and I am really thinking in flash it and 
give a try :) But since I have a mod in my x230 for having FHD (edp screen), 
somehow I will need to somehow setup on the bios that I need to use the 
external Digital output (the one used for the dock station) as default... Is it 
any way to configure that?

thanks very much in advance :)-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin]

Hi,

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

32 new defect(s) introduced to coreboot found with Coverity Scan.
12 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
recent build analyzed by Coverity Scan.

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


** CID 1368413:  Control flow issues  (DEADCODE)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/dram/dfs.c: 1236 in 
gen_rk3399_ctl_params()



*** CID 1368413:  Control flow issues  (DEADCODE)
/3rdparty/arm-trusted-firmware/plat/rockchip/rk3399/drivers/dram/dfs.c: 1236 in 
gen_rk3399_ctl_params()
1230tmp0 |= (1 << 24);
1231 #endif
1232for (i = 0; i < timing_config->ch_cnt; i++) {
1233if (tmp0 | tmp1)
1234mmio_setbits_32(CTL_REG(i, 305), 1 << 16);
1235if (tmp0)
>>> CID 1368413:  Control flow issues  (DEADCODE)
>>> Execution cannot reach this statement: "mmio_setbits_32(4289200128U...".
1236mmio_setbits_32(CTL_REG(i, 70), tmp0);
1237if (tmp1)
1238mmio_setbits_32(CTL_REG(i, 71), tmp1);
1239}
1240 #endif
1241 }

** CID 1361275:(TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 838 in parse_subpart_dir()



*** CID 1361275:(TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 831 in parse_subpart_dir()
825 memcpy(hdr.name, data + offset, sizeof(hdr.name));
826 offset += sizeof(hdr.name);
827 
828 validate_subpart_dir_without_checksum((struct subpart_dir 
*)&hdr, name);
829 
830 assert(size > subpart_dir_size(&hdr));
>>> CID 1361275:(TAINTED_SCALAR)
>>> Passing tainted variable "subpart_dir_size(&hdr)" to a tainted sink.
831 alloc_buffer(subpart_dir_buf, subpart_dir_size(&hdr), "Subpart 
Dir");
832 memcpy(buffer_get(subpart_dir_buf), &hdr, 
SUBPART_DIR_HEADER_SIZE);
833 
834 /* Read Subpart Dir entries. */
835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
836 struct subpart_dir_entry *e = &subpart_dir->e[0];
/util/cbfstool/ifwitool.c: 838 in parse_subpart_dir()
832 memcpy(buffer_get(subpart_dir_buf), &hdr, 
SUBPART_DIR_HEADER_SIZE);
833 
834 /* Read Subpart Dir entries. */
835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf);
836 struct subpart_dir_entry *e = &subpart_dir->e[0];
837 uint32_t i;
>>> CID 1361275:(TAINTED_SCALAR)
>>> Using tainted variable "hdr.num_entries" as a loop boundary.
838 for (i = 0; i < hdr.num_entries; i++) {
839 memcpy(e[i].name, data + offset, sizeof(e[i].name));
840 offset += sizeof(e[i].name);
841 offset = read_member(data, offset, sizeof(e[i].offset),
842  &e[i].offset);
843 offset = read_member(data, offset, sizeof(e[i].length),

** CID 1361274:  Insecure data handling  (TAINTED_SCALAR)



*** CID 1361274:  Insecure data handling  (TAINTED_SCALAR)
/util/cbfstool/ifwitool.c: 717 in alloc_bpdt_buffer()
711 {
712 struct bpdt_header bpdt_header;
713 assert((offset + BPDT_HEADER_SIZE) < size);
714 bpdt_read_header((uint8_t *)data + offset, &bpdt_header, name);
715 
716 /* Buffer to read BPDT header and entries. */
>>> CID 1361274:  Insecure data handling  (TAINTED_SCALAR)
>>> Passing tainted variable "get_bpdt_size(&bpdt_header)" to a tainted 
>>> sink.
717 alloc_buffer(b, get_bpdt_size(&bpdt_header), name);
718 
719 struct bpdt *bpdt = buffer_get(b);
720 memcpy(&bpdt->h, &bpdt_header, BPDT_HEADER_SIZE);
721 
722 /*

** CID 1361253:  Memory - illegal accesses  (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry()



*** CID 1361253:  Memory - illegal accesses  (BUFFER_SIZE_WARNING)
/util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry()
1294 static size_t init_subpart_dir_entry(struct subpart_dir_entry *e,
1295 struct buffer *b, size_t offset)
1296 {
1297memset(e, 0, sizeof(*e));
1298 
1299assert(strlen(b->name) <= sizeof(e->name));
>>> CID 1361253:  Memory - illegal accesses  (BUFFER_SIZE_WARNING)
>>> Calling strncpy with a maximum s

[coreboot] SMBIOS table enablement in coreboot

[Mayuri Tendulkar]

Hi
We are using coreboot for our board based on Intel Baytrail 3845.

When we use dmidecode -t to get DDR details, we get empty. It means data is 
missing in SMBIOS.

Are there any settings in coreboot to enable this?

Regards
Mayuri
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot