coreboot October 2018

coreboot@coreboot.org

53 participants
145 discussions

[AMD family16h] What need to be done in coreboot to support the Virtual Wire mode
by Zheng Bao 22 Oct '18

22 Oct '18

Hi, all, I need to support VxWorks in Virtual Wire mode. The code is stable in coreboot.org for a long time which supports Windows and Linux. I add code to set the Interrupt Line in PciConfiguration space. What else needs to be done? Zheng

1 0

F2A85M board
by kinky_nekoboi 21 Oct '18

21 Oct '18

if anybody of you has a working setup up of an F2A85M board with an addon Grahpics Card, please contact me.

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 19 Oct '18

19 Oct '18

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1396275: (ARRAY_VS_SINGLETON) /src/soc/mediatek/mt8183/emi.c: 252 in emi_init2() /src/soc/mediatek/mt8183/emi.c: 253 in emi_init2() ________________________________________________________________________________________________________ *** CID 1396275: (ARRAY_VS_SINGLETON) /src/soc/mediatek/mt8183/emi.c: 252 in emi_init2() 246 } 247 248 static void emi_init2(const struct sdram_params *params) 249 { 250 emi_esl_setting2(); 251 >>> CID 1396275: (ARRAY_VS_SINGLETON) >>> Using "&emi_mpu->mpu_ctrl_d0" as an array. This might corrupt or misinterpret adjacent memory locations. 252 setbits_le32(&emi_mpu->mpu_ctrl_d0 + 0x4 * 1, 0x1 << 4); 253 setbits_le32(&emi_mpu->mpu_ctrl_d0 + 0x4 * 7, 0x1 << 4); 254 255 write32(&emi_regs->bwct0, 0x0a000705); 256 write32(&emi_regs->bwct0_3rd, 0x0); 257 /src/soc/mediatek/mt8183/emi.c: 253 in emi_init2() 247 248 static void emi_init2(const struct sdram_params *params) 249 { 250 emi_esl_setting2(); 251 252 setbits_le32(&emi_mpu->mpu_ctrl_d0 + 0x4 * 1, 0x1 << 4); >>> CID 1396275: (ARRAY_VS_SINGLETON) >>> Using "&emi_mpu->mpu_ctrl_d0" as an array. This might corrupt or misinterpret adjacent memory locations. 253 setbits_le32(&emi_mpu->mpu_ctrl_d0 + 0x4 * 7, 0x1 << 4); 254 255 write32(&emi_regs->bwct0, 0x0a000705); 256 write32(&emi_regs->bwct0_3rd, 0x0); 257 258 /* EMI QoS 0.5 */ ** CID 1396274: Error handling issues (CHECKED_RETURN) ________________________________________________________________________________________________________ *** CID 1396274: Error handling issues (CHECKED_RETURN) /src/drivers/tpm/tpm.c: 29 in init_tpm_dev() 23 #endif 24 25 static void init_tpm_dev(void *unused) 26 { 27 #if IS_ENABLED(CONFIG_HAVE_ACPI_RESUME) 28 int s3resume = acpi_is_wakeup_s3(); >>> CID 1396274: Error handling issues (CHECKED_RETURN) >>> Calling "tpm_setup(s3resume)" without checking return value. It wraps a library function that may fail and return an error code. 29 tpm_setup(s3resume); 30 #else 31 /* This can lead to PCR reset attacks but currently there 32 is no generic way to detect resume on other platforms. */ 33 tpm_setup(false); 34 #endif 35 } 36 ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

FSP integration
by Zvi Vered 19 Oct '18

19 Oct '18

Hello, I'm using an FSP file for coreboot porting. According to Intel's "atom-e3800-fsp-integration-guide": FspInit is calling "Bus and Devices Init" NotifyPhase is calling "Boot Device Init" How can I know what initialization is required in each phase ? FSP has documented return values. I assume FSP is run by coreboot. Where can I inspect this return value ? Thank you, Zvika

1 0

Will a KCMA-D8 boot without the 8pin EPSV12 cable if you are using a 35W CPU?
by Taiidan＠gmx.com 18 Oct '18

18 Oct '18

I wish to use a picopsu with one which is why I am wondering.

2 1

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

17 Oct '18

Hi Jose, All, I built coreboot.rom with the right microcode. Following is the coreboot build summary: ******************************************************************************* Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 28660 none cpu_microcode_blob.bin 0x7100 microcode 52224 none fallback/ramstage 0x13d80 stage 62434 none config 0x231c0 raw 614 none revision 0x23480 raw 570 none cmos_layout.bin 0x23700 cmos_layout 872 none fallback/dsdt.aml 0x23ac0 raw 12528 none (empty) 0x26c00 null 1675672 none fsp.bin 0x1bfdc0 fsp 229376 none (empty) 0x1f7e00 null 30936 none bootblock 0x1ff700 bootblock 1720 none ******************************************************************************* The size of microcode is 52224 bytes. This is exactly the size of the file 06-37-09 I'm using. I also modified FSP. According to the datasheet of the board: MAIN MEMORY: Up to 4 GByte DDR3L-1333 memory down So I set: Enable Memory Down: Enabled Now the post code is 0x12F. The board has 4 digits post code display. Nothing is displayed on the RS232 terminal. Can you please advise how to proceed ? Best regards, Zvika On Wed, Oct 17, 2018 at 1:14 PM Jose Trujillo <ce.autom(a)protonmail.com> wrote: > Zvika: > The microcode you downloaded doesn't include the binary for your system... > read the release notes. > > 6, 55, 9 = 06-37-09 > > Download this: > > > https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu30679_plat0F… > > Rename this bin to: 06-37-09 > Add the path in "Microcode binary path and filename" > > And try again! > Jose > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Wednesday, October 17, 2018 12:06 AM, Zvi Vered <veredz72(a)gmail.com> > wrote: > > 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] SPI controller and Lock bits
by Youness Alaoui 17 Oct '18

17 Oct '18

On Wed, Oct 17, 2018 at 9:42 AM R S <rene.shuster(a)bcsemail.org> wrote: > > Yes, thanks Youness for all the hard work and research. You provided an exceptional service. I enjoyed your rants and explanations both on Purism's blog and here. Hopefully Purism can fill that void you are leaving behind. > Thanks! I had a lot of fun, and this community is really great! I hope we still get to work together again in the future and cross paths! > On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper <sam.kuper(a)uclmail.net> wrote: >> >> 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. >> Thanks! I understand that the criticism was never personal, and I think you all were justified in being critical as well, but then things started to change for the better in purism and it took time for people here (understandably) to see that the change was not just smoke and mirrors. I hope that with me gone, they'll find a good replacement and they'll continue working with the coreboot community and keep moving forward, instead of backward. No, you or anyone else's criticism here had zero part in my decision to leave. On the contrary, I really enjoyed working with the coreboot community, you're all very welcoming, so thanks for that! I'm leaving because I'm feeling close to a burnout, and I don't want to get stuck in one, so I dropped both Purism and a second client I had, in order to concentrate on my health and well being. The reason I might not be coming back to Purism in the future is because they have a new contract for employees/contractors which I disagree with and I'm not ready to sign. It's still a draft though so if the feedback is taken into consideration and lawyers don't reject the feedback and the final version of the contract is acceptable to me, then I might come back. We'll see what happens! :) >> >> > @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... >> Yeah, it might make someone not update if they realize they need to do that, but I guess if they'd only need to do it in order to break the root of trust and overwrite the bootblock or whatever, then that might be good. Either way, it's better than having the WP# hard wired to VCC as it is right now. >> > 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). >> Yeah, I did that a few months ago, the PoC is rather simple but would be hard to have in a test suite, I'm not sure. Basically, I did 'cbmem -c | grep -i extend" to get the log which says "extending PCR <id> with <hash>", then I rebuilt coreboot and disabled MEASURED_BOOT, then in head's init script I just added the lines : tpmcli pcr extend <id> -h <hash> (more or less, can't remember the name of the command or what arguments it needed.. I think i had to build a modified version of the tool so i can give it directly the hash to extend with instead of a message for it to hash) That's all! >> 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. >> I don't think there's a way to fix it without using some other method. Currently, having Heads block any writes to the SPI flash and only allow heads itself to update the bios after it verifies that the rom is signed correctly, that's a good solution, but of course, it will only prevent remote attacks or local software attacks. Anyone can always just open the cover and use a hardware flasher to replace everything. Hopefully with the next hardware, they'll have a way to tell users if the cover was ever opened, and make it easier for users (I'm hoping for a header) to have users verify their flash content with a hardware flasher when needed/periodically. Either way, 100% security doesn't exist in my opinion, all anyone can do is make it so difficult, it stops being worth the trouble (or force the attack to tailor his attack to a specific machine). >> >> > 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. >> I don't know, either way, in 2 days, it will be out of my hands :) I've sent Kyle a link so he can read this entire thread and figure out what needs to be done. >> >> >> 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. >> You're welcome! You can see here : https://www.winbond.com/resource-files/w25q64fw_revk%2007012016%20sfdp.pdf Pages 14 to 20. Especially figure in 7.1.7 >> All best, >> >> Sam >> Thanks, Youness.

