Re: [coreboot] [ haswell i7-4600] Why does accessing data in MCHBAR hang the boar?

[Zheng Bao]

I keep debugging and find out the MCHBAR+0x5400 - MCHBAR+0x7FFC can be 
accessed. The address below 0x5400 can cause hang.



Zheng



From: coreboot  on behalf of Zheng Bao 

Sent: Monday, January 29, 2018 11:03 AM
To: coreboot@coreboot.org; Matt DeVillier; Nico Huber
Subject: [coreboot] [ haswell i7-4600] Why does accessing data in MCHBAR hang 
the boar?


After the MRC.bin is loaded and run, the board hang at  accessing data in 
MCHBAR32. If I move MCHBAR32 backward
before the MRC.bin runs, it still hangs. It seems has nothing to do with 
MRC.bin, does it?


   /* For reference print the System Agent version
 * after executing the UEFI PEI stage.
 */
post_code(0xb1);
u32 version = MCHBAR32(0x5034);  //<---hang here
post_code(0x1b);
printk(BIOS_DEBUG, "System Agent Version %d.%d.%d Build %d\n",
version >> 24 , (version >> 16) & 0xff,
(version >> 8) & 0xff, version & 0xff);

Zheng

--
coreboot-4.6-894-ga26344d-dirty Wed Jan 24 05:38:45 UTC 2018 romstage 
starting...
Disabling Watchdog reboot... done.
SMBus controller enabled.

dimm: 00.0: 50
00: 92 10 0b 03 03 19 00 01 03 52 01 08 0c 00 3e 00
10: 69 78 69 30 69 11 20 89 00 05 3c 3c 00 f0 83 81
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 11 21 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 01 98 04 11 41 4f 1a 2d f8 85 10
80: 48 50 35 37 32 32 39 33 2d 44 38 38 2d 45 4c 43
90: 57 47 00 20 02 fe 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5a
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Setting up static northbridge registers... done.
Initializing Graphics...
Back from haswell_early_initialization()
CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
AES supported, TXT supported, VT supported
PCH type: LP Premium, device id: 9c43, rev id 4
Starting UEFI PEI System Agent ___
CBFS: 'Master Header Locator' located CBFS at [300100:3fffc0)
CBFS: Locating 'mrc.bin'
CBFS: Found @ offset 9fec0 size 2e6e4
System Agent: Starting up...
System Agent: Initializing PCH
install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845}
install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276}
System Agent: Initializing PCH (SMBUS)
System Agent: Initializing PCH (USB)
System Agent: Initializing PCH (SA Init)
System Agent: Initializing PCH (Me UMA)
System Agent: Initializing Memory
System Agent: Done.
Sanity checking heap.



-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Power off in Coreboot?

[David Hendricks]

On Mon, Jan 29, 2018 at 1:59 PM, Julius Werner  wrote:

> In grepping the sources I see the API is provided and only used in a
>> handful of cases, mainly x86.
>>
>> On an ARMv8 target is there a power-off use-case for Coreboot?
>> This is strictly from Coreboot perspective, not Depthcharge.
>>
>
> You're right, there is no globally standardized power off API in coreboot,
> it's only implemented internally by select chipsets. There is no ARM target
> that implements something like this at the moment, because they don't
> really need to.
>

Indeed, hlt() is just an infinite loop as currently implemented on aarch64
and that's only used if CONFIG_FATAL_ASSERTS is set as a debug option.

I think the prevailing wisdom is that coreboot always has to try to load
the payload. An error path that shuts down the machine isn't very helpful
to a user, though perhaps that is not always true if we can log an error
(e.g. to RW_ELOG on boot ROM) and the user can retrieve it out-of-band
(systems with a BMC, etc).
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Power off in Coreboot?

[Julius Werner]

>
> In grepping the sources I see the API is provided and only used in a
> handful of cases, mainly x86.
>
> On an ARMv8 target is there a power-off use-case for Coreboot?
> This is strictly from Coreboot perspective, not Depthcharge.
>

You're right, there is no globally standardized power off API in coreboot,
it's only implemented internally by select chipsets. There is no ARM target
that implements something like this at the moment, because they don't
really need to.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Power off in Coreboot?

[mturney]

Folks,
We are working through the PMIC requirements for Coreboot on our 
hardware.
I understand the need for Coreboot to command a reboot, e.g. VerStage 
detects FW_A is bad and wants to try FW_B.
What is not clear is what is the use-case for Coreboot to command a 
power-off.


In grepping the sources I see the API is provided and only used in a 
handful of cases, mainly x86.


On an ARMv8 target is there a power-off use-case for Coreboot?
This is strictly from Coreboot perspective, not Depthcharge.
Cheers,
T.mike

--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] [ haswell i7-4600] Why does accessing data in MCHBAR hang the boar?

[Zheng Bao]

After the MRC.bin is loaded and run, the board hang at  accessing data in 
MCHBAR32. If I move MCHBAR32 backward
before the MRC.bin runs, it still hangs. It seems has nothing to do with 
MRC.bin, does it?


   /* For reference print the System Agent version
 * after executing the UEFI PEI stage.
 */
post_code(0xb1);
u32 version = MCHBAR32(0x5034);  //<---hang here
post_code(0x1b);
printk(BIOS_DEBUG, "System Agent Version %d.%d.%d Build %d\n",
version >> 24 , (version >> 16) & 0xff,
(version >> 8) & 0xff, version & 0xff);

Zheng

--
coreboot-4.6-894-ga26344d-dirty Wed Jan 24 05:38:45 UTC 2018 romstage 
starting...
Disabling Watchdog reboot... done.
SMBus controller enabled.

dimm: 00.0: 50
00: 92 10 0b 03 03 19 00 01 03 52 01 08 0c 00 3e 00
10: 69 78 69 30 69 11 20 89 00 05 3c 3c 00 f0 83 81
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 11 21 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 01 98 04 11 41 4f 1a 2d f8 85 10
80: 48 50 35 37 32 32 39 33 2d 44 38 38 2d 45 4c 43
90: 57 47 00 20 02 fe 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5a
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Setting up static northbridge registers... done.
Initializing Graphics...
Back from haswell_early_initialization()
CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz
AES supported, TXT supported, VT supported
PCH type: LP Premium, device id: 9c43, rev id 4
Starting UEFI PEI System Agent ___
CBFS: 'Master Header Locator' located CBFS at [300100:3fffc0)
CBFS: Locating 'mrc.bin'
CBFS: Found @ offset 9fec0 size 2e6e4
System Agent: Starting up...
System Agent: Initializing PCH
install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845}
install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276}
System Agent: Initializing PCH (SMBUS)
System Agent: Initializing PCH (USB)
System Agent: Initializing PCH (SA Init)
System Agent: Initializing PCH (Me UMA)
System Agent: Initializing Memory
System Agent: Done.
Sanity checking heap.



-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot