[coreboot] Re: PSE devices enumeration in corevoot
Hi Sheng, https://mail.coreboot.org/hyperkitty/list/coreboot-ger...@coreboot.org/thread/NQYVLWQ53ZJ3PGKVLMRJEAUXP7N6AEPP/ I tried to pull the commit 112fea3, May I know how to get the given binaries These 3 binaries are not part of the commit? tsnmac.bin tsnconfig.bin psetsnipconfig.bin Thanks Ranga On Thu, Mar 31, 2022 at 3:19 PM Rao G wrote: > Hi Sheng, > > In the coreboot log I see > > PCI: 00:1d.0 [8086/4bb3] disabled > PCI: Static device PCI: 00:1d.1 not found, disabling it. > PCI: Static device PCI: 00:1d.2 not found, disabling it. > > In the FSP debug log I see > > PSE TSN Device: Device Id: 0x, Vendor Id: 0x > PSE TSN Device: Device Id: 0x, Vendor Id: 0x > > Thanks > Ranga > > Thanks > Ranga > > On Thu, Mar 31, 2022 at 3:04 PM Rao G wrote: > >> Hi Sheng, >> >> Thanks for your email and response. >> >> 1. Yes I used unsigned binary - PSE_FW that came along with 638228_PSE >> >> 2. In Device Tree >> device pci 1d.0 off end # Intel Programmable Services Engine IPC >> (local host to PSE) >> device pci 1d.1 on end # Intel Programmable Services Engine >> Time-Sensitive Networking GbE 0 >> device pci 1d.2 on end # Intel Programmable Services Engine >> Time-Sensitive Networking GbE 1 >> >> 3. This is not an RVP but a platform with EHL SoC and I could boot to >> OS/Ubuntu with coreboot BIOS >> >> Do these TSN GbE devices need MAC programming? I don't see them >> enumerated from EFI Shell or in OS/spci >> >> Thanks >> Ranga >> >> >> On Thu, Mar 31, 2022 at 2:34 PM Lean Sheng Tan >> wrote: >> >>> Hi Ranga, >>> Are you using Intel RVP? Yes you should at least be able to see the PSE >>> TSN working if the PSE binary is included correctly (remember to include >>> the 'unsigned' PSE binary from Intel), by turning on PSE TSN devices in >>> devicetree.cb: >>> device pci 1d.1 on end # Intel PSE Time-Sensitive Networking GbE 0 >>> device pci 1d.2 on end # Intel PSE Time-Sensitive Networking GbE 1 >>> >>> Thanks, >>> Sheng >>> >>> On Tue, 29 Mar 2022 at 18:32, Rao G wrote: >>> >>>> Hi All, >>>> >>>> Did anybody work on Elkhart Lake that comes with PSE Firmware? >>>> I don't see any devices getting enumerated which are under PSE >>>> I2C,UART, Gbe,TSN >>>> >>>> The logs shows >>>> >>>> PSE Firmware Status is A138 read from address FE400034 >>>> BIOS: PSE FW is loaded and running >>>> >>>> Looks like FSP is disabling PSE devices to enumerate >>>> >>>> Is this binary enough for coreboot? PSE_FW.bin >>>> [image: image.png] >>>> >>>> Appreciate any pointers that would help to enumerate PSE devices in EFI >>>> Shell >>>> >>>> Thanks >>>> Ranga >>>> ___ >>>> 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: PSE devices enumeration in corevoot
Hi Sheng, In the coreboot log I see PCI: 00:1d.0 [8086/4bb3] disabled PCI: Static device PCI: 00:1d.1 not found, disabling it. PCI: Static device PCI: 00:1d.2 not found, disabling it. In the FSP debug log I see PSE TSN Device: Device Id: 0x, Vendor Id: 0x PSE TSN Device: Device Id: 0x, Vendor Id: 0x Thanks Ranga Thanks Ranga On Thu, Mar 31, 2022 at 3:04 PM Rao G wrote: > Hi Sheng, > > Thanks for your email and response. > > 1. Yes I used unsigned binary - PSE_FW that came along with 638228_PSE > > 2. In Device Tree > device pci 1d.0 off end # Intel Programmable Services Engine IPC > (local host to PSE) > device pci 1d.1 on end # Intel Programmable Services Engine > Time-Sensitive Networking GbE 0 > device pci 1d.2 on end # Intel Programmable Services Engine > Time-Sensitive Networking GbE 1 > > 3. This is not an RVP but a platform with EHL SoC and I could boot to > OS/Ubuntu with coreboot BIOS > > Do these TSN GbE devices need MAC programming? I don't see them enumerated > from EFI Shell or in OS/spci > > Thanks > Ranga > > > On Thu, Mar 31, 2022 at 2:34 PM Lean Sheng Tan > wrote: > >> Hi Ranga, >> Are you using Intel RVP? Yes you should at least be able to see the PSE >> TSN working if the PSE binary is included correctly (remember to include >> the 'unsigned' PSE binary from Intel), by turning on PSE TSN devices in >> devicetree.cb: >> device pci 1d.1 on end # Intel PSE Time-Sensitive Networking GbE 0 >> device pci 1d.2 on end # Intel PSE Time-Sensitive Networking GbE 1 >> >> Thanks, >> Sheng >> >> On Tue, 29 Mar 2022 at 18:32, Rao G wrote: >> >>> Hi All, >>> >>> Did anybody work on Elkhart Lake that comes with PSE Firmware? >>> I don't see any devices getting enumerated which are under PSE I2C,UART, >>> Gbe,TSN >>> >>> The logs shows >>> >>> PSE Firmware Status is A138 read from address FE400034 >>> BIOS: PSE FW is loaded and running >>> >>> Looks like FSP is disabling PSE devices to enumerate >>> >>> Is this binary enough for coreboot? PSE_FW.bin >>> [image: image.png] >>> >>> Appreciate any pointers that would help to enumerate PSE devices in EFI >>> Shell >>> >>> Thanks >>> Ranga >>> ___ >>> 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] PSE devices enumeration in corevoot
Hi All, Did anybody work on Elkhart Lake that comes with PSE Firmware? I don't see any devices getting enumerated which are under PSE I2C,UART, Gbe,TSN The logs shows PSE Firmware Status is A138 read from address FE400034 BIOS: PSE FW is loaded and running Looks like FSP is disabling PSE devices to enumerate Is this binary enough for coreboot? PSE_FW.bin [image: image.png] Appreciate any pointers that would help to enumerate PSE devices in EFI Shell Thanks Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Memory Init failures
Hi All, On elkhartlake_crb https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/elkhartlake_crb/romstage_fsp_params.c ehlcrb_spd_info.read_type = READ_SPD_CBFS; ehlcrb_spd_info.spd_spec.spd_index = 0x00; *Can this setting be changed to READ_SMBUS?* Seeing Memory Init failures in FSP MRC task Early ReadMPR Timing Centering 2D -- FAILED, Status = 6h. Stack Depth: 55724 MRC timer: Total time for SAGV Low point = 11955 msec. MRC task -- debug print: 0 MRC timer: Total time to execute tasks = 11955 msec. Memory initialization has failed It would be great if someone can let me know the settings Thanks Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] EFI Payload and coreboot Debug Control
Hi All, Trying to pass data between EFI Payload and coreboot, my use case is when a setup token is enabled, the data should be read by coreboot and change the DEBUG options in coreboot In EFI Payload values in PcdDebugPropertyMask can be toggled to ON/OFFit Please shed some light onto it Thanks Rao ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: SPIBAR + 0x10 offset with MMIOREAD32 causing exception
This platform is elkhart lake, 32MB SPI flash with coreboot BIOS+EFI Payload Thanks Rao On Fri, Jan 28, 2022 at 5:16 PM Jeff Daly wrote: > What platform are we talking about here, and are you sure this isn’t a bit > of hardware that hasn’t been disabled during boot somehow? > > > > *From:* Rao G > *Sent:* Friday, January 28, 2022 11:55 AM > *To:* Jeff Daly > *Cc:* coreboot > *Subject:* Re: [coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing > exception > > > > *Caution:* This is an external email. Please take care when clicking > links or opening attachments. > > > > That's correct, PCIE_BASE= 0xC000 > > > > On Fri, Jan 28, 2022 at 4:32 PM Jeff Daly wrote: > > And your ECAM base address for PCIE is at 0xC000 ? > > > > *From:* Rao G > *Sent:* Friday, January 28, 2022 11:21 AM > *To:* Jeff Daly ; coreboot > *Subject:* Re: [coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing > exception > > > > *Caution:* This is an external email. Please take care when clicking > links or opening attachments. > > > > Yes 0xC00FD000 (Bus 0 Dev 1F Func 5) not Func 0 > > > > Thanks > > Rao > > > > On Fri, Jan 28, 2022 at 3:40 PM Jeff Daly wrote: > > 0xFD000 is bdf 0/1f/5, not 0/1f/0 > > Is your SPI controller at function 5?That’s where it usually is for > Intel SoCs. > > > > *From:* Rao G > *Sent:* Friday, January 28, 2022 8:31 AM > *To:* coreboot > *Subject:* [coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing > exception > > > > *Caution:* This is an external email. Please take care when clicking > links or opening attachments. > > > > Hi All, > > > > Trying to access SPI Flash from EFI payload > > > > 1) > > SpiInstance->PchSpiBase = MmPciBase ( > DEFAULT_PCI_BUS_NUMBER_PCH, > PCI_DEVICE_NUMBER_PCH_SPI, > PCI_FUNCTION_NUMBER_PCH_SPI > ); > > DEBUG ((DEBUG_INFO, "PchSpiBase at 0x%x\n", SpiInstance->PchSpiBase)); > >> returns PchSpiBase as 0xC00FD000 (Bus 0 Dev 1F Func 0) > > > > > > > > 2) > > ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase + > PCI_BASE_ADDRESSREG_OFFSET) & 0xF000; > > > > Expectation: > > this should return value at 0xC00FD010 > > > > Result > > The above code is throwing processor exception > > > > PchSpiBase at 0xC00FD000 > X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - > ExceptionData - I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0 > RIP - 771903D0, CS - 0038, RFLAGS - 00010046 > > > > Any clues whether SPI flash needs to be enabled in descriptor or any > straps by using FIT tool? > > > > Thanks > > Rao > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: SPIBAR + 0x10 offset with MMIOREAD32 causing exception
That's correct, PCIE_BASE= 0xC000 On Fri, Jan 28, 2022 at 4:32 PM Jeff Daly wrote: > And your ECAM base address for PCIE is at 0xC000 ? > > > > *From:* Rao G > *Sent:* Friday, January 28, 2022 11:21 AM > *To:* Jeff Daly ; coreboot > *Subject:* Re: [coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing > exception > > > > *Caution:* This is an external email. Please take care when clicking > links or opening attachments. > > > > Yes 0xC00FD000 (Bus 0 Dev 1F Func 5) not Func 0 > > > > Thanks > > Rao > > > > On Fri, Jan 28, 2022 at 3:40 PM Jeff Daly wrote: > > 0xFD000 is bdf 0/1f/5, not 0/1f/0 > > Is your SPI controller at function 5?That’s where it usually is for > Intel SoCs. > > > > *From:* Rao G > *Sent:* Friday, January 28, 2022 8:31 AM > *To:* coreboot > *Subject:* [coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing > exception > > > > *Caution:* This is an external email. Please take care when clicking > links or opening attachments. > > > > Hi All, > > > > Trying to access SPI Flash from EFI payload > > > > 1) > > SpiInstance->PchSpiBase = MmPciBase ( > DEFAULT_PCI_BUS_NUMBER_PCH, > PCI_DEVICE_NUMBER_PCH_SPI, > PCI_FUNCTION_NUMBER_PCH_SPI > ); > > DEBUG ((DEBUG_INFO, "PchSpiBase at 0x%x\n", SpiInstance->PchSpiBase)); > >> returns PchSpiBase as 0xC00FD000 (Bus 0 Dev 1F Func 0) > > > > > > > > 2) > > ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase + > PCI_BASE_ADDRESSREG_OFFSET) & 0xF000; > > > > Expectation: > > this should return value at 0xC00FD010 > > > > Result > > The above code is throwing processor exception > > > > PchSpiBase at 0xC00FD000 > X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - > ExceptionData - I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0 > RIP - 771903D0, CS - 0038, RFLAGS - 00010046 > > > > Any clues whether SPI flash needs to be enabled in descriptor or any > straps by using FIT tool? > > > > Thanks > > Rao > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: SPIBAR + 0x10 offset with MMIOREAD32 causing exception
Yes 0xC00FD000 (Bus 0 Dev 1F Func 5) not Func 0 Thanks Rao On Fri, Jan 28, 2022 at 3:40 PM Jeff Daly wrote: > 0xFD000 is bdf 0/1f/5, not 0/1f/0 > > Is your SPI controller at function 5?That’s where it usually is for > Intel SoCs. > > > > *From:* Rao G > *Sent:* Friday, January 28, 2022 8:31 AM > *To:* coreboot > *Subject:* [coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing > exception > > > > *Caution:* This is an external email. Please take care when clicking > links or opening attachments. > > > > Hi All, > > > > Trying to access SPI Flash from EFI payload > > > > 1) > > SpiInstance->PchSpiBase = MmPciBase ( > DEFAULT_PCI_BUS_NUMBER_PCH, > PCI_DEVICE_NUMBER_PCH_SPI, > PCI_FUNCTION_NUMBER_PCH_SPI > ); > > DEBUG ((DEBUG_INFO, "PchSpiBase at 0x%x\n", SpiInstance->PchSpiBase)); > >> returns PchSpiBase as 0xC00FD000 (Bus 0 Dev 1F Func 0) > > > > > > > > 2) > > ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase + > PCI_BASE_ADDRESSREG_OFFSET) & 0xF000; > > > > Expectation: > > this should return value at 0xC00FD010 > > > > Result > > The above code is throwing processor exception > > > > PchSpiBase at 0xC00FD000 > X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - > ExceptionData - I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0 > RIP - 771903D0, CS - 0038, RFLAGS - 00010046 > > > > Any clues whether SPI flash needs to be enabled in descriptor or any > straps by using FIT tool? > > > > Thanks > > Rao > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] SPIBAR + 0x10 offset with MMIOREAD32 causing exception
Hi All, Trying to access SPI Flash from EFI payload 1) SpiInstance->PchSpiBase = MmPciBase ( DEFAULT_PCI_BUS_NUMBER_PCH, PCI_DEVICE_NUMBER_PCH_SPI, PCI_FUNCTION_NUMBER_PCH_SPI ); DEBUG ((DEBUG_INFO, "PchSpiBase at 0x%x\n", SpiInstance->PchSpiBase)); >> returns PchSpiBase as 0xC00FD000 (Bus 0 Dev 1F Func 0) 2) ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase + PCI_BASE_ADDRESSREG_OFFSET) & 0xF000; Expectation: this should return value at 0xC00FD010 Result The above code is throwing processor exception PchSpiBase at 0xC00FD000 X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - ExceptionData - I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0 RIP - 771903D0, CS - 0038, RFLAGS - 00010046 Any clues whether SPI flash needs to be enabled in descriptor or any straps by using FIT tool? Thanks Rao ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] EFI menu using UART console
Hi All, Good morning! EFI Payload in coreboot has enabled MdeModulePkg/Universal/SerialDxe/SerialDxe.inf in .dsc/.fdf file There is a *SerialRead *function in this DXE Driver, am trying to access F2 from UART Console but this does not work, How to enable this feature? Who is invoking SerialRead from the platform? Thanks for your time! Best Regards Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Gopdriver into coreboot
Thanks Michal for your response. On Thu, Dec 2, 2021 at 2:08 PM Michał Żygowski wrote: > Hi Ranga, > > > > Trying to figure out how the GOP driver is enabled/added in the coreboot > > tree. > > > > IntelGraphicsPeim.efi > > IntelGopDriver.efi > > > > Above 2 drivers part of FSP? > > IntelGraphicsPeim.efi is included in the FSP. For the DXE GOP driver you > have to integrate it into your final solution, e.g. tianocore payload > (and additionally provide GOP policy protocol). > > To use the graphics PEIM, include your VBT in CBFS and in the coreboot > menuconfig select: Devices -> Graphics Initialization -> Run GOP driver > VBT can be included in the Device submenu. > > > Best regards, > > -- > Michał Żygowski > Firmware Engineer > GPG: 6B5BA214D21FCEB2 > https://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] Gopdriver into coreboot
Hi All, Trying to figure out how the GOP driver is enabled/added in the coreboot tree. IntelGraphicsPeim.efi IntelGopDriver.efi Above 2 drivers part of FSP? Intel is providing DisCon tool to configure VBT, this tool is a replacement for BMP which is EOL Thanks for your time! Best Regards Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Question on flashrom 1.2
Hi Coreboot Team, Am trying flashrom 1.2 on W25R256JVEIQ NOR flash. Datasheet below https://www.mouser.ie/datasheet/2/949/Winbond_Electronics_Corporation_11012018_W25R256JV-1499901.pdf Flashrom supports below winbond DEVID's but not W25R series? In Ubuntu /sys/class/mtd0 does not exist error is seen #define WINBOND_NEX_W25Q40_V 0x4013 /* W25Q40BV; W25Q40BL (2.3-3.6V) */ #define WINBOND_NEX_W25Q80_V 0x4014 /* W25Q80BV */ #define WINBOND_NEX_W25Q16_V 0x4015 /* W25Q16CV; W25Q16DV */ #define WINBOND_NEX_W25Q32_V 0x4016 /* W25Q32BV; W25Q32FV in SPI mode (default) */ #define WINBOND_NEX_W25Q64_V 0x4017 /* W25Q64BV, W25Q64CV; W25Q64FV in SPI mode (default) */ #define WINBOND_NEX_W25Q128_V 0x4018 /* W25Q128BV; W25Q128FV in SPI mode (default) */ #define WINBOND_NEX_W25Q256_V 0x4019 /* W25Q256FV or W25Q256JV_Q (QE=1) */ #define WINBOND_NEX_W25Q512JV 0x4020 /* W25Q512JV */ #define WINBOND_NEX_W25Q20_W 0x5012 /* W25Q20BW */ #define WINBOND_NEX_W25Q40BW 0x5013 /* W25Q40BW */ #define WINBOND_NEX_W25Q80BW 0x5014 /* W25Q80BW */ #define WINBOND_NEX_W25Q40EW 0x6013 /* W25Q40EW */ #define WINBOND_NEX_W25Q80EW 0x6014 /* W25Q80EW */ #define WINBOND_NEX_W25Q16_W 0x6015 /* W25Q16DW */ #define WINBOND_NEX_W25Q32_W 0x6016 /* W25Q32DW; W25Q32FV in QPI mode */ #define WINBOND_NEX_W25Q64_W 0x6017 /* W25Q64DW; W25Q64FV in QPI mode */ #define WINBOND_NEX_W25Q128_W 0x6018 /* W25Q128FW; W25Q128FV in QPI mode */ #define WINBOND_NEX_W25Q256_W 0x6019 /* W25Q256JW */ #define WINBOND_NEX_W25Q128_V_M 0x7018 /* W25Q128JVSM */ #define WINBOND_NEX_W25Q256JV_M 0x7019 /* W25Q256JV_M (QE=0) */ #define WINBOND_NEX_W25Q32JW_M 0x8016 /* W25Q32JW...M */ #define WINBOND_NEX_W25Q64JW_M 0x8017 /* W25Q64JW...M */ #define WINBOND_NEX_W25Q128_DTR 0x8018 /* W25Q128JW_DTR */ #define WINBOND_NEX_W25Q256_DTR 0x8019 /* W25Q256JW_DTR aka W25Q256256JW-IM */ Is anyone aware whether the specific DEVID not supporting causes /sys/class/mtd0 does not exist? Thanks for your time! Best Regards Rao ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: GPU clock throttling on Intel Atom family
Hi All, Any clues on GPU throttling? BR's Ranga On Thu, Oct 21, 2021 at 2:42 PM Rao G wrote: > Hi All, > > Trying to enable GPU clock throttling on Intel Gen 7 UHD > > The SoC is E3815 Atom BayTrail > > On Ubuntu > > *command* > *i*ntel_gpu_frequency > > *output* > cur:200MHz > min:200MHz > RP1:400MHz > max:400 MHz > > Can GPU Frequency be throttled? Any specific registers to enable > throttling for GPU/GFX > > Thanks > Ranga > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] GPU clock throttling on Intel Atom family
Hi All, Trying to enable GPU clock throttling on Intel Gen 7 UHD The SoC is E3815 Atom BayTrail On Ubuntu *command* *i*ntel_gpu_frequency *output* cur:200MHz min:200MHz RP1:400MHz max:400 MHz Can GPU Frequency be throttled? Any specific registers to enable throttling for GPU/GFX Thanks Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] PXE on Coreboot
Hi Coreboot Developers, Very warm greetings! Trying to enable PXE along with UEFI payload on Elkhart Lake CRB platform Enabling Network stack requires below DXE drivers to be enabled https://github.com/tianocore/edk2/blob/vUDK2018/MdeModulePkg/MdeModulePkg.dsc MdeModulePkg/Universal/Network/ArpDxe/ArpDxe.inf MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Dxe.inf MdeModulePkg/Universal/Network/DpcDxe/DpcDxe.inf MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Dxe.inf MdeModulePkg/Universal/Network/IScsiDxe/IScsiDxe.inf MdeModulePkg/Universal/Network/MnpDxe/MnpDxe.inf MdeModulePkg/Universal/Network/VlanConfigDxe/VlanConfigDxe.inf MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf MdeModulePkg/Universal/Network/SnpDxe/SnpDxe.inf MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf [Components.IA32, Components.X64, Components.IPF, Components.AARCH64] MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf Please send your comments/views on how to enable PXE with uEFI payload, It is also okay incase if there is an alternate approach to enable PXE without UEFI payload. Thanks Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: There is a python in our toolchain?!?
Hi Patrick, That's good to hear, would there be change to "make menuconfig" with kconfiglib Thanks Ranga On Wed, Sep 29, 2021 at 10:58 AM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote: > Hi everybody, > > Historically, coreboot avoided depending on python too much (we got rid of > an entire python based configuration and build system, for example), with > few minor exceptions. > > The main reason has been that while python code is quick to slap together, > it has demonstrated a penchant for breaking in all kinds of mysterious ways > (python 2->3 really was just a slightly bigger instance of what's going on > in python all the time), and its users demonstrate a disregard for their > fellow developers as demonstrated by endless stack traces on trivial errors > (or is the language too complicated to properly catch them all?) > > While probably nice for one-off prototypes, long term maintenance is a > concern: this project has over 20 years of history under its belt, with > more to come. > > That said, python makes its way back into the tree every now and then > (typically as small snippets to compute and add hashes to binaries as > needed by ARM SoCs). Uncanny, but typically not a big deal. > > There are two bigger initiatives proposed that would significantly > increase our python footprint: > 1. Replacing Linux's kconfig with kconfiglib ( > https://review.coreboot.org/c/coreboot/+/48679) > 2. Using pytest for end-to-end testing utilities ( > https://review.coreboot.org/c/coreboot/+/57869) > > Compared to the "inject a hash value at a fixed location" scripts, these > would probably be here to stay, and sufficiently integrated that everybody > will have to deal with them. > > People spending time working on python code when it has no chance to land > isn't a good use of their time and we should avoid that in the project. > > People spending time arguing that python shouldn't be used (to avoid > the other outcome) even though the project's culture shifted and is now > accepting Python isn't creating a great community for anybody. > > To avoid these scenarios, could we possibly nail down the policy on python > in coreboot? > > > Regards, > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > ___ > 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: Question On External Display
Hi Matt, Compared VBT data in pre-OS and OS, the data is identical. Likely issue due to MMIO registers not configured correctly defined in below spec? https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol10_-_display_0.pdf The LVDS display which is on DDI0 is fine so I could switch to OS and get VBT data. DP/HDMI/DVI on DDI1 in windows is causing the issue. I expect coreboot is filling below mailbox's correctly? INTEL_IGD_OPREGION_MBOX1 MBox1; // Mailbox 1: Public ACPI Methods INTEL_IGD_OPREGION_MBOX2 MBox2; // Mailbox 2: Software SCI Inteface INTEL_IGD_OPREGION_MBOX3 MBox3; // Mailbox 3: BIOS/Driver Communication INTEL_IGD_OPREGION_VBTVBT; // Video BIOS Table (OEM customizable data) Regards Rao On Thu, Aug 12, 2021 at 10:24 AM Rao G wrote: > Thank you Matt. > > the VBT data in BIOS and VBT data captured in OS if they remain identical > would that mean this problem > is not due to VBT data copied into ACPINVS igd_opregion? > > Attaching VBT data for this platform which is captured from OS > > also Xrandr output on each Video Interface > > On Wed, Aug 11, 2021 at 3:28 PM Matt DeVillier > wrote: > >> On Wed, Aug 11, 2021 at 5:05 AM Rao G wrote: >> > >> > Thanks Nico for your response. >> > >> > > am expecting some register should set with eDP as interface and when >> > > display is connected >> > > >> > > any clue why the i915 OS driver was turning off DP display in case 2? >> > I assume the HPD signal doesn't get through to the software. >> > >> > [Rao] >> > You mean I need to check PORT_HOTPLUG_EN and PORT_HOTPLUG_STAT mmio >> offsets for this issue? >> > BIOS display is fine, Windows logo is also seen but there is no signal >> when "windows login" is reached >> >> IME, that's almost always due to incorrect/missing/mismatched VBT data >> in the ACPI opregion/mailbox >> >> > >> > It had similar behaviour w.r.t to ubuntu 18.04, I configured DDI1 to >> "DP with HDMI/DVI" >> > >> > Can this issue be fixed with VBE data configured through BMP or it >> needs a fix from graphics MMIO? >> > >> > Regards >> > Rao >> > >> > On Fri, Jul 30, 2021 at 10:27 PM Nico Huber wrote: >> >> >> >> On 30.07.21 18:59, Rao G wrote: >> >> > Thanks Nico. >> >> > >> >> > HPD is active , measured the signal >> >> >> >> Is your coreboot port public somewhere? If the hardware is fine, maybe >> >> the firmware isn't? >> >> >> >> > >> >> > Configured Ports >> >> > 1.DDI0- PortB - DP with HDMI/DVI is good in BIOS & OS >> >> > 2.DDI1- PortC - DP with HDMI/DVI is good in BIOS, i915 was turning >> off the >> >> > DP display (Never understood the reason) >> >> >> >> It's very suspicious that these two behave differently. Does the HPD >> >> signal (MMIO read) work for DDI0? >> >> >> >> > >> >> > So configured PortC with eDP >> >> > >> >> > If there is no way BIOS to detect the external display with MMIO >> registers >> >> > when configured as eDP, Can i not turn off the DDI1/Port C at >> runtime in >> >> > BIOS, >> >> >> >> Maybe it's time to switch to an open-source solution? libgfxinit will >> >> probably have the same issue, but it might be possible to get a rather >> >> short delay. >> >> >> >> > am expecting some register should set with eDP as interface and when >> >> > display is connected >> >> > >> >> > any clue why the i915 OS driver was turning off DP display in case 2? >> >> >> >> I assume the HPD signal doesn't get through to the software. >> >> >> >> 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: Question On External Display
Thank you Matt. the VBT data in BIOS and VBT data captured in OS if they remain identical would that mean this problem is not due to VBT data copied into ACPINVS igd_opregion? Attaching VBT data for this platform which is captured from OS also Xrandr output on each Video Interface On Wed, Aug 11, 2021 at 3:28 PM Matt DeVillier wrote: > On Wed, Aug 11, 2021 at 5:05 AM Rao G wrote: > > > > Thanks Nico for your response. > > > > > am expecting some register should set with eDP as interface and when > > > display is connected > > > > > > any clue why the i915 OS driver was turning off DP display in case 2? > > I assume the HPD signal doesn't get through to the software. > > > > [Rao] > > You mean I need to check PORT_HOTPLUG_EN and PORT_HOTPLUG_STAT mmio > offsets for this issue? > > BIOS display is fine, Windows logo is also seen but there is no signal > when "windows login" is reached > > IME, that's almost always due to incorrect/missing/mismatched VBT data > in the ACPI opregion/mailbox > > > > > It had similar behaviour w.r.t to ubuntu 18.04, I configured DDI1 to "DP > with HDMI/DVI" > > > > Can this issue be fixed with VBE data configured through BMP or it needs > a fix from graphics MMIO? > > > > Regards > > Rao > > > > On Fri, Jul 30, 2021 at 10:27 PM Nico Huber wrote: > >> > >> On 30.07.21 18:59, Rao G wrote: > >> > Thanks Nico. > >> > > >> > HPD is active , measured the signal > >> > >> Is your coreboot port public somewhere? If the hardware is fine, maybe > >> the firmware isn't? > >> > >> > > >> > Configured Ports > >> > 1.DDI0- PortB - DP with HDMI/DVI is good in BIOS & OS > >> > 2.DDI1- PortC - DP with HDMI/DVI is good in BIOS, i915 was turning > off the > >> > DP display (Never understood the reason) > >> > >> It's very suspicious that these two behave differently. Does the HPD > >> signal (MMIO read) work for DDI0? > >> > >> > > >> > So configured PortC with eDP > >> > > >> > If there is no way BIOS to detect the external display with MMIO > registers > >> > when configured as eDP, Can i not turn off the DDI1/Port C at runtime > in > >> > BIOS, > >> > >> Maybe it's time to switch to an open-source solution? libgfxinit will > >> probably have the same issue, but it might be possible to get a rather > >> short delay. > >> > >> > am expecting some register should set with eDP as interface and when > >> > display is connected > >> > > >> > any clue why the i915 OS driver was turning off DP display in case 2? > >> > >> I assume the HPD signal doesn't get through to the software. > >> > >> Nico > > > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > VBT header: VBT signature: "$VBT VALLEYVIEW " VBT version:0x0486 (11.58) VBT header size:0x0030 (48) VBT size: 0x11b2 (4530) VBT checksum: 0x24 BDB offset: 0x0030 (48) BDB header: BDB signature: "BIOS_DATA_BLOCK " BDB version:155 BDB header size:0x0016 (22) BDB size: 0x1182 (4482) BDB blocks present: 1 2 4 6 7 8 10 12 13 14 15 16 17 18 19 20 27 40 41 42 43 44 60 61 62 63 64 254 BDB block 1 - General features block: Panel fitting: text & graphics Flexaim: no Message: no Clear screen: 0 DVO color flip required: no External VBT: no Enable SSC: no LFP on override: no Disable SSC on clone: no Underscan support for VGA timings: no Hotplug support in VBIOS: no Disable smooth vision: no Single DVI for CRT/DVI: no Inverted FDI Rx polarity: no Legacy monitor detect: yes Integrated CRT: yes Integrated TV: no Integrated EFP: no DP SSC enable: no DP SSC dongle supported: no BDB block 2 - General definitions block: CRT DDC GMBUS addr: 0x02 Use ACPI DPMS CRT power states: no Skip CRT detect at boot: no Use DPMS on AIM devices: yes Boot display type: 0x Child device size: 33 Child device count: 5 Child device info:
[coreboot] Re: Question On External Display
Thanks Nico for your response. > am expecting some register should set with eDP as interface and when > display is connected > > any clue why the i915 OS driver was turning off DP display in case 2? I assume the HPD signal doesn't get through to the software. [*Rao*] You mean I need to check PORT_HOTPLUG_EN and PORT_HOTPLUG_STAT mmio offsets for this issue? BIOS display is fine, Windows logo is also seen but there is no signal when "windows login" is reached It had similar behaviour w.r.t to ubuntu 18.04, I configured DDI1 to "DP with HDMI/DVI" Can this issue be fixed with VBE data configured through BMP or it needs a fix from graphics MMIO? Regards Rao On Fri, Jul 30, 2021 at 10:27 PM Nico Huber wrote: > On 30.07.21 18:59, Rao G wrote: > > Thanks Nico. > > > > HPD is active , measured the signal > > Is your coreboot port public somewhere? If the hardware is fine, maybe > the firmware isn't? > > > > > Configured Ports > > 1.DDI0- PortB - DP with HDMI/DVI is good in BIOS & OS > > 2.DDI1- PortC - DP with HDMI/DVI is good in BIOS, i915 was turning off > the > > DP display (Never understood the reason) > > It's very suspicious that these two behave differently. Does the HPD > signal (MMIO read) work for DDI0? > > > > > So configured PortC with eDP > > > > If there is no way BIOS to detect the external display with MMIO > registers > > when configured as eDP, Can i not turn off the DDI1/Port C at runtime in > > BIOS, > > Maybe it's time to switch to an open-source solution? libgfxinit will > probably have the same issue, but it might be possible to get a rather > short delay. > > > am expecting some register should set with eDP as interface and when > > display is connected > > > > any clue why the i915 OS driver was turning off DP display in case 2? > > I assume the HPD signal doesn't get through to the software. > > Nico > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question On External Display
Thanks Nico. HPD is active , measured the signal Configured Ports 1.DDI0- PortB - DP with HDMI/DVI is good in BIOS & OS 2.DDI1- PortC - DP with HDMI/DVI is good in BIOS, i915 was turning off the DP display (Never understood the reason) So configured PortC with eDP If there is no way BIOS to detect the external display with MMIO registers when configured as eDP, Can i not turn off the DDI1/Port C at runtime in BIOS, am expecting some register should set with eDP as interface and when display is connected any clue why the i915 OS driver was turning off DP display in case 2? Regards Rao On Fri, Jul 30, 2021 at 4:49 PM Nico Huber wrote: > Hi, > > On 30.07.21 16:47, Rao G wrote: > > The problem originally I had was that on PortC, DP/HDMI did not work for > > the external display in the OS, In BIOS it looked good, > > so I configured PortC as an eDP interface then the external display > started > > working in the OS. > > this sounds much like you are still facing the same problem. When you > configure the port as eDP, Linux' i915 will simply skip reading the > exact register we are looking (and just assume the display is present). > > Have you tried to measure the hotplug signal when your display is > connected/disconnected? Maybe something is physically wrong with the > board design, cable, or display? > > Nico > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Question On External Display
Hi Nico, Thanks for your email & response. The problem originally I had was that on PortC, DP/HDMI did not work for the external display in the OS, In BIOS it looked good, so I configured PortC as an eDP interface then the external display started working in the OS. Now at runtime when there is no external display, the VBIOS is causing delay, so I want to disable PortC for eDP at runtime when there is no external display connected. So am trying to find which MMIO register gets set when there is external Display connected to DisplayPort Thanks Rao On Fri, Jul 30, 2021 at 3:29 PM Rao G wrote: > Hi Nico, > > Thanks for your response, though I enabled Bits 29,28,27 in 0x61110h, the > values in 0x61114h returned 0, > I have configured the port as eDP in VBIOS not as HDMI/DP, will that > make a difference? > For eDP which MMIO register need to be checked? > > Thanks > Rao > > On Fri, Jul 30, 2021 at 2:47 PM Nico Huber wrote: > >> Hello Rao, >> >> On 30.07.21 13:53, Rao G wrote: >> > trying to see the MMIO or VBIOS data when a external display device is >> > plugged/unplugged with DP/HDMI interface, which MMIO register is set or >> > cleared >> >> I think you are looking at the right register (last one below). >> >> > >> > Any inputs are appreciated, some of the registers tried on Port B/Port C >> > are given below. when Display is connected and when Display is not >> > connected, both these instances >> > return the same data. Looking for register/bit that sets/clears when >> > external display is connected/disconnected >> > >> > printk(BIOS_DEBUG, "Intel Gfx BAR GTTMMADR\n"); >> > printk(BIOS_DEBUG, " DP_B %X\n", read32(bar+0x18+0x64100)); >> > printk(BIOS_DEBUG, " DP_C %X\n", read32(bar+0x18+0x64200)); >> > printk(BIOS_DEBUG, " HDMIC %X\n", read32(bar+0x18+0x61160)); >> > printk(BIOS_DEBUG, " HDMIB %X\n", read32(bar+0x18+0x61140)); >> > printk(BIOS_DEBUG, " Hotplug control %X\n", >> read32(bar+0x18+0x61164)); >> > printk(BIOS_DEBUG, " pipeA control %X\n", read32(bar+0x18+0x61204)); >> > printk(BIOS_DEBUG, " pipeB control %X\n", read32(bar+0x18+0x61304)); >> > printk(BIOS_DEBUG, " porthot plug stat %X\n", >> read32(bar+0x18+0x61114)); >> >> According to the datasheet, the bits in this register should change but >> only if enabled in PORT_HOTPLUG_EN (0x61110). >> >> Nico >> >> NB. There is also libgfxinit support under review [1]. In case you are >> trying to do some native graphics init ;) >> >> [1] https://review.coreboot.org/q/topic:%2522baytrail-libgfxinit%2522 >> > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Question On External Display
Hi All, Hope you are doing well. Platform Baytrail Issue: Graphics External Display VBIOS/VBT data trying to see the MMIO or VBIOS data when a external display device is plugged/unplugged with DP/HDMI interface, which MMIO register is set or cleared Any inputs are appreciated, some of the registers tried on Port B/Port C are given below. when Display is connected and when Display is not connected, both these instances return the same data. Looking for register/bit that sets/clears when external display is connected/disconnected printk(BIOS_DEBUG, "Intel Gfx BAR GTTMMADR\n"); printk(BIOS_DEBUG, " DP_B %X\n", read32(bar+0x18+0x64100)); printk(BIOS_DEBUG, " DP_C %X\n", read32(bar+0x18+0x64200)); printk(BIOS_DEBUG, " HDMIC %X\n", read32(bar+0x18+0x61160)); printk(BIOS_DEBUG, " HDMIB %X\n", read32(bar+0x18+0x61140)); printk(BIOS_DEBUG, " Hotplug control %X\n", read32(bar+0x18+0x61164)); printk(BIOS_DEBUG, " pipeA control %X\n", read32(bar+0x18+0x61204)); printk(BIOS_DEBUG, " pipeB control %X\n", read32(bar+0x18+0x61304)); printk(BIOS_DEBUG, " porthot plug stat %X\n", read32(bar+0x18+0x61114)); *Display SPEC* https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol10_-_display_0.pdf Thanks Rao ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: ASUS F2A85-M PRO VGA BIOS binary extraction
You can extract the VBIOS.rom after booting to OS, incase it is linux echo 1 > /sys/devices/pci:00/:00:02.0/rom cat /sys/devices/pci:00/:00:02.0/rom > vbios.dump echo 0 > /sys/devices/pci:00/:00:02.0/rom the .rom file can be opened with Intel BMP tool On Tue, Jun 8, 2021 at 8:11 PM se7enge via coreboot wrote: > Okay thanks guys, I was hoping for a way to extract the VGA binary from > the bios image, on a separate machine as I don't have this new one up and > running yet, but I will definitely try the method mentioned by Paul. Should > be able to boot into a live Linux environment and extract the binary from > there following the wiki. > > I'll let you know if I run into any serious issues which I can't resolve; > looks to be doable though. > > Kind regards, > se7enge > > ‐‐‐ Original Message ‐‐‐ > > On Monday, June 7th, 2021 at 3:38 PM, Raul Rangel > wrote: > > > You might also want to try > https://github.com/al3xtjames/ghidra-firmware-utils > > > > From what I remember it allows browsing the .bin. > > > > On Sat, Jun 5, 2021 at 5:12 PM Paul Menzel pmen...@molgen.mpg.de wrote: > > > > > Dear se7enge, > > > > > > Am 05.06.21 um 19:52 schrieb se7enge via coreboot: > > > > > > > I am about to embark on a mission to install coreboot on an ASUS > > > > > > > > F2A85-M PRO (w/ AMD A10-6800k) desktop machine. Admittedly, I don't > > > > > > > > have much experience in this field and am not extremely technical; > > > > > > > > but I am willing to learn and put in the effort needed. > > > > > > > > My main question to you at this time is regarding the extraction of > > > > > > > > the VGA BIOS binary, in order to make the integrated GPU function as > > > > > > > > intended, and how one goes about doing it. I have downloaded the > > > > > > > > available .CAP (BIOS image?) file from the official Asus support page > > > > > > > > (https://www.asus.com/supportonly/F2A85-M PRO/HelpDesk_BIOS/) and I > > > > > > > > can see that on your own documentation page for the ASUS F2A85-M > > > > > > > > (https://doc.coreboot.org/mainboard/asus/f2a85-m.html) you have > > > > > > > > recommended that one should use 'MMTool Aptio' in order to load the > > > > > > > > image and extract the VGA binary. However, I have struggled to find > > > > > > > > any official download or support page for this tool and it does not > > > > > > > > appear to be in my official distro repository or the AUR either. I am > > > > > > > > therefore seemingly unable to get a hold of it and follow your > > > > > > > > documentation. > > > > > > > > Please could you advise on the best way to solve this problem so that > > > > > > > > I may successfully extract the needed binary and continue on to > > > > > > > > compile the coreboot ROM. Any support is much appreciated :) > > > > > > > > I extracted it directly from within GNU/Linux following the Wiki page > > > > > > > > VGA support 1. > > > > > > Note, to get graphics before the Linux kernel initializes it (using the > > > > > > ROM), I have to run it in SeaBIOS. Letting coreboot run the VGA BIOS > > > > > > Option ROM is not working here. > > > > > > I never tried if there is an UEFI GOP driver(?) which could be used > with > > > > > > (?) TianoCore. > > > > > > Kind regards, > > > > > > Paul > > > > > > PS: After you get it going, it’d be really great if you extended the > > > > > > documentation and maybe even moved the information from the Wiki to the > > > > > > documentation folder. You only need to know Markdown for that. > > > > > > 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] Re: Display Port Monitor turns off during Ubuntu OS boot
Hi Mike, Yes the platform uses coreboot, the display is fine in BIOS only in the OS ubuntu it turns off Is it required to dump the graphics registers in OS through intel-gpu-tools? https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol10_-_display_0.pdf Anyone come across similar behavior with display port? HDMI, LVDS, DVI all works well Thanks Rao On Tue, Mar 2, 2021 at 3:29 PM Mike Banon wrote: > Is your platform coreboot-supported, if yes - have you tested it with > coreboot? > > On Thu, Feb 25, 2021 at 9:09 PM Rao G wrote: > > > > Hi Coreboot Team, > > > > There is an external Monitor which works on HDMI/DVI and also DP , In > BIOS the display is good whereas in OS (Ubuntu 18.04) until the kernel is > initialized and i915 Video driver > > is loaded display is perfect, looks like the i915 OS driver switches off > the monitor and there is no signal > > > > Does ACPI GFX method have to return any External display specific data > to the OS driver ? > > Tried to make changes to VBIOS but did not help, thought ASL code is > missing under GFX0 > > > > From the OS following data can be read > > > > External Monitor's EDID data can be read from I2C Bus > > Even VBT data from ACPI NVS can be read > > > > > > Tried to dig into some of these files > > > https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/i915/display > > > > intel_dp.c, intel_acpi.c to understand what function is turning off DP > link > > when i have the OS debug driver logs, can send it across > > > > Any clues will help, appreciate your time > > > > PS:The platform has Intel BayTrail SoC, ValleyView chipset and VBIOS. > The bios do not use GOP driver which replaces VBIOS > > > > Thanks > > Rao > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Display Port Monitor turns off during Ubuntu OS boot
Hi Coreboot Team, There is an external Monitor which works on HDMI/DVI and also DP , In BIOS the display is good whereas in OS (Ubuntu 18.04) until the kernel is initialized and i915 Video driver is loaded display is perfect, looks like the i915 OS driver switches off the monitor and there is no signal Does ACPI GFX method have to return any External display specific data to the OS driver ? Tried to make changes to VBIOS but did not help, thought ASL code is missing under GFX0 >From the OS following data can be read 1. External Monitor's EDID data can be read from I2C Bus 2. Even VBT data from ACPI NVS can be read Tried to dig into some of these files https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/i915/display intel_dp.c, intel_acpi.c to understand what function is turning off DP link when i have the OS debug driver logs, can send it across Any clues will help, appreciate your time PS:The platform has Intel BayTrail SoC, ValleyView chipset and VBIOS. The bios do not use GOP driver which replaces VBIOS Thanks Rao ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] DP (Display Port) not enumerating in OS
Hello Coreboot Developers, Display port which comes along with Integrated LVDS, does not show up any OS graphics display text or screen after booting to OS, the DP port looks good during BIOS, at some point of time during OS booting display port turns off and no video on DP. Using ubuntu 18.04 Some ASL code for graphics is missing? HDMI, DVI & LVDS works well, no issue there Thanks for your time and any clues that would help to resolve this issue? Kind Regards Rao ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: HDA Audio on Baytrail SoC
Thank you Paul. Attaching the logs, please have a look *Log Snippet below for Azalia* ConfigureAzalia() Start Detected Azalia Codec with verb table, VendorID = 0x10EC0262 on SDI0, revision = 0x2. SDI1 has no Azalia device. Detected Azalia Codec with verb table, VendorID = 0x80862882 on SDI2, revision = 0x0. SDI3 has no Azalia device. ConfigureAzalia() End AzaliaEnable = 1 On Mon, Dec 28, 2020 at 11:57 AM Paul Menzel wrote: > Dear Ranga, > > > Am 28.12.20 um 12:45 schrieb Rao G: > > > On the Baytrail platform with ALC262 Realtek Codec, HDA Audio is > enumerated > > as PCI device 00 1b 00, > > the verb table is being programmed on HDABAR + command offset. > > > > Using uefi Payload which has PchInit -> DetectAndInitializeAzalia, there > > are no Errors in this path, all looks good > > > > Either Beep or Audio speakers fail to work in EFI Shell and also in > Ubuntu > > aplay -l does not Audio ALC Codec as sound card > > > > what is missing to enumerate, FSP path\SoC Straps are enabled for Audio > so > > they seem to be fine too > > > > Appreciate for any clues to make HDA to work on a BayTrail Platform > > Please provide the name of your board, your code, and the coreboot and > Linux log messages. > > > Kind regards, > > Paul > HDA.log Description: Binary data ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] HDA Audio on Baytrail SoC
Hi Everyone, On the Baytrail platform with ALC262 Realtek Codec, HDA Audio is enumerated as PCI device 00 1b 00, the verb table is being programmed on HDABAR + command offset. Using uefi Payload which has PchInit -> DetectAndInitializeAzalia, there are no Errors in this path, all looks good Either Beep or Audio speakers fail to work in EFI Shell and also in Ubuntu aplay -l does not Audio ALC Codec as sound card what is missing to enumerate, FSP path\SoC Straps are enabled for Audio so they seem to be fine too Appreciate for any clues to make HDA to work on a BayTrail Platform Thanks Ranga ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
