coreboot July 2015

coreboot@coreboot.org

46 participants
98 discussions

Re: [coreboot] Kernel couldn't find proper MAC address with coreboot (gigabyte ma785gmt-ud2h)
by YongGon Kim 14 Jul '15

14 Jul '15

Off topic. There was a request to find revision in upstream which hinders my ma785gmt to boot. I found that after the revision 13e4182119bcfcf09bdd9fa2b0cc5d09cd3550c2 coreboot fails to boot. I think AMD_RS790 in src/southbridge/amd/rs780/Makefile.inc is typo of AMD_RS780. The correction of it makes coreboot to successfully boot. 2015-07-09 19:42 GMT+09:00 YongGon Kim <ilios86(a)gmail.com>: > Thank you for reply! > > > 2015-07-09 15:43 GMT+09:00 Paul Menzel <paulepanter(a)users.sourceforge.net> > : > >> Dear YongGon, >> >> >> welcome to coreboot and thank you for your message! >> >> >> Am Mittwoch, den 08.07.2015, 20:47 +0900 schrieb YongGon Kim: >> >> […] >> >> > I have uploaded detailed information using board_status.sh >> > Following is link for the information. >> > >> http://review.coreboot.org/gitweb?p=board-status.git;a=commit;h=dedf456d257… >> >> Your commit is marked as *dirty*, meaning that you have applied local >> changes. What are these? >> > > I just changed board_status.sh to properly upload my logs. i didn't > change anything else. > > > >> >> Additionally, could you please also upload the logs of a run with the >> current code in master? >> > > I pasted logs of master code. (revision > 5d866213f42fd22aed80abb5a91d74f6d485ac3f) > > As you can see, booting process stopped in the middle. > I chose the previous snapshot of coreboot since i found some valid results > in following link. > http://www.coreboot.org/Supported_Motherboards#gigabyte.2Fma785gmt > > > > > > >> >> >> Thanks, >> >> Paul >> >> >> PS: Please just send plain text messages to mailing lists. >> Additionally, pasting logs in the Google Mail Web interface is not >> optimal as there is no way to turn off auto-wrapping the lines, which >> is not wanted for pastes. >> > > I'm sorry. I'm not clearly understanding your request. > Do you know any alternative interface for sending plain logs? > > Anyway, followings are log from master coreboot. > > coreboot-4.0-10265-g5d86621-dirty Thu Jul 9 06:47:41 UTC 2015 romstage > starting... > BSP Family_Model: 00100f42 > *sysinfo range: [000c4100,000c7d31] > bsp_apicid = 00 > cpu_init_detectedx = 00000000 > CBFS @ 0 size ffc40 > CBFS: Locating 'cpu_microcode_blob.bin' > CBFS: Found @ offset 2fc0 size 3800 > [microcode] patch id to apply = 0x010000db > [microcode] updated to patch id = 0x010000db success > POST: 0x33 > cpuSetAMDMSR done > POST: 0x34 > Enter amd_ht_init() > AMD_CB_EventNotify() > event class: 02 > event: 2005 > data: 05 00 00 00 01 > AMD_CB_EventNotify() > event class: 05 > event: 2006 > data: 04 00 00 ff > Exit amd_ht_init() > POST: 0x35 > cpuSetAMDPCI 00 done > Prep FID/VID Node:00 > F3x80: e600e681 > F3x84: 80e641e6 > F3xD4: c8810f24 > F3xD8: 03001816 > F3xDC: 00006322 > POST: 0x36 > core0 started: > start_other_cores() > init node: 00 cores: 02 > Start other core - nodeid: 00 cores: 02 > POST: 0x37 > started ap apicid: * AP 01started > * AP 02started > > POST: 0x38 > rs780_early_setup() > fam10_optimization() > rs780_por_init > sb700_early_setup() > sb700_devices_por_init() > sb700_devices_por_init(): SMBus Device, BDF:0-20-0 > SMBus controller enabled, sb revision is A14 > sb700_devices_por_init(): IDE Device, BDF:0-20-1 > sb700_devices_por_init(): LPC Device, BDF:0-20-3 > sb700_devices_por_init(): P2P Bridge, BDF:0-20-4 > sb700_devices_por_init(): SATA Device, BDF:0-18-0 > sb700_pmio_por_init() > > Begin FIDVID MSR 0xc0010071 0x30b40093 0x40035040 > POST: 0x39 > FIDVID on BSP, APIC_id: 00 > BSP fid = 10600 > Wait for AP stage 1: ap_apicid = 1 > readback = 1010601 > common_fid(packed) = 10600 > Wait for AP stage 1: ap_apicid = 2 > readback = 2010601 > common_fid(packed) = 10600 > common_fid = 10600 > FID Change Node:00, F3xD4: c8810f26 > POST: 0x3a > End FIDVIDMSR 0xc0010071 0x30b40093 0x38005040 > rs780_htinit cpu_ht_freq=0. > rs780_htinit: HT1 mode > ...WARM RESET... > > > > > coreboot-4.0-10265-g5d86621-dirty Thu Jul 9 06:47:41 UTC 2015 romstage > starting... > BSP Family_Model: 00100f42 > *sysinfo range: [000c4100,000c7d31] > bsp_apicid = 00 > cpu_init_detectedx = 00000000 > CBFS @ 0 size ffc40 > CBFS: Locating 'cpu_microcode_blob.bin' > CBFS: Found @ offset 2fc0 size 3800 > [microcode] patch id to apply = 0x010000db > [microcode] updated to patch id = 0x010000db success > POST: 0x33 > cpuSetAMDMSR done > POST: 0x34 > Enter amd_ht_init() > AMD_CB_EventNotify() > event class: 02 > event: 2005 > data: 05 00 00 00 01 > AMD_CB_EventNotify() > event class: 05 > event: 2006 > data: 04 00 00 ff > Exit amd_ht_init() > POST: 0x35 > cpuSetAMDPCI 00 done > Prep FID/VID Node:00 > F3x80: e600e681 > F3x84: 80e641e6 > F3xD4: c8810f26 > F3xD8: 03001816 > F3xDC: 00006322 > POST: 0x36 > core0 started: > start_other_cores() > init node: 00 cores: 02 > Start other core - nodeid: 00 cores: 02 > POST: 0x37 > started ap apicid: * AP 01started > * AP 02started > > POST: 0x38 > rs780_early_setup() > fam10_optimization() > rs780_por_init > sb700_early_setup() > sb700_devices_por_init() > sb700_devices_por_init(): SMBus Device, BDF:0-20-0 > SMBus controller enabled, sb revision is A14 > sb700_devices_por_init(): IDE Device, BDF:0-20-1 > sb700_devices_por_init(): LPC Device, BDF:0-20-3 > sb700_devices_por_init(): P2P Bridge, BDF:0-20-4 > sb700_devices_por_init(): SATA Device, BDF:0-18-0 > sb700_pmio_por_init() > > Begin FIDVID MSR 0xc0010071 0x30b40093 0x38005040 > POST: 0x39 > POST: 0x3a > End FIDVIDMSR 0xc0010071 0x30b40093 0x3800240a > rs780_htinit cpu_ht_freq=0. > rs780_htinit: HT1 mode > POST: 0x3b > fill_mem_ctrl() > POST: 0x40 > raminit_amdmct() > raminit_amdmct begin: > DIMMPresence: DIMMValid=2 > DIMMPresence: DIMMPresent=2 > DIMMPresence: RegDIMMPresent=0 > DIMMPresence: DimmECCPresent=0 > DIMMPresence: DimmPARPresent=0 > DIMMPresence: Dimmx4Present=0 > DIMMPresence: Dimmx8Present=2 > DIMMPresence: Dimmx16Present=0 > DIMMPresence: DimmPlPresent=0 > DIMMPresence: DimmDRPresent=2 > DIMMPresence: DimmQRPresent=0 > DIMMPresence: DATAload[0]=0 > DIMMPresence: MAload[0]=0 > DIMMPresence: MAdimms[0]=0 > DIMMPresence: DATAload[1]=2 > DIMMPresence: MAload[1]=10 > DIMMPresence: MAdimms[1]=1 > DIMMPresence: Status 1000 > DIMMPresence: ErrStatus 0 > DIMMPresence: ErrCode 0 > DIMMPresence: Done > > DCTInit_D: mct_DIMMPresence Done > SPDCalcWidth: Status 1000 > SPDCalcWidth: ErrStatus 0 > SPDCalcWidth: ErrCode 0 > SPDCalcWidth: Done > DCTInit_D: mct_SPDCalcWidth Done > SPDGetTCL_D: DIMMCASL 4 > SPDGetTCL_D: DIMMAutoSpeed 4 > SPDGetTCL_D: Status 1000 > SPDGetTCL_D: ErrStatus 0 > SPDGetTCL_D: ErrCode 0 > SPDGetTCL_D: Done > > AutoCycTiming: Status 1000 > AutoCycTiming: ErrStatus 0 > AutoCycTiming: ErrCode 2 > AutoCycTiming: Done > > DCTInit_D: mct_DIMMPresence Done > SPDCalcWidth: Status 1000 > SPDCalcWidth: ErrStatus 0 > SPDCalcWidth: ErrCode 0 > SPDCalcWidth: Done > DCTInit_D: mct_SPDCalcWidth Done > AutoCycTiming: Status 1000 > AutoCycTiming: ErrStatus 0 > AutoCycTiming: ErrCode 0 > AutoCycTiming: Done > > DCTInit_D: AutoCycTiming_D Done > SPDSetBanks: CSPresent 3 > SPDSetBanks: Status 1000 > SPDSetBanks: ErrStatus 0 > SPDSetBanks: ErrCode 0 > SPDSetBanks: Done > > AfterStitch pDCTstat->NodeSysBase = 0 > mct_AfterStitchMemory: pDCTstat->NodeSysLimit = 7fffff > StitchMemory: Status 1000 > StitchMemory: ErrStatus 0 > StitchMemory: ErrCode 0 > StitchMemory: Done > > InterleaveBanks_D: Status 1000 > InterleaveBanks_D: ErrStatus 0 > InterleaveBanks_D: ErrCode 0 > InterleaveBanks_D: Done > > AutoConfig_D: DramControl: 2a06 > AutoConfig_D: DramTimingLo: 90092 > AutoConfig_D: DramConfigMisc: 0 > AutoConfig_D: DramConfigMisc2: 0 > AutoConfig_D: DramConfigLo: 10000 > AutoConfig_D: DramConfigHi: f48000b > AutoConfig: Status 1000 > AutoConfig: ErrStatus 0 > AutoConfig: ErrCode 0 > AutoConfig: Done > > DCTInit_D: AutoConfig_D Done > DCTInit_D: PlatformSpec_D Done > DCTInit_D: StartupDCT_D > mctAutoInitMCT_D: SyncDCTsReady_D > mctAutoInitMCT_D: HTMemMapInit_D > Node: 00 base: 00 limit: 7fffff BottomIO: a00000 > Node: 00 base: 03 limit: 7fffff > Node: 01 base: 00 limit: 00 > Node: 02 base: 00 limit: 00 > Node: 03 base: 00 limit: 00 > Node: 04 base: 00 limit: 00 > Node: 05 base: 00 limit: 00 > Node: 06 base: 00 limit: 00 > Node: 07 base: 00 limit: 00 > mctAutoInitMCT_D: CPUMemTyping_D > CPUMemTyping: Cache32bTOP:800000 > CPUMemTyping: Bottom32bIO:800000 > CPUMemTyping: Bottom40bIO:0 > mctAutoInitMCT_D: DQSTiming_D > TrainRcvrEn: Status 1000 > TrainRcvrEn: ErrStatus 0 > TrainRcvrEn: ErrCode 0 > TrainRcvrEn: Done > > TrainDQSRdWrPos: Status 1000 > TrainDQSRdWrPos: TrainErrors 0 > TrainDQSRdWrPos: ErrStatus 0 > TrainDQSRdWrPos: ErrCode 0 > TrainDQSRdWrPos: Done > > TrainDQSRdWrPos: Status 1000 > TrainDQSRdWrPos: TrainErrors 0 > TrainDQSRdWrPos: ErrStatus 0 > TrainDQSRdWrPos: ErrCode 0 > TrainDQSRdWrPos: Done > > TrainDQSRdWrPos: Status 1000 > TrainDQSRdWrPos: TrainErrors 0 > TrainDQSRdWrPos: ErrStatus 0 > TrainDQSRdWrPos: ErrCode 0 > TrainDQSRdWrPos: Done > > TrainDQSRdWrPos: Status 1000 > TrainDQSRdWrPos: TrainErrors 0 > TrainDQSRdWrPos: ErrStatus 0 > TrainDQSRdWrPos: ErrCode 0 > TrainDQSRdWrPos: Done > > mctAutoInitMCT_D: UMAMemTyping_D > mctAutoInitMCT_D: :OtherTiming > InterleaveNodes_D: Status 1000 > InterleaveNodes_D: ErrStatus 0 > InterleaveNodes_D: ErrCode 0 > InterleaveNodes_D: Done > > InterleaveChannels_D: Node 0 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 1 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 2 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 3 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 4 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 5 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 6 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Node 7 > InterleaveChannels_D: Status 1000 > InterleaveChannels_D: ErrStatus 0 > InterleaveChannels_D: ErrCode 0 > InterleaveChannels_D: Done > > mctAutoInitMCT_D: ECCInit_D > ECCInit: Node 00 > ECCInit: Status 1000 > ECCInit: ErrStatus 0 > ECCInit: ErrCode 0 > ECCInit: Done > mctAutoInitMCT_D Done: Global Status: 0 > raminit_amdmct end: > CBMEM: > IMD: root @ 6ffff000 254 entries. > IMD: root @ 6fffec00 62 entries. > POST: 0x41 > amdmct_cbmem_store_info: Storing AMDMCT configuration in CBMEM > POST: 0x42 > Prepare CAR migration and stack regions... Fill [003fbc00-003fffff] ... > Done > Copying data from cache to RAM... Copy [000c4000-000c7d3f] to [003fc2c0 - > 003fffff] ... Done > Switching to use RAM as stack... Top about 003fc2ac ... Done > Disabling cache as ram now > Prepare ramstage memory region... Fill [00000000-003fbbff] ... Done > CBFS provider active. > CBFS @ 0 size ffc40 > CBFS: Locating 'fallback/ramstage' > CBFS: Found @ offset 1bf40 size 19959 > 'fallback/ramstage' located at offset: 1bf78 size: 19959 > > > coreboot-4.0-10265-g5d86621-dirty Thu Jul 9 06:47:41 UTC 2015 ramstage > starting... > POST: 0x39 > Moving GDT to 6fffe700...ok > POST: 0x80 > POST: 0x70 > BS: BS_PRE_DEVICE times (us): entry 8 run 1065 exit 0 > POST: 0x71 > BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 1060 exit 0 > POST: 0x72 > Enumerating buses... > Show all devs... Before device enumeration. > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > APIC: 00: enabled 1 > DOMAIN: 0000: enabled 1 > PCI: 00:18.0: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:02.0: enabled 1 > PCI: 00:03.0: enabled 1 > PCI: 00:04.0: enabled 1 > PCI: 00:05.0: enabled 0 > PCI: 00:06.0: enabled 0 > PCI: 00:07.0: enabled 0 > PCI: 00:08.0: enabled 0 > PCI: 00:09.0: enabled 1 > PCI: 00:0a.0: enabled 1 > PCI: 00:11.0: enabled 1 > PCI: 00:12.0: enabled 1 > PCI: 00:12.1: enabled 1 > PCI: 00:12.2: enabled 1 > PCI: 00:13.0: enabled 1 > PCI: 00:13.1: enabled 1 > PCI: 00:13.2: enabled 1 > PCI: 00:14.0: enabled 1 > I2C: 00:50: enabled 1 > I2C: 00:51: enabled 1 > I2C: 00:52: enabled 1 > I2C: 00:53: enabled 1 > PCI: 00:14.1: enabled 1 > PCI: 00:14.2: enabled 1 > PCI: 00:14.3: enabled 1 > PNP: 002e.0: enabled 0 > PNP: 002e.1: enabled 1 > PNP: 002e.2: enabled 0 > PNP: 002e.3: enabled 0 > PNP: 002e.4: enabled 0 > PNP: 002e.5: enabled 1 > PNP: 002e.6: enabled 1 > PNP: 002e.7: enabled 0 > PNP: 002e.8: enabled 0 > PNP: 002e.9: enabled 0 > PNP: 002e.a: enabled 0 > PCI: 00:14.4: enabled 1 > PCI: 00:14.5: enabled 1 > PCI: 00:18.1: enabled 1 > PCI: 00:18.2: enabled 1 > PCI: 00:18.3: enabled 1 > PCI: 00:18.4: enabled 1 > Compare with tree... > Root Device: enabled 1 > CPU_CLUSTER: 0: enabled 1 > APIC: 00: enabled 1 > DOMAIN: 0000: enabled 1 > PCI: 00:18.0: enabled 1 > PCI: 00:00.0: enabled 1 > PCI: 00:01.0: enabled 1 > PCI: 00:02.0: enabled 1 > PCI: 00:03.0: enabled 1 > PCI: 00:04.0: enabled 1 > PCI: 00:05.0: enabled 0 > PCI: 00:06.0: enabled 0 > PCI: 00:07.0: enabled 0 > PCI: 00:08.0: enabled 0 > PCI: 00:09.0: enabled 1 > PCI: 00:0a.0: enabled 1 > PCI: 00:11.0: enabled 1 > PCI: 00:12.0: enabled 1 > PCI: 00:12.1: enabled 1 > PCI: 00:12.2: enabled 1 > PCI: 00:13.0: enabled 1 > PCI: 00:13.1: enabled 1 > PCI: 00:13.2: enabled 1 > PCI: 00:14.0: enabled 1 > I2C: 00:50: enabled 1 > I2C: 00:51: enabled 1 > I2C: 00:52: enabled 1 > I2C: 00:53: enabled 1 > PCI: 00:14.1: enabled 1 > PCI: 00:14.2: enabled 1 > PCI: 00:14.3: enabled 1 > PNP: 002e.0: enabled 0 > PNP: 002e.1: enabled 1 > PNP: 002e.2: enabled 0 > PNP: 002e.3: enabled 0 > PNP: 002e.4: enabled 0 > PNP: 002e.5: enabled 1 > PNP: 002e.6: enabled 1 > PNP: 002e.7: enabled 0 > PNP: 002e.8: enabled 0 > PNP: 002e.9: enabled 0 > PNP: 002e.a: enabled 0 > PCI: 00:14.4: enabled 1 > PCI: 00:14.5: enabled 1 > PCI: 00:18.1: enabled 1 > PCI: 00:18.2: enabled 1 > PCI: 00:18.3: enabled 1 > PCI: 00:18.4: enabled 1 > Mainboard MA785GMT-UD2H Enable. dev=0x0013a000 > Init adt7461 end , status 0x02 fd > Dev3 is not present. GFX Configuration is One x16 slot > Root Device scanning... > root_dev_scan_bus for Root Device > setup_bsp_ramtop, TOP MEM: msr.lo = 0x80000000, msr.hi = 0x00000000 > setup_bsp_ramtop, TOP MEM2: msr.lo = 0x00000000, msr.hi = 0x00000000 > setup_uma_memory: uma size 0x10000000, memory start 0x70000000 > CPU_CLUSTER: 0 enabled > DOMAIN: 0000 enabled > CPU_CLUSTER: 0 scanning... > PCI: 00:18.3 siblings=2 > CPU: APIC: 00 enabled > CPU: APIC: 01 enabled > CPU: APIC: 02 enabled > DOMAIN: 0000 scanning... > PCI: pci_scan_bus for bus 00 > POST: 0x24 > PCI: 00:18.0 [1022/1200] bus ops > PCI: 00:18.0 [1022/1200] enabled > PCI: 00:18.1 [1022/1201] enabled > PCI: 00:18.2 [1022/1202] enabled > PCI: 00:18.3 [1022/1203] ops > PCI: 00:18.3 [1022/1203] enabled > PCI: 00:18.4 [1022/1204] enabled > POST: 0x25 > PCI: 00:18.0 scanning... > PCI: 00:00.0 [1022/9601] enabled > Capability: type 0x08 @ 0xc4 > flags: 0x0181 > PCI: pci_scan_bus for bus 00 > PCI: pci_scan_bus limits devfn 0 - devfn ffffffff > PCI: pci_scan_bus upper limit too big. Using 0xff. > POST: 0x24 > PCI: 00:00.0 [1022/9601] enabled > Capability: type 0x08 @ 0x44 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0x44 > Capability: type 0x08 @ 0x44 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0x44 > Capability: type 0x0d @ 0xb0 > PCI: 00:01.0 [1022/9602] enabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:02.0 subordinate bus PCI Express > PCI: 00:02.0 [1022/9603] enabled > PCI: Static device PCI: 00:03.0 not found, disabling it. > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:04.0 subordinate bus PCI Express > PCI: 00:04.0 [1022/9604] enabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:05.0 subordinate bus PCI Express > PCI: 00:05.0 [1022/9605] disabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:06.0 subordinate bus PCI Express > PCI: 00:06.0 [1022/9606] disabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:07.0 subordinate bus PCI Express > PCI: 00:07.0 [1022/9607] disabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:08.0 subordinate bus PCI Express > PCI: 00:08.0 [1022/960a] disabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:09.0 subordinate bus PCI Express > PCI: 00:09.0 [1022/9608] enabled > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x05 @ 0xa0 > Capability: type 0x0d @ 0xb0 > Capability: type 0x08 @ 0xb8 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > PCI: 00:0a.0 subordinate bus PCI Express > PCI: 00:0a.0 [1022/9609] enabled > sb7xx_51xx_enable() > PCI: 00:11.0 [1002/4390] ops > PCI: 00:11.0 [1002/4390] enabled > sb7xx_51xx_enable() > PCI: 00:12.0 [1002/4397] ops > PCI: 00:12.0 [1002/4397] enabled > sb7xx_51xx_enable() > PCI: 00:12.1 [1002/4398] ops > PCI: 00:12.1 [1002/4398] enabled > sb7xx_51xx_enable() > PCI: 00:12.2 [1002/4396] ops > PCI: 00:12.2 [1002/4396] enabled > sb7xx_51xx_enable() > PCI: 00:13.0 [1002/4397] ops > PCI: 00:13.0 [1002/4397] enabled > sb7xx_51xx_enable() > PCI: 00:13.1 [1002/4398] ops > PCI: 00:13.1 [1002/4398] enabled > sb7xx_51xx_enable() > PCI: 00:13.2 [1002/4396] ops > PCI: 00:13.2 [1002/4396] enabled > sb7xx_51xx_enable() > PCI: 00:14.0 [1002/4385] bus ops > PCI: 00:14.0 [1002/4385] enabled > sb7xx_51xx_enable() > PCI: 00:14.1 [1002/439c] ops > PCI: 00:14.1 [1002/439c] enabled > sb7xx_51xx_enable() > PCI: 00:14.2 [1002/4383] ops > PCI: 00:14.2 [1002/4383] enabled > sb7xx_51xx_enable() > PCI: 00:14.3 [1002/439d] bus ops > PCI: 00:14.3 [1002/439d] enabled > sb7xx_51xx_enable() > PCI: 00:14.4 [1002/4384] bus ops > PCI: 00:14.4 [1002/4384] enabled > sb7xx_51xx_enable() > PCI: 00:14.5 [1002/4399] ops > PCI: 00:14.5 [1002/4399] enabled > PCI: 00:18.0 [1022/1200] bus ops > PCI: 00:18.0 [1022/1200] enabled > PCI: 00:18.1 [1022/1201] enabled > PCI: 00:18.2 [1022/1202] enabled > PCI: 00:18.3 [1022/1203] ops > PCI: 00:18.3 [1022/1203] enabled > PCI: 00:18.4 [1022/1204] enabled > POST: 0x25 > PCI: 00:01.0 scanning... > do_pci_scan_bridge for PCI: 00:01.0 > PCI: pci_scan_bus for bus 01 > POST: 0x24 > > (booting process stops here) > ================ >

1 0

There is no coreboot_ram.debug in my directory
by Yu-Cheng Liu 14 Jul '15

14 Jul '15

hello , 1.I tried to trace coreboot, I followed the coreboot Debugging steps but there is no *coreboot_ram.debug *in my directory. I select *GDB debugging support* and *Wait for a GDB connection *rebuild coreboot already, what step is missing ?

1 0

T400 screen issue / EDID handling
by kroms＠posteo.be 14 Jul '15

14 Jul '15

Hello, I allready contacted Francis from libreboot and he forwared me to this list, because it seems to be an issue regarding coreboot. I have flashed a Lenovo T400 with libreboot. The T400 has an Intel GPU and I am able to use it with an external display connected to the onboard vga-port. The issue is, that I can't use the internal display, which is an 1440x900 Samusung LTN141WD-L05, EDID dump: https://paste.debian.net/plainh/b3699c60 It seems like the internal screen is powered on while booting but it stays black. Francis assumes that this is due to bugs in how coreboot handles the EDID. Here is an EDID dump of a working display: http://paste.debian.net/plainh/776705d5 Anyone is able to help? Thanks in advance!

6 18

Re: [coreboot] Announcing coreboot 4.1
by Peter Stuge 14 Jul '15

14 Jul '15

Patrick Georgi wrote: > I decided to take a random commit and call it ‘4.1’. Well done. Thanks! //Peter

2 1

New on blogs.coreboot.org: [GSoC] EC/H8S firmware week #6
by WordPress 13 Jul '15

13 Jul '15

1 0

Announcing coreboot 4.1
by Patrick Georgi 13 Jul '15

13 Jul '15

Dear coreboot community, It has been more than 5 years since we have “released” coreboot ‘4.0’. That last release marked some very important milestones that we originally prototyped in the abandoned LinuxBIOS v3 efforts, like the coreboot filesystem (CBFS), Kconfig support, and (strictly) separate device trees, build logic and configuration. Since then there have been as many significant original developments, such as support for many new architectures (ARM, ARM64, MIPS, RISC-V), and related architectural changes like access to non-memory mapped SPI flash, or better insight about the internals of coreboot at runtime through the cbmem console, timestamp collection, or code coverage support. It became clear that a new release is overdue. With our new release process only slowly getting in shape, I decided to take a random commit and call it ‘4.1’. The release itself happens at an arbitrary point in time, but will serve as a starting point for other activities that require some kind of ‘starting point’ to build on, described below. Future releases will happen more frequently, and with more guarantees about the state of the release, like having a cool down phase where boards can be tested and so on. I plan to create a release every three months, so the changes between any two release don’t become too overwhelming. With the release of coreboot 4.1, you get an announcement (this email), a git tag (4.1), and tar archives at http://www.coreboot.org/releases/, for the coreboot sources and the redistributable blobs. Starting with coreboot 4.1, we will maintain a high level changelog and ‘flag days’ document. The latter will provide a concise list of changes which went into coreboot that require chipset or mainboard code to change to keep it working with the latest upstream coreboot. For the time being, I will run these efforts, but I’ll happily share documentation duties with somebody else - it is a great opportunity to keep track of things, learn about the project and its design and various internals, while contributing to the project without the need to code. Please contact me (for example by email or on IRC) if you’re interested, and we’ll work out how to collaborate on this. The process should enable users of coreboot to follow releases if they want a more static base to build on, while making it easier to follow along with new developments by providing upgrade documentation. Since moving away from a rolling (non-)release model is new for coreboot, things may still be a bit rough around the edges, but I’ll provide support for any issues that arise from the release process. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

Re: [coreboot] T400 screen issue / EDID handling
by Pi Van Den Cirkel 13 Jul '15

13 Jul '15

> Dear coreboot community, > > tty0_ in #coreboot/#libreboot found a partial fix. > > See: > http://libreboot.org/docs/hcl/gm45_lcd.html Setting gfx.lvds_dual_channel = 1 is a workaround so that the kernel driver (i915) pickups the right value that coreboot had set. But there are few things to be fixed: 1) No video (fb) during payload(grub) for gm45 (T500) with lcd with dual channel lvds, up to the point where the kernel installs the i915 driver at which point i get working screen. (For single channel lvds controllers all works ok - there is video during payload). 2) There are devices with same model that come both variants (i.e T500) with a single or dual channel lvds . I dont know if there is (currently) way in coreboot (without using the vbios blob) to detect this dynamically (in runtime) instead of setting it in the devicetree. I am willing to work on this problems, but my knowledge is limited in this area. So, any hints on how to proceed, links to specs/docs, etc are welcome.

1 0

Handling NMIs?
by Nick 13 Jul '15

13 Jul '15

Hi guys, Question - Does Coreboot have a facility for catching and handling NMIs? Background: I have a problematic PCI bridge that throws a NMI when enabling it. When this happens, firmware code stops executing. Otherwise, the bridge works. Simply disabling NMIs when enabling this particular device might cause a miss of some other failure and seems like the wrong thing to do. Any suggestions? Thanks! Nick

1 0

Re: [coreboot] [HEADS UP] Time stamps for AGESA boards now measured relatively to start and not ramstage
by Aaron Durbin 11 Jul '15

11 Jul '15

On Sat, Jul 11, 2015 at 12:51 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Sat, Jul 11, 2015 at 11:52 AM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: >> Am Samstag, den 11.07.2015, 08:00 -0500 schrieb Aaron Durbin: >>> On Sat, Jul 11, 2015 at 4:34 AM, Paul Menzel wrote: >> >> […] >> >>> > With the latest changes we they are measured relatively to system >>> > start. >>> > >>> > $ more asrock/e350m1/4.0-10270-gbd1499d/2015-07-10T13\:23\:53Z/coreboot_timestamps.txt >>> > 12 entries total: >>> > >>> > 10:start of ramstage 385,974 >>> > 30:device enumeration 385,982 (8) >>> > 40:device configuration 480,233 (94,250) >>> > 50:device enable 484,088 (3,855) >>> > 60:device initialization 494,049 (9,960) >>> > 70:device setup done 508,368 (14,318) >>> > 75:cbmem post 508,736 (368) >>> > 80:write tables 508,741 (4) >>> > 90:load payload 513,320 (4,579) >>> > 15:starting LZMA decompress (ignore for x86) 513,574 (253) >>> > 16:finished LZMA decompress (ignore for x86) 531,423 (17,848) >>> > 99:selfboot jump 531,445 (21) >>> >>> This is actually surprising, but I just looked into it. I see why; >>> it's from my most recent change. >> >> yes, I also assumed it was due to your change set [1]. >> >>> If I guard with CONFIG_EARLY_CBMEM_INIT it'd go back to the previous >>> way. >> >> I do too. >> >>> But I actually do like this way (though unintended). The base_time >>> was never properly exported it from cbmem: >>> >>> > -------for (i = 0; i < tst_p->num_entries; i++) { >>> > ------->-------const struct timestamp_entry *tse_p = tst_p->entries + i; >>> > ------->-------timestamp_print_entry(tse_p->entry_id, tse_p->entry_stamp, >>> > ------->------->-------i ? tse_p[-1].entry_stamp : 0); >>> > -------} >>> >>> It always assumed 0 as a base_time. Without the diff below base_time >>> is actually 0 in this case so you see the accumulated time until >>> ramstage started. I actually think we should fix cbmem.c to not pass 0 >>> as prev_stamp for 0th index. It should be passing base_time as well as >>> reporting what base_time was from an informational perspective. >> >> I totally agree. > > Care to test this and show the output? See what you like? I don't > have a machine up to test against at the moment. The same information > is there, but it's shown in a different way in that base_time is > reported as an entry of '1st timestamp'. Your example would change to > something like this: > > 0:1st timestamp 385,974 > 10:start of ramstage 385,975 (1) > 30:device enumeration 385,983 (8) > ... > > http://review.coreboot.org/10883 Sorry. You'll see 0 for '1st timestamp' w/ just that patch. However if you test with the following patch (as my original reply) as well then you should see the visibility as I noted above: http://review.coreboot.org/10884 > >> >>> If we want to change it back it's not that hard: >> >> […] >> >> I can’t think of a reason, why we’d want to have the old behavior back. >> >> >> Thanks, >> >> Paul >> >> >>> > [1] http://review.coreboot.org/10880

1 0

Re: [coreboot] [HEADS UP] Time stamps for AGESA boards now measured relatively to start and not ramstage
by Paul Menzel 11 Jul '15

11 Jul '15

Am Samstag, den 11.07.2015, 08:00 -0500 schrieb Aaron Durbin: > On Sat, Jul 11, 2015 at 4:34 AM, Paul Menzel wrote: […] > > With the latest changes we they are measured relatively to system > > start. > > > > $ more asrock/e350m1/4.0-10270-gbd1499d/2015-07-10T13\:23\:53Z/coreboot_timestamps.txt > > 12 entries total: > > > > 10:start of ramstage 385,974 > > 30:device enumeration 385,982 (8) > > 40:device configuration 480,233 (94,250) > > 50:device enable 484,088 (3,855) > > 60:device initialization 494,049 (9,960) > > 70:device setup done 508,368 (14,318) > > 75:cbmem post 508,736 (368) > > 80:write tables 508,741 (4) > > 90:load payload 513,320 (4,579) > > 15:starting LZMA decompress (ignore for x86) 513,574 (253) > > 16:finished LZMA decompress (ignore for x86) 531,423 (17,848) > > 99:selfboot jump 531,445 (21) > > This is actually surprising, but I just looked into it. I see why; > it's from my most recent change. yes, I also assumed it was due to your change set [1]. > If I guard with CONFIG_EARLY_CBMEM_INIT it'd go back to the previous > way. I do too. > But I actually do like this way (though unintended). The base_time > was never properly exported it from cbmem: > > > -------for (i = 0; i < tst_p->num_entries; i++) { > > ------->-------const struct timestamp_entry *tse_p = tst_p->entries + i; > > ------->-------timestamp_print_entry(tse_p->entry_id, tse_p->entry_stamp, > > ------->------->-------i ? tse_p[-1].entry_stamp : 0); > > -------} > > It always assumed 0 as a base_time. Without the diff below base_time > is actually 0 in this case so you see the accumulated time until > ramstage started. I actually think we should fix cbmem.c to not pass 0 > as prev_stamp for 0th index. It should be passing base_time as well as > reporting what base_time was from an informational perspective. I totally agree. > If we want to change it back it's not that hard: […] I can’t think of a reason, why we’d want to have the old behavior back. Thanks, Paul > > [1] http://review.coreboot.org/10880

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2015