coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Re: [coreboot] SPI controller and Lock bits
by Martin Kepplinger 15 Oct '18

15 Oct '18

Am 01.10.2018 23:38 schrieb Youness Alaoui: > On Sat, Sep 29, 2018 at 12:21 PM Nico Huber <nico.h(a)gmx.de> wrote: >> >> On 9/27/18 10:29 PM, Youness Alaoui wrote: >> > Thanks everyone for the responses. >> > So far my understanding on the task at hand is : >> > - Add a CONFIG to decide if we set FLOCKDN or not (and one to decide >> > if we lock it on the resume path?) >> >> Maybe no config at all, see discussion of PRR34_LOCKDN below. But if, >> then only one config, IMO: On the resume path FLOCKDN should always be >> set. >> >> > - Remove the chipset_lockdown devicetree config and change the code to >> > always assume it's LOCKDOWN_COREBOOT (this applies to all platforms, >> > right?) >> >> Yes, unless somebody objects. Please make sure to add the right >> reviewers to this patch. I expect some resistance. >> > Ok, this is already done, but I want to finish/test my work before I > send for review and I might not have time until the end of the week. > >> > - remove the call to fast_spi_pr_dlock() and fix the comment above >> > that function to be more accurate >> >> Please also check the tree for code that sets PRRs. IIRC, it is used >> somewhere to protect the MRC cache. I would set the discrete lock >> directly after writing the region. >> > Ok, thanks, will do. > Note: I've also changed the fast_spi_pr_dlock() function to take 5 u8 > arguments to allow the caller to lock each prr individually instead of > being an all or nothing. > >> > - Add .config CONFIG options or maybe optional devicetree configs for >> > how to setup the registers so coreboot can prepare them (due to the >> > resume path) ? >> >> Hmm, I would add Kconfig options for this as well. I you want to match >> the configuration of your payload, it definitely doesn't belong into >> the >> devicetree. Note that "prepare" also implies to lock them on the >> resume >> path. >> > Yeah, so far, the KConfigs I added are : > FAST_SPI_LOCK_REGISTERS > FAST_SPI_LOCK_REGISTERS_ON_RESUME > FAST_SPI_LOCK_PRR34_REGISTERS > FAST_SPI_LOCK_PRR34_REGISTERS_ON_RESUME > FAST_SPI_PRR3_REGISTER (hex value) > FAST_SPI_PRR4_REGISTER (hex value) > > This way, a user can lock/unlock the register (since it affects more > than just the PRRs) and they can override/set the PRR3 and PRR4 values > and decide whether to lock them or not or only on resume, etc.. I > think those should be enough for most use cases and it's enough for > what I need. > >> >> AIUI, FLOCKDN always locks the PRRs. >> > Actually from what I can see, the FLOCKDN will lock a few registers, >> > among which it will lock the "discrete PR locks" register, and it will >> > lock the PR 0, 1 and 2, but there's also a PRR34_LOCKDN bit to >> > separately lock the PRR 3 and 4. So technically, I could leave FLOCKDN >> > set, and in the payload, just set protected range in PRR3 or PRR4, >> > then set the PRR34_LOCKDN. Unfortunately, I can't do that because the >> > PRR3 and 4 were already locked with the discrete lock register (if I >> > remove the call to fast_spi_pr_dlock(), it should be fine for my needs >> > though I think, since you said swseq would also fail for protected >> > ranges). >> >> Ah, that PRR34_LOCKDN was only introduced with SKL. Didn't know it or >> at least didn't remember it. In this case it seems best to always set >> FLOCKDN in coreboot. The payload can then still protect additional >> regions with PRR3/4. On the resume path, coreboot would set both >> FLOCKDN >> and PRR34_LOCKDN, right? > > On resume, even if coreboot sets them, the PRRs need to be filled, > which is why I also added the hex value of the PRR in the KConfig. > I also want to keep FLOCKDN unlocked, so Heads can set the write > protect bits in the flash then prevent writing to the status register > via hwseq before locking it with FLOCKDN. > >> >> >> Also note that swseq is not an option anymore since Skylake (IIRC, the >> >> ME protects the flash-cycle go bit in its default configuration). With >> >> only hwseq, you can only access the flash chip's first status register >> >> which makes many security features unusable. So we have to rely on the >> >> protected regions :-/ I hope Intel is going to fix that for future plat- >> >> forms (or with an ME update if that could add more hwseq commands). >> > >> > Well, I saw the opmenu/optypes/etc.. registers still being set in >> > skylake (their offsets were not in the datasheet though), so I figured >> > swseq is still there, just undocumented. It might work on systems >> > where the ME is disabled. I'd have to test. I was thinking of using >> > swseq and add the write-register-2 opcode and use it to set SPR1 and >> > lock the entire flash until it gets power cycled. I don't know if that >> > would work during suspend, but if it does, it might help with the >> > resume path at least (but would prevent updating flash after a reboot >> > and would force user to shut down and boot). I guess I have some >> > trial-error to do. >> >> The tricky part is to get access to the flash chip's second status >> register. I couldn't figure any way to do that with SKL (this cost >> me some weeks of work once because FSP also locked empty flash pro- >> tection). > Only way I see is through swseq, but you say it doesn't work because > of the ME. I'd have to test if the disabled ME allows swseq to work. > >> >> > Actually, if status register remains the same through a >> > reboot/suspend/resume, and swseq doesn't work on skylake at all, I >> > could just set the protect bits and prevent writing to status register >> > on resume path. >> >> I don't understand, is there a lock to prevent status register writes >> with hwseq? Also I though, you can't disable these status register >> bits >> w/o a reset. Whether the flash chip is reset, depends on your board >> design and power sequencing ofc. >> > Yes, see bit 11 of HSFSC register (WRSDIS). That one already has a > Kconfig to decide if we want it locked or not. > >> > >> >> One way would be to let coreboot decide, e.g. prepare the configuration >> >> and don't lock it, and let the payload lock. The payload could validate >> >> this configuration before locking (and issue a warning if coreboot >> >> didn't set the expected bits). >> > >> > Thanks, that's a good idea, I forgot about the suspend/resume case. >> > This implies I need coreboot to know about what config the payload >> > will want to set. I'm not sure if that should go into a CONFIG or a >> > devicetree config. Since it might be user-configured, it makes more >> > sense for it to go into .config, right ? >> >> Yes, Kconfig seems to be the right place. >> >> Nico > Thanks! is there already a gerrit change you are working on this? Do plan to support / test a X230 flash chip's lock bits? * MX25L6406E/MX25L6408E * EN25QH64 * MX25L3206E thanks, martin

