Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Lewis, Ian (Microstar Laboratories)]

Hello Philipp,

Philipp Deppenwiese wrote:

> There is already an easy solution. Just tell your customers that you will 
> make the coreboot implementation open source (hw init). 
> They can load their own proprietary stuff afterwards as payload (binary) 
> without having issues with the GPLv2. 
> Sure if they use SeaBIOS it's a problem (GPLv3) but there are tons of 
> payloads out there.

Our customers will never load their own payload. Our systems always boot to our 
own OS, which manages the measurement hardware and data processing side of the 
customer application. Our customers send relatively simple scripts to our 
systems that tell them how to manage the real-time, control, and signal 
processing portions of the application, while they typically have a relatively 
complex application-specific human interface application that runs on the host 
OS, typically operating under Windows, but sometimes operating under Linux 
(these few customers operating under Linux, obviously, will not have any 
trouble with GPL). Most customers want our system to “just work”. They send our 
system a PID() command, say, and it runs a PID loop for them until they tell it 
to stop. They do not dig down into the boot process or load a different OS.

> coreboot makes things cost effective because we are all working together on 
> the platform support.
> Another good reason for not reinventing the wheel again :)

> Even Siemens uses coreboot + SeaBIOS -> 
> https://www.youtube.com/watch?v=tq4xSipCWEU 
> without having the "fear" of licensing issues. Sure they are not selling it 
> to end users.

On a quick look at the Siemens website for this product, this definitely looks 
like a good example of a product that matches what we do quite well, though I 
suspect they aim at much bigger customers than we do. With a few minutes spent 
looking, it is not at all clear to me how Siemens handles their GPL 
responsibility and whether they attempt to provide compliance for their 
customers or not.

> If you want to make it easy for them. Upstream open source as much as 
> possible.
> If it is already there people will stop asking your customers for the source 
> code!
> Also if they use a custom payload without GPL code they don't need to open 
> source it!

We will definitely push any changes we make back to Coreboot or SeaBIOS to 
accept or reject.

Best Regards,
Ian


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

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Lewis, Ian (Microstar Laboratories)]

Hello David,

 

David Hendricks wrote:

Ø  Did you actually need to change coreboot or SeaBIOS? If so, how extensive 
were the changes? I am guessing that the boot firmware isn't considered to be 
part of the high-value IP of the product - that is presumably in your OS.

No. We have made no changes. At the moment we do not even know how to build the 
required modules for the system. Personally, I would rather we did not have to 
know how to do a build, but I think we will need to so that we can validate 
that the source code matches the binary we distribute. Even once we do work out 
how to do a build, I very much doubt we will make any changes at all. If we do 
change anything in coreboot or SeaBIOS – or any other GPL licensed project for 
that matter, we will definitely release our changes back to the relevant 
project to accept or reject. 

 

Ø  Your idea about using the "About" tab to inform the user about the licenses 
and where to find the code is good. It should cover your company even if the 
customer never reads it. 

If this is correct, and an About tab with all the relevant information about 
coreboot and SeaBIOS meets our – and our customer’s – licensing responsibility, 
then we clearly can do something that will work well for our purposes. And, the 
issue becomes purely one of engineering work and administration in production. 

 

Ø  Like you say, the goal here should be to make it so that downstream 
customers don't need to think about this stuff. The nice thing is that if you 
act consistently with the spirit of the open-source licenses then this should 
all be simple for them and for your company as well, and you get to spend more 
time engineering and collaborating and less time worrying.

Once I have an idea what I am talking about, I may spend less time worrying. 

 

Ø  Just my $0.02. Please make sure to consult your company's legal department 
before acting on anything you read in this thread (or elsewhere) :-)

:->

 

Ian

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

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[David Hendricks]

Hi Ian,
Did you actually need to change coreboot or SeaBIOS? If so, how extensive
were the changes? I am guessing that the boot firmware isn't considered to
be part of the high-value IP of the product - that is presumably in your OS.

If you can publish the coreboot and SeaBIOS code on your website (it could
be a zip file or something) then things should be reasonably simple. Even
better would be to add the mainboard support to upstream coreboot or fork
upstream coreboot on github and then add your patches on top. Then
downstream customers can then easily download the code and, if needed,
modify and commit their patches to the same codebase as to be in compliance
in the same manner as you.

Your idea about using the "About" tab to inform the user about the licenses
and where to find the code is good. It should cover your company even if
the customer never reads it. You shouldn't need a clickthrough license or
anything (gnu.org has a FAQ that covers that topic:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html). Also, the
"conspicuous" requirement should already be met with the license
information that exists in the header of each source code file and/or a
LICENSE or COPYING file. As Peter mentioned that is exactly how the
requirement is met for large companies who work with open source software.

Like you say, the goal here should be to make it so that downstream
customers don't need to think about this stuff. The nice thing is that if
you act consistently with the spirit of the open-source licenses then this
should all be simple for them and for your company as well, and you get to
spend more time engineering and collaborating and less time worrying.

Just my $0.02. Please make sure to consult your company's legal department
before acting on anything you read in this thread (or elsewhere) :-)


On Fri, Dec 29, 2017 at 6:21 PM, Lewis, Ian (Microstar Laboratories) <
ile...@mstarlabs.com> wrote:

> ron minnich wrote
> > how are you different in this case from Motorola, who had to put their
> linux source on a web site? companies resold motorola phones. Or the many
> switch vendors who sell network switches that run coreboot/linuxbios? or
> irobot, who use it still on the packbot?
> > Or how are you different from just about every vendor that sells
> embedded ARM boards that run u-boot?
> We are, because of the nature of our customers, very different from all of
> your example use cases, except perhaps the people who sell embedded ARM
> boards.
>
> Motorola phone: They sell their product to people (well, companies) who
> set out to make GPL licensed products, typically for a large market. The
> customer of Motorola makes no modifications to the Motorola phone, or at
> least no significant modifications. There is no difficulty for such a
> prospective reseller of such a product to comply with GPL. There are lots
> of sales to cover the initial costs. But, most importantly, the Motorola
> reseller is typically not making a new product. They are reselling the
> Motorola product, perhaps as a private label, to an end user who will
> receive Motorola's packaging and notifications (at first boot, perhaps - I
> do not actually know how).
>
> As far as I can see (well, guess), network switch purchasers are almost
> always end users (corporate or personal). And, it is my guess - after
> spending the past week and a half trying to understand GPL's implications -
> that there are many, many small resellers of network switches in complete
> systems that are out of compliance with GPL because they do not even think
> about the issue. As a side note, our customers are a bit like this kind of
> reseller of a complete system that happens to contain a network switch,
> though the analogy is not great because the network switch is in some sense
> a complete system, while what we make is not. Still, if I sell a network
> installation to a small shop, and I fail to give the recipient of my system
> that includes that switch the GPL license and a place to get the source
> code, I am in violation of GPL. I do not want this to happen to my
> customers.
>
> iRobot is making an end use product, not a product that someone else is
> going to take and build into something very different from the iRobot
> product. Again, a lot like Motorola and their phone. If NewEgg sells an
> iRobot product, they just pass through the iRobot package - with everything
> in it - so (I think, though I am not quite sure) they are in compliance as
> long as iRobot was. I suspect that NewEgg just assumes that iRobot got
> their licensing right. My reading of GPL is that NewEgg actually has their
> own obligation under GPL separate from iRobot's, but I would guess they do
> not worry about it much. They are not making anything. They are just
> reselling.
>
> ARM boards that run u-boot: The target customer base is aiming to take
> advantage of the ARM board to make a product at a low cost (typically), and
> most of them are well aware of GPL and 

Re: [coreboot] G505s with Coreboot unable to run any version of Qubes

[Emil Novik via coreboot]

Thanks !

With the help of Awokd I managed to boot each version by using 
"xen-pciback.hide=(PCI address of the discrete GPU)" and the small grub fix for 
3.2.

I was planning on using 4rc3 but the VM setup on first boot always fails to 
create sys-net because of a libxenlight error. I can still start my session but 
no internet access, same error each time I try to start sys-net and no VM 
manager to be found.

So I decided to use 3.2 and it works like a charm, just needs some more ram and 
all will be perfect :)

---
Emil Novik

 Original Message 
On Dec 30, 2017, 21:44, Ivan Ivanov wrote:

> Hi Emil, thank you very much for your report.
> Regarding Qubes 3.2 : at the Qubes HCL list I wrote:
>
> "after Qubes R3.2 installation it cant boot - cant reach GRUB Boot Menu
> because MBR (or GRUB) is corrupted. Use grub2-install to fix it (read more)
> Everything else is OK "
>
> https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ
>
> If you fix your GRUB as described ^^^ you may be able to finally boot Qubes 
> 3.2
> Please test it and let me know the results
>
> Live 3.1 was buggy, full 3.1 would have worked. Haven't tested 4.0 -
> can't speak about it
>
> Best regards,
> Ivan
>
> 2017-12-28 1:19 GMT+03:00 Emil Novik via coreboot :
>> Hey, I'm having some heavy trouble getting my laptop to run Qubes and I
>> first thought I was having issues with the OS. But after digging into the
>> logs I managed to get(crashes too early during boot to get any persistent
>> logs, had to write most by hand) it feels more like an issue with my
>> Coreboot built.
>>
>> So there are the details :
>> - G505s with integrated HD 8650G + discrete R5 M230 graphics.
>> - Coreboot 4.6-2477-g6ab3edac3c-dirty with processor microcode patch
>> (change-ID: Ibbfee47ce1d5081640d6924e2b12f5213a7fcadb).
>> - Runs Debian Stretch fine.
>> - Fails to start Qubes 3.2 / 4.0 rc3 / Live 3.1.
>> - I added the vgabios.rom for the integrated card with menuconfig and the
>> one for the discrete card with cbfstool.
>> - Coreboot.rom, .config and full make output as attachment.
>>
>>
>> Some more error data I gathered from coreinfo's Bootlog :
>>
>> Failed to enable LTR for dev = PCI: 01:00.0
>> Failed to enable LTR for dev = PCI: 02:00.0
>> ...
>> I2C: 01:50 missing read_resources
>> I2C: 01:51 missing read_resources
>> PNP: 00ff.1 missing read_resources
>> ...
>> Warning: Can't write PCI_INTR 0xC00/0xC01 registers because
>> 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL
>> Warning: Can't write PCI IRQ assignments because 'mainboard_pirq_data'
>> structure does not exist
>> ...
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
>> ASSERTION ERROR: file
>> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
>> ...
>> Manufacturer: ef
>> SF: Detected W25Q32 with sector size 0x1000, total 0x40
>> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
>> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
>> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
>> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
>> Manufacturer: ef
>> SF: Detected W25Q32 with sector size 0x1000, total 0x40
>> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
>> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
>> 

Re: [coreboot] G505s with Coreboot unable to run any version of Qubes

[Ivan Ivanov]

Hi Emil, thank you very much for your report.
Regarding Qubes 3.2 : at the Qubes HCL list I wrote:

"after Qubes R3.2 installation it cant boot - cant reach GRUB Boot Menu
because MBR (or GRUB) is corrupted. Use grub2-install to fix it (read more)
Everything else is OK "

https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ

If you fix your GRUB as described ^^^ you may be able to finally boot Qubes 3.2
Please test it and let me know the results

Live 3.1 was buggy, full 3.1 would have worked. Haven't tested 4.0 -
can't speak about it

Best regards,
Ivan

