Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass with FSP 2.0. I have a strange issue that I hope to get some wisdom. The boot hangs when executing this line "sub %ecx, %ebx" in src/arch/x86/walkcbfs.S; the post code showing up is 0xb1.
When I add a spinloop before this statement "sub %ecx, %ebx", the postcode stays at 0x21, which means code execution till this point is smooth.
My codebase is based on current tip of upstream code. In the .config file, following are set (greping BOOTBLOCK): CONFIG_C_ENV_BOOTBLOCK_SIZE=0x10000 CONFIG_BOOTBLOCK_CPU_INIT="soc/intel/fsp_skylake_fsp/bootblock/bootblock.c" CONFIG_ARCH_BOOTBLOCK_X86_32=y CONFIG_BOOTBLOCK_SIMPLE=y CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c" CONFIG_BOOTBLOCK_CONSOLE=y CONFIG_C_ENVIRONMENT_BOOTBLOCK=y
Any pointer is appreciated. Let me know if you need any additional information.
Thank you, Jonathan
I am not sure you have access to some kind of XDP or Jtag, but an general idea is after romcc complied the code may looks different. You may use objdump to double check that, such as compare the disasemble on DUT and disasemble from objdump.
I have not been able to work on that platform before, just a general idea.
On Wed, Feb 13, 2019, 3:32 PM Jonathan Zhang jon.zhixiong.zhang@gmail.com wrote:
Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass with FSP 2.0. I have a strange issue that I hope to get some wisdom. The boot hangs when executing this line "sub %ecx, %ebx" in src/arch/x86/walkcbfs.S; the post code showing up is 0xb1.
When I add a spinloop before this statement "sub %ecx, %ebx", the postcode stays at 0x21, which means code execution till this point is smooth.
My codebase is based on current tip of upstream code. In the .config file, following are set (greping BOOTBLOCK): CONFIG_C_ENV_BOOTBLOCK_SIZE=0x10000 CONFIG_BOOTBLOCK_CPU_INIT="soc/intel/fsp_skylake_fsp/bootblock/bootblock.c" CONFIG_ARCH_BOOTBLOCK_X86_32=y CONFIG_BOOTBLOCK_SIMPLE=y CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c" CONFIG_BOOTBLOCK_CONSOLE=y CONFIG_C_ENVIRONMENT_BOOTBLOCK=y
Any pointer is appreciated. Let me know if you need any additional information.
Thank you, Jonathan _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I am not sure you have access to some kind of XDP or Jtag, but an general
idea is after romcc complied the code may looks different. You may use objdump to double check that, such as compare the disasemble on DUT and disasemble from objdump.
Well the first suspect was .S file so it does not go thru C compiler. It was also skylake platform so it would not be romcc even for bootblock.
Sometimes system watchdogs can fool you to believe a fault between two POST codes, when it's really hitting some timeout.
Kyösti
Yes you are right, .s is purely assembly file.
On Wed, Feb 13, 2019, 4:20 PM Kyösti Mälkki kyosti.malkki@gmail.com wrote:
I am not sure you have access to some kind of XDP or Jtag, but an general
idea is after romcc complied the code may looks different. You may use objdump to double check that, such as compare the disasemble on DUT and disasemble from objdump.
Well the first suspect was .S file so it does not go thru C compiler. It was also skylake platform so it would not be romcc even for bootblock.
Sometimes system watchdogs can fool you to believe a fault between two POST codes, when it's really hitting some timeout.
Kyösti
Hi Jonathan,
On 13.02.19 08:31, Jonathan Zhang wrote:
Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass with FSP 2.0. I have a strange issue that I hope to get some wisdom. The boot hangs when executing this line "sub %ecx, %ebx" in src/arch/x86/walkcbfs.S
I don't know what might cause it, but have two pointers:
1. I was wondering why you would have to look at CBFS from assembly at all. Do you have CONFIG_FSP_CAR set? Using the FSP CAR setup is probably not the best idea, as it is likely the least tested path. Better select a native coreboot solution instead, in case.
2. First idea that always jumps into mind when I see early instabili- ties: Do you have microcode updates *matching your CPU stepping* in your coreboot.rom? It might also be worth to check if the FIT table points correctly to them (64 bytes from the top of the .rom should be a pointer to the FIT, that should have an entry pointing to the updates). I don't know about Skylake, but generally, there may be steppings that need an update really early.
Hope that helps, Nico
I had once a very similar case on Baytrail or Broadwell at the very beginning. The root cause in my case was that walkcbfs was not able to find the next stage (romstage IIRC) because the SPI flash address was not mapped properly into MMIO space.
Check the size of your flash in Kconfig and the size you have set up for caching (VIRTUAL_ROM_SIZE). You can hit the same issue if you have used 32 MB for flash size in Kconfig. Then exact this can happen as x86 can only map 16 MB maximum into MMIO space and your next stage might be to far away from the bootblock.
Werner
-----Ursprüngliche Nachricht----- Von: Nico Huber nico.h@gmx.de Gesendet: Mittwoch, 13. Februar 2019 10:29 An: Jonathan Zhang jon.zhixiong.zhang@gmail.com; coreboot@coreboot.org Betreff: [coreboot] Re: hang in walkcbfs.S on skylake SP
Hi Jonathan,
On 13.02.19 08:31, Jonathan Zhang wrote:
Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass with FSP 2.0. I have a strange issue that I hope to get some wisdom. The boot hangs when executing this line "sub %ecx, %ebx" in src/arch/x86/walkcbfs.S
I don't know what might cause it, but have two pointers:
- I was wondering why you would have to look at CBFS from assembly at all. Do you have CONFIG_FSP_CAR set? Using the FSP CAR
setup is probably not the best idea, as it is likely the least tested path. Better select a native coreboot solution instead, in case.
- First idea that always jumps into mind when I see early instabili-
ties: Do you have microcode updates *matching your CPU stepping* in your coreboot.rom? It might also be worth to check if the FIT table points correctly to them (64 bytes from the top of the .rom should be a pointer to the FIT, that should have an entry pointing to the updates). I don't know about Skylake, but generally, there may be steppings that need an update really early.
Hope that helps, Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Thank you for your feedback, Lance/Kyosti/Nico/Zeh.
After I used INTEL_COMMON_BLOCK_CAR instead of FSP_CAR, the boot process progressed beyond this failure point.
Jonathan
On Wed, Feb 13, 2019 at 1:45 AM Zeh, Werner werner.zeh@siemens.com wrote:
I had once a very similar case on Baytrail or Broadwell at the very beginning. The root cause in my case was that walkcbfs was not able to find the next stage (romstage IIRC) because the SPI flash address was not mapped properly into MMIO space.
Check the size of your flash in Kconfig and the size you have set up for caching (VIRTUAL_ROM_SIZE). You can hit the same issue if you have used 32 MB for flash size in Kconfig. Then exact this can happen as x86 can only map 16 MB maximum into MMIO space and your next stage might be to far away from the bootblock.
Werner
-----Ursprüngliche Nachricht----- Von: Nico Huber nico.h@gmx.de Gesendet: Mittwoch, 13. Februar 2019 10:29 An: Jonathan Zhang jon.zhixiong.zhang@gmail.com; coreboot@coreboot.org Betreff: [coreboot] Re: hang in walkcbfs.S on skylake SP
Hi Jonathan,
On 13.02.19 08:31, Jonathan Zhang wrote:
Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass with FSP 2.0. I have a strange issue that I hope to get some wisdom. The boot hangs when executing this line "sub %ecx, %ebx" in src/arch/x86/walkcbfs.S
I don't know what might cause it, but have two pointers:
- I was wondering why you would have to look at CBFS from assembly at all. Do you have CONFIG_FSP_CAR set? Using the FSP CAR
setup is probably not the best idea, as it is likely the least tested path. Better select a native coreboot solution instead, in case.
- First idea that always jumps into mind when I see early instabili-
ties: Do you have microcode updates *matching your CPU stepping* in your coreboot.rom? It might also be worth to check if the FIT table points correctly to them (64 bytes from the top of the .rom should be a pointer to the FIT, that should have an entry pointing to the updates). I don't know about Skylake, but generally, there may be steppings that need an update really early.
Hope that helps, Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Jonathan Zhang -
Kyösti Mälkki -
Lance Zhao -
Nico Huber -
Zeh, Werner