3 2

Re: [coreboot] MRC in coreboot
by Aaron Durbin 15 Oct '18

15 Oct '18

On Mon, Oct 15, 2018 at 6:42 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com> wrote: > > Hi Aron, > > > > I have tried giving iomem=relaxed to the kernel command line. But still I am getting the same error. > > > > This time I tried with verbose option and the output is below > > $ ./cbmem -V -t > > > > Looking for coreboot table at 0 1048576 bytes. > > Mapping 1MB of physical memory at 0x0 (requested 0x0). > > Unmapping 1MB of virtual memory at 0x7fd372347000. > > Looking for coreboot table at f0000 1048576 bytes. > > Mapping 1MB of physical memory at 0xf0000 (requested 0xf0000). > > ... failed. Mapping 1052671B of physical memory at 0xef000. > > Failed to mmap /dev/mem: Operation not permitted > > > > Also could you please tell any method to measure the boot time ? Currently we are measuring with the help of stop watch which may not accurate. cbmem -t will provide it. What do you see in 'dmesg' ? Also, what do the e820 entries show? They should match below. 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-000000000fffffff: RAM 4. 0000000010000000-0000000012150fff: RESERVED 5. 0000000012151000-000000007a92cfff: RAM 6. 000000007a92d000-000000007affffff: CONFIGURATION TABLES 7. 000000007b000000-000000007fffffff: RESERVED 8. 00000000d0000000-00000000ffffffff: RESERVED How old of a cbmem utility are you using? don't understand where the 1MiB mappings are coming from. > > > > Thanks, > > Antony > > > > From: Aaron Durbin [mailto:adurbin@google.com] > Sent: Friday, October 12, 2018 7:12 PM > To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com> > Cc: Coreboot <coreboot(a)coreboot.org>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM> > Subject: Re: [coreboot] MRC in coreboot > > > > > > > > On Fri, Oct 12, 2018 at 4:38 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com> wrote: > > Hi Aron, > > > > I am not able to get the cbmem timestamps. I am using cbmem utility to find the timestamps. > > > > $ . /cbmem -t > > > > The above command gives the following error. > > > > Failed to mmap /dev/mem : Operation not permitted > > > > Could you please help on this? > > > > https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/kernel-parameters.html > > > > Adding 'iomem=relaxed' to the kernel cmdline would fix that particular problem. > > > > Note, with that current error, that you should see a PAT error in dmesg. > > > > > > Thanks & Regards, > > Antony > > From: Aaron Durbin [mailto:adurbin@google.com] > Sent: Thursday, October 11, 2018 9:44 PM > To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com> > Cc: Coreboot <coreboot(a)coreboot.org>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM> > Subject: Re: [coreboot] MRC in coreboot > > > > cbmem timstamps will be needed. > > > > Looks like FSP is manipulating the tsc: > > BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 4291539104 exit 0 > > > > I have a hard time believing that took 4291 seconds. > > > > On Thu, Oct 11, 2018 at 10:11 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com> wrote: > > Hi Aaron, > > PFA the console log for your reference. > > Please look into this and provide feedback. > > Thanks, > Antony > > -----Original Message----- > From: Aaron Durbin [mailto:adurbin@google.com] > Sent: Thursday, October 11, 2018 7:27 PM > To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com> > Cc: Coreboot <coreboot(a)coreboot.org>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM> > Subject: Re: [coreboot] MRC in coreboot > > On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com> wrote: > > > > Hi All, > > > > We are able to achieve the memory initialization time reduction. Now we have achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf boot). > > > > We have reduced the unwanted codes. We would like to reduce the boot time to less than 2sec. > > > > Could anyone please tell what can be done further ? > > You're going to need to post more information (cbmem timings and console logs). > > > > > Thanks, > > Antony > > > > -----Original Message----- > > From: Aaron Durbin [mailto:adurbin@google.com] > > Sent: Wednesday, September 05, 2018 7:39 PM > > To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com> > > Cc: Coreboot <coreboot(a)coreboot.org> > > Subject: Re: [coreboot] MRC in coreboot > > > > On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com> wrote: > > > > > > Hi, > > > > > > > > > > > > We are developing coreboot for Apollo lake custom board. MRC training data save is enabled in FSP using Binary configuration tool. > > > > > > > > > > > > But we are getting logs like, > > > > > > > > > > > > No MRC cache found. > > > > > > MRC SeCUmaSize memory size from SeC ... 0 > > > > > > MRC Parameters not valid. Status is Success > > > > > > MRC:CpuMemoryTest Successful! > > > > > > Saving MRC data using CSE through HECI interface > > > > I have never seen this path used in coreboot. This line above is saying CSE is responsible for saving and retrieving training data. In coreboot we use the main processor to save and restore. I suggest reading over the UPD parameters and ensure they match with our typical use cases. BCT tool enabling 'training data save' sounds like it's enabling CSE path. > > > > > > > > Try to find MRC training data HOB. > > > > > > No MRC training data found, perform data save via HECI. > > > > > > Saved MRC training data with status (0x80000003) > > > > > > > > > > > > It seems that MRC data is not found and saved. Also I found that there are options to add MRC file path and mrc.bin in menuconfig. The only option I have is save cached MRC settings. > > > > > > > > > > > > What this mrc.bin will do? > > > > > > How to add the mrc.bin in coreboot? > > > > > > > > > > > > Please explain on this. > > > > > > > > > > > > Thanks & Regards, > > > > > > Antony > > > > > > > > > > > > L&T Technology Services Ltd > > > > > > www.LntTechservices.com > > > > > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. > > > > > > -- > > > coreboot mailing list: coreboot(a)coreboot.org > > > https://mail.coreboot.org/mailman/listinfo/coreboot > > L&T Technology Services Ltd > > > > www.LntTechservices.com<http://www.lnttechservices.com/> > > > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. > L&T Technology Services Ltd > > www.LntTechservices.com<http://www.lnttechservices.com/> > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. > > L&T Technology Services Ltd > > www.LntTechservices.com > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. > > L&T Technology Services Ltd > > www.LntTechservices.com > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