2017-12-28 1:19 GMT+03:00 Emil Novik via coreboot :
> Hey, I'm having some heavy trouble getting my laptop to run Qubes and I
> first thought I was having issues with the OS. But after digging into the
> logs I managed to get(crashes too early during boot to get any persistent
> logs, had to write most by hand) it feels more like an issue with my
> Coreboot built.
>
> So there are the details :
> - G505s with integrated HD 8650G + discrete R5 M230 graphics.
> - Coreboot 4.6-2477-g6ab3edac3c-dirty with processor microcode patch
> (change-ID: Ibbfee47ce1d5081640d6924e2b12f5213a7fcadb).
> - Runs Debian Stretch fine.
> - Fails to start Qubes 3.2 / 4.0 rc3 / Live 3.1.
> - I added the vgabios.rom for the integrated card with menuconfig and the
> one for the discrete card with cbfstool.
> - Coreboot.rom, .config and full make output as attachment.
>
>
> Some more error data I gathered from coreinfo's Bootlog :
>
> Failed to enable LTR for dev = PCI: 01:00.0
> Failed to enable LTR for dev = PCI: 02:00.0
> ...
> I2C: 01:50 missing read_resources
> I2C: 01:51 missing read_resources
> PNP: 00ff.1 missing read_resources
> ...
> Warning: Can't write PCI_INTR 0xC00/0xC01 registers because
> 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL
> Warning: Can't write PCI IRQ assignments because 'mainboard_pirq_data'
> structure does not exist
> ...
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ...
> Manufacturer: ef
> SF: Detected W25Q32 with sector size 0x1000, total 0x40
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> Manufacturer: ef
> SF: Detected W25Q32 with sector size 0x1000, total 0x40
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 309
> ...
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> ...
> I2C: 01:50 (unknown)
> I2C: 01:51 (unknown)
> ...
> APIC: 11 (unknown)
> APIC: 12 (unknown)
> APIC: 13 (unknown)
> PCI: 01:00.0 (unknown)
> PCI: 02:00.0 (unknown)
> PNP: 00ff.0 (unknown)
>
>
> "..." are parts I didn't write down as they didn't show any obvious
> errors(but I'm bad at seeing them) and it would take me a lng time to
> write down the full 

Re: [coreboot] Doubt about SPD init in Skylake

[Nico Huber]

Hi,

On 30.12.2017 08:56, 王翔 wrote:

The system must initialize some arrays before initializing the SPD in
order to execute FspMemoryInit.  I do not know what these arrays do,
and how do I get these values when porting new motherboard.


These codes exist on the SKYLAKE platform which using FSP2.0.  Call path
:
fsp_memory_init->do_fsp_memory_init->platform_fsp_memory_init_params_cb->mainboard_memory_init_params


array list : FSPM_UPD->FspmConfig->DqByteMapCh0
FSPM_UPD->FspmConfig->DqByteMapCh1
FSPM_UPD->FspmConfig->DqsMapCpu2DramCh0
FSPM_UPD->FspmConfig->DqsMapCpu2DramCh1
FSPM_UPD->FspmConfig->RcompResistor FSPM_UPD->FspmConfig->RcompTarget


These have nothing to do with the SPD information for your memory chips.
These settings are about board specific routing (and calibration, I
guess). The former four are only needed for soldered-down LPDDR3 memory,
AIUI, so if you have DIMMs with SPD they don't apply for your board.

The `RcompResistor` settings are chipset dependent. IIRC, you can find
these in the respective Platform Design Guide for your chipset. The
`RcompTarget` I've never really figured out. I can only guess, that this
is a board specific calibration target. You should ask your Intel con-
tacts about it.

For further assistance we'd need to know your exact target chipset (SKU)
and what kind of memory (e.g. DDR3/DDR4, DIMMs or soldered down) you use
on your board.

Hope that helps,
Nico

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

Re: [coreboot] Doubt about SPD init in Skylake

[Zoran Stojsavljevic]

> The system must initialize some arrays before initializing
> the SPD in order to execute FspMemoryInit. I do not know
> what these arrays do, and how do I get these values when
> porting new motherboard.

It is, actually, vice versa (SPD is used for the IMC initialization).
Serial Presence Detect is a small flash, mounted on the DDR2/DDR3/DDR4
SIMM/DIMM modules, from where MRC algorithms read DDRx parameters, RAS
and CAS latencies, and configure IMC, as my best understanding is.

Please, refer to: https://en.wikipedia.org/wiki/Serial_presence_detect

This page also says: "Coreboot reads and uses SPD information to
initialize all memory controllers in a computer with timing, size and
other properties."

To find out yours SPD parameters, please, use the following tool for
WIN: https://www.cpuid.com/softwares/cpu-z.html

For Linux, please, use dmidecode Linux command.

Zoran

On Sat, Dec 30, 2017 at 8:56 AM, 王翔  wrote:
> The system must initialize some arrays before initializing the SPD in order
> to execute FspMemoryInit.
> I do not know what these arrays do,  and how do I get these values when
> porting new motherboard.
>
> These codes exist on the SKYLAKE platform which using FSP2.0.  Call path :
> fsp_memory_init->do_fsp_memory_init->platform_fsp_memory_init_params_cb->mainboard_memory_init_params
>
> array list :
> FSPM_UPD->FspmConfig->DqByteMapCh0
> FSPM_UPD->FspmConfig->DqByteMapCh1
> FSPM_UPD->FspmConfig->DqsMapCpu2DramCh0
> FSPM_UPD->FspmConfig->DqsMapCpu2DramCh1
> FSPM_UPD->FspmConfig->RcompResistor
> FSPM_UPD->FspmConfig->RcompTarget
>
>
> If you can help me extremely grateful ! ! !
>
>
>
>
> --
>
> 王翔
>
> 安全研究员
>
> 广州市腾御安信息科技有限公司
>
> 广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

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

[coreboot] Doubt about SPD init in Skylake

[王翔]

The system must initialize some arrays before initializing the SPD in order to 
execute FspMemoryInit. 
I do not know what these arrays do,  and how do I get these values when porting 
new motherboard.


These codes exist on the SKYLAKE platform which using FSP2.0.  Call path : 
fsp_memory_init->do_fsp_memory_init->platform_fsp_memory_init_params_cb->mainboard_memory_init_params


array list :
FSPM_UPD->FspmConfig->DqByteMapCh0
FSPM_UPD->FspmConfig->DqByteMapCh1
FSPM_UPD->FspmConfig->DqsMapCpu2DramCh0
FSPM_UPD->FspmConfig->DqsMapCpu2DramCh1
FSPM_UPD->FspmConfig->RcompResistor
FSPM_UPD->FspmConfig->RcompTarget





If you can help me extremely grateful ! ! !




--



王翔

安全研究员

广州市腾御安信息科技有限公司





广州市天河区珠江新城华穗路406号保利克洛维二期中景A座1020-1024-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot