[coreboot] Re: Request help and Support
Hello, Must create Fsp directory (e.g 3rdparty\fsp\RocketLakeFspBinPkg) Create FspBin and Include subdirectory (similar to 3rdparty\fsp\ElkhartLakeBinPkg) Copy the includes from the Intel FSP package to the include subdirectory. Copy the FSP binary to FspBIn The next step is to create Intel soc support (src\soc\intel\rocketlakeport). You can port e.g. \soc\intel\tigerlake to Rocket Lake. Final step is creating src\mainboard. You can port e.g. mainboard\intel\tglrvp. Best regards, Frans Hendriks Eltan B.V. The Netherlands From: rainhe...@savelife-tech.com [mailto:rainhe...@savelife-tech.com] Sent: donderdag 21 april 2022 20:58 To: Lance Zhao Cc: coreboot Subject: [coreboot] Re: Request help and Support Hello: After I signed CNDA with Intel. I have got the FSP of Rocket Lake platform. But I don't know how to use this FSP in Coreboot. Looking forward to your reply Thank you very much [cid:image001.png@01D8594C.7BE40FC0] SAVELIFE® Technology of Yunnan Co., LTD 云南赛莱福科技有限公司 王祥福 (Rainhenry Wang) Tel: +86-13104051251 (Voice calls only support Chinese) E-mail: rainhe...@savelife-tech.com<mailto:rainhe...@savelife-tech.com> Website: www.savelife-tech.com From: Lance Zhao<mailto:lance.z...@gmail.com> Date: 2022-04-22 10:46 To: rainhe...@savelife-tech.com<mailto:rainhe...@savelife-tech.com> CC: coreboot<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Request help and Support https://github.com/intel/FSP I am not sure you can use tiger lake fsp on rocket lake or not. Regards, Lance rainhe...@savelife-tech.com<mailto:rainhe...@savelife-tech.com> mailto:rainhe...@savelife-tech.com>> 于2022年4月21日周四 17:55写道： Hello: I'm Rainhenry Wang from SAVELIFE Technology of Yunnan Co., LTD Company. We are currently developing a computer motherboard. Also want to use Coreboot to develop its BIOS firmware. It is based on Intel's Rocket Lake platform. The PCH model is FH82H510, and the spec code is SRKM2. However, I did not find Rocket Lake platform support code in all versions of Coreboot. So we want to understand and learn in detail how to add the code of another platform into Coreboot. I am not sure whether you have relevant learning resources or documents to share with us? Looking forward to your reply. Thank you very much. [cid:image001.png@01D8594C.7BE40FC0] SAVELIFE® Technology of Yunnan Co., LTD 云南赛莱福科技有限公司 王祥福 (Rainhenry Wang) Tel: +86-13104051251 (Voice calls only support Chinese) E-mail: rainhe...@savelife-tech.com<mailto:rainhe...@savelife-tech.com> ___ coreboot mailing list -- coreboot@coreboot.org<mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-le...@coreboot.org<mailto:coreboot-le...@coreboot.org> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Add ivy bridge/ sandy bridge IFD and ME extracted blobs
Hello Thierry, Adding ME/IFD binaries might require an license. (This depends on the original license supplied with the system) For Facebook fbg7101 license has been arranged with Intel. Google Parrot is uploaded 7 years ago. I don’t know if there was a license at the time. Note: INAL Best regards, Frans Hendriks Eltan B.V. From: Thierry Laurion [mailto:thierry.laur...@gmail.com] Sent: zondag 1 maart 2020 18:59 To: Coreboot Subject: [coreboot] Add ivy bridge/ sandy bridge IFD and ME extracted blobs Hello there, Can Lenovo x230, x220, t430 and t420 (sandy bridge/ivy bridge) ME/IFD binary blobs be added into coreboot-blobs without licensing issues? Non-neutered ME and ifd blobs are already distributed here: https://github.com/coreboot/blobs/tree/master/mainboard. Some are distributed with a license file: https://github.com/coreboot/blobs/blob/master/mainboard/facebook/fbg1701/license.txt Others are distributed without: https://github.com/coreboot/blobs/tree/master/mainboard/google/parrot How does coreboot proceeds into adding board specific blobs into the tree? What is the deal with Intel regarding the ones present without license? Do they tolerate them? Would it be an issue to distribute x230/x220/t430/t530 to ease CI reproducible builds? Asking because nobody dares to answer from the legal perspective. Can we extend coreboot-blobs? https://github.com/osresearch/heads/issues/307#issuecomment-578524123 https://github.com/osresearch/heads/issues/307#issuecomment-552961256 https://github.com/osresearch/heads/issues/307#issuecomment-588264758 Thanks -- Thierry Laurion ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Still need assistance porting to ASUS P8Z77-M
Hi Keith, PCI-to-PCI bridge need to be configured before you can use PCI POST card. Default post code are send out to port 80h. Depending on the chipset (and your needs) you need to enable the port80 to the right channel PCI/LPC. Best regards, Frans Hendriks Eltan B.V. -Original Message- From: Angel Pons [mailto:th3fan...@gmail.com] Sent: vrijdag 28 februari 2020 10:30 To: Keith Hui Cc: coreboot Subject: [coreboot] Re: Still need assistance porting to ASUS P8Z77-M Hi Keith, On Fri, Feb 28, 2020 at 7:18 AM Keith Hui wrote: > > A week ago I wrote here about my problems trying to port coreboot to > my board. Unfortunately I am still no closer to booting. > > In the meantime I flashed my new chip with my OEM firmware backup. It > boots; then I flashed my patched IFD (for chip ID and flash unlock) > and it still boots. So it's not chip compatibility or corrupted > descriptor. > > The only sign of life I got is the bootblock banner left in the SPI > console. My PCI POST card is showing nothing, but knowing that it sits > on a PCIe-PCI bridge (ASM1063 that P8Z77M-PRO does not have) and not > knowing if it needs software init to work, I am now trying to pull > POST codes off the LPC bus over the TPM header, using an Arduino Due. > Do I have to add some early init to have port 80 accesses sent to LPC > bus for this to work? You have to tell coreboot where to route LPC post codes to. It defaults to "None", but you can choose PCI or LPC. I have never tried to print post codes with coreboot, though. I would try using the serial port though, as it is more practical for debugging than post codes. > Thanks for your help > Keith > ___ > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an > email to coreboot-le...@coreboot.org Best regards, Angel Pons ___ 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] Request for review verified boot and measure boot implementation
Hi all, Have a few patchsets waiting for review related to vendor implementation of 'verified boot' and 'measure boot'. This implementation is working/booting on Facebook FBG1701 (Intel Braswell), but not chipset related. Anyone have time for review. Thanks in advance. Met vriendelijke groet / Best regards, Frans Hendriks www.eltan.com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion Computer-On-Module implementations
It's not related to a project but general support for computer-on-module (COM) boards. COM board is a single-board computers containing CPU, Memory, Chipset (SoC). These boards don't contain the standard connectors for I/O. These boards need to be placed on a carrier board (baseboad), which provides the standard I/O connectors and the power. The connection between the COM and carrier boards is a Qseven/Com Express/ETX/etc connector. Also non-standard connection is possible. coreboot is running on COM boards, but the coreboot configuration/settings would depend on the used carrier board. The carrier can also contains EC, SIO devices. In embedded market using COM is very common. The COM board is 'subset' of mainboard. Suggestion is splitting COM board support (which is not a complete mainboard) from carrier support. Regards, Frans -Original Message- From: Julius Werner [mailto:jwer...@chromium.org] Sent: woensdag 10 juli 2019 03:23 To: Patrick Rudolph Cc: Felix Held ; Coreboot Subject: [coreboot] Re: Suggestion Computer-On-Module implementations Could you guys explain your board layout a little more for those of us not familiar with your project? Is this SOM/COM something that runs coreboot code, or just something that the SoC running coreboot code talks to? In the latter case, I would say that it's a peripheral and thus its code belongs under src/drivers/ (e.g. maybe src/drivers/som//). (Although there is some precedent with src/ec and src/superio to have this stuff at top-level... I guess the question is whether this module has the same kind of exceptional position on the board as those other chips.) On Tue, Jul 9, 2019 at 3:42 AM Patrick Rudolph wrote: > > Hi Frans and Felix, > > On 2019-07-09 11:56 AM, Felix Held wrote: > > Hi Frans! > > > >> Proposal is creating a COM directory ‘src/com’ where the module > >> manufacturer and module name are used. (Similar to mainboard). > >> In this src/com directory common module support is placed. > >> mainboard will use this COM module and contains the ‘variant’ code. > > > > Sounds like a good idea to me; I wouldn't call the directory src/com > > though since my first association with that name would be some sort > > of communication device support. Maybe src/som (system on module)? > > > > Technically a SOM/COM wont work at all without a carrier board. > The configuration (devicetree.cb) heavily depends on the carrier > board, but on the other hand the GPIO configuration is likely SOM > specific. > > I guess it's a good idea to put *non mainboard-specific* code in > src/som (or whatever). > On the other hand as already said the variant scheme works quite well. > > > I think I talked with Nico and siro on that some months ago on IRC, > > so it would be good if they could also comment on this. > > > > I think the other option we talked about was having the module as a > > base and the official carrier board as mainboard variant and then > > use the module code in a mainboard with the vendor being the vendor > > of the carrier module which is a variant of the other mainboard code. > > Putting this into a separate directory is probably the cleaner > > option though. > > > > If the variants approach works well for that, I'd like to keep using > > that and not introducing some new infrastructure; if that causes > > some major pain, it might also be worth investigating how to improve > > things there. > > > > Regards > > Felix > > > If we decide to go either way the documentation should be updated to > explain this decision. > > Regards, > Patrick > ___ > 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] Suggestion Computer-On-Module implementations
Hi All, Variants can be used for mainboards. The variants are used for boards within the same mainboard manufacturer directory. Computer-On-Module (COM) can be used on different carriers which do not have same manufacturer. Proposal is creating a COM directory 'src/com' where the module manufacturer and module name are used. (Similar to mainboard). In this src/com directory common module support is placed. mainboard will use this COM module and contains the 'variant' code. What's the opinion on this suggestion? Met vriendelijke groet / Best regards, Frans Hendriks Eltan B.V. www.eltan.com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Intel Braswell uploads
Hi Michal, How about adding both of us as MAINTAINERS for the Braswell patches? Best regards, Frans Hendriks Eltan B.V. -Original Message- From: Nico Huber [mailto:nic...@gmx.de] Sent: donderdag 28 februari 2019 10:49 To: Michal Zygowski ; coreboot@coreboot.org Subject: [coreboot] Re: Intel Braswell uploads Hi Michal, On 28.02.19 10:38, Michal Zygowski wrote: > AFAIK gerrit now adds the reviewers to patches based on MAINTAINERS > file. It would be great to be added automatically to Braswell patches. > Is there a way to workaround that without being Braswell maintainer? you can just push a patch that adds you to the MAINTAINERS file. I don't think there is any requirement to be a maintainer, it's just your offer to look into things. Please also consider removing stale entries and up- dating the status (e.g. from Supported to Maintained, in case you prefer that). You can also set up "Notifications" in Gerrit based on a search pattern. Nico ___ 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: Intel Braswell uploads
An additional question related to this SoC and new mainboards: Should maintainer of Braswell SoC also take care of review/merge new mainboards based on this chipset? Who should merge new boards? (I have uploaded code for two mainboards based on this SoC, where 1 is waiting 3 months to be merged?) Best regards, Frans Hendriks Eltan B.V. -Original Message- From: Patrick Rudolph [mailto:patrick.rudo...@9elements.com] Sent: donderdag 28 februari 2019 09:20 To: Michal Zygowski ; coreboot@coreboot.org Subject: [coreboot] Re: Intel Braswell uploads On Thu, 2019-02-28 at 08:51 +0100, Michal Zygowski wrote: > I would like to submit my candidacy for Braswell SoC maintainership > along with Piotr Król. Since we have 3 Braswell SoC platforms on hand, > we are willing to test any incoming patches to Braswell SoC code base. > We would be glad to become the maintainers. Would like to hear Your > opinions, dear coreboot developers/maintainers, what do You think > about the change? Hi Michal, I'm glad to see that you want to maintain an additional platform. I recommend to email all maintainers, that are not known to be active, as part of the half year release process. If you don't get a response or a bounce message the platform should be marked as unmaintained. What do you think about adding a "supporters section" to the start page of https://coreboot.org/ to ackknowledge companies that really maintain coreboot code. Regards, -- Patrick Rudolph 9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany Email: patrick.rudo...@9elements.com Phone: +49 234 68 94 188 Sitz der Gesellschaft: Bochum Handelsregister: Amtsgericht Bochum, HRB 17519 Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen ___ 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: Intel Xeon D-1577 (16-core)
This relocation is performed in a later stage, so some output is expected. Is (correct) microcode included for D-1577? I assume wbinvd() must be included in smm_relocation() function. (We have implemented coreboot on several Broadwell-DE boards with >4 cores without using wbinv() of 8:SPEW.) Best regards, Frans Hendriks Eltan B.V. -Original Message- From: Jay Talbott [mailto:jaytalb...@sysproconsulting.com] Sent: woensdag 27 februari 2019 22:19 To: aure...@platinasystems.com; coreboot@coreboot.org Subject: [coreboot] Re: Intel Xeon D-1577 (16-core) There's a bug in the SMM relocation code for Broadwell-DE that causes a race condition resulting in the SoC locking up during the MP init. With the stock 4-core SKU that comes in most of the Camelback Mountain CRBs, it's not a problem, which is why Intel didn't find it when they developed the original coreboot implementation for the CRB. But as has been reported previously on this list, it becomes a problem with more than 4 cores. We actually have an open ticket with Intel to see if they are willing to diagnose the root cause and fix it, but I have zero expectation that any action will ever be done on their part at this point. If you turn up your console output level to 8:SPEW, the problem will go away, as the extra printks that get enabled in that case result in serialization of the SMM relocation code on each core, thus masking the race condition (try this first!). Another workaround is to insert a call to wbinvd() in function smm_relocation_handler() in file src/soc/intel/fsp_broadwell_de/smmrelocate.c. This will also result in serialization that masks the race condition (fixed it for us on a 12-core SKU) without needing to have the console turned all the way up. At some point somebody needs to dig into the actual code in smmrelocate.c and identify the root cause of the actual race condition. We just haven't had the time to do any further investigation into the root cause since we have a working workaround. Hope that helps... - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) jaytalb...@sysproconsulting.com http://www.sysproconsulting.com > -Original Message- > From: aure...@platinasystems.com [mailto:aure...@platinasystems.com] > Sent: Wednesday, February 27, 2019 12:46 PM > To: coreboot@coreboot.org > Subject: [coreboot] Intel Xeon D-1577 (16-core) > > Hello, > > I got a daughter-card (DC) based on the Intel's Camelback Mountain CRB. > Coreboot won't boot when a DC is populated with a 16-core Xeon D-1577 > processor. Nothing is printed in the boot process, so it doesn't seem to be > getting very far. However, if i load/program the boot SPI with AMI BIOS > instead of coreboot, then everything is hunky-dory. It boots up all the way > into linux (see below for the platform information when AMI is loaded). In > addition, if DC is populated with a 4-core D-1527 or 2-core D-1508 then > coreboot has no issues (see below for info). > > Is there any configuration that i need to change in coreboot to support the D- > 1577? > > thanks! > > ## AMI BIOS > ## > @unassigned:~$ inxi -F > System:Host: unassigned Kernel: 4.13-platina-mk1 x86_64 (64 bit) >Console: tty 0 Distro: Debian GNU/Linux 8 > Machine: Mobo: Default string model: Default string v: Default string >Bios: American Megatrends v: 5.11 date: 05/31/2017 > CPU: Octa core Intel Xeon D-1577 (-HT-MCP-) cache: 24576 KB >Clock Speeds: 1: 1300 MHz 2: 1300 MHz 3: 1300 MHz 4: 1300 MHz >5: 1300 MHz 6: 1300 MHz 7: 1300 MHz 8: 1300 MHz > Graphics: Card: Failed to Detect Video Card! >Display Server: N/A driver: N/A >tty size: 80x24 Advanced Data: N/A out of X > Network: Card-1: Broadcom Device b960 >IF: N/A state: N/A speed: N/A duplex: N/A mac: N/A >Card-2: Broadcom Device b960 >IF: N/A state: N/A speed: N/A duplex: N/A mac: N/A >Card-3: Intel Device 15ab driver: ixgbe >IF: eth1 state: down mac: 00:a0:c9:00:00:00 >Card-4: Intel Device 15ab driver: ixgbe >IF: eth2 state: down mac: 34:12:78:56:01:00 >Card-5: Intel I210 Gigabit Network Connection driver: igb >IF: eth0 state: up speed: 1000 Mbps duplex: full >mac: 50:18:4c:00:16:a1 > Drives:HDD Total Size: 520.1GB (4.0% used) >ID-1: /dev/sda model: TS512ZBTDM1500T size: 512.1GB >ID-2: USB /dev/sdb model: Echo size: 8.0GB > Partition: ID-1: / size: 451G used: 942M (1%) fs: ext4 dev: /dev/sda1 >ID-2: swap-1 size: 20.75GB used: 0.00GB (0%) fs: swap dev: /dev/sda5 > RAID: No RAID devices: /proc/mdstat
[coreboot] Re: Intel Braswell uploads
Hi, Still no response from MAINTAINERS. Is there a way have to trigger review/merge/reply? Or just keep waiting? Best regards, Frans -Original Message- From: Angel Pons [mailto:th3fan...@gmail.com] Sent: vrijdag 1 februari 2019 11:13 To: Frans Hendriks Cc: coreboot@coreboot.org; hannah.willi...@intel.com Subject: Re: [coreboot] Intel Braswell uploads Hello, On Fri, Feb 1, 2019 at 10:53 AM Frans Hendriks wrote: > > Hi, > > I'm working on Intel Braswell implementation and uploaded several patches. > > It seems that the maintainer of the Intel Braswell is not active for > review/merge/reply of the uploads. > Is the maintainer in MAINTAINERS document correct and still active? > > Met vriendelijke groet / Best regards, > Frans Hendriks > Eltan B.V. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org There are mail addresses on MAINTAINERS. I CC'd this message to the maintainer for braswell so that they can reply to it. Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Braswell FPS memory init problems
Hi Michal, In coreboot 3rdparty package release version is available only. The FSP debug is not available in public. I can't help you with FSP debug in this public community, due too (Intel) license restrictions. If interested in assistance, you can contact us for engineering services. Best regards, Frans -Original Message- From: Michal Zygowski [mailto:michal.zygow...@3mdeb.com] Sent: vrijdag 1 februari 2019 11:47 To: coreboot@coreboot.org Cc: Frans Hendriks Subject: Re: [coreboot] Re: Braswell FPS memory init problems Hi Frans, Thank You for response. Yes, I have also tried setting Channel Config to 0 (DIMM installed), but it does not work either. I have also been playing with CA mirroring and DVFS, but results are the same all the time. Debug FSP? Is such binary available anywhere? Could You point me please where to get it? Best regards, Michał On 01.02.2019 11:38, Frans Hendriks wrote: > Hi Michal, > > Your logging seems to be correct. > Any different behavior when specifying channel 0 as SPD and have FSP using > DIMM spd data? > > Another suggestion is using debug version of FSP. > > Best regards, > Frans > > -Original Message- > From: Michal Zygowski [mailto:michal.zygow...@3mdeb.com] > Sent: dinsdag 29 januari 2019 11:22 > To: coreboot@coreboot.org > Subject: [coreboot] Re: Braswell FPS memory init problems > > Hi Frans, > > These are settings I use in devicetree.cb: > > register "PcdMrcInitTsegSize" = "8" # SMM Region size in MiB > register "PcdMrcInitMmioSize" = "0x0800" > register "PcdMrcInitSpdAddr1" = "0xa0" > register "PcdMrcInitSpdAddr2" = "0xa2" > register "PcdIgdDvmt50PreAlloc" = "1" > register "PcdApertureSize" = "2" > register "PcdGttSize" = "1" > register "PcdDvfsEnable" = "0" > register "PcdCaMirrorEn" = "1" > > Secondly, using common Intel SoC SMBus block implementation, I retrieve SPD > from DIMM and pass it to PcdMemorySpdPtr. Then setting PcdMemChannel0Config > to 1 (soldered down memory) and PcdMemChannel0Config to 2 (DIMM disabled, > because only first channel is populated). PcdMemoryTypeEnable is left default > to 0 (DDR3) which should be correct. > > Here are the logs from Celeron J3160 (I have applied few of Your patches > locally, C_ENV_BOOTBLOCK and FSP MR2 support): > > 1. Using FSP MR2: > > coreboot-4.9-312-gc316fc82b8 Sat Jan 26 19:00:59 UTC 2019 bootblock > starting... > CBFS @ 32 size 4e > CBFS: 'Master Header Locator' located CBFS at [32:80) > CBFS: Locating 'fallback/romstage' > CBFS: Found @ offset 80 size 9564 > > > coreboot-4.9-312-gc316fc82b8 Sat Jan 26 19:00:59 UTC 2019 romstage starting... > CBFS @ 32 size 4e > CBFS: 'Master Header Locator' located CBFS at [32:80) > CBFS: Locating 'fsp.bin' > CBFS: Found @ offset 3fffc0 size 4cc00 > POST: 0x30 > CBFS @ 32 size 4e > CBFS: 'Master Header Locator' located CBFS at [32:80) > CBFS: Locating 'cpu_microcode_blob.bin' > CBFS: Found @ offset 482780 size 44800 > microcode: sig=0x406c4 pf=0x1 revision=0x410 > CONFIG_MMCONF_BASE_ADDRESS: 0xe000 Using FSP 1.1 > FSP_INFO_HEADER: fff20094 > FSP Signature: BSWSBFSP > FSP Header Version: 2 > FSP Revision: 1.1.4.1 > FSP Entry Points: > 0xfff2: Image Base > 0xfff6baa8: TempRamInit > 0xfff6bc01: FspInit > 0xfff6bc0f: MemoryInit > 0xfff6bc16: TempRamExit > 0xfff6bc1d: SiliconInit > 0xfff6bc08: NotifyPhase > 0xfff6cc00: Image End > pm1_sts: 0100 pm1_en: pm1_cnt: > gpe0_sts: gpe0_en: tco_sts: > prsts: 00040910 gen_pmcon1: 00245208 gen_pmcon2: > prev_sleep_state 5 SPD @ 0x50 > SPD: module type is DDR3 > SPD: module part is M471B5273DH0-YK0 > SPD: banks 8, ranks 2, rows 15, columns 10, density 2048 Mb > SPD: device width 8 bits, bus width 64 bits > SPD: module size is 4096 MB (per channel) > POST: 0x32 > POST: 0x33 > FMAP: Found "FLASH" version 1.1 at 30. > FMAP: base = ff80 size = 80 #areas = 4 > FMAP: area RW_MRC_CACHE found @ 31 (65536 bytes) > MRC: no data in 'RW_MRC_CACHE' > No MRC cache found. > POST: 0x34 > VPD Data: 0xfff6452c > UPD Data: 0xfff63494 > Updating UPD values for MemoryInit > POST: 0x36 > UPD values for MemoryInit: > 0x0004 --> 0x0008: PcdMrcInitTsegSize > 0x0800: PcdMrcInitMmioSize > 0xa0: PcdMrcInitSpdAddr1 > 0xa2: PcdMrcInitSpdAddr2 > 0x00 --> 0x01: PcdMem
[coreboot] Re: Braswell FPS memory init problems
RamExit 0xfff6781d: SiliconInit 0xfff67808: NotifyPhase 0xfff68800: Image End pm1_sts: 0100 pm1_en: pm1_cnt: gpe0_sts: gpe0_en: tco_sts: prsts: 00040910 gen_pmcon1: 00245208 gen_pmcon2: prev_sleep_state 5 SPD @ 0x50 SPD: module type is DDR3 SPD: module part is M471B5273DH0-YK0 SPD: banks 8, ranks 2, rows 15, columns 10, density 2048 Mb SPD: device width 8 bits, bus width 64 bits SPD: module size is 4096 MB (per channel) POST: 0x32 POST: 0x33 FMAP: Found "FLASH" version 1.1 at 30. FMAP: base = ff80 size = 80 #areas = 4 FMAP: area RW_MRC_CACHE found @ 31 (65536 bytes) MRC: no data in 'RW_MRC_CACHE' No MRC cache found. POST: 0x34 VPD Data: 0xfff4a39c UPD Data: 0xfff4a3b0 Updating UPD values for MemoryInit POST: 0x36 UPD values for MemoryInit: 0x0004 --> 0x0008: PcdMrcInitTsegSize 0x0800: PcdMrcInitMmioSize 0xa0: PcdMrcInitSpdAddr1 0xa2: PcdMrcInitSpdAddr2 0x00 --> 0x01: PcdMemChannel0Config 0x00 --> 0x02: PcdMemChannel1Config 0x --> 0xfef02ea0: PcdMemorySpdPtr 0x01: PcdIgdDvmt50PreAlloc 0x02: PcdApertureSize 0x01: PcdGttSize 0x00: PcdLegacySegDecode 0x01 --> 0x00: PcdDvfsEnable Calling FspMemoryInit: 0xfff6780f 0x: NvsBufferPtr 0xfef01de4: RtBufferPtr 0xfef01d8c: HobListPtr POST: 0x92 After the post code 0x92 platform seems to not going any further. The dump is from serial port on SuperIO. Thank You in advance. Best regards, Michał On 29.01.2019 10:12, Frans Hendriks wrote: > Hi Michal, > > We have implemented coreboot on Braswell SoC (Pentium N3170) using SPD. > > Did you verify the UDP fields: PcdMemoryTypeEnable, PcdMemorySpdPtr > PcdMemChannel0Config and > PcdMemChannel1Config? > > Do you have some coreboot/FSP logging? > > Best regards, > Frans Hendriks > Eltan B.V. > > -Original Message- > From: Michal Zygowski [mailto:michal.zygow...@3mdeb.com] > Sent: maandag 28 januari 2019 15:48 > To: coreboot@coreboot.org > Cc: Piotr Król > Subject: [coreboot] Braswell FPS memory init problems > > Dear coreboot community, > > I am experiencing problems with FSP Memory Init on Braswell SoCs. FSP Memory > Init is not returning. I have following processors that fail: > Celeron J3060 and Celeron J3160; both have the same issue. > > The platform has 1 SODIMM module on channel 0. I am feeding the UPD header > with correct SPD, but still no luck. I have also tried FSP MR1 and MR2, but > nothing works. > > Is anyone here more experienced with Braswell platforms? Could You give me > some advices? > > Best regards, > > -- > Michał Żygowski > Embedded Systems Engineer > http://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 -- -- Michał Żygowski Embedded Systems Engineer http://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] Intel Braswell uploads
Hi, I'm working on Intel Braswell implementation and uploaded several patches. It seems that the maintainer of the Intel Braswell is not active for review/merge/reply of the uploads. Is the maintainer in MAINTAINERS document correct and still active? Met vriendelijke groet / Best regards, Frans Hendriks Eltan B.V. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Braswell FPS memory init problems
Hi Michal, We have implemented coreboot on Braswell SoC (Pentium N3170) using SPD. Did you verify the UDP fields: PcdMemoryTypeEnable, PcdMemorySpdPtr PcdMemChannel0Config and PcdMemChannel1Config? Do you have some coreboot/FSP logging? Best regards, Frans Hendriks Eltan B.V. -Original Message- From: Michal Zygowski [mailto:michal.zygow...@3mdeb.com] Sent: maandag 28 januari 2019 15:48 To: coreboot@coreboot.org Cc: Piotr Król Subject: [coreboot] Braswell FPS memory init problems Dear coreboot community, I am experiencing problems with FSP Memory Init on Braswell SoCs. FSP Memory Init is not returning. I have following processors that fail: Celeron J3060 and Celeron J3160; both have the same issue. The platform has 1 SODIMM module on channel 0. I am feeding the UPD header with correct SPD, but still no luck. I have also tried FSP MR1 and MR2, but nothing works. Is anyone here more experienced with Braswell platforms? Could You give me some advices? Best regards, -- Michał Żygowski Embedded Systems Engineer http://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] Retrigger gerrit to build
I've uploaded a patch to gerrit, but the build was unstable. This caused by another patch in gerrit, without any relation to my patch. This issue in now solved in gerrit, so my patch should build without any problems now. What is the best/easiest way to trigger gerrit to rebuild ? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