1 0

Re: [coreboot] Wired problems with Intel skylake based board
by Naresh G. Solanki 15 Oct '18

15 Oct '18

Hi, There are two things here. 1. System fails to boot i.e., hangs 2. FPGA's connected to root port are not detected in FW/OS For problem 1, can you give data on where exactly it hangs?, Is it in OS or FW ?, Can you provide kernel/coreboot log, port 80 dump when it hangs. For problem 2, Can you try setting UPD PcieRpHotPlug, & check the behaviour. reference: https://review.coreboot.org/cgit/coreboot.git/tree/src/soc/intel/skylake/ch… Can you please check FPGA datasheet & check for frequency tolerance of PCIE_CLK_REF signal from FPGA. Also can you re-verify board layout for any PDG(Platform Design Guide) violations like impedance, length matching, limits for differential PCIE_CLK_REF, PCIe Lanes. Sometimes noise generated within board can generate huge EMI. I assume high noisy circuits(power supply, backlight driver etc) are kept away from high speed PCIe signals. Regards, Naresh G Solanki On Mon, Oct 15, 2018 at 5:37 PM Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > > Am Fr., 12. Okt. 2018 um 10:15 Uhr schrieb Nico Huber <nico.h(a)gmx.de>: > > > > On 10/11/18 11:29 AM, Christian Gmeiner wrote: > > > During the last weeks I found the root cause of my problem - PCIe > > > spread spectrum > > > > > > Our FPGAs need a stable 100MHz PCIE clock to work. The used FSP config > > > thing looked > > > like this: > > > > > > void mainboard_memory_init_params(FSPM_UPD *mupd) > > > { > > > FSP_M_CONFIG *mem_cfg; > > > struct spd_block blk = { > > > .addr_map = { 0x50 }, > > > }; > > > > > > mem_cfg = &mupd->FspmConfig; > > > > > > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > > > mem_cfg->PchPmPciePllSsc = 0; > > > > > > ... > > > } > > > > > > With this configuration the PCIe reference clock was off more then 8% which > > > caused the system to hang during cold and warm boots. > > > > > > In the next step I removed assignment of PchPmPciePllSsc as it is documented > > > as 'No BIOS override'. With this change I got more then 1000 soft and > > > 2000 hard reboots > > > without any problem. Keep in mind we started with only 10 successful reboots. > > > > Please be more specific about the final setting of this UPD. `No BIOS > > override` is the documentation for the default value of 0xff. But is > > this set to the default in the binary? who knows... > > > > void mainboard_memory_init_params(FSPM_UPD *mupd) > { > FSP_M_CONFIG *mem_cfg; > struct spd_block blk = { > .addr_map = { 0x50 }, > }; > > mem_cfg = &mupd->FspmConfig; > > /* Disable PCIe Spread Spectrum Clocking */ > printk(BIOS_ERR, "PegDisableSpreadSpectrumClocking: %x\n", > mem_cfg->PegDisableSpreadSpectrumClocking); > printk(BIOS_ERR, "PchPmPciePllSsc: %x\n", mem_cfg->PchPmPciePllSsc); > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > > get_spd_smbus(&blk); > dump_spd_info(&blk); > assert(blk.spd_array[0][0] != 0); > > mainboard_fill_dq_map_data(&mem_cfg->DqByteMapCh0); > mainboard_fill_dqs_map_data(&mem_cfg->DqsMapCpu2DramCh0); > mainboard_fill_rcomp_res_data(&mem_cfg->RcompResistor); > mainboard_fill_rcomp_strength_data(&mem_cfg->RcompTarget); > > mem_cfg->DqPinsInterleaved = TRUE; > mem_cfg->MemorySpdDataLen = blk.len; > mem_cfg->MemorySpdPtr00 = (uintptr_t) blk.spd_array[0]; > } > > And here is the output taken from cbmem -1: > > .. > FMAP: base = ff000000 size = 1000000 #areas = 4 > FMAP: area RW_MRC_CACHE found @ a50000 (65536 bytes) > MRC: no data in 'RW_MRC_CACHE' > PegDisableSpreadSpectrumClocking: 0 > PchPmPciePllSsc: ff > SPD @ 0x50 > SPD: module type is DDR4 > .. > > > > > > > The big problem is that PegDisableSpreadSpectrumClocking has no effect > > > at all. I measured > > > the freq it is not the 100MHz as expected. And I need to have a stable > > > 100MHz this clock source > > > is used internally by the FPGA to drive internal clocks. The end > > > results is that EtherCAT is not > > > able to sync. > > > > This setting is about a different clock, I guess. Can you please clarify > > what is connected to which clock on your board. > > > > Our FPGAs are using the 100 MHz PCIe clock as input to drive internal > clocks etc. One > of these clock is used for EtherCAT. If spread spectrum is active we > are around 100 MHz > (worst measured freq was ~92 MHz) and as a result the internal FPGA clock is not > stable/reliable --> EtherCAT sync fails. > > If I use the following pattern: > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > mem_cfg->PchPmPciePllSsc = 0; > > I get a stable 100 MHz PCIe clock signal and everything works - except > the device hangs > after < 10 warm reboots. Looks like PCIe link training fails > uncountable times (seen with protocol > analyzer). > > -- > greets > -- > Christian Gmeiner, MSc > > https://christian-gmeiner.info > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- Best regards, Naresh G. Solanki

