Hi all,
I made a discovery yesterday that somehow solves my initial problem:
The function bootblock_cpu_init() (/src/soc/intel/braswell/bootblock/bootblock.c) contains a call to enable_rom_caching(). If I remove this call then TempRamInit returns successfully and coreboot is able to call cache_as_ram_main(). Hence, TempRamInit must have returned a valid (cache) memory range and I have a stack now.
I don’t yet understand the implications of this “fix”, nor how it relates to TempRamInit. Maybe, someone from Intel can shed light on this. Meanwhile I’m learning about memory type range registers (MTRRs) because they are being accessed in enable_rom_caching().
Also, cheng, can you confirm that this works for you?
Best regards, Alex
Hi Alex
It's workable, after remove enable_rom_caching(). but I don't know why cpu will be impacted by MTRR. Thank you for your sharing
2016-07-27 16:56 GMT+08:00 Alexander Böcken < Alexander.Boecken@junger-audio.com>:
Hi all,
I made a discovery yesterday that somehow solves my initial problem:
The function bootblock_cpu_init() (/src/soc/intel/braswell/bootblock/bootblock.c) contains a call to enable_rom_caching(). If I remove this call then TempRamInit returns successfully and coreboot is able to call cache_as_ram_main(). Hence, TempRamInit must have returned a valid (cache) memory range and I have a stack now.
I don’t yet understand the implications of this “fix”, nor how it relates to TempRamInit. Maybe, someone from Intel can shed light on this. Meanwhile I’m learning about memory type range registers (MTRRs) because they are being accessed in enable_rom_caching().
Also, cheng, can you confirm that this works for you?
Best regards,
Alex
The function bootblock_cpu_init() (/src/soc/intel/braswell/bootblock/bootblock.c)
contains a call to enable_rom_caching()
This is the function, you are talking about:
static void enable_rom_caching(void) { msr_t msr;
disable_cache(); /* Why only top 4MiB ? */ set_var_mtrr(1, 0xffc00000, 4*1024*1024, MTRR_TYPE_WRPROT); enable_cache();
/* Enable Variable MTRRs */ msr.hi = 0x00000000; msr.lo = 0x00000800; wrmsr(MTRR_DEF_TYPE_MSR, msr); }
I went to the Intel® 64 and IA-32 Architectures Software Developer Manuals https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwj8pJm7m5XOAhWIQpoKHQ-pBQMQFggcMAA&url=http%3A%2F%2Fwww.intel.com%2Fcontent%2Fwww%2Fus%2Fen%2Fprocessors%2Farchitectures-software-developer-manuals.html&usg=AFQjCNE0-V4xbVESpNFUdDMbSBXxnivKNw&sig2=6FShgOk_1L15UQbj6FlfYA&bvm=bv.128153897,d.bGg to try to understand what really MTRR_DEF_TYPE_MSR refister (MSR 0x2FF) really means.
After reading the appropriate parts to actually analyze this register, I got confused.
[image: Inline image 1]
First, I do not understand (as comment says correctly: Why only top 4MiB?), why not all 8MiB? Or maybe 16MiB, actual size of board flash?
Second. I see that the type of this memory (msr.lo = 0x00000800;) is E - MTRR enable, FE disabled, type uncacheable - 0x00 (instead MTRR_TYPE_WRPROT - 0x05).
Seems that this function was blindly copy/pasted from some other place... While creating BSW Coreboot context.
Best Regards, Zoran
On Wed, Jul 27, 2016 at 10:56 AM, Alexander Böcken < Alexander.Boecken@junger-audio.com> wrote:
Hi all,
I made a discovery yesterday that somehow solves my initial problem:
The function bootblock_cpu_init() (/src/soc/intel/braswell/bootblock/bootblock.c) contains a call to enable_rom_caching(). If I remove this call then TempRamInit returns successfully and coreboot is able to call cache_as_ram_main(). Hence, TempRamInit must have returned a valid (cache) memory range and I have a stack now.
I don’t yet understand the implications of this “fix”, nor how it relates to TempRamInit. Maybe, someone from Intel can shed light on this. Meanwhile I’m learning about memory type range registers (MTRRs) because they are being accessed in enable_rom_caching().
Also, cheng, can you confirm that this works for you?
Best regards,
Alex