Dear Coreboot list, I'm still trying to bring up custom mainboard with Apollo Lake E3950 SoC and LPDDR4 memory. I have successfully built images with different payloads that passes all the initializations but all of them fails to boot further:
1. Coreboot + Seabios + bootable USB with Linux. Stuck when booting from USB (but I am able to reboot the system using a Ctr-Alt-Del on a keyboard) 2. Coreboot + Seabios + memtest. Stuck on booting memtest (CtrAltDel does nothing) 3. Coreboot + Seabios + coreinfo. General protection fault 4. Coreboot + LinuxBoot. Works on QEMU, hangs on my board (CtrAltDel does nothing) Looks like a hardware or FSP configuration issue. But I cannot find a way to debug this thing and find the reason. For instance, how I can understand why Linux kernel (or memtest) fails to boot when there is no debug output at all?
You will find Coreboot logs and .config for Seabios image (memtest, coreinfo, usb).
PS Still have no HDMI output and DCI debug. Serial console is my only option for now.
Best Regards, Anatolii Vorobev
Anatolii Vorobev wrote:
Run img/coreinfo Calling addr 0x00100000 ERROR: No keyboard controller found!
General Protection Fault Exception Error code: 0x0 - descriptor 0x0 in the GDT, internal to the CPU EIP: 0x00101943 CS: 0x0010 EFLAGS: 0x00010002 EAX: 0xffffffff ECX: 0xffffffff EDX: 0x00000000 EBX: 0x00000004 ESP: 0x00167a7c EBP: 0x00167ae8 ESI: 0xffd1bdba EDI: 0x0011d8da DS: 0x0018 ES: 0x0018 SS: 0x0018 FS: 0x0018 GS: 0x0018
So what does the disassembly look like of that coreinfo binary around the EIP address of the fault?
Dumping stack: 0x167c60: 83358235 833592b5 83359334 83359336 833583b4 d3258324 83358325 833582a4 0x167c40: e88ff89f f88ff99e e99fec9d e99ef88e 789fe88f f88de98e e89ee99f e9bef98f 0x167c20: 83358235 83359237 83359335 13379334 83358334 83258325 83358325 83358225 0x167c00: 2c8ff89f f887d99d e99fe89e f99cf80e f89fe88f e88fe99e ec9ee99f f99ef90f 0x167be0: 6ae6fbe3 fa73ebe2 fa7aeae3 fff3caf2 fbd9fae2 fafbfbf2 efc7fb73 fa8aebf3 0x167bc0: 8ac79ac4 9ad58ad5 8bcc8bd5 8ac78ec4 9b549a44 8bd48bd5 9ac5afd5 1bd49ad5 0x167ba0: eac0fbe3 fa53ebe3 faf8eae3 7fe3ca72 fbe3fae2 eaebdaf2 efb1fa63 fac2ebd3 0x167b80: 8ea49ac4 9eef8ad5 9b4c8bd5 8ad58ac4 9b5e9ac4 8ec48bd4 9add8b95 9ff29ad4 0x167b60: 964a0762 065a1e6b 067a377b 077b066a 076b176b 17d3063a 177916fa 56620663 0x167b40: 4a060b14 0b0c0845 1a150a05 0b1d1b05 1a241b05 0a070b04 1b040b04 13070b15 0x167b20: 1672076a 066216eb 06f2177b 0778066a 0761176a 177f067b 1779367a 567a076a 0x167b00: 00000000 00000000 0010009c 00006fb4 1af41b05 0a050b24 bb2c0b04 1b050b15 0x167ae0: 00100000 ffd1bdba ffcfe4c4 00104904 00107f5f 001139af 0011bf58 00104904 0x167ac0: ffd1bdba 00167adc ffcfe4c4 00106015 00000000 0011d8da 00106015 00167b00 0x167aa0: 00000010 00143ce0 001115ca 8000f900 0000000e 00111556 8000ff00 00100000 0x167a80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00143cf8 0x167a60: ffd1bdba 0011d8da 00167a78 00000000 00101943 00000010 00010002 0010468c
Is this stack contents plausible in your application?
It looks quite regular.
The other two cases unfortunately provide no information once SeaBIOS hands off, but at least you have this output from coreinfo, which may provide some clues. Looking quickly I didn't see anything super obvious in the coreboot output, but I also don't know this platform.
//Peter
-
Anatolii Vorobev -
Peter Stuge