1 0

Re: [coreboot] MRC in coreboot
by Antony AbeePrakash X V 15 Oct '18

15 Oct '18

Hi Aron, I have tried giving iomem=relaxed to the kernel command line. But still I am getting the same error. This time I tried with verbose option and the output is below $ ./cbmem -V -t Looking for coreboot table at 0 1048576 bytes. Mapping 1MB of physical memory at 0x0 (requested 0x0). Unmapping 1MB of virtual memory at 0x7fd372347000. Looking for coreboot table at f0000 1048576 bytes. Mapping 1MB of physical memory at 0xf0000 (requested 0xf0000). ... failed. Mapping 1052671B of physical memory at 0xef000. Failed to mmap /dev/mem: Operation not permitted Also could you please tell any method to measure the boot time ? Currently we are measuring with the help of stop watch which may not accurate. Thanks, Antony From: Aaron Durbin [mailto:adurbin@google.com] Sent: Friday, October 12, 2018 7:12 PM To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com> Cc: Coreboot <coreboot(a)coreboot.org>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM> Subject: Re: [coreboot] MRC in coreboot On Fri, Oct 12, 2018 at 4:38 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com<mailto:AntonyAbee.PrakashXV@lnttechservices.com>> wrote: Hi Aron, I am not able to get the cbmem timestamps. I am using cbmem utility to find the timestamps. $ . /cbmem -t The above command gives the following error. Failed to mmap /dev/mem : Operation not permitted Could you please help on this? https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/kernel-parameters.html Adding 'iomem=relaxed' to the kernel cmdline would fix that particular problem. Note, with that current error, that you should see a PAT error in dmesg. Thanks & Regards, Antony From: Aaron Durbin [mailto:adurbin@google.com<mailto:adurbin@google.com>] Sent: Thursday, October 11, 2018 9:44 PM To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com<mailto:AntonyAbee.PrakashXV@LntTechservices.com>> Cc: Coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM<mailto:DINESHKUMAR.VARADARAJAN@LNTTECHSERVICES.COM>> Subject: Re: [coreboot] MRC in coreboot cbmem timstamps will be needed. Looks like FSP is manipulating the tsc: BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 4291539104 exit 0 I have a hard time believing that took 4291 seconds. On Thu, Oct 11, 2018 at 10:11 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com<mailto:AntonyAbee.PrakashXV@lnttechservices.com>> wrote: Hi Aaron, PFA the console log for your reference. Please look into this and provide feedback. Thanks, Antony -----Original Message----- From: Aaron Durbin [mailto:adurbin@google.com<mailto:adurbin@google.com>] Sent: Thursday, October 11, 2018 7:27 PM To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com<mailto:AntonyAbee.PrakashXV@LntTechservices.com>> Cc: Coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>>; Dinesh Kumar <DINESHKUMAR.VARADARAJAN(a)LNTTECHSERVICES.COM<mailto:DINESHKUMAR.VARADARAJAN@LNTTECHSERVICES.COM>> Subject: Re: [coreboot] MRC in coreboot On Thu, Oct 11, 2018 at 3:24 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com<mailto:AntonyAbee.PrakashXV@lnttechservices.com>> wrote: > > Hi All, > > We are able to achieve the memory initialization time reduction. Now we have achieved the boot time as 5sec until the Postcode 0xf8 (entry into Elf boot). > > We have reduced the unwanted codes. We would like to reduce the boot time to less than 2sec. > > Could anyone please tell what can be done further ? You're going to need to post more information (cbmem timings and console logs). > > Thanks, > Antony > > -----Original Message----- > From: Aaron Durbin [mailto:adurbin@google.com<mailto:adurbin@google.com>] > Sent: Wednesday, September 05, 2018 7:39 PM > To: Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)LntTechservices.com<mailto:AntonyAbee.PrakashXV@LntTechservices.com>> > Cc: Coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>> > Subject: Re: [coreboot] MRC in coreboot > > On Wed, Sep 5, 2018 at 8:06 AM Antony AbeePrakash X V <AntonyAbee.PrakashXV(a)lnttechservices.com<mailto:AntonyAbee.PrakashXV@lnttechservices.com>> wrote: > > > > Hi, > > > > > > > > We are developing coreboot for Apollo lake custom board. MRC training data save is enabled in FSP using Binary configuration tool. > > > > > > > > But we are getting logs like, > > > > > > > > No MRC cache found. > > > > MRC SeCUmaSize memory size from SeC ... 0 > > > > MRC Parameters not valid. Status is Success > > > > MRC:CpuMemoryTest Successful! > > > > Saving MRC data using CSE through HECI interface > > I have never seen this path used in coreboot. This line above is saying CSE is responsible for saving and retrieving training data. In coreboot we use the main processor to save and restore. I suggest reading over the UPD parameters and ensure they match with our typical use cases. BCT tool enabling 'training data save' sounds like it's enabling CSE path. > > > > > Try to find MRC training data HOB. > > > > No MRC training data found, perform data save via HECI. > > > > Saved MRC training data with status (0x80000003) > > > > > > > > It seems that MRC data is not found and saved. Also I found that there are options to add MRC file path and mrc.bin in menuconfig. The only option I have is save cached MRC settings. > > > > > > > > What this mrc.bin will do? > > > > How to add the mrc.bin in coreboot? > > > > > > > > Please explain on this. > > > > > > > > Thanks & Regards, > > > > Antony > > > > > > > > L&T Technology Services Ltd > > > > www.LntTechservices.com<http://www.LntTechservices.com> > > > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> > > https://mail.coreboot.org/mailman/listinfo/coreboot > L&T Technology Services Ltd > > www.LntTechservices.com<http://www.LntTechservices.com><http://www.lnttechservices.com/> > > This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. L&T Technology Services Ltd www.LntTechservices.com<http://www.LntTechservices.com><http://www.lnttechservices.com/> This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. L&T Technology Services Ltd www.LntTechservices.com<http://www.lnttechservices.com/> This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. L&T Technology Services Ltd www.LntTechservices.com<http://www.lnttechservices.com/> This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

