coreboot March 2019

coreboot@coreboot.org

49 participants
47 discussions

G505S - slightly different Voltages at integrated HD 8650G iGPU AtomBIOS ?
by Ivan Ivanov 16 Mar '19

16 Mar '19

Interesting discovery about the AtomBIOS files at " g505s-atombios " repository - https://github.com/g505s-opensource-researcher/g505s-atombios : While there was the same "clean" proprietary UEFI image flashed both to "G505S with HD 8570M" and to "G505S with R5 M230" before the AtomBIOS extraction, their AtomBIOSes for _ integrated HD 8650G _ turned out as slightly different! (see sha256) So I made their full disassembly with this AtomDis tool - https://cgit.freedesktop.org/~mhopf/AtomDis/ , and compared, diff results here - https://pastebin.com/eewzswnD . As you could see from these diff results, for some reason "G505S R5 version" sets a slightly higher voltages for its' integrated GPU : compared to "G505S HD version" it is 1.8% - 3.2% higher if these 0x3e / 0x40 / 0x6e / 0x70 values are linear and 0x0 = 0 volts. (usNBP0Voltage / usNBP1Voltage / usVoltageID ) What do you think: would it be okay to use the integrated VGA BIOS obtained from "G505S R5 version" for "G505S HD version" ? This voltage difference seems small enough and the integrated GPU is the same part after all ---> I think that it should be fine.

2 1

Shubhendra - GSoC proposal Inquiry about "Port payloads to RISC-V"
by Shubhendra Singhal 16 Mar '19

16 Mar '19

Dear Sir/Ma'am, I am Shubhendra Pal Singhal, currently third year in Computer Science at NIT Trichy, India. I wish to apply for Google Summer of Code. I looked into the profile of coreboot 4.9 and found out the project idea "*Port payloads to ARM, AArch64, MIPS or RISC-V*" to be very interesting. I have worked in the similar field on *RISCV architecture at IIT Madras where I helped in porting real time OS eChronos*, on RISCV architecture. I will be undergoing a *project in Embedded systems offered by USC Los Angeles in solving the SAT Solvers using OS and Digital Logic*. Furthermore, I am currently working on a *long term project with under Prof. N.Ramasubramanium on the AI chip* where we are trying to solve the processing speeds by efficiently reducing the number of writes in the cache for faster access. I am also *undergoing Microcontrollers and Microprocessors* as my core subject in my current semester and have already* undergone OS, Real time Systems* in my B.Tech IV semester. I have included my further details in my Linkedin : * <https://www.linkedin.com/in/shubhendra-singhal-7378a9131/>https://www.linkedin.com/in/ <https://www.linkedin.com/in/>shubhendra-singhal-7378a9131/* I want to contribute to the open source community in the field of Operating Systems and this can prove to be an excellent platform for gaining experience in field of systems. This opportunity can pave my career, towards applied research in the field of Systems. *While browsing through the link, I saw the mailing list assigned for the project. It would be very useful if you could guide me as to what is expected in the project proposal and how can I serve the open source community in the best possible way. *Any guidance would be very useful and I hope to receive a reply soon. Thanking you for your time and consideration. Regards Shubhendra Pal Singhal National Institute Of Technology, Trichy, India Phone number : +91 9787888015 Email-id : shubhendrapalsinghal(a)gmail.com Linkedin : <https://www.linkedin.com/in/shubhendra-singhal-7378a9131/> https://www.linkedin.com/in/shubhendra-singhal-7378a9131/

1 0

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

15 Mar '19

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1399716: Null pointer dereferences (NULL_RETURNS) /src/security/vboot/common.c: 167 in vb2_migrate_cbmem() ________________________________________________________________________________________________________ *** CID 1399716: Null pointer dereferences (NULL_RETURNS) /src/security/vboot/common.c: 167 in vb2_migrate_cbmem() 161 size_t cbmem_size = wd_preram->buffer_offset + wd_preram->buffer_size; 162 struct vb2_working_data *wd_cbmem = 163 cbmem_add(CBMEM_ID_VBOOT_WORKBUF, cbmem_size); 164 printk(BIOS_DEBUG, 165 "VBOOT: copying vb2_working_data (%zu bytes) to CBMEM...\n", 166 cbmem_size); >>> CID 1399716: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a pointer that might be null "wd_cbmem" when calling "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] 167 memcpy(wd_cbmem, wd_preram, cbmem_size); 168 assert(wd_cbmem != NULL); 169 } 170 ROMSTAGE_CBMEM_INIT_HOOK(vb2_migrate_cbmem) 171 #elif CONFIG(VBOOT_STARTS_IN_ROMSTAGE) 172 static void vb2_setup_cbmem(int unused) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Fastboot support for udc
by sriram.dash＠samsung.com 15 Mar '19

15 Mar '19

