coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

Re: [coreboot] SPI controller and Lock bits
by Sam Kuper 17 Oct '18

17 Oct '18

Hi Youness, On 15/10/2018, Youness Alaoui <kakaroto(a)kakaroto.homelinux.net> wrote: > One thing to note is that this week will be my last week at Purism as > I'm going on sabbatical for a few months, and I may or may not (most > likely won't) come back to Purism in a few months. Thank you for your efforts to make Coreboot work on the Librems, and for the enthusiasm you displayed here in the mailing list and on the Purism blog. Although I might have sounded critical on occasion, this was never personal; it was always out of a concern to avoid missing opportunities to achieve the most secure and privacy-protecting machines available within the constraints of the hardware and the business model. I.e. my "criticisms" were always intended to be constructive. I hope that they did not form any part of your decision to take a break from Purism, and if they did, I apologise. I wish you a good sabbatical, in any case. > @Sam > for 90% of the users, they would either : > - never [flash the ROM] > - only do it when a new update is released and interests them, i.e: > once or twice a year. > So [...] it would be far > from annoying to users since most won't care or notice that all that > is needed, and if they do, they won't care to have to do it so rarely. I fear that even performed rarely, it might be beyond some users' abilities. But... > It will however, especially with cover-opening protections (either > using glitter/whatever methods on screws to notice if they'd been > opened, or with an EC handling a cover switch notification), that > could be very helpful to increase their security. ... I agree that making it tamper-evident is indeed potentially valuable. >> Your assumption fails against a BadHeads attack. > Yes indeed, I wrote a proof of concept which was a Heads that would > extend PCRs with the same values that coreboot did (and have a > coreboot with measured boot disabled) and it passed the TOTP > authentication. Many thanks for confirming this to the mailing list. I was hoping to write and somehow disseminate (e.g. to the Heads developers) a POC myself, but I'm glad to be spared that need. If you could send your POC to the Heads team for integration into the test suite, that would be great. This flaw in Heads needs to be fixed (if it hasn't already been). Having the POC in the test suite would also help to detect future regressions, once the issue is fixed (if it *can* be fixed). If it hasn't yet been fixed... Thinking aloud: as a community, we need to find a way (or else, determine that it really is impossible) to achieve robust mutual authentication between PC and user, with just an SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token. Some kind of formal verification might be in order. > That's something that other possible solutions would > try to mitigate (such as vboot I think). In the open world, vboot does seem to be the state of the art. Apple's T2 chip might also mitigate against this sort of thing, although it does not authenticate to the user via TOTP: the check is implicit rather than explicit. I may be wrong, though. Public documentation seems to be scarce. >> it would be great if Purism could be >> sure not only to spec, but also to list on the Librem specification >> pages on the website, a SPI flash ROM chip that *does* obey its >> write-protect pin regardless of firmware. Thanks :) > I didn't realize that "some chips don't obey the write-protect pin", > but rather my understanding is that the write protect pin is there to > say "the protected blocks are protected/not-protected according to > hardware. > The SPI flash (according to the datasheets I've read) can protect > regions either with "don't protect" or "protected by WP#" or > "protected until power-cycle". > The status register bits can be written to either as volatile or > non-volatile (for non volatile, you need another command iirc, and you > can't do it with hardware sequencing, same for the 'protect until > power cycle', which also needs to write to status-register-2 which > can't be done with hardware sequencing either). > So, really, a flash rom chip does obey its WP pin, it just depends on > how it's set. Thanks for this. I clearly need to spend more time reading data sheets and running tests on SPI flash ROM chips. All best, Sam

1 0

Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
by Zvi Vered 16 Oct '18

16 Oct '18

Hi Jose, In menuconfig I have the following options in "Include CPU microcode in CBFS" 1. Generate from tree (current selection) 2. Include external microcode header files 3. Do not include microcode updates I downloaded the file: microcode-20180807a.tgz The output of /proc/cpuinfo is: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 55 model name : Intel(R) Atom(TM) CPU E3845 @ 1.91GHz stepping : 9 microcode : 0x90a ... But the folder intel-ucode has no file named: 06-55-09 Does it mean that my CPU does not require micocode ? Thank you in advance, Zvika On Tue, Oct 16, 2018 at 8:49 AM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Good day Zvika: > > Looks typical the configuration > But for DIMM Density to get this information you should run the command I > told you yesterday or check the memory chip datasheet. > > About the 0xCE postcode you need to set the microcode (or the correct one, > or the correct path) in menuconfig. > > Jose. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, October 16, 2018 6:41 AM, Zvi Vered <veredz72(a)gmail.com> > wrote: > > Hi Jose, All, > > According to the following outputs, it seems my target has SPD EEPROM. > If I understand correctly from your reply, I should modify only: > DRAM Type: DDR3 > DRAM Speed: 1333 MT/s > DIMM 0 Enable: Enabled > DIMM 1 Enable: Disabled > DIMM_DWidth: x8 > DIMM_Density: ??? (Default is 2Gbit) > DIMM_BusWidth: 64 > DIMM_Sides: 1 Ranks > > Am I right ? > > I tried booting the target with the modified FSP and got post code : 0xCE > There is nothing on the 232 console. > There is no such post code in coreboot code. > Is it possible that FSP is sending post code ? > How can I proceed from here? > > Thank you very much, > Zvika > > ********************************** sensors-detect > **************************************** > .... > Probing for `SPD EEPROM'... Yes > (confidence 8, not a hardware monitoring chip) > ..... > ********************************** dmidecode > *************************************** > ..... > Handle 0x0009, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0008 > Error Information Handle: Not Provided > Total Width: 72 bits > Data Width: 64 bits > Size: 4096 MB > Form Factor: SODIMM > Set: None > Locator: DIMM0 > Bank Locator: BANK 0 > Type: DDR3 > Type Detail: Synchronous > Speed: 1333 MHz > Manufacturer: 00 > Serial Number: 00000000 > Asset Tag: Unknown > Part Number: > Rank: Unknown > Configured Clock Speed: 1333 MHz > > Handle 0x000B, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0008 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: No Module Installed > Form Factor: SODIMM > Set: None > Locator: DIMM1 > Bank Locator: BANK 1 > Type: Unknown > Type Detail: None > Speed: Unknown > Manufacturer: Not Specified > Serial Number: Not Specified > Asset Tag: Unknown > Part Number: Not Specified > Rank: Unknown > Configured Clock Speed: Unknown > .... > > *******************************************decode-dimms************************************** > # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) > > Memory Serial Presence Detect Decoder > By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, > Jean Delvare, Trent Piepho and others > > > Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/8-0050 > Guessing DIMM is in bank 1 > > ---=== SPD EEPROM Information ===--- > EEPROM CRC of bytes 0-116 OK (0x59A6) > # of bytes written to SDRAM EEPROM 176 > Total number of bytes in EEPROM 256 > Fundamental Memory type DDR3 SDRAM > Module Type 72b-SO-UDIMM > > ---=== Memory Characteristics ===--- > Fine time base 1.000 ps > Medium time base 0.125 ns > Maximum module speed 1333 MHz (PC3-10600) > Size 4096 MB > Banks x Rows x Columns x Bits 8 x 16 x 10 x 64 > Ranks 1 > SDRAM Device Width 8 bits > Bus Width Extension 8 bits > tCL-tRCD-tRP-tRAS 9-9-9-24 > Supported CAS Latencies (tCL) 10T, 9T, 8T, 7T, 6T > > ---=== Timing Parameters ===--- > Minimum Write Recovery time (tWR) 15.000 ns > Minimum Row Active to Row Active Delay (tRRD) 6.000 ns > Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns > Minimum Recovery Delay (tRFC) 260.000 ns > Minimum Write to Read CMD Delay (tWTR) 7.500 ns > Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns > Minimum Four Activate Window Delay (tFAW) 30.000 ns > > ---=== Optional Features ===--- > Operable voltages 1.5V, 1.35V > RZQ/6 supported? Yes > RZQ/7 supported? Yes > DLL-Off Mode supported? Yes > Operating temperature range 0-95 degrees C > Refresh Rate in extended temp range 1X > Auto Self-Refresh? No > On-Die Thermal Sensor readout? No > Partial Array Self-Refresh? No > Thermal Sensor Accuracy Not implemented > SDRAM Device Type Standard Monolithic > > ---=== Manufacturer Data ===--- > Module Manufacturer Invalid > Part Number Undefined > > > Number of SDRAM DIMMs detected and decoded: 1 > > ************************************************************************************************* > > On Mon, Oct 15, 2018 at 9:43 AM Jose Trujillo <ce.autom(a)protonmail.com> > wrote: > >> 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

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

16 Oct '18

On 10/16/18 9:46 AM, Christian Gmeiner wrote: > Am Mo., 15. Okt. 2018 um 15:26 Uhr schrieb Naresh G. Solanki > <naresh.solanki.2011(a)gmail.com>: >> 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. > > It only hangs If I change the following values: > > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > mem_cfg->PchPmPciePllSsc = 0; > > The 'physical' cause for the hang is also known: PLT_RST# never gets > high again. There are chances > that it does not hang but PCI devices (sata, usb hc, ...) are not > working as expected as the PCe reference clock > is in such a case at around 92 Mhz. You said earlier that you can dump (but not change) the ICC settings, right? Did you check what settings are made with PchPmPciePllSsc == 0? If FSP ends up enabling it with a value of 0, I could imagine that this is just unexpected / the result undefined. Did you try other values than 0? 1? I guess the value gives a percentage of a percentage; 0.01% down- spread is probably not too bad. And maybe somebody with access to the FSP source can document what it does and if there is a switch (missing) to disabled it ;) Nico

1 0

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

16 Oct '18

On 10/16/18 11:42 AM, Christian Gmeiner wrote: > Am Di., 16. Okt. 2018 um 11:25 Uhr schrieb Peter Stuge <peter(a)stuge.se>: >> >> Christian Gmeiner wrote: >>> The system does not hang if I only change >>> >>> mem_cfg->PegDisableSpreadSpectrumClocking = 1; >>> >>> But it has no effect on the PCIe reference clock and it looks like >>> spread spectrum is still used. >> >> AFAIK Peg refers to PCI Express Graphics. Maybe there's another, >> per-port, setting? >> > > Could be but and the comment is about this variable is wrong: > https://github.com/coreboot/coreboot/blob/f3122426b851b9ca009e501a8d8c60d06… Why wrong? It just doesn't tell for what clock source it is. Or clock input? even that's not clear to me. But I agree that it doesn't seem to apply in your case. PEG is PCIe too, but not a feature of your SKU, AFAICT. Nico

1 0

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

16 Oct '18

Hi, A1. PLTRST# not getting de-asserted might be a separate issue. I recommend you debug power on sequence & find the exact point of failures like powerok, VR stability(check for over/undervoltage) near SoC. A2. Do same VR's provide power to FPGA & there is no power shortage ? B1. SoC is clocked by external crystal, Can you please check Crystal OSC frequency, accuracy/deviation from expected values. I'm guessing that the external crystal frequency is around 8% lower than expected levels. B2. If possible provide waveform of external crystal & clksrc Regards, Naresh G Solanki On Tue, Oct 16, 2018 at 3:13 PM Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > > Am Di., 16. Okt. 2018 um 11:25 Uhr schrieb Peter Stuge <peter(a)stuge.se>: > > > > Christian Gmeiner wrote: > > > The system does not hang if I only change > > > > > > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > > > > > > But it has no effect on the PCIe reference clock and it looks like > > > spread spectrum is still used. > > > > AFAIK Peg refers to PCI Express Graphics. Maybe there's another, > > per-port, setting? > > > > Could be but and the comment is about this variable is wrong: > https://github.com/coreboot/coreboot/blob/f3122426b851b9ca009e501a8d8c60d06… > > -- > 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] Wired problems with Intel skylake based board
by Peter Stuge 16 Oct '18

16 Oct '18

Christian Gmeiner wrote: > The system does not hang if I only change > > mem_cfg->PegDisableSpreadSpectrumClocking = 1; > > But it has no effect on the PCIe reference clock and it looks like > spread spectrum is still used. AFAIK Peg refers to PCI Express Graphics. Maybe there's another, per-port, setting? //Peter

2 1

Re: [coreboot] MRC in coreboot
by Peter Stuge 16 Oct '18

16 Oct '18

Antony AbeePrakash X V wrote: > This time I tried with verbose option and the output is below > $ ./cbmem -V -t .. > Failed to mmap /dev/mem: Operation not permitted You have to run that command as root. Regular users are not allowed arbitrary access to memory. //Peter

1 0

Re: [coreboot] Wired problems with Intel skylake based board
by Christian Gmeiner 16 Oct '18

16 Oct '18

Hi Am Mo., 15. Okt. 2018 um 15:26 Uhr schrieb Naresh G. Solanki <naresh.solanki.2011(a)gmail.com>: > > Hi, > > There are two things here. > 1. System fails to boot i.e., hangs Correct. > 2. FPGA's connected to root port are not detected in FW/OS Wrong. The FPGAs are detected correctly and work most of the time. The only problem we have is that the PCIe reference clock is not 100MHz as spread spectrum is activated. This causes that the internal clock used for EtherCAT ist not reliable which has the result that we fail to sync with EtherCAT clients and there no communication over EtherCAT works. > > 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. It only hangs If I change the following values: mem_cfg->PegDisableSpreadSpectrumClocking = 1; mem_cfg->PchPmPciePllSsc = 0; The 'physical' cause for the hang is also known: PLT_RST# never gets high again. There are chances that it does not hang but PCI devices (sata, usb hc, ...) are not working as expected as the PCe reference clock is in such a case at around 92 Mhz. The end goal is to disable PCIe Spread Specturm and get a constant PCIe reference clock of 100MHz. The system does not hang if I only change mem_cfg->PegDisableSpreadSpectrumClocking = 1; But it has no effect on the PCIe reference clock and it looks like spread spectrum is still used. > 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 -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info

1 0

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

16 Oct '18

Good day Zvika: Looks typical the configuration But for DIMM Density to get this information you should run the command I told you yesterday or check the memory chip datasheet. About the 0xCE postcode you need to set the microcode (or the correct one, or the correct path) in menuconfig. Jose. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, October 16, 2018 6:41 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > Hi Jose, All, > > According to the following outputs, it seems my target has SPD EEPROM. > If I understand correctly from your reply, I should modify only: > DRAM Type: DDR3 > DRAM Speed: 1333 MT/s > DIMM 0 Enable: Enabled > DIMM 1 Enable: Disabled > DIMM_DWidth: x8 > DIMM_Density: ??? (Default is 2Gbit) > DIMM_BusWidth: 64 > DIMM_Sides: 1 Ranks > > Am I right ? > > I tried booting the target with the modified FSP and got post code : 0xCE > There is nothing on the 232 console. > There is no such post code in coreboot code. > Is it possible that FSP is sending post code ? > How can I proceed from here? > > Thank you very much, > Zvika > > ********************************** sensors-detect **************************************** > .... > Probing for `SPD EEPROM'... Yes > (confidence 8, not a hardware monitoring chip) > ..... > ********************************** dmidecode *************************************** > ..... > Handle 0x0009, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0008 > Error Information Handle: Not Provided > Total Width: 72 bits > Data Width: 64 bits > Size: 4096 MB > Form Factor: SODIMM > Set: None > Locator: DIMM0 > Bank Locator: BANK 0 > Type: DDR3 > Type Detail: Synchronous > Speed: 1333 MHz > Manufacturer: 00 > Serial Number: 00000000 > Asset Tag: Unknown > Part Number: > Rank: Unknown > Configured Clock Speed: 1333 MHz > > Handle 0x000B, DMI type 17, 34 bytes > Memory Device > Array Handle: 0x0008 > Error Information Handle: Not Provided > Total Width: Unknown > Data Width: Unknown > Size: No Module Installed > Form Factor: SODIMM > Set: None > Locator: DIMM1 > Bank Locator: BANK 1 > Type: Unknown > Type Detail: None > Speed: Unknown > Manufacturer: Not Specified > Serial Number: Not Specified > Asset Tag: Unknown > Part Number: Not Specified > Rank: Unknown > Configured Clock Speed: Unknown > .... > *******************************************decode-dimms************************************** > # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) > > Memory Serial Presence Detect Decoder > By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, > Jean Delvare, Trent Piepho and others > > Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/8-0050 > Guessing DIMM is in bank 1 > > ---=== SPD EEPROM Information ===--- > EEPROM CRC of bytes 0-116 OK (0x59A6) > # of bytes written to SDRAM EEPROM 176 > Total number of bytes in EEPROM 256 > Fundamental Memory type DDR3 SDRAM > Module Type 72b-SO-UDIMM > > ---=== Memory Characteristics ===--- > Fine time base 1.000 ps > Medium time base 0.125 ns > Maximum module speed 1333 MHz (PC3-10600) > Size 4096 MB > Banks x Rows x Columns x Bits 8 x 16 x 10 x 64 > Ranks 1 > SDRAM Device Width 8 bits > Bus Width Extension 8 bits > tCL-tRCD-tRP-tRAS 9-9-9-24 > Supported CAS Latencies (tCL) 10T, 9T, 8T, 7T, 6T > > ---=== Timing Parameters ===--- > Minimum Write Recovery time (tWR) 15.000 ns > Minimum Row Active to Row Active Delay (tRRD) 6.000 ns > Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns > Minimum Recovery Delay (tRFC) 260.000 ns > Minimum Write to Read CMD Delay (tWTR) 7.500 ns > Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns > Minimum Four Activate Window Delay (tFAW) 30.000 ns > > ---=== Optional Features ===--- > Operable voltages 1.5V, 1.35V > RZQ/6 supported? Yes > RZQ/7 supported? Yes > DLL-Off Mode supported? Yes > Operating temperature range 0-95 degrees C > Refresh Rate in extended temp range 1X > Auto Self-Refresh? No > On-Die Thermal Sensor readout? No > Partial Array Self-Refresh? No > Thermal Sensor Accuracy Not implemented > SDRAM Device Type Standard Monolithic > > ---=== Manufacturer Data ===--- > Module Manufacturer Invalid > Part Number Undefined > > Number of SDRAM DIMMs detected and decoded: 1 > ************************************************************************************************* > > On Mon, Oct 15, 2018 at 9:43 AM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > >> 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

Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
by Zvi Vered 16 Oct '18

16 Oct '18

Hi Jose, All, According to the following outputs, it seems my target has SPD EEPROM. If I understand correctly from your reply, I should modify only: DRAM Type: DDR3 DRAM Speed: 1333 MT/s DIMM 0 Enable: Enabled DIMM 1 Enable: Disabled DIMM_DWidth: x8 DIMM_Density: ??? (Default is 2Gbit) DIMM_BusWidth: 64 DIMM_Sides: 1 Ranks Am I right ? I tried booting the target with the modified FSP and got post code : 0xCE There is nothing on the 232 console. There is no such post code in coreboot code. Is it possible that FSP is sending post code ? How can I proceed from here? Thank you very much, Zvika ********************************** sensors-detect **************************************** .... Probing for `SPD EEPROM'... Yes (confidence 8, not a hardware monitoring chip) ..... ********************************** dmidecode *************************************** ..... Handle 0x0009, DMI type 17, 34 bytes Memory Device Array Handle: 0x0008 Error Information Handle: Not Provided Total Width: 72 bits Data Width: 64 bits Size: 4096 MB Form Factor: SODIMM Set: None Locator: DIMM0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Speed: 1333 MHz Manufacturer: 00 Serial Number: 00000000 Asset Tag: Unknown Part Number: Rank: Unknown Configured Clock Speed: 1333 MHz Handle 0x000B, DMI type 17, 34 bytes Memory Device Array Handle: 0x0008 Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: SODIMM Set: None Locator: DIMM1 Bank Locator: BANK 1 Type: Unknown Type Detail: None Speed: Unknown Manufacturer: Not Specified Serial Number: Not Specified Asset Tag: Unknown Part Number: Not Specified Rank: Unknown Configured Clock Speed: Unknown .... *******************************************decode-dimms************************************** # decode-dimms version 6231 (2014-02-20 10:54:34 +0100) Memory Serial Presence Detect Decoder By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner, Jean Delvare, Trent Piepho and others Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/8-0050 Guessing DIMM is in bank 1 ---=== SPD EEPROM Information ===--- EEPROM CRC of bytes 0-116 OK (0x59A6) # of bytes written to SDRAM EEPROM 176 Total number of bytes in EEPROM 256 Fundamental Memory type DDR3 SDRAM Module Type 72b-SO-UDIMM ---=== Memory Characteristics ===--- Fine time base 1.000 ps Medium time base 0.125 ns Maximum module speed 1333 MHz (PC3-10600) Size 4096 MB Banks x Rows x Columns x Bits 8 x 16 x 10 x 64 Ranks 1 SDRAM Device Width 8 bits Bus Width Extension 8 bits tCL-tRCD-tRP-tRAS 9-9-9-24 Supported CAS Latencies (tCL) 10T, 9T, 8T, 7T, 6T ---=== Timing Parameters ===--- Minimum Write Recovery time (tWR) 15.000 ns Minimum Row Active to Row Active Delay (tRRD) 6.000 ns Minimum Active to Auto-Refresh Delay (tRC) 49.125 ns Minimum Recovery Delay (tRFC) 260.000 ns Minimum Write to Read CMD Delay (tWTR) 7.500 ns Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns Minimum Four Activate Window Delay (tFAW) 30.000 ns ---=== Optional Features ===--- Operable voltages 1.5V, 1.35V RZQ/6 supported? Yes RZQ/7 supported? Yes DLL-Off Mode supported? Yes Operating temperature range 0-95 degrees C Refresh Rate in extended temp range 1X Auto Self-Refresh? No On-Die Thermal Sensor readout? No Partial Array Self-Refresh? No Thermal Sensor Accuracy Not implemented SDRAM Device Type Standard Monolithic ---=== Manufacturer Data ===--- Module Manufacturer Invalid Part Number Undefined Number of SDRAM DIMMs detected and decoded: 1 ************************************************************************************************* On Mon, Oct 15, 2018 at 9:43 AM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > 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

← Newer
1
2
3
4
5
6
7
8
9
...
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