[coreboot] Re: RAM without SPD
Hi Michal, Thank you very much for your help. Best regards, Zvika On Thu, Feb 21, 2019 at 10:17 AM Michal Zygowski wrote: > > On 20.02.2019 22:14, Zvi Vered wrote: > > Hi Michal, > > Hi Zvika, > > > Your detailed answer is highly appreciated ! > > The output I got on the console is: > ... > Memory Down Data Existed : Enabled > - Speed (0: 800, 1: 1066, 2: 1333, 3: 1600): 2 > - Type (0: DDR3, 1: DDR3L) : 1 > - DIMM0: Disabled > - DIMM1: Disabled > - Width: x8 > - Density : 2Gbit > - BudWidth : 64bit > - Rank # : 1 > - tCL : 0B > - tRPtRCD : 0B > - tWR : 0A > - tWTR : 05 > - tRRD : 04 > - tRTP : 05 > - tFAW : 14 > > > The file devicetree.cb contains the default settings. Few parameters are > override with the code in romstage.c > Am I right ? > > devicetree.cb can have Your target settings if You wish so. And yes, You > can override the values in mainboard's romstage.c in the > `romstage_fsp_rt_buffer_callback` function. > > I comment all the code in romstage.c but the values printed in the console > are only partially identical to the ones in devicetree.cb > Does it make sense ? > > It depends, coreboot does the default UPD values check. > > Finally - very basic question - Where is the binary file of the FSP > located ? > According to default configuration of minnowmax, no path is specified for > FSP and microcode. > But somehow they are linked in . > > Everything is in the menuconfig Chipset menu and/or Generic Drivers menu. > There You can enable inclusion of microcode and FSP binary. When enabled, > the base addresses for the blobs pop up in one or both menus. > > Some platforms have their minimal configs in the configs directory, but > some unfortunately not and one have to go through whole configuration by > himself. > > Best regards, > Zvika > > Best regards, > Michał > > > On Tue, Feb 19, 2019 at 9:29 PM Michal Zygowski > wrote: > >> >> On 2/19/19 7:50 PM, Zvi Vered wrote: >> >> Hi Michal, >> >> Thank you very much for your reply. >> >> You are right. I have soldered down memory. No dimm slot. >> In what routine should I configure RAM ? Where can I see a sample code ? >> >> coreboot has everything prepared for that. What I would do is to look at >> existing BayTrail platforms supported in coreboot (e.g. Intel Minnow Max), >> which uses FSP. As it is BayTrail it will surely be FSP1.0. >> >> >> From the RAM vendor I got the following table: >> >> Part Number Byte Number Byte Description Byte Value >> MT4KTF25664HZ-1G9P1 0 DDR3-CRC RANGE; EEPROM BYTES; BYTES USED 92 >> MT4KTF25664HZ-1G9P1 1 DDR3-SPD REVISON 13 >> MT4KTF25664HZ-1G9P1 2 DDR3-DRAM DEVICE TYPE 0B >> MT4KTF25664HZ-1G9P1 3 DDR3-MODULE TYPE (FORM FACTOR) 3 >> >> Is it possible to use FSP but not for RAM setup ? How ? >> FSP has many features which I want to use. I do not want to write all by >> myself. >> >> Great that You have found the SPD. AFAIK FSP1.0 has only one entry >> available (except TempRamInit), i.e. FspInit which initializes memory and >> silicon. It is inseparable comparing to FSP1.1 or FSP2.0, so everything has >> to be set right away from the start. FSP will always be used for RAM setup >> for BayTrail, unless You have a MRC binary. Of course there are some boards >> that do not need any blob for memory initialization, but this is out of >> scope of this topic. >> >> Most configuration settings for FSP is defined in mainboard's >> devicetree.cb file. What You would have to do in the devicetree is to set >> EnableMemoryDown option and all other memory parameters DIMM* and DRAM* >> (taken from SPD) as listed here (only example of minnowmax): >> >> https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/minnowmax/devicetree.cb#L36 >> >> You don't need to worry much about writing code, since everything is >> almost in place. Have a look at: >> src/soc/intel/fsp_baytrail/fsp/chipset_fsp_util.c and >> src/drivers/intel/fsp1_0/fsp_util.c >> >> The settings are automatically filled and FspInitApi is called with the >> parameters You set in devicetree. >> What You only need is to create a mainboard directory for Your platform >> and implement few necessary callbacks. First and foremost, coreboot is a >> framework :) >> >> >> Best regards, >> Zvika >> >> Best regards, >> Michał >> >> -- >> Michał Żygowski >> Firmware Engineerh
[coreboot] Re: RAM without SPD
Hi Michal, Your detailed answer is highly appreciated ! The output I got on the console is: ... Memory Down Data Existed : Enabled - Speed (0: 800, 1: 1066, 2: 1333, 3: 1600): 2 - Type (0: DDR3, 1: DDR3L) : 1 - DIMM0: Disabled - DIMM1: Disabled - Width: x8 - Density : 2Gbit - BudWidth : 64bit - Rank # : 1 - tCL : 0B - tRPtRCD : 0B - tWR : 0A - tWTR : 05 - tRRD : 04 - tRTP : 05 - tFAW : 14 The file devicetree.cb contains the default settings. Few parameters are override with the code in romstage.c Am I right ? I comment all the code in romstage.c but the values printed in the console are only partially identical to the ones in devicetree.cb Does it make sense ? Finally - very basic question - Where is the binary file of the FSP located ? According to default configuration of minnowmax, no path is specified for FSP and microcode. But somehow they are linked in . Best regards, Zvika On Tue, Feb 19, 2019 at 9:29 PM Michal Zygowski wrote: > > On 2/19/19 7:50 PM, Zvi Vered wrote: > > Hi Michal, > > Thank you very much for your reply. > > You are right. I have soldered down memory. No dimm slot. > In what routine should I configure RAM ? Where can I see a sample code ? > > coreboot has everything prepared for that. What I would do is to look at > existing BayTrail platforms supported in coreboot (e.g. Intel Minnow Max), > which uses FSP. As it is BayTrail it will surely be FSP1.0. > > > From the RAM vendor I got the following table: > > Part Number Byte Number Byte Description Byte Value > MT4KTF25664HZ-1G9P1 0 DDR3-CRC RANGE; EEPROM BYTES; BYTES USED 92 > MT4KTF25664HZ-1G9P1 1 DDR3-SPD REVISON 13 > MT4KTF25664HZ-1G9P1 2 DDR3-DRAM DEVICE TYPE 0B > MT4KTF25664HZ-1G9P1 3 DDR3-MODULE TYPE (FORM FACTOR) 3 > > Is it possible to use FSP but not for RAM setup ? How ? > FSP has many features which I want to use. I do not want to write all by > myself. > > Great that You have found the SPD. AFAIK FSP1.0 has only one entry > available (except TempRamInit), i.e. FspInit which initializes memory and > silicon. It is inseparable comparing to FSP1.1 or FSP2.0, so everything has > to be set right away from the start. FSP will always be used for RAM setup > for BayTrail, unless You have a MRC binary. Of course there are some boards > that do not need any blob for memory initialization, but this is out of > scope of this topic. > > Most configuration settings for FSP is defined in mainboard's > devicetree.cb file. What You would have to do in the devicetree is to set > EnableMemoryDown option and all other memory parameters DIMM* and DRAM* > (taken from SPD) as listed here (only example of minnowmax): > > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/minnowmax/devicetree.cb#L36 > > You don't need to worry much about writing code, since everything is > almost in place. Have a look at: > src/soc/intel/fsp_baytrail/fsp/chipset_fsp_util.c and > src/drivers/intel/fsp1_0/fsp_util.c > > The settings are automatically filled and FspInitApi is called with the > parameters You set in devicetree. > What You only need is to create a mainboard directory for Your platform > and implement few necessary callbacks. First and foremost, coreboot is a > framework :) > > > Best regards, > Zvika > > Best regards, > Michał > > -- > Michał Żygowski > Firmware Engineerhttp://3mdeb.com | @3mdeb_com > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 4.9: FSP debug level (0-3)
Hi Wim, Thank you very much for your reply. Best regards. Zvika On Wed, Feb 20, 2019 at 10:14 AM Wim Vervoorn wrote: > Hello Zvi, > > > > The Baytrail FSP doesn’t support the debug levels. > > > > So unfortunately this will not help you. > > > > Most likely your issue is in the memory configuration. What you can do is > have a look at the port 80 codes. This provides an indication of where the > problem is in the FSP. > > > > Best regards, > > > Wim Vervoorn > > > > > > *From:* Zvi Vered [mailto:vered...@gmail.com] > *Sent:* Saturday, February 9, 2019 12:24 PM > *To:* coreboot@coreboot.org > *Subject:* [coreboot] 4.9: FSP debug level (0-3) > > > > Helllo, > > > > I'm porting core boot to a bay trail board. > > > > I noticed that starting from version 4.9, I can set the debug level of > FSP. > > > > I downloaded FSP for Bay trail and used Intel's BCT to modify it. > > But coreboot hangs after calling to the FSP binary. > > > > How can I use the "FSP debug level" ? > > > > Thank you, > > Zvika > > > > > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: RAM without SPD
Hi Michal, Thank you very much for your reply. You are right. I have soldered down memory. No dimm slot. In what routine should I configure RAM ? Where can I see a sample code ? >From the RAM vendor I got the following table: Part Number Byte Number Byte Description Byte Value MT4KTF25664HZ-1G9P1 0 DDR3-CRC RANGE; EEPROM BYTES; BYTES USED 92 MT4KTF25664HZ-1G9P1 1 DDR3-SPD REVISON 13 MT4KTF25664HZ-1G9P1 2 DDR3-DRAM DEVICE TYPE 0B MT4KTF25664HZ-1G9P1 3 DDR3-MODULE TYPE (FORM FACTOR) 3 Is it possible to use FSP but not for RAM setup ? How ? FSP has many features which I want to use. I do not want to write all by myself. Best regards, Zvika On Tue, Feb 19, 2019 at 12:27 PM Michal Zygowski wrote: > On 18.02.2019 20:28, Zvi Vered wrote: > > Hello, > > Hi Zvika, > > > I suspect the RAM on my bay-trail module has no SPD interface. > Can Intel's FSP work without SPD ? > > I tried to run decode-dimms with vendor's bios and got: > No EEPROM found, try loading the eeprom or at24 module > > It looks like You have a platform with soldered down memory. No DIMM > slot, am I right? > > > In this case the is no EEPROM which would hold the SPD data. Typically the > SPD should be obtained from hardware vendor/platform vendor. > > I ran an FSP with debug info and got: > C0.D0: SPD not present. > C1.D0: SPD not present. > > FSP won't run without SPD, because SPD data is crucial for memory > training. It contains timing values, memory hierarchy and other memory > characteristics. The memory training process is so complex that it requires > the right parameters, which can be retrieved from SPD. The SPD content is > highly dependent on memory module design, in Your case the memory chips > layout probably, PCB paths length etc. > > Thank you, > Zvika > > Best regards, > Michał > > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > > -- > Michał Żygowski > Fimrware Engineerhttp://3mdeb.com | @3mdeb_com > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] RAM without SPD
Hello, I suspect the RAM on my bay-trail module has no SPD interface. Can Intel's FSP work without SPD ? I tried to run decode-dimms with vendor's bios and got: No EEPROM found, try loading the eeprom or at24 module I ran an FSP with debug info and got: C0.D0: SPD not present. C1.D0: SPD not present. Thank you, Zvika ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] FSP Memory down setup
Helllo, In my BayTrail module, Enable Memory Down = Enabled. In this case are the following parameters relevant ? DIMM 0 Enable DIMM 1 Enable DIMM_DWidth DIMM_Density DIMM _BusWidth DIMM_Sides Thank you, Zvika ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 4.9: FSP debug level (0-3)
Hi Nico, I did not do any code changes in coreboot. The messages are coming from a debug version of FSP I got from Intel. I did not patch this fsp.fd at all. I expected that this version will help me to patch my FSP using BCT. Can you tell how to use the above FSP messages to patch FSP ? For example: what are RID , Reg_EFF_DualCH_EN ? Attached the output of dmidecode and decode-dimms I ran on this board under ubuntu. Hope I can attach files here. Thank you, Zvika On Tue, Feb 12, 2019 at 8:35 PM Nico Huber wrote: > Hi Zvika, > > On 09.02.19 20:40, Zvi Vered wrote: > > PcdMrcInitSPDAddr1 = A0 > > PcdMrcInitSPDAddr2 = A2 > > ... > > C0.D0: SPD not present. > > C1.D0: SPD not present. > > Did you solve this SPD problem yet? If not, this is likely still where > your later logs end, i.e. in FSP's raminit. It seems you try to tell FSP > to read them from the SMBus addresses above. If the addresses are cor- > rect and the SPD chips present, it might not find them because the SMBus > is not functional. IIRC, you have to configure the SoC pads explicitly > to be used for SMBus. This is the first thing I'd investigate. > > If you could push your code to Gerrit, or any public Git repository, we > might be able to help you better. > > Nico > dmidecode.log Description: Binary data decode-dimms.log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] 4.9: Payload is not running
Hello, I got the following output via RS232 console: -- coreboot-4.9-539-gde3ace0-dirty Mon Jan 28 13:44:10 UTC 2019 romstage starting (log level: 7)... RTC Init Starting the Intel FSP (early_init) CBFS: 'Master Header Locator' located CBFS at [200:20) CBFS: Locating 'cpu_microcode_blob.bin' CBFS: Found @ offset 7940 size cc00 microcode: sig=0x30679 pf=0x1 revision=0x90a PM1_STS = 0x2100 PM1_CNT = 0x0 GEN_PMCON1 = 0x45008 prev_sleep_state = S5 Configure Default UPD Data PcdMrcInitSPDAddr1: 0xa0 (default) PcdMrcInitSPDAddr2: 0xa2 (default) PcdSataMode:0x01 (set) PcdLpssSioEnablePciMode:0x01 (default) PcdMrcInitMmioSize: 0x800 (default) PcdIgdDvmt50PreAlloc: 0x02 (default) PcdApertureSize:0x02 (default) PcdGttSize: 0x02 (default) SerialDebugPortAddress: 0x3f8 (default) SerialDebugPortType:0x01 (default) PcdMrcDebugMsg: 0x00 (default) PcdSccEnablePciMode:0x01 (default) IgdRenderStandby: 0x00 (default) TxeUmaEnable: 0x00 (default) PcdOsSelection: 0x04 (default) PcdEMMC45DDR50Enabled: 0x01 (default) PcdEMMC45HS200Enabled: 0x00 (default) PcdEMMC45RetuneTimerValue: 0x08 (default) PcdEnableIgd: 0x01 (default) AutoSelfRefreshEnable: 0x00 (default) APTaskTimeoutCnt: 0x00 (default) GTT Size: 2 MB Tseg Size: 8 MB Aperture Size: 256 MB IGD Memory Size:64 MB MMIO Size: 2048 MB MIPI/ISP: Disabled Sdio: Enabled Sdcard: Enabled SATA: Enabled SIO Dma 0: Enabled SIO I2C0: Enabled SIO I2C1: Enabled SIO I2C2: Enabled SIO I2C3: Enabled SIO I2C4: Enabled SIO I2C5: Enabled SIO I2C6: Enabled Azalia: Enabled SIO Dma1: Enabled Pwm0: Enabled Pwm1: Enabled Hsuart0:Enabled Hsuart1:Enabled Spi:Enabled Lpe:Disabled eMMC Mode: eMMC 4.5 SATA Mode: AHCI Xhci: Enabled - And then - nothing. It seems payload is not running. Currently SeaBIOS is enabled. My goal it to boot vanilla linux with grub (or grub2) via RS232 console only. With the original BIOS I got from vendor, I used knoppix to burn grub on the SATA disk. If coreboot is running grub, how should I burn grub ? Is it part of coreboot image ? Thank you, Zvika ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 4.9: FSP debug level (0-3)
Intel is reading this ... what's the reason for debug > builds of FSP vs. non-debug? That approach has not worked tremendously > well in UEFI, why have it in FSP? > > On Sat, Feb 9, 2019 at 11:43 AM Zvi Vered > wrote:1FAFB2926 > > > C0.D0: SPD not present. > > C1.D0: SPD not present. > > oh boy. No SPD? Do you need to set up some fake SPD then? > > ron > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 4.9: FSP debug level (0-3)
Hi Nico, All, I tried an FSP.fd with debug infro I got from Intel. For this purpose I had to change the "FSP location in CBFS" to 0xFFFB (default was 0xFFFC) Following is the information I got via UART: = PEIM FSP v1.0 (VLYVIEW0 v0.0.3.5) = Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A The 0th FV start address is 0x000FFFE0400, size is 0x00017C00, handle is 0x0 Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389 Install PPI: 06E81C58-4AD7-44BC-8390-F10265F72480 Install PPI: 01F34D25-4DE2-23AD-3FF3-36353FF323F1 Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry point: FFFE0FE4 The 1th FV start address is 0x000FFFB, size is 0x0002F400, handle is 0xFFFB Install PPI: A55D6970-1306-440C-8C72-8F51FAFB2926 PcdMrcInitTsegSize = 8 PcdMrcInitMmioSize = 800 PcdMrcInitSPDAddr1 = A0 PcdMrcInitSPDAddr2 = A2 Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type AutoSelfRefreshEnable = 0x2 RID = 0x11. Reg_EFF_DualCH_EN = 0x100301C0. CurrentMrcData.BootMode = 4 C0.D0: SPD not present. C1.D0: SPD not present. = What should be my next step ? Do you think the above info is what I need in order to configure FSP ? Thank you, Zvika On Sat, Feb 9, 2019 at 5:33 PM Gregg Levine wrote: > Hello! > Nico you said here, "Also, generally, you need a build of FSP with > debugging enabled. The public builds usually are not." > > I agree that the public builds usually are not so enabled. What would > need to be done to enable such a function? > > Obviously to further dig into these issues, I'm going to need to be > more involved, but, ah, that's not doable this month. > - > Gregg C Levine gregg.drw...@gmail.com"This signature fought the Time > Wars, time and again." > On Sat, Feb 9, 2019 at 7:25 AM Nico Huber wrote: > > > > Hi Zvika, > > > > On 09.02.19 12:23, Zvi Vered wrote: > > > I noticed that starting from version 4.9, I can set the debug level of > FSP. > > > > > > I downloaded FSP for Bay trail and used Intel's BCT to modify it. > > > But coreboot hangs after calling to the FSP binary. > > > > > > How can I use the "FSP debug level" ? > > > > This option is only implemented for the Broadwell-DE FSP. I've pushed a > > patch to move it accordingly[1], sorry for the confusion. > > > > Also, generally, you need a build of FSP with debugging enabled. The > > public builds usually are not. > > > > Nico > > > > [1] https://review.coreboot.org/c/coreboot/+/31300 > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] 4.9: FSP debug level (0-3)
Helllo, I'm porting core boot to a bay trail board. I noticed that starting from version 4.9, I can set the debug level of FSP. I downloaded FSP for Bay trail and used Intel's BCT to modify it. But coreboot hangs after calling to the FSP binary. How can I use the "FSP debug level" ? Thank you, Zvika ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] FSP settings according to decode-dimms
Hi Nico, All, The DRAM is soldered. There is no DIMM module. After changing to "Enable Memory Down = Enabled" I got post code 0x92 just before calling to: FspInitApi() in src/drivers/intel/fsp1_0 >From there, romstage_main_continue in soc/intel/fsp_baytrail/romstage should be called but it does not happen. Any ideas why ? Thank you, Zvika On Sat, Nov 10, 2018 at 2:01 PM Nico Huber wrote: > Hi Zvi, > > I assume you still ask for the BayTrail FSP, correct? You didn't > mention it in your last mails. > > On 11/10/18 8:47 AM, Zvi Vered wrote: > > Module Type 72b-SO-UDIMM > > This suggests that you have a DIMM? i.e. a module, not soldered down > DRAM, is that correct? > > > Enable Memory Down: Disabled > > DRAM Speed: 1333 > > ... > > These settings all live in a struct called MEMORY_DOWN_DATA. I don't > know for sure, but I assume with "EnableMemoryDown Disabled" you disable > the whole struct. I can also not find a single board in coreboot that > sets `EnableMemoryDown` explicitly to 0. > > Maybe one of the FSP BayTrail maintainers can clarify? or even provide > some documentation? > > Also, please use coreboot's infrastructure to set these things from your > mainboard's `romstage.c` or `devicetree.cb`. If you want help with BCT, > better ask Intel. > > If you have a real DIMM module with an SPD that can be read from SMBus, > I would try setting `PcdMrcInitSPDAddr1`. Be aware that it expects the > SMBus address shifted left by 1 (e.g. the 7-bit address 0x50 would be > 0xa0 for FSP). You can set it from the devicetree, for examples check > the source, e.g.: > git grep '"PcdMrcInitSPDAddr1"' > > If you don't have a module but soldered down memory, here's an example > how to map the values from your SPD to FSP: `mainboard/siemens/mc_tcu3/ > romstage.c`. > > I'm not sure if this works though, as this board also sets > `PcdMrcInitSPDAddr*` in the devicetree, which confuses me (same for > intel/minnowmax, Intel maintainers?). > > Hope that helps, > Nico > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] FSP settings according to decode-dimms
Hello, Following is a partial output of decode-dimms: - Module Type 72b-SO-UDIMM Maximum module speed1333 MHz Size4096 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 Number of SDRAM DIMMs detected and decoded: 1 - Following is a partial output of dmidecode: - Handle 0x0011, DMI type 17, 40 bytes Memory Device Array Handle: 0x000F Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: A1_DIMM0 Bank Locator: A1_BANK0 Type: DDR3 Type Detail: Unknown Speed: 1333 MHz Manufacturer: A1_Manufacturer0 Serial Number: A1_SerNum0 Asset Tag: A1_AssetTagNum0 Part Number: Array1_PartNumber0 Rank: Unknown Configured Clock Speed: 1066 MHz Minimum Voltage: 1.35 V Maximum Voltage: 1.5 V Configured Voltage: 1.35 V - According to the above output I set the following in BCT: Enable Memory Down: Disabled DRAM Speed: 1333 DRAM Type: DDR3 DIMM 0 Enable: Enabled DIMM 1 Enabled: Disabled DIMM_DWidth: x8 DIMM Density: 4 Gbit DIMM_BusWidth: 8 bits DIMM_Sides: 1 Ranks tCL: 9 tRP_tRCD: 9 tWR: 15 tWTR: 7 tRRD: 6 tRTP: 7 tFAW: 30 I set DIMM_Density according to DDR's datasheet (MEM4G08D3E/FABG) Can you please tell if my settings are correct ? tWTR = 7.5nsec. but BCT gets only integer value. tRTP = 7.5nsec but BCT gets only integer value. Configured Clock Speed: 1066 MHz. Is this the speed I should set ? Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Use VBIOS from vendor's original bin file
Hi Mike, Thank you very much ! Best regards, Zvika On Wed, Nov 7, 2018 at 12:43 AM Mike Banon wrote: > Hello Zvika, > > > How can it find [VBIOS] in the vendor's bin file ? > > It really depends on the type of vendor's BIOS because they could be > packed differently. For example, if your vendor's BIOS is Inside then > you can use Inside H2OEZE utility (sadly its' Windows-only and not > available officially, but you could find it if really want). But > please keep in mind that your vendor's BIOS might be patching that > VBIOS during booting, if that is indeed so - then a "clean" unpatched > VBIOS extracted with this method, either will not work at all or work > with errors. So it is always recommended to extract VBIOS from a > running system, just in case. Usually these instructions are working - > https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios > , see "Retrieval via Linux kernel" part. But if that's not working at > your system and you've tried everything else, here is a great > alternative method - > https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html > > Best regards, > Mike Banon > On Tue, Nov 6, 2018 at 10:18 PM Zvi Vered wrote: > > > > Hello, > > > > Currently I'm replacing the BIOS in the vendor's bin file with > coreboot.bin > > Can coreboot use Vendor's VBIOS instead of the serial console ? > > How can it find it in the vendor's bin file ? > > > > Thank you, > > Zvika > > -- > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Baytrail: FspInitApi causing unknown post code
Hello,
In fsp_util.c I added 2 lines after FspInitApi:
...
post_code(POST_FSP_MEMORY_INIT);
FspInitApi();
post_code (0x66);
while (1);
/* Should never return. Control will continue from ContinuationFunc */
die("Uh Oh! FspInitApi returned");
After booting I *** did not *** get 0x66 which is good.
But I got post code 0x1E.
It is not from coreboot source.
How can I debug it ?
Can wrong FSP settings cause this ?
Thank you,
Zvika
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] FSP - Momory configuration
Hello, The memory configuration contains (also) the following fields: tCL tRP_tRCD tWR tWTR tRRD tRTP tFAW According to the datasheet of the DDR: tCL(avg): 0.47(Min) to 0.53(Max) The value in the BCT can be from: 1..255 How should I translate the values from datasheet to Intel's BCT ? Should we take the min or max value ? Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Use VBIOS from vendor's original bin file
Hello, Currently I'm replacing the BIOS in the vendor's bin file with coreboot.bin Can coreboot use Vendor's VBIOS instead of the serial console ? How can it find it in the vendor's bin file ? Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] FSP integration
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
Hi Jose, All, I built coreboot.rom with the right microcode. Following is the coreboot build summary: *** Name OffsetType Size Comp cbfs master header 0x0cbfs header32 none fallback/romstage0x80 stage 28660 none cpu_microcode_blob.bin 0x7100 microcode 52224 none fallback/ramstage0x13d80stage 62434 none config 0x231c0 raw 614none revision 0x23480 raw 570none cmos_layout.bin 0x23700 cmos_layout 872 none fallback/dsdt.aml0x23ac0 raw 12528 none (empty) 0x26c00 null 1675672 none fsp.bin0x1bfdc0 fsp 229376 none (empty) 0x1f7e00 null 30936none 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 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_ver090A_2018-01-10_PRD_252563C5.bin > > 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 > 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 > 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 >> 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 >&g
Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
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 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 > 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: > 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 base0.125 ns > Maximum module speed1333 MHz (PC3-10600) > Size4096 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 D
Re: [coreboot] Modifying FSP in Binary Configuration Tool (BCT)
ttings (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 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@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Modifying FSP in Binary Configuration Tool (BCT)
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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Post code 0xCE: coreboot.rom with fsp
Hello, After selecting "Use Intel Firmware Support Package" and specified fsp file, I got post code: 0xCE Before using this FSP I got post code: 0xb0 Where can I find documentation for those post codes ? Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] post code 0xb0 after coreboot.rom BIOs burn
Hello, After injecting coreboot.rom into the original bin file + boot I got post code 0xb0. Can you tell what does it mean ? I modified devicetree.cb accorindg to lspci + superiotool. In romstage.c I added: post_code(0x30); in early_mainboard_romstage_entry post_code(0x31); in late_mainboard_romstage_entry I did not modiled FSP yet. Is it possible that 0xb0 was sent from a code not developed in ELAT Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Change superio in "Bayley Bay FSP-based CRB"
Hi Jose, All, According to lspci I modified devicetree.cp copied from the "Bay Trail" reference: 1. Should I add the devices at the end of the list marked with # in domain 1.2.3 ? 2. How can I know to set 'on' or 'off' ? /* device domain 0 on device pci 00.0 on end# 8086 0F00 - SoC router device pci 02.0 on end# 8086 0F31 - GFX device pci 12.0 on end# 8086 0F16 - SD Port (SD3 pins) device pci 13.0 on end# 8086 0F23 - SATA AHCI (0F20, 0F21, 0F22, 0F23) device pci 14.0 on end# 8086 0F35 - USB XHCI - Only 1 USB controller at a time device pci 17.0 on end# 8086 0F50 - EMMC 4.5 Port (MMC1 pins) - Only 1 EMMC port at a time device pci 1b.0 on end# 8086 0F04 - HD Audio device pci 1c.0 on end# 8086 0F48 - PCIe Root Port 1 (x4 slot) device pci 1c.1 on end# 8086 0F4A - PCIe Root Port 2 (half mini pcie slot) device pci 1c.2 on end# 8086 0F4C - PCIe Root Port 3 (front x1 slot) device pci 1c.3 on end# 8086 0F4E - PCIe Root Port 4 (rear x1 slot) device pci 1d.0 off end# 8086 0F34 - USB EHCI - Only 1 USB controller at a time device pci 1f.0 on chip superio/winbond/w83627hf device pnp 2e.0 off # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 end device pnp 2e.1 off # Parallel Port io 0x60 = 0x378 irq 0x70 = 7 end device pnp 2e.2 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.3 on # Com2 io 0x60 = 0x2f8 irq 0x70 = 3 end device pnp 2e.5 on # Keyboard io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 irq 0x72 = 12 end device pnp 2e.6 off # SFI io 0x62 = 0x100 end device pnp 2e.7 off # GPIO_GAME_MIDI io 0x60 = 0x220 io 0x62 = 0x300 irq 0x70 = 9 end device pnp 2e.8 off end # WDTO_PLED device pnp 2e.9 off end # GPIO_SUSLED device pnp 2e.a off end # ACPI device pnp 2e.b on # HW Monitor io 0x60 = 0x290 irq 0x70 = 5 end end#superio/winbond/w83627hf end# 8086 0F1C - LPC bridge device pci 1f.3 on end# 8086 0F12 - SMBus 0 end #01:00.0 0604: 10b5:8505 #02:01.0 0604: 10b5:8505 #02:02.0 0604: 10b5:8505 #02:03.0 0604: 10b5:8505 #02:04.0 0604: 10b5:8505 #03:00.0 0604: 10b5:8112 #0a:00.0 0200: 8086:157b */ Thank you very much, Zvika On Mon, Oct 8, 2018 at 10:16 AM Jose Trujillo wrote: > > Hello Zvika, > > Add your device in Konfig and configure it under devicetree. > Look for examples and/or previous threads in this mail list. > > Jose. > > ‐‐‐ Original Message ‐‐‐ > On Monday, October 8, 2018 12:02 AM, Zvi Vered wrote: > > > Hello, > > > > I have to port coreboot to a "Bay Trail" board (KONTRON). > > I selected "Bayley Bay FSP-based CRB" as a reference. > > > > In my board, the output of superiotool is: > > Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x41) at 0x2e > > > > But the configuration of the reference board is: > > *** Super I/O *** > > > > How can I change it ? > > > > I wish there was a basic configuration that could be easily modified. > > > > Thank you, > > Zvika > > > > -- > > > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Change superio in "Bayley Bay FSP-based CRB"
Hello, I have to port coreboot to a "Bay Trail" board (KONTRON). I selected "Bayley Bay FSP-based CRB" as a reference. In my board, the output of superiotool is: Found Winbond W83627HF/F/HG/G (id=0x52, rev=0x41) at 0x2e But the configuration of the reference board is: *** Super I/O *** How can I change it ? I wish there was a basic configuration that could be easily modified. Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Hi Nico, Thank you very much for the information. Best regards, Zvika On Sat, Oct 6, 2018 at 6:18 PM Nico Huber wrote: > > On 10/6/18 2:46 PM, Zvi Vered wrote: > > Hello Nathaniel, Nico, > > > > Thank you very much for the detailed answers. > > > > The vendor's bin file starts with the following pattern: > > : > > 0010: 5AA5F00F 03000402 0602100B 20002100 > > > > Can you confirm that this is the start of IFD ? > > Yes, it is (at least the first 20B are distinctive). > > There is not much public documentation about it ([1] is all I know) > but you might find something less public with Google [2]. There's also > a lot of open-source code of programs that can parse it [3][4]. Code > is usually more accurate than documentation but it explains less about > the configuration bits. You'll have to ask Intel for the SPI Program- > ming Guide for your particular platform if you want to fully under- > stand it and craft your own. > > Nico > > [1] > https://review.coreboot.org/cgit/flashrom.git/plain/Documentation/mysteries_intel.txt > [2] "Intel" "SPI" "Programming Guide" *cough > [3] https://review.coreboot.org/cgit/flashrom.git/tree/ich_descriptors.c > [4] https://review.coreboot.org/cgit/coreboot.git/tree/util/ifdtool/ -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Source code for "Intel Firmware"
Hello Nathaniel, Nico, Thank you very much for the detailed answers. The vendor's bin file starts with the following pattern: : 0010: 5AA5F00F 03000402 0602100B 20002100 Can you confirm that this is the start of IFD ? Best regards, Zvika On Sat, Oct 6, 2018 at 1:30 PM Nico Huber wrote: > > On 10/6/18 6:50 AM, Zvi Vered wrote: > > Hello, > > > > A bin file burned on a BIOS chip contains "Intel FW": > > > > Intel FW = IFD +PD+ME/TXE+GBE > > > > IFD=Intel Firmware Descriptor Table. > > PD=Parameters > > ME=Management Engine (For "Core" kind of processors). > > TXE=Trusted Execution Engine (For "Atom" kind of processors). > > GBE=Network card firmware. > > > > If I'm not mistaken, this package is not supplied within coreboot. > > Right. > > > > > coreboot only replaces the BIOS part developed by vendors like "AMI bios". > > Yes, mostly. For some platforms, coreboot also replaces reference code > of the silicon vendor, but today it's mostly just what an IBV like AMI > does. > > > > > Where can I find full source code for "Intel FW" ? > > Most of the regions you mentioned above don't contain code at all. > Beside the BIOS, there is ME/TXE code but Intel provides only binaries > for these, AFAIK. > > > > > 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. > > > > I want to depend only on Intel. > > That is possible but will require you to dive even deeper in Intel's > platform configuration. I can only advice you to treat each of the > firmware parts individually as much as possible. For instance, first > try to replace the BIOS with coreboot (while keeping the original other > parts), then try to replace the ME/TXE firmware, then the GBE and IFD > (the latter both only contain configuration data, AFAIK). > > You will need an NDA with Intel. Then ask them for their binaries, docu- > mentation and (Windows) tools to create your own configuration. > > Don't underestimate the effort. You'll probably need some months to get > your own coreboot running, then few more to read through all the docu- > mentation and craft your own IFD etc. > > Nico -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Source code for "Intel Firmware"
Hello, A bin file burned on a BIOS chip contains "Intel FW": Intel FW = IFD +PD+ME/TXE+GBE IFD=Intel Firmware Descriptor Table. PD=Parameters ME=Management Engine (For "Core" kind of processors). TXE=Trusted Execution Engine (For "Atom" kind of processors). GBE=Network card firmware. If I'm not mistaken, this package is not supplied within coreboot. coreboot only replaces the BIOS part developed by vendors like "AMI bios". Where can I find full source code for "Intel FW" ? 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. I want to depend only on Intel. Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Jose, Mariusz, All, The vendor is Adlink. The board is called LEC-BTS https://www.adlinktech.com/Products/Computer_on_Modules/SMARC/LEC-BTS?lang=en The CPU is Intel's Bay Trail. According to the help of flashrom, it works with bin files only. So I should take coreboot.rom and stitch it to the parts of the original vendor's bin file. Am I right? Thank you, Zvika On Fri, Oct 5, 2018 at 12:12 PM Mariusz Szafrański via coreboot < coreboot@coreboot.org> wrote: > Also have no idea :( > My solution should work when vendor`s utility just put unmodified whole 5M > coreboot.rom.new at top of the flash chip space. > But this could not be true and vendor`s utility is doing something else :( > (e.g. put it on other location, split it and place chunks on non > continuous areas or injects some kind of "id" or "keys" before flashing) > > Mariusz > W dniu 05.10.2018 o 10:50, Jose Trujillo pisze: > > I have no idea bro > I cannot help you with that. > I am just curious Which brand and model of board are you using? > > ‐‐‐‐‐‐‐ Original Message ‐‐‐ > On Friday, October 5, 2018 6:05 AM, Zvi Vered > wrote: > > Hi Jose, Mariusz,All, > > The vendor's rom file size is: 5,242,880 bytes > > After running: > dd if=coreboot.rom of=coreboot.rom.new bs=1M skip=3 > > I got a new file with the same size. > > I tried to program this new file and got the following message from the > vendor's utlity: > > WARNING ! > This Image file doesn't match current System design! > Force update it will destroy the System's Activation Key. > We do not recommend flashing your BIOS. > Press "Y" to force update BIOS. > Press "N" to quit flash. > - Please select one of the options: > > I ignored the warning and programmed the BIOS. > > After reset, I got nothing. > > What is "System's Activation Key" ? > I'm sure that FSP (and other files) for my board are not properly > configured yet. > But I suspect this is not the reason for the message. > > Thank you, > Zvika > > > On Thu, Oct 4, 2018 at 9:47 PM Zvi Vered wrote: > >> Hi Jose, >> >> I probably made a mistake and erased the main BIOS chip (and also the >> secondary one) >> Currently my target is not booting OS at all. >> So I can not try Mariusz procedure. >> Hope to have an identical target soon. >> >> Thank you very much for your help, >> Zvika >> >> On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo >> wrote: >> >>> Zvika: >>> Doing a full flash doesn't work for you, this is what I been doing. >>> Try to use flashrom from linux if you want to do the full flash (may be >>> it will work). >>> >>> An external programmer would be the optimal choice. >>> >>> Did you tried what Mariusz said? >>> Jose. >>> >>> >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Thursday, October 4, 2018 6:20 PM, Zvi Vered >>> wrote: >>> >>> Hi Mariusz, Jose, All, >>> >>> Mariusz - Thank you very much for the solution. >>> Jose - You wrote "I have never done this way...". >>> Can you please suggest a better alternative ? >>> >>> Thank you, >>> Zvika >>> >>> >>> On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot < >>> coreboot@coreboot.org> wrote: >>> >>>> Hi Jose, >>>> >>>> In your case set: >>>> ROM chip size = 8MB (your case) >>>> CBFS_SIZE <= 5MB (your specific case) >>>> >>>> This will build 8M file. After that just cut last 5M of this 8M file >>>> (using any hexeditor) or use something like below from command line: >>>> >>>> dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 >>>> >>>> (before doing that double check if original vendor`s rom file size is >>>> 5242880 bytes long) >>>> >>>> Mariusz >>>> >>>> >>>> W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: >>>> >>>> You can do that but I have never done this way and I cannot help you >>>> with that. >>>> >>>> Someone else can advise on this? >>>> >>>> ‐‐‐ Original Message ‐‐‐ >>>> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered >>>> wrote: >>>> >>>> Hi Jose, All, >>>> >>>> Highly appreciate your answers. >>>> It seems the vital information in your replies are not documente
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Jose, Mariusz,All, The vendor's rom file size is: 5,242,880 bytes After running: dd if=coreboot.rom of=coreboot.rom.new bs=1M skip=3 I got a new file with the same size. I tried to program this new file and got the following message from the vendor's utlity: WARNING ! This Image file doesn't match current System design! Force update it will destroy the System's Activation Key. We do not recommend flashing your BIOS. Press "Y" to force update BIOS. Press "N" to quit flash. - Please select one of the options: I ignored the warning and programmed the BIOS. After reset, I got nothing. What is "System's Activation Key" ? I'm sure that FSP (and other files) for my board are not properly configured yet. But I suspect this is not the reason for the message. Thank you, Zvika On Thu, Oct 4, 2018 at 9:47 PM Zvi Vered wrote: > Hi Jose, > > I probably made a mistake and erased the main BIOS chip (and also the > secondary one) > Currently my target is not booting OS at all. > So I can not try Mariusz procedure. > Hope to have an identical target soon. > > Thank you very much for your help, > Zvika > > On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo > wrote: > >> Zvika: >> Doing a full flash doesn't work for you, this is what I been doing. >> Try to use flashrom from linux if you want to do the full flash (may be >> it will work). >> >> An external programmer would be the optimal choice. >> >> Did you tried what Mariusz said? >> Jose. >> >> >> >> ‐‐‐ Original Message ‐‐‐ >> On Thursday, October 4, 2018 6:20 PM, Zvi Vered >> wrote: >> >> Hi Mariusz, Jose, All, >> >> Mariusz - Thank you very much for the solution. >> Jose - You wrote "I have never done this way...". >> Can you please suggest a better alternative ? >> >> Thank you, >> Zvika >> >> >> On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot < >> coreboot@coreboot.org> wrote: >> >>> Hi Jose, >>> >>> In your case set: >>> ROM chip size = 8MB (your case) >>> CBFS_SIZE <= 5MB (your specific case) >>> >>> This will build 8M file. After that just cut last 5M of this 8M file >>> (using any hexeditor) or use something like below from command line: >>> >>> dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 >>> >>> (before doing that double check if original vendor`s rom file size is >>> 5242880 bytes long) >>> >>> Mariusz >>> >>> >>> W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: >>> >>> You can do that but I have never done this way and I cannot help you >>> with that. >>> >>> Someone else can advise on this? >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered >>> wrote: >>> >>> Hi Jose, All, >>> >>> Highly appreciate your answers. >>> It seems the vital information in your replies are not documented. >>> >>> The original vendor's rom file size is 5MB. >>> Do you think I can create a 5MB coreboot.rom ? >>> >>> It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom >>> file like the original one. For any other file size, AfuEfix64 fails. >>> >>> Thank you, >>> Zvika >>> >>> On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo >>> wrote: >>> >>>> Zvika: >>>> >>>> There are 2 ways to build coreboot: (choose one) >>>> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS. >>>> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash >>>> and just rewrite coreboot on top of the BIOS block. >>>> >>>> Your original computer Firmware = Intel FW + "BIOS" >>>> >>>> Intel FW = IFD +PD+ME/TXE+GBE >>>> BIOS=AMI-Phoenix etc... >>>> >>>> IFD=Intel Firmware Descriptor Table. >>>> PD=Parameters >>>> ME=Management Engine (For "Core" kind of processors). >>>> TXE=Trusted Execution Engine (For "Atom" kind of processors). >>>> GBE=Network card firmware. >>>> >>>> Zvika said: >>>> "After creating coreboot.rom should I always use the original BIOS with >>>> ifdtool to convert rom to bin ?" >>>> Answer: >>>> No, there are other methods and tools that can do the merge >>>> (ifdtool and I
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Jose, I probably made a mistake and erased the main BIOS chip (and also the secondary one) Currently my target is not booting OS at all. So I can not try Mariusz procedure. Hope to have an identical target soon. Thank you very much for your help, Zvika On Thu, Oct 4, 2018 at 6:31 PM Jose Trujillo wrote: > Zvika: > Doing a full flash doesn't work for you, this is what I been doing. > Try to use flashrom from linux if you want to do the full flash (may be it > will work). > > An external programmer would be the optimal choice. > > Did you tried what Mariusz said? > Jose. > > > > ‐‐‐ Original Message ‐‐‐ > On Thursday, October 4, 2018 6:20 PM, Zvi Vered > wrote: > > Hi Mariusz, Jose, All, > > Mariusz - Thank you very much for the solution. > Jose - You wrote "I have never done this way...". > Can you please suggest a better alternative ? > > Thank you, > Zvika > > > On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot < > coreboot@coreboot.org> wrote: > >> Hi Jose, >> >> In your case set: >> ROM chip size = 8MB (your case) >> CBFS_SIZE <= 5MB (your specific case) >> >> This will build 8M file. After that just cut last 5M of this 8M file >> (using any hexeditor) or use something like below from command line: >> >> dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 >> >> (before doing that double check if original vendor`s rom file size is >> 5242880 bytes long) >> >> Mariusz >> >> >> W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: >> >> You can do that but I have never done this way and I cannot help you with >> that. >> >> Someone else can advise on this? >> >> ‐‐‐ Original Message ‐‐‐ >> On Tuesday, October 2, 2018 9:39 PM, Zvi Vered >> wrote: >> >> Hi Jose, All, >> >> Highly appreciate your answers. >> It seems the vital information in your replies are not documented. >> >> The original vendor's rom file size is 5MB. >> Do you think I can create a 5MB coreboot.rom ? >> >> It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom >> file like the original one. For any other file size, AfuEfix64 fails. >> >> Thank you, >> Zvika >> >> On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo >> wrote: >> >>> Zvika: >>> >>> There are 2 ways to build coreboot: (choose one) >>> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS. >>> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash >>> and just rewrite coreboot on top of the BIOS block. >>> >>> Your original computer Firmware = Intel FW + "BIOS" >>> >>> Intel FW = IFD +PD+ME/TXE+GBE >>> BIOS=AMI-Phoenix etc... >>> >>> IFD=Intel Firmware Descriptor Table. >>> PD=Parameters >>> ME=Management Engine (For "Core" kind of processors). >>> TXE=Trusted Execution Engine (For "Atom" kind of processors). >>> GBE=Network card firmware. >>> >>> Zvika said: >>> "After creating coreboot.rom should I always use the original BIOS with >>> ifdtool to convert rom to bin ?" >>> Answer: >>> No, there are other methods and tools that can do the merge (ifdtool >>> and Intel's FIT are working fine for me) >>> >>> After the creation of the coreboot build you have 2 ways of doing the >>> flashing for your case: (with fpt). >>> 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or >>> have unknown firmware. >>> Use IFDTool in this case to inject coreboot to Intel FW. then >>> flash it with fpt . >>> 2.- Flash only the BIOS block (5MB your specific case) in this case ask >>> someone else how to do it with fpt >>> >>> I hope this answered your questions. >>> Jose.. >>> >>> ‐‐‐ Original Message ‐‐‐ >>> On Saturday, September 29, 2018 12:24 AM, Zvi Vered >>> wrote: >>> >>> Hi Jose, >>> >>> You wrote: >>> "My recommended approach is using the original Intel FW with already >>> included the FD, TXE". >>> >>> What is "original intel FW" ? >>> What is FD, TXE ? >>> >>> After creating coreboot.rom should I always use the original BIOS with >>> ifdtool to convert rom to bin ? >>> >>> Thank you, >>> Zvika >>> >>> On Wed, Sep 26, 2018 at 7:27 PM
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Mariusz, Jose, All, Mariusz - Thank you very much for the solution. Jose - You wrote "I have never done this way...". Can you please suggest a better alternative ? Thank you, Zvika On Wed, Oct 3, 2018 at 8:39 PM Mariusz Szafrański via coreboot < coreboot@coreboot.org> wrote: > Hi Jose, > > In your case set: > ROM chip size = 8MB (your case) > CBFS_SIZE <= 5MB (your specific case) > > This will build 8M file. After that just cut last 5M of this 8M file > (using any hexeditor) or use something like below from command line: > > dd if=coreboot.rom of=corebootout.rom bs=1M skip=3 > > (before doing that double check if original vendor`s rom file size is > 5242880 bytes long) > > Mariusz > > > W dniu 03.10.2018 o 08:53, Jose Trujillo via coreboot pisze: > > You can do that but I have never done this way and I cannot help you with > that. > > Someone else can advise on this? > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, October 2, 2018 9:39 PM, Zvi Vered > wrote: > > Hi Jose, All, > > Highly appreciate your answers. > It seems the vital information in your replies are not documented. > > The original vendor's rom file size is 5MB. > Do you think I can create a 5MB coreboot.rom ? > > It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom file > like the original one. For any other file size, AfuEfix64 fails. > > Thank you, > Zvika > > On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo > wrote: > >> Zvika: >> >> There are 2 ways to build coreboot: (choose one) >> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS. >> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash >> and just rewrite coreboot on top of the BIOS block. >> >> Your original computer Firmware = Intel FW + "BIOS" >> >> Intel FW = IFD +PD+ME/TXE+GBE >> BIOS=AMI-Phoenix etc... >> >> IFD=Intel Firmware Descriptor Table. >> PD=Parameters >> ME=Management Engine (For "Core" kind of processors). >> TXE=Trusted Execution Engine (For "Atom" kind of processors). >> GBE=Network card firmware. >> >> Zvika said: >> "After creating coreboot.rom should I always use the original BIOS with >> ifdtool to convert rom to bin ?" >> Answer: >> No, there are other methods and tools that can do the merge (ifdtool >> and Intel's FIT are working fine for me) >> >> After the creation of the coreboot build you have 2 ways of doing the >> flashing for your case: (with fpt). >> 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or >> have unknown firmware. >> Use IFDTool in this case to inject coreboot to Intel FW. then >> flash it with fpt . >> 2.- Flash only the BIOS block (5MB your specific case) in this case ask >> someone else how to do it with fpt >> >> I hope this answered your questions. >> Jose.. >> >> ‐‐‐ Original Message ‐‐‐ >> On Saturday, September 29, 2018 12:24 AM, Zvi Vered >> wrote: >> >> Hi Jose, >> >> You wrote: >> "My recommended approach is using the original Intel FW with already >> included the FD, TXE". >> >> What is "original intel FW" ? >> What is FD, TXE ? >> >> After creating coreboot.rom should I always use the original BIOS with >> ifdtool to convert rom to bin ? >> >> Thank you, >> Zvika >> >> On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo >> wrote: >> >>> You are right Nico, >>> >>> I just forgot the troubles this caused me. >>> I am sorry Vika... My mistake. >>> >>> I can confirm with Nico: >>> ROM chip size = 8MB (your case) >>> CBFS_SIZE = 2 to 5MB (your specific case) >>> >>> My recommended approach is using the original Intel FW with already >>> included the FD, TXE. >>> >>> I never tested adding regions to coreboot but you can try. >>> >>> To have better chances of success you should be dumping hardware >>> settings booting with your original "BIOS" (look for the attached file). >>> >>> Check if the system is "Memory down"or/and ECC because it will be needed >>> to edit FSP (if using it). >>> Dump memory settings with the following commands: >>> >>> sudo dnf install i2c-tools-perl >>> sudo modprobe eeprom >>> decode-dimms >>> >>> If you have not done this already there is still a long way to go. >>> Don't get intimidated, just
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Jose, All,
Highly appreciate your answers.
It seems the vital information in your replies are not documented.
The original vendor's rom file size is 5MB.
Do you think I can create a 5MB coreboot.rom ?
It seems that AfuEfix64.efi supplied by vendor is looking for 5MB rom file
like the original one. For any other file size, AfuEfix64 fails.
Thank you,
Zvika
On Mon, Oct 1, 2018 at 2:08 PM Jose Trujillo
wrote:
> Zvika:
>
> There are 2 ways to build coreboot: (choose one)
> 1.- Including IFD, TXE, GBE etc inside coreboot CBFS.
> 2.- Using the original firmware(FW) with IFD, TXE, GBE already in flash
> and just rewrite coreboot on top of the BIOS block.
>
> Your original computer Firmware = Intel FW + "BIOS"
>
> Intel FW = IFD +PD+ME/TXE+GBE
> BIOS=AMI-Phoenix etc...
>
> IFD=Intel Firmware Descriptor Table.
> PD=Parameters
> ME=Management Engine (For "Core" kind of processors).
> TXE=Trusted Execution Engine (For "Atom" kind of processors).
> GBE=Network card firmware.
>
> Zvika said:
> "After creating coreboot.rom should I always use the original BIOS with
> ifdtool to convert rom to bin ?"
> Answer:
> No, there are other methods and tools that can do the merge (ifdtool
> and Intel's FIT are working fine for me)
>
> After the creation of the coreboot build you have 2 ways of doing the
> flashing for your case: (with fpt).
> 1.- Flash the full 8MB (Intel FW+coreboot) if the SPI flash is blank or
> have unknown firmware.
> Use IFDTool in this case to inject coreboot to Intel FW. then
> flash it with fpt .
> 2.- Flash only the BIOS block (5MB your specific case) in this case ask
> someone else how to do it with fpt....
>
> I hope this answered your questions.
> Jose..
>
> ‐‐‐ Original Message ‐‐‐
> On Saturday, September 29, 2018 12:24 AM, Zvi Vered
> wrote:
>
> Hi Jose,
>
> You wrote:
> "My recommended approach is using the original Intel FW with already
> included the FD, TXE".
>
> What is "original intel FW" ?
> What is FD, TXE ?
>
> After creating coreboot.rom should I always use the original BIOS with
> ifdtool to convert rom to bin ?
>
> Thank you,
> Zvika
>
> On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo
> wrote:
>
>> You are right Nico,
>>
>> I just forgot the troubles this caused me.
>> I am sorry Vika... My mistake.
>>
>> I can confirm with Nico:
>> ROM chip size = 8MB (your case)
>> CBFS_SIZE = 2 to 5MB (your specific case)
>>
>> My recommended approach is using the original Intel FW with already
>> included the FD, TXE.
>>
>> I never tested adding regions to coreboot but you can try.
>>
>> To have better chances of success you should be dumping hardware settings
>> booting with your original "BIOS" (look for the attached file).
>>
>> Check if the system is "Memory down"or/and ECC because it will be needed
>> to edit FSP (if using it).
>> Dump memory settings with the following commands:
>>
>> sudo dnf install i2c-tools-perl
>> sudo modprobe eeprom
>> decode-dimms
>>
>> If you have not done this already there is still a long way to go.
>> Don't get intimidated, just do it, if you have questions just ask I
>> will try to help
>>
>> Good luck,
>> Jose.
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, September 26, 2018 6:28 PM, Nico Huber
>> wrote:
>>
>> > Hi,
>> >
>> > On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote:
>> >
>> > > No, don't change it, you change the size of coreboot only if during
>> the
>> > > building process "make" complain that there is not enough space but in
>> > > your case your build was already successful leave it like that.
>> >
>> > this advice seems very weird to me. I'm not experienced with Bay Trail.
>> > But unless there is a bug in the Bay Trail code, you should always set
>> > the correct ROM_SIZE (to the full flash chip size). Otherwise you may
>> > introduce bugs in code that relies on this setting (e.g. saving the
>> > MRC cache might fail and so would S3 resume).
>> >
>> > CBFS_SIZE however is the setting to adjust according to your needs. It
>> > should be at most the size of the BIOS region.
>> >
>> > > In the rare circumstance that more space is required you can increase
>> > > coreboot size to 4MB and istill will fit into your system 5MB of space
>> > > available.
>> > > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save
>> > > as BYT_orig.bin.new that you can flash to your system.
>> >
>> > I assume this doesn't work oob if you set ROM_SIZE correctly. But it is
>> > unnecessary to craft a single file by hand. You can either only flash
>> > the BIOS region (recommended) or add the other regions in coreboot's
>> > config (HAVE_{IFD,ME,GBE}_BIN).
>> >
>> > Nico
>>
>>
>>
>
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Porting coreboot to another Intel's bay-trail
Hello, I created a new mainboard based on "Bayley Bay FSP-based CRB" It seems that (at least) the following files are mandatory for build: cmos.layout devicetree.cb romstage.c Am I right ? If yes - what info required to write those files ? Can I use coreboot default files instead ? Honestly - I thought that FSP binary configuration is all I have to do. And few changes in menuconfig (e.g ROM size). Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Jose,
You wrote:
"My recommended approach is using the original Intel FW with already
included the FD, TXE".
What is "original intel FW" ?
What is FD, TXE ?
After creating coreboot.rom should I always use the original BIOS with
ifdtool to convert rom to bin ?
Thank you,
Zvika
On Wed, Sep 26, 2018 at 7:27 PM Jose Trujillo
wrote:
> You are right Nico,
>
> I just forgot the troubles this caused me.
> I am sorry Vika... My mistake.
>
> I can confirm with Nico:
> ROM chip size = 8MB (your case)
> CBFS_SIZE = 2 to 5MB (your specific case)
>
> My recommended approach is using the original Intel FW with already
> included the FD, TXE.
>
> I never tested adding regions to coreboot but you can try.
>
> To have better chances of success you should be dumping hardware settings
> booting with your original "BIOS" (look for the attached file).
>
> Check if the system is "Memory down"or/and ECC because it will be needed
> to edit FSP (if using it).
> Dump memory settings with the following commands:
>
> sudo dnf install i2c-tools-perl
> sudo modprobe eeprom
> decode-dimms
>
> If you have not done this already there is still a long way to go.
> Don't get intimidated, just do it, if you have questions just ask I
> will try to help
>
> Good luck,
> Jose.
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, September 26, 2018 6:28 PM, Nico Huber
> wrote:
>
> > Hi,
> >
> > On 9/26/18 9:19 AM, Jose Trujillo via coreboot wrote:
> >
> > > No, don't change it, you change the size of coreboot only if during the
> > > building process "make" complain that there is not enough space but in
> > > your case your build was already successful leave it like that.
> >
> > this advice seems very weird to me. I'm not experienced with Bay Trail.
> > But unless there is a bug in the Bay Trail code, you should always set
> > the correct ROM_SIZE (to the full flash chip size). Otherwise you may
> > introduce bugs in code that relies on this setting (e.g. saving the
> > MRC cache might fail and so would S3 resume).
> >
> > CBFS_SIZE however is the setting to adjust according to your needs. It
> > should be at most the size of the BIOS region.
> >
> > > In the rare circumstance that more space is required you can increase
> > > coreboot size to 4MB and istill will fit into your system 5MB of space
> > > available.
> > > "ifdtool" will inject coreboot in the top of the BYT_orig.bin and save
> > > as BYT_orig.bin.new that you can flash to your system.
> >
> > I assume this doesn't work oob if you set ROM_SIZE correctly. But it is
> > unnecessary to craft a single file by hand. You can either only flash
> > the BIOS region (recommended) or add the other regions in coreboot's
> > config (HAVE_{IFD,ME,GBE}_BIN).
> >
> > Nico
>
>
>
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hi Jose, Thank you very much for the detail information. The output of ifdtool in layout.txt is: :0fff fd 0030:007f bios 1000:002f me So the original bios size is 0x50 = 5MB You wrote: if the size of the original BIOS is bigger or equal than coreboot build you are good to go ahead. The original "ROM chip size" in menuconfig is 2MB. Should I change it to 8MB ? I'm aware my board is not identical to the "Bayley Bay FSP-based CRB" Should I use another board as reference ? Best regards, Zvika On Tue, Sep 25, 2018 at 10:16 AM Jose Trujillo wrote: > Hello Zvika: > > First get the correct original full 8MB FW from the manufacturer or dump > it from the board with the command in EFI: > "ftp -d BYT_orig.bin" and double save it. > > 2.- in coreboot/util/ifdtool do make and sudo make install. > 3.- in terminal go to the FW directory and do:"ifdtool BYT_orig.bin -f > fw_layout.txt" > a).- in "fw_layout.txt" you will get the BIOS area size from the > original FW (just substract). > b).- if the size of the original BIOS is bigger or equal than > coreboot build you are good to go ahead. > 4.- copy/move "BYT_orig.bin" in the directory which resides the coreboot > folder (not inside the coreboot folder) and do: > ifdtool -i BIOS:./coreboot/build/coreboot.rom CB_baytrail.bin > 5.- flash it: "fpt -f CB_baytrail.bin" booting from UEFI. > > If the build was correctly done and followed accurately those steps the > system should boot. > > Good luck, > Jose Trujillo. > > ‐‐‐ Original Message ‐‐‐ > On Monday, September 24, 2018 10:18 PM, Zvi Vered > wrote: > > Hello, > > I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: > > CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 > Northbridge: 8086:0f00 (Bay Trail) > Southbridge: 8086:0f1c (Bay Trail) > IGD: 8086:0f31 (unknown) > > In coreboot configuration I selected: > Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB > The default ROM chip size is 2MB. > This is also the size of coreboot.rom created after "make" > > The board has 8MB BIOS flash. > It's delivered with a BIOS programming utility that runs under EFI shell. > > The original BIOS has 2 versions: rom (5MB) and bin (8MB) > I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. > > I got: > 3 - Error: ROM file size does not match existing BIOS size. > Should I convert coreboot.rom to coreboot.bin ? How ? > If not, how can I program coreboot.rom ? > > Thank you, > Zvika > > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Burn 2MB coreboot.rom on 8MB flash chip
Hello, I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 Northbridge: 8086:0f00 (Bay Trail) Southbridge: 8086:0f1c (Bay Trail) IGD: 8086:0f31 (unknown) In coreboot configuration I selected: Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB The default ROM chip size is 2MB. This is also the size of coreboot.rom created after "make" The board has 8MB BIOS flash. It's delivered with a BIOS programming utility that runs under EFI shell. The original BIOS has 2 versions: rom (5MB) and bin (8MB) I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. I got: 3 - Error: ROM file size does not match existing BIOS size. Should I convert coreboot.rom to coreboot.bin ? How ? If not, how can I program coreboot.rom ? Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] (no subject)
Hello, I have an Intel's ATOM Bay Trail board. The output of "inteltool" is: CPU: ID 0x30679, Processor Type 0x0, Family 0x6, Model 0x37, Stepping 0x9 Northbridge: 8086:0f00 (Bay Trail) Southbridge: 8086:0f1c (Bay Trail) IGD: 8086:0f31 (unknown) In coreboot configuration I selected: Mainboard -> Mainboard model -> Bayley Bay FSP-based CRB The default ROM chip size is 2MB. This is also the size of coreboot.rom created after "make" The board has 8MB BIOS flash. It's delivered with a BIOS programming utility that runs under EFI shell. The original BIOS has 2 versions: rom (5MB) and bin (8MB) I tried to burn the 2MB coreboot.rom with the vendor's BIOS utlity. I got: 3 - Error: ROM file size does not match existing BIOS size. Should I convert coreboot.rom to coreboot.bin ? How ? If not, how can I program coreboot.rom ? Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] flashrom programmer
Hello, How can I know what is the right flashrom programmer I should use ? under DOS\EFI I have a vendor's utility that enables flash programming. But it can flash to a specified address. The vendor's programmer works without any external hardware. When I tried: flashrom --programmer internal, I got: -- flashrom v0.9.9-rc1-r1942 on Linux 4.13.0-36-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. WARNING: No chipset found. Flash detection will most likely fail. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. -- Thank you, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bayley Bay FSP-based CRB
Dear Jose & Nico, Thank you very much for your help ! Best regards, Zvika On Thu, Jun 21, 2018 at 11:28 AM Jose Trujillo wrote: > Hello Zvika, > Look for the list of Linux commands to dump many of the information from > your original BIOS running, maybe there you will find this information. > > Also, some configuration can be seen from your original BIOS running Intel > FIT for Baytrail in Windows. > > About configuring those settings in coreboot look for other examples in > the coreboot tree about configuring PCI devices in devicetree.cb and other > places. > > I Am new to coreboot too and please correct me if I Am wrong. > Good Luck! > J. Trujillo > > ‐‐‐ Original Message ‐‐‐ > On June 21, 2018 3:34 AM, Zvi Vered wrote: > > Hello, > > Thank you very much for the detailed reply. > Vendor's BIOS contains few peripherals initialization. > For example: PCIe enumeration, SATA controller, USB etc. > In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. > Should vendor supply code for this ? or any other information ? > How can I write it from scratch ? Can Intel provide information on how to > implement this initialization ? > > Thank you, > Zvika > > > On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot < > coreboot@coreboot.org> wrote: > >> Hello Zvika: >> 1.- Usually it is not necessary to change the CBFS size unless the >> compiler complain of lack of space. >> 2.- You should not worry about this setting to make your system to work. >> 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO >> because it will enable SOC internal COM1, instead (if your plan is to use >> FSP) enable FSP and add a VGA bios bin manually (The use of FSP is >> optional but I never tried without FSP). >> 4.- You need to add them yourself, there are examples to follow in this >> mail list. >> Good luck! >> J.Trujillo >> >> ‐‐‐ Original Message ‐‐‐ >> On June 18, 2018 6:24 AM, Zvi Vered wrote: >> >> Hello, >> I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after >> make distclean I chose: >> Mainboard vendor: Intel >> Mainboard model: Bayley Bay FSP-based CRB >> 1. The size of CBFS is: 0x20. Is it a fix size or should I change it >> according to my board (which is also bay trail) ? >> 2. According to "dmidecode" I ran on my target, "Address: 0xE" >> Should I set this address in coreboot configuration ? How ? >> >> 3. In this board default configuration, "Configure defaults for the Intel >> FSP package" is not selected. Is it possible that this board does not use >> Intel FSP at all ? >> Under "Generic Drivers", "Use Intel firmware Support Package' is also not >> selected. >> >> 4. Under "chipset", there is no option to set "Super I/O". Can you please >> tell why ? >> 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of >> coreboot.rom is also 4MB. >> >> Thank you in advance, >> Zvika >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Bayley Bay FSP-based CRB
Hello, Thank you very much for the detailed reply. Vendor's BIOS contains few peripherals initialization. For example: PCIe enumeration, SATA controller, USB etc. In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set. Should vendor supply code for this ? or any other information ? How can I write it from scratch ? Can Intel provide information on how to implement this initialization ? Thank you, Zvika On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot < coreboot@coreboot.org> wrote: > Hello Zvika: > 1.- Usually it is not necessary to change the CBFS size unless the > compiler complain of lack of space. > 2.- You should not worry about this setting to make your system to work. > 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO > because it will enable SOC internal COM1, instead (if your plan is to use > FSP) enable FSP and add a VGA bios bin manually (The use of FSP is > optional but I never tried without FSP). > 4.- You need to add them yourself, there are examples to follow in this > mail list. > Good luck! > J.Trujillo > > ‐‐‐ Original Message ‐‐‐ > On June 18, 2018 6:24 AM, Zvi Vered wrote: > > Hello, > I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make > distclean I chose: > Mainboard vendor: Intel > Mainboard model: Bayley Bay FSP-based CRB > 1. The size of CBFS is: 0x20. Is it a fix size or should I change it > according to my board (which is also bay trail) ? > 2. According to "dmidecode" I ran on my target, "Address: 0xE" > Should I set this address in coreboot configuration ? How ? > > 3. In this board default configuration, "Configure defaults for the Intel > FSP package" is not selected. Is it possible that this board does not use > Intel FSP at all ? > Under "Generic Drivers", "Use Intel firmware Support Package' is also not > selected. > > 4. Under "chipset", there is no option to set "Super I/O". Can you please > tell why ? > 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of > coreboot.rom is also 4MB. > > Thank you in advance, > Zvika > > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Bayley Bay FSP-based CRB
Hello, I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after make distclean I chose: Mainboard vendor: Intel Mainboard model: Bayley Bay FSP-based CRB 1. The size of CBFS is: 0x20. Is it a fix size or should I change it according to my board (which is also bay trail) ? 2. According to "dmidecode" I ran on my target, "Address: 0xE" Should I set this address in coreboot configuration ? How ? 3. In this board default configuration, "Configure defaults for the Intel FSP package" is not selected. Is it possible that this board does not use Intel FSP at all ? Under "Generic Drivers", "Use Intel firmware Support Package' is also not selected. 4. Under "chipset", there is no option to set "Super I/O". Can you please tell why ? 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of coreboot.rom is also 4MB. Thank you in advance, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Porting coreboot to new board
Hi All, The links you provided: https://www.coreboot.org/Motherboard_Porting_Guide https://www.coreboot.org/Developer_Manual Does not mention Intel's FSP at all. How FSP is integrated during coreboot porting ? src\venorcode\intel contains 2 FSP versions. src\soc\intel contains fsp_baytrail, fsp_broadwell_de Thank you, Zvika On Thu, May 31, 2018 at 2:07 AM Youness Alaoui < kakar...@kakaroto.homelinux.net> wrote: > This is the best I can do for you : > > > https://ark.intel.com/products/89608/Intel-Xeon-Processor-E3-1505M-v5-8M-Cache-2_80-GHz > > Product Collection: Intel® Xeon® Processor E3 v5 Family > Code Name: Products formerly Skylake > > kakaroto@kakaroto:~/coding/purism/coreboot$ git grep SOC_INTEL_SKYLAKE > | grep mainboard > src/mainboard/google/chell/Kconfig: select SOC_INTEL_SKYLAKE > src/mainboard/google/glados/Kconfig: select SOC_INTEL_SKYLAKE > src/mainboard/google/lars/Kconfig: select SOC_INTEL_SKYLAKE > src/mainboard/intel/kblrvp/Kconfig: select SOC_INTEL_SKYLAKE > src/mainboard/intel/kunimitsu/Kconfig: select SOC_INTEL_SKYLAKE > src/mainboard/intel/saddlebrook/Kconfig: select SOC_INTEL_SKYLAKE > src/mainboard/purism/librem_skl/Kconfig: select SOC_INTEL_SKYLAKE > > I'm going to assume that the skylake Xeon is supported and will work > (from a coreboot standpoint) just the same as a Core i5 or whatever, > but it might not be the case. That will be your job to figure the rest > out. > > Good luck, > Youness. > > > On Wed, May 30, 2018 at 3:35 PM, Zvi Vered wrote: > > Hello Youness, > > > > Thank you very much for the detailed information ! > > > > Can you please tell what is the best starting point for a XEON board ? > > I think there are no "Intel® XEON® Processor E3-1505M v5" boards in last > > version of coreboot. > > Am I right ? > > > > Best regards, > > Zvika > > > > On Tue, May 29, 2018 at 9:15 PM Youness Alaoui > > wrote: > >> > >> Hi, > >> > >> I suggest you read the wiki : > >> https://www.coreboot.org/Developer_Manual and > >> https://www.coreboot.org/Motherboard_Porting_Guide > >> I would also suggest maybe (optional) that you read my blog posts > >> about my own experience porting coreboot to a new motherboard : > >> https://puri.sm/posts/diving-back-into-coreboot-development/ > >> https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ > >> https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/ > >> https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/ > >> https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/ > >> https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/ > >> > >> To answer your specific questions : It depends on your machine, is it > >> AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or > >> Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs? > >> Depending on the CPU architecture, the CPU 'brand' and even the model > >> of the CPU itself, the port will be done very differently. You'd first > >> want to find a mainboard that is as close as your current one, and > >> start modifying that, there isn't "one mainboard to use as base" > >> because the code, files, etc.. are almost unique depending on the > >> CPU/northbridge/southbridge model, so use the closest one as your > >> base. > >> As far as I know, the file board_info.txt is just information about > >> the board, it's not getting used by coreboot, it's more of an > >> indication for developers. > >> As for the other files, it will depend once again on your board. I'd > >> say Kconfig and devicetree.cb are mandatory, the rest may or may not > >> be mandatory depending on your hardware. The cmos.layout for example > >> isn't mandatory, but you'd probably need it if you enable CMOS support > >> in your KConfig, The 'spd' files containing the RAM's SPD EEPROM > >> information are mandatory only if your board has soldered RAM (common > >> in laptops but not in desktops), but they are not needed (and actually > >> can't be provided) if the motherboard has SODIMM slots instead. So it > >> all depends. Your best bet is to look at what's there and see if you > >> need it or not and if you do, understand what it's for and what needs > >> to be changed in order to match your board. > >> Don't forget that before you get your board to boot with coreboot, you > >> will probably have to flash it and brick your board 100 times, so make > >> sure you have a backup of your o
Re: [coreboot] Porting coreboot to new board
Hello Youness, Thank you very much for the detailed information ! Can you please tell what is the best starting point for a XEON board ? I think there are no "Intel® XEON® Processor E3-1505M v5" boards in last version of coreboot. Am I right ? Best regards, Zvika On Tue, May 29, 2018 at 9:15 PM Youness Alaoui < kakar...@kakaroto.homelinux.net> wrote: > Hi, > > I suggest you read the wiki : > https://www.coreboot.org/Developer_Manual and > https://www.coreboot.org/Motherboard_Porting_Guide > I would also suggest maybe (optional) that you read my blog posts > about my own experience porting coreboot to a new motherboard : > https://puri.sm/posts/diving-back-into-coreboot-development/ > https://puri.sm/posts/librem-13-coreboot-report-january-12-2017/ > https://puri.sm/posts/librem-13-coreboot-report-february-3rd-2017/ > https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017/ > https://puri.sm/posts/coreboot-on-the-librem-13-v2-part-1/ > https://puri.sm/posts/coreboot-on-the-skylake-librems-part-2/ > > To answer your specific questions : It depends on your machine, is it > AMD or is it Intel? Is it Ivybridge or Broadwell or Skylake or > Apollolake, etc.. ? Does it have soldered RAM or does it use SODIMMs? > Depending on the CPU architecture, the CPU 'brand' and even the model > of the CPU itself, the port will be done very differently. You'd first > want to find a mainboard that is as close as your current one, and > start modifying that, there isn't "one mainboard to use as base" > because the code, files, etc.. are almost unique depending on the > CPU/northbridge/southbridge model, so use the closest one as your > base. > As far as I know, the file board_info.txt is just information about > the board, it's not getting used by coreboot, it's more of an > indication for developers. > As for the other files, it will depend once again on your board. I'd > say Kconfig and devicetree.cb are mandatory, the rest may or may not > be mandatory depending on your hardware. The cmos.layout for example > isn't mandatory, but you'd probably need it if you enable CMOS support > in your KConfig, The 'spd' files containing the RAM's SPD EEPROM > information are mandatory only if your board has soldered RAM (common > in laptops but not in desktops), but they are not needed (and actually > can't be provided) if the motherboard has SODIMM slots instead. So it > all depends. Your best bet is to look at what's there and see if you > need it or not and if you do, understand what it's for and what needs > to be changed in order to match your board. > Don't forget that before you get your board to boot with coreboot, you > will probably have to flash it and brick your board 100 times, so make > sure you have a backup of your original ROM copied somewhere safe and > that you have the hardware to re-program the SPI flash externally (and > test that it works), before you attempt to flash it. > Also, make sure you are patient, and ready to learn! > > Good luck! > Youness. > > > On Mon, May 28, 2018 at 10:31 PM, Zvi Vered wrote: > > Hello, > > > > I have to port coreboot to a new "Mainboard" not listed in menuconfig. > > Is there a basic "Mainboard" I should use as a starting point that will > be > > copied to my board ? > > > > The file board_info.txt contains few parameters. > > How can I know the meaning of each parameter and its possible values ? > > > > The board kontron/kt690 for example contains few files like: cmos.layout, > > devicetree.cb, etc > > Are all those files mandatory ? > > Is there a list of mandatory files or routines required in order to port > a > > board ? > > > > Your help is highly appreciated. > > Best regards, > > Zvika > > > > -- > > coreboot mailing list: coreboot@coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Porting coreboot to new board
Hello, I have to port coreboot to a new "Mainboard" not listed in menuconfig. Is there a basic "Mainboard" I should use as a starting point that will be copied to my board ? The file board_info.txt contains few parameters. How can I know the meaning of each parameter and its possible values ? The board kontron/kt690 for example contains few files like: cmos.layout, devicetree.cb, etc Are all those files mandatory ? Is there a list of mandatory files or routines required in order to port a board ? Your help is highly appreciated. Best regards, Zvika -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