Hello, I am very newbie to core-boot and want to have my coreboot depict the fastboot functionality. Currently I am making the uboot load udc and fastboot function, to start the fastboot, without any involvement of coreboot. I want the udc and fastboot porting to coreboot. I see some commit messages like "TEST=Compiles successfully. fastboot devices shows serial number for shark". Here, I understand that the udc driver is UP in coreboot and the fastboot command is invoked from host. But I am not sure how the command reaches to the udc drivers and then how it gives the data to the fastboot function. AFAIU, fastboot is started at uboot with a cmd to uboot prompt. I am not sure how it will starts/ integrated/ works with coreboot. Is there any standard way? Any light on this would be a great help.

4 3

MEC1619 gpio access question (X230)
by Martin Kepplinger 14 Mar '19

14 Mar '19

Hi, So, I'm looking into h8 EC access. Where does ec_set_bit(0x3a, 0) for audio-mute or ec_set_bit(0x3a, 6) for wwan-enable come from (let's keep that as an example)? On the X230, for example wwan-disable should be on GPIO23 (GPIO023 i guess). In the mec1618 (ok different, but hopefully similar enough) datasheet I can't really find the connection to coreboot's implementation here -.- So there's the AHB Base Address 0xC400h right? Then for example there's the 4 bytes "GPIO[000:036] Input Register" at base+0x300. According to this "bit indexing example" table, GPIO023 would be Bit 19 of those 4 bytes... If so (?), how does that relate to ec_set_bit(0x3a, 6)? It all still totally unclear to me, but I might get it all wrong :) thanks a lot, martin

3 3

Re: Coreboot hang when under control of Intel System Debugger
by Lance Zhao 13 Mar '19

13 Mar '19

The time I am using XDP on bay trail platform it was fine, but i was not using coreboot then. What about you don't run any system debuger, just simply hook up xdp to see the issue still there or not? If so, maybe some xdp config itself. On Wed, Mar 13, 2019, 7:33 AM Perkins, Graham (GB) <Graham.Perkins(a)cubic.com> wrote: > Hello, > > I would be grateful for some advice on the problem described below. > > > > I have coreboot running successfully on our own hardware based around the > Intel Atom E3805. Recently I wanted to debug our boot process to determine > the settings of some PCU iLB Low Pin Count (LPC) Bridge PCI Configuration > Registers. I have the Intel System Debugger connect via the Itel ITP XDP > BR3 probe. If I simply run coreboot from the debugger it hangs. I cannot > pause the debugger since the target is reported as still running (reported > in its debug logs). > > > > The console log extract is: > > > > ============= PEIM FSP (VLYVIEW0 0x00000304) ============= > > 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: FFFE0FD4 > > The 1th FV start address is 0x000FFFB0000, size is 0x0002F400, handle is > 0xFFFB0000 > > > > ø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 > > RID = 0x11. > > Reg_EFF_DualCH_EN = 0x40030040. > > CurrentMrcData.BootMode = 4 > > Configuring Memory Start... > > > > Without using the debugger everything is fine: > > > > ============= PEIM FSP (VLYVIEW0 0x00000304) ============= > > 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: FFFE0FD4 > > The 1th FV start address is 0x000FFFB0000, size is 0x0002F400, handle is > 0xFFFB0000 > > > > ð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 > > RID = 0x11. > > Reg_EFF_DualCH_EN = 0x40030040. > > CurrentMrcData.BootMode = 4 > > Configuring Memory Start... > > START_RMT: > > RxDqLeft RxDqRight RxVLow RxVHigh TxDqLeft > TxDqRight CmdLeft CmdRight > > > ------------------------------------------------------------------------------------------------ > > Channel 0 Rank 0 -23 24 -24 16 -27 > 28 0 0 > > STOP_RMT: > > CMD module is per channel only and without Rank differentiation > > Configuring Memory End > > UpperTotalMemory = 0x80000000 > > dBMBOUND = 0x80000000 > > dBMBOUNDHI = 0x80000000 > > dGFXBase = 0x7BE00000 > > dTSegBase = 0x7B000000 > > Save MRC params. > > > > Coreboot is version coreboot-4.5 > > Intel FSP is Baytrail_FSP_Gold4 > > > > I realise I am in the Intel FSP so do not think it is a direct coreboot > problem but has anybody got a similar debug setup and can confirm it works? > If it should work maybe we have a board fault in the jtag area. It just > seems weird at this point. > > > > Many thanks, > > Graham Perkins. > > > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

Coreboot hang when under control of Intel System Debugger
by Perkins, Graham (GB) 13 Mar '19

13 Mar '19