1 0

Re: [coreboot] Wired problems with Intel skylake based board
by Nico Huber 15 Oct '18

15 Oct '18

On 10/11/18 11:29 AM, Christian Gmeiner wrote: > During the last weeks I found the root cause of my problem - PCIe > spread spectrum > > Our FPGAs need a stable 100MHz PCIE clock to work. The used FSP config > thing looked > like this: > > void mainboard_memory_init_params(FSPM_UPD *mupd) > { > FSP_M_CONFIG *mem_cfg; > struct spd_block blk = { > .addr_map = { 0x50 }, > }; > > mem_cfg = &mupd->FspmConfig; > > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > mem_cfg->PchPmPciePllSsc = 0; > > ... > } > > With this configuration the PCIe reference clock was off more then 8% which > caused the system to hang during cold and warm boots. > > In the next step I removed assignment of PchPmPciePllSsc as it is documented > as 'No BIOS override'. With this change I got more then 1000 soft and > 2000 hard reboots > without any problem. Keep in mind we started with only 10 successful reboots. Please be more specific about the final setting of this UPD. `No BIOS override` is the documentation for the default value of 0xff. But is this set to the default in the binary? who knows... > > The big problem is that PegDisableSpreadSpectrumClocking has no effect > at all. I measured > the freq it is not the 100MHz as expected. And I need to have a stable > 100MHz this clock source > is used internally by the FPGA to drive internal clocks. The end > results is that EtherCAT is not > able to sync. This setting is about a different clock, I guess. Can you please clarify what is connected to which clock on your board. Nico