1 0

Re: [coreboot] SPI controller and Lock bits
by R S 17 Oct '18

17 Oct '18

Yes, thanks Youness for all the hard work and research. You provided an exceptional service. I enjoyed your rants and explanations both on Purism's blog and here. Hopefully Purism can fill that void you are leaving behind. On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper <sam.kuper(a)uclmail.net> wrote: > 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 > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- Tech III * AppControl * Endpoint Protection * Server Maintenance Buncombe County Schools Technology Department Network Group ComicSans Awareness Campaign <http://comicsanscriminal.com>

1 0

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

17 Oct '18

Zvika: The microcode you downloaded doesn't include the binary for your system... read the release notes. 6, 55, 9 = 06-37-09 Download this: https://github.com/platomav/CPUMicrocodes/blob/master/Intel/cpu30679_plat0F… Rename this bin to: 06-37-09 Add the path in "Microcode binary path and filename" And try again! Jose ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, October 17, 2018 12:06 AM, Zvi Vered <veredz72(a)gmail.com> wrote: > 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] SPI controller and Lock bits
by Peter Stuge 17 Oct '18

17 Oct '18

Youness Alaoui wrote: > So, really, a flash rom chip does obey its WP pin, it just depends > on how it's set. For all flash with non-volatile status register the WP pin is irrelevant from reset until software (in same write-enabled flash) writes block protection into the status register. (Only then does the WP pin matter.) The later that status register write happens the more time there is for anything with access to the SPI bus to write to the flash. //Peter

1 0

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