Hello, I would be grateful for some advice on the problem described below. I have coreboot running successfully on our own hardware based around the Intel Atom E3805. Recently I wanted to debug our boot process to determine the settings of some PCU iLB Low Pin Count (LPC) Bridge PCI Configuration Registers. I have the Intel System Debugger connect via the Itel ITP XDP BR3 probe. If I simply run coreboot from the debugger it hangs. I cannot pause the debugger since the target is reported as still running (reported in its debug logs). The console log extract is: ============= PEIM FSP (VLYVIEW0 0x00000304) ============= 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: FFFE0FD4 The 1th FV start address is 0x000FFFB0000, size is 0x0002F400, handle is 0xFFFB0000 ø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 RID = 0x11. Reg_EFF_DualCH_EN = 0x40030040. CurrentMrcData.BootMode = 4 Configuring Memory Start... Without using the debugger everything is fine: ============= PEIM FSP (VLYVIEW0 0x00000304) ============= 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: FFFE0FD4 The 1th FV start address is 0x000FFFB0000, size is 0x0002F400, handle is 0xFFFB0000 ð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 RID = 0x11. Reg_EFF_DualCH_EN = 0x40030040. CurrentMrcData.BootMode = 4 Configuring Memory Start... START_RMT: RxDqLeft RxDqRight RxVLow RxVHigh TxDqLeft TxDqRight CmdLeft CmdRight ------------------------------------------------------------------------------------------------ Channel 0 Rank 0 -23 24 -24 16 -27 28 0 0 STOP_RMT: CMD module is per channel only and without Rank differentiation Configuring Memory End UpperTotalMemory = 0x80000000 dBMBOUND = 0x80000000 dBMBOUNDHI = 0x80000000 dGFXBase = 0x7BE00000 dTSegBase = 0x7B000000 Save MRC params. Coreboot is version coreboot-4.5 Intel FSP is Baytrail_FSP_Gold4 I realise I am in the Intel FSP so do not think it is a direct coreboot problem but has anybody got a similar debug setup and can confirm it works? If it should work maybe we have a board fault in the jtag area. It just seems weird at this point. Many thanks, Graham Perkins.

1 0

RFC: Replacing IS_ENABLED(CONFIG_XXX) with the shorter CONFIG(XXX)
by Julius Werner 12 Mar '19

12 Mar '19

Hi folks, I'm proposing a small policy change for the way we refer to boolean Kconfig variables in code. Right now, the directive is to always use the IS_ENABLED() macro. I would like to replace this with a shorter macro CONFIG() that also removes the need to type the CONFIG_ prefix again. The idea is mostly to save some horizontal space and the occasional extra line break for this boilerplate and make it a little easier to type. It's a very simple change (patch train starts at https://review.coreboot.org/c/coreboot/+/31773), but since it affects pretty much all code in coreboot and payloads I wanted to send out a quick FYI. Please let me know if anyone has any concerns with this.

7 11

IS_ENABLED() vs CONFIG()
by ehaouas＠noos.fr 11 Mar '19

11 Mar '19

Dear all, Now, when we run "coreboot$ ./util/lint/kconfig_lint " , we can see : #!!!!! Warning: CONFIG() used on unknown value (option) at src/include/kconfig.h:21. #!!!!! Warning: CONFIG() used on unknown value (%02x) at src/northbridge/amd/amdfam10/util.c:138. B. Regards, Elyes

2 2

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

08 Mar '19

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 2 new defect(s) introduced to coreboot found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1399411: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/fsp_baytrail/fsp/chipset_fsp_util.c: 90 in ConfigureDefaultUpdData() ________________________________________________________________________________________________________ *** CID 1399411: Null pointer dereferences (NULL_RETURNS) /src/soc/intel/fsp_baytrail/fsp/chipset_fsp_util.c: 90 in ConfigureDefaultUpdData() 84 { 85 DEVTREE_CONST struct device *dev; 86 DEVTREE_CONST config_t *config; 87 printk(FSP_INFO_LEVEL, "Configure Default UPD Data\n"); 88 89 dev = pcidev_path_on_root(SOC_DEV_FUNC); >>> CID 1399411: Null pointer dereferences (NULL_RETURNS) >>> Dereferencing a null pointer "dev". 90 config = dev->chip_info; 91 92 /* Set up default verb tables - Just HDMI audio */ 93 UpdData->AzaliaConfigPtr = (UINT32)&mAzaliaConfig; 94 95 /* Set SPD addresses */ ** CID 1255946: Memory - corruptions (ARRAY_VS_SINGLETON) /src/soc/intel/fsp_baytrail/fsp/chipset_fsp_util.c: 177 in ConfigureDefaultUpdData() ________________________________________________________________________________________________________ *** CID 1255946: Memory - corruptions (ARRAY_VS_SINGLETON) /src/soc/intel/fsp_baytrail/fsp/chipset_fsp_util.c: 177 in ConfigureDefaultUpdData() 171 case MIPI_DEV_FUNC: /* Camera / Image Signal Processing */ 172 if (FspInfo->ImageRevision >= FSP_GOLD3_REV_ID) { 173 UpdData->ISPEnable = dev->enabled; 174 } else { 175 /* Gold2 and earlier FSP: ISPEnable is the field */ 176 /* next to PcdGttSize in UPD_DATA_REGION struct */ >>> CID 1255946: Memory - corruptions (ARRAY_VS_SINGLETON) >>> Using "&UpdData->PcdGttSize" as an array. This might corrupt or misinterpret adjacent memory locations. 177 *(&(UpdData->PcdGttSize)+sizeof(UINT8)) = dev->enabled; 178 printk (FSP_INFO_LEVEL, 179 "Baytrail Gold2 or earlier FSP, adjust ISPEnable offset.\n"); 180 } 181 printk(FSP_INFO_LEVEL, "MIPI/ISP:\t\t%s\n", 182 dev->enabled?"Enabled":"Disabled"); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2019