Change in coreboot[master]: libpayload: Parse DDR information through coreboot tables

[Julius Werner (Code Review)]

Attention is currently required from: Hung-Te Lin, Shelley Chen, Ravi kumar, Paul Menzel, mturney mturney, Ravi Kumar Bokka, Angel Pons, Arthur Heymans, Xixi Chen, Yu-Ping Wu.
Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/59193 )

Change subject: libpayload: Parse DDR information through coreboot tables
......................................................................

Patch Set 35:

(3 comments)

Patchset:

PS32:
> This is for getting the dram size in ramstage. […]

There seems to be very little overlap between that structure and the kind of information we care about here, so I don't think that would really work out. I guess we could consider reusing the smbios_memory_type enum if you want, though?

Patchset:

PS35: 
Apologies for not getting back to this in a while, I haven't seen the end of my inbox since Perf started (and am clearly bad at prioritization).

File src/commonlib/bsd/include/commonlib/bsd/mem_chip_info.h:

https://review.coreboot.org/c/coreboot/+/59193/comment/1a9595d4_e63b5c03 
PS32, Line 24: 2
> I wasn't suggesting creating or using a linked-list. […]

Sorry for the confusion. This was always meant to be a variable-size array, that's why there *is* a channel_count field (see the `num_channels` above, that's exactly what that is for). All code that is reading this structure should read entries up to the number indicated in that field rather than just assume it is always 2. I didn't object to defining this array as length [2] in the struct because that made it easier to work with for now, but you are right that it should technically be length [0]. So since it already seems to be cause for confusion, let's change it to that.

There should not be a total_density field because that's just redundant with adding up the densities of all individual channels, and redundancy in informational structures is usually a bad idea (that just poses the risk of them going out of sync).