2 1

Re: [coreboot] Watchdog timer (WDT) support on Kabylake w/FSP2.0
by Solanki, Naresh 15 Oct '18

15 Oct '18

Can you please check with patch: https://review.coreboot.org/c/coreboot/+/29108 Make sure that mainboard devicetree.cb has PmTimerDisabled=0 for TCO to work. Thanks, Naresh G Solanki On Wed, Oct 10, 2018 at 11:07 PM Matt DeVillier <matt.devillier(a)gmail.com> wrote: > > greetings! I'm trying to enable WDT support for Kabylake Chromeboxes > (google/fizz) but not having any luck. The current SoC code doesn't > expose the FSP fields which appear to control this (WdtDisableAndLock, > WatchDog, WatchDogTimerOS, WatchDogTimerBIOS), so I added them to > chip_fsp20.c and set them accordingly in devicetree (though it's > unclear what the values of WatchDogTimerOS/WatchDogTimerBIOS are to > be, the documentation doesn't state if this is a timeout value, units, > etc). Still, I'm unable to remotely trigger a reset via > /dev/watchdog0. > > Has anyone else used this feature, or have any insight as to the > proper FSP settings? AIUI this works properly on older non-FSP > Chromeboxes (Haswell/Broadwell) > > cheers, > Matt > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
by Jose Trujillo 15 Oct '18

15 Oct '18

Zvika: In my experience with my Baytrail system I can tell you my system is "really" memory down because has soldered memory chips on the motherboard BUT has also a soldered SPD memory so, if keep "Enable Memory Down = Disabled" in BCT the system fetch memory timings from SPD so, no need to edit memory timings but other things like "DRAM Speed" and "DRAM Type" and other settings (not timings) needs to be edited. but if still needed to edit timings extract them from SPD with "i2c-tools-perl".... I alredy sent you this information in previous emails and attachments so, look for this..... Good luck, Jose. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 12, 2018 7:29 PM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hello, > > The BCT has a "Memory Down" section. > Can you please advise how can I know the right values for my board ? > > DIMM 0/1 Enable: > DIMM DWidth: > DIMM Density: > DIMM_BusWidth: > DIMM Sides: > tCL: > tRP_tRCD: > tWR: > tWTR: > tRRD: > tRTP: > tFAW: > > Thank you in advance, > Zvika > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

What determines PCI-e capabilities per chipset in coreboot? (ie: pcie register space)
by Taiidan＠gmx.com 14 Oct '18

14 Oct '18

What I want to do is fix the SR5690/SR56xx capabilities list to reflect what is actually documented rather than what currently functions. It is lacking ARI, ATS and a few other things although it has ACS I am not sure exactly what enables it at the moment either coreboot or quirked in linux.

1 0

Re: [coreboot] Source code for "Intel Firmware"
by Philipp Stanner 14 Oct '18

14 Oct '18

Am Samstag, den 13.10.2018, 10:27 -0700 schrieb ron minnich: > good summary. > > The most security critical code gets the least attention and no > external security review. > > If this sounds crazy, well ... it is. I honestly don't think that matters at all. Worrying about crappy BIOS code while a real time surveilance tool like the IME is on the system is like complaining about missing sweets on a sinking ocean liner.

2 1

Re: [coreboot] Source code for "Intel Firmware"
by Philipp Stanner 13 Oct '18

13 Oct '18

Am Samstag, den 06.10.2018, 07:50 +0300 schrieb Zvi Vered: > Currently, in order to replace vendor's BIOS we must take binary > parts > of the original bin file and then stitch it to coreboot.rom built > with > the coreboot project. Well, exactly. Why do you think that is? Intel won't give you or anyone that code. Their policy seems to be to hide as much source code as possible. I don't know why they contribute so much to the Linux Kernel, though… > I want to depend only on Intel. ? You do depend on Intel. You depend on them not doing awkward stuff on their machines (what they clearly do, running Minix within the whole "BIOS").

4 8

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

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 October 2018