Re: [coreboot] Microcode problem with Braswell CPU
Hi Zoran,
yes, that’s the function. I also found the same information in the Intel docs.
The docs say, the processor starts up with all caching disabled. So, the
function marks the top 4 MB as write-protected memory and thus enables caching
for this region. The MTTR_DEF_TYPE MSR set the default memory configuration for
all memory regions that were not explicitly configured by fixed/variable MTTRs.
Intel recommends to use uncachable memory for all non-existing physical memory.
As we haven’t initialized DDR memory at this point, this seems fine to me.
However, TempRamInit also seems to fuss about caching, regarding the FSP
specification. So the code seems to interfere somehow, at least on my CPU. I
don’t know.
Best regards,
Alex
Von: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
Gesendet: Donnerstag, 28. Juli 2016 06:47
An: Alexander Böcken
Cc: cheng yichen; coreboot; york.y...@intel.com
Betreff: Re: [coreboot] Microcode problem with Braswell CPU
> 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, 0xffc0, 4*1024*1024, MTRR_TYPE_WRPROT);
enable_cache();
/* Enable Variable MTRRs */
msr.hi = 0x;
msr.lo = 0x0800;
wrmsr(MTRR_DEF_TYPE_MSR, msr);
}
I went to the Intel® 64 and IA-32 Architectures Software Developer
Manuals
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.
[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 = 0x0800;) 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
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode problem with Braswell CPU
> 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, 0xffc0, 4*1024*1024, MTRR_TYPE_WRPROT);
enable_cache();
/* Enable Variable MTRRs */
msr.hi = 0x;
msr.lo = 0x0800;
wrmsr(MTRR_DEF_TYPE_MSR, msr);
}
I went to the Intel® 64 and IA-32 Architectures Software Developer Manuals
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 = 0x0800;) 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.boec...@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
>
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Turns out I never knew what intuitive meant.
"ASUS AM1I-A is an AM1 Socket-based Mini-ITX motherboard. It has an intuitive UEFI BIOS " er, what? What's the word intuitive mean again? ron -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] ASUS KFSN4-DRE (K8) Automated Test Failure [master]
The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit e3e2bb0a892bc185a52f210bcae15db268c1d034 The following tests failed: BOOT_FAILURE Commits since last successful test: e3e2bb0 util: Correct typo in MSR_EBC_SOFT_POWERON 7ab98fb util/msrtool: update register for Pentium4_later e5a5084 msrtool/README: Remove trailing spaces 3339861 soc/intel/skylake: Use init_vbnv_cmos from vboot vbnv 0faf401 soc/intel/broadwell: Use init_vbnv_cmos from vboot vbnv <9 commits skipped> af8ef2a drivers/intel/fsp2_0: Update MRC cache with dead version in recovery c319737 soc/intel/common: Store MRC data in next available slot in the cache bc24b85 mainboard/google/slippy: remove unobtainable mainboard 139314b mainboard/google/bolt: remove unobtainable mainboard 60cc75d soc/intel/apollolake: Disable monitor mwait See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand Want to test on your own equipment? Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering regarding any issues stemming from this notification 1469669503-2-automaster.log.bz2 Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] WG: What is the best way to treat warnings reported by checkpatch.pl
Hey Werner, Thanks for bringing up this topic. It's something we've discussed a bunch of times, but hadn't done anything about until now. Here's what I've done: I've pushed the .checkpatch.conf from the Chrome OS coreboot tree https://review.coreboot.org/#/c/15919/ I had initially pushed a patch to update the pre-commit git hook to say "If this failure is invalid, bypass it with 'git commit -n'.", but i decided I'd rather do that inside checkpatch.pl so everyone who has already run make gitconfig will get the fix, so I abandoned that change. It needed some additional fixes anyway. I'll push another commit shortly. I've also added a jenkins build to run checkpatch on every commit, but that doesn't give any feedback in the commit, so it doesn't seem super useful right now. You have to go into the console output for the jenkins build to see the results. Here's an example: https://qa.coreboot.org/job/coreboot-checkpatch/30/console What other changes to checkpatch are needed? Martin On Tue, Jul 26, 2016 at 10:34 PM, Zeh, Werner wrote: >>Does git commit --no-verify (or -n for short) allow you to commit? >> > > Yes, one can go this way and I did it already earlier. But I just wanted to > point it out here. > We do not need a check script for every commit if we simply disable the check > when it comes to issues. > I wanted to start this discussion to improve the situation with this script > we currently have. > >>I think we should try to do a little of option 1 within reason, not by >>forking the script but rather by disabling more check steps that don't match >>the coreboot code style (by >having our wrapper pass --ignore XXX flags to >>checkpatch) and possibly upstreaming checkpatch.pl patches with new features >>we need to the Linux kernel (to make the >detection more accurate or add a >>more specific --ignore flag we can turn on). In the Chromium fork of coreboot >>we're already using a bunch of those flags that we should >probably use in >>upstream coreboot as well: >> >>--ignore C99_COMMENTS >>--ignore GLOBAL_INITIALISERS >>--ignore INITIALISED_STATIC >>--ignore LINE_SPACING >>--ignore NEW_TYPEDEFS >>--ignore PREFER_ALIGNED >>--ignore PREFER_PACKED >>--ignore PREFER_PRINTF >>--ignore SPLIT_STRING >> > > If we really did not touch the contents of the script, I totally agree with > you. We can disable warnings that do not match our coding style while > updating the script from its origin from time to time. If we have already > started tailoring this script, than we should do it the right way and end > this tailoring process to match our needs. I admit that the later one will > end up in more work if one wants to synchronize this script with origin again > one day. > > Werner > -- > coreboot mailing list: coreboot@coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the best way to treat warnings reported by checkpatch.pl
> typedef struct dmar_atsr_entry {
>u16 type;
>u16 length;
>u8 flags;
>u8 reserved;
>u16 segment;
> } __attribute__ ((packed)) dmar_atsr_entry_t;
Looking at the original example here, I would still recommend not to
use the packed attribute. It forces the compiler to use accesses that
would work on unaligned data... for x86 that doesn't matter (and
granted, this sounds x86-specific, but it's worth applying the same
principles to all code), but for other architectures it may generate
very inefficient code (even on ARM where unaligned accesses are okay
after you turn on caching, GCC keeps doing this for all packed
structures and there's no way to convince it otherwise). In this case,
the members are all correctly aligned so there's no need to insert
padding, so you can (and therefore should) leave out the packed
attribute.
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the best way to treat warnings reported by checkpatch.pl
Ah well, Werner, I've had the error of my ways pointed out to me, turns out this packed stuff is a standard practice in coreboot now. I must have missed the memo. So, I'm not a fan but if that's how we do it, it's how we do it. thanks and apologies ron On Wed, Jul 27, 2016 at 10:07 AM ron minnich wrote: > On Tue, Jul 26, 2016 at 9:25 PM Zeh, Werner > wrote: > >> >> >> >> In the case of ACPI we need to provide a table which has constrains on >> the used data types and alignment >> as the contents of the table will be interpreted by the ACPI interpreter >> of the OS. >> So if we omit the usage of packed it may result in gaps in between the >> single members of the data structure >> which will in turn lead to errors while the OS interprets the contents. >> >> So in my point of view, we really need this structure to be packed in >> this case. >> >> >> > > no, please don't do this. We and others have made this mistake before and > it took a lot of work to unwind it where we did it. Using packed structs to > create aligned data in memory is a frequent source of bugs. > > If you're creating a desired data layout in memory, from a struct, using > packed will fail badly should we ever have a big endian machine, but it can > even have weird problems between gcc versions. When you pack data into > memory with a specified alignment, byte order, and padding, you are > converting it to an external data representation, i.e. XDR. You need to do > that explicitly, not by using packed structs. > > We've got code in the repo which does this. Please look at util/cbfstool/ > for example code, or see the mptable generation code. just git grep xdr to > see some usage. > > But using packed structs to try to force layout of data in memory is > almost always going to end badly. For a fun read, check this out > https://sourceware.org/bugzilla/show_bug.cgi?id=5070 > > This one section is applicable: > "Tom Hunter 2007-10-02 05:45:39 UTC > ARM is one of the architectures supported by glibc. You may not like it, > but it > is a fact. > > Independently of the architecture, the padding done is not valid. You > can't > (and shouldn't) make any assumption about the alignment and associated > padding > done by the compiler for any architecture. GCC is free to change the > alignment > rules in any future versions. It seems rather silly to have the assert() > which > is meant to verify at runtime that your invalid assumption holds true. > > I would also suggest that you don't use structures to format packets for > networking. Packets for networking should be treated as byte streams to > avoid > any alignment/padding/byte-order issues. A standard way of doing this is > something like this: > > unsigned char buf[MaxPacketSize]; > unsigned char *bp; > int skt; > size_t len; > > ... > bp = buf; > *bp++ = ...; > *bp++ = ...; > *bp++ = ...; > ... > len = send(skt, buf, bp - buf, 0); > " > > The key realization is that Tom is right even when you're packing to > memory. > > ron > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] What is the best way to treat warnings reported by checkpatch.pl
On Tue, Jul 26, 2016 at 9:25 PM Zeh, Werner wrote: > > > > In the case of ACPI we need to provide a table which has constrains on the > used data types and alignment > as the contents of the table will be interpreted by the ACPI interpreter > of the OS. > So if we omit the usage of packed it may result in gaps in between the > single members of the data structure > which will in turn lead to errors while the OS interprets the contents. > > So in my point of view, we really need this structure to be packed in this > case. > > > no, please don't do this. We and others have made this mistake before and it took a lot of work to unwind it where we did it. Using packed structs to create aligned data in memory is a frequent source of bugs. If you're creating a desired data layout in memory, from a struct, using packed will fail badly should we ever have a big endian machine, but it can even have weird problems between gcc versions. When you pack data into memory with a specified alignment, byte order, and padding, you are converting it to an external data representation, i.e. XDR. You need to do that explicitly, not by using packed structs. We've got code in the repo which does this. Please look at util/cbfstool/ for example code, or see the mptable generation code. just git grep xdr to see some usage. But using packed structs to try to force layout of data in memory is almost always going to end badly. For a fun read, check this out https://sourceware.org/bugzilla/show_bug.cgi?id=5070 This one section is applicable: "Tom Hunter 2007-10-02 05:45:39 UTC ARM is one of the architectures supported by glibc. You may not like it, but it is a fact. Independently of the architecture, the padding done is not valid. You can't (and shouldn't) make any assumption about the alignment and associated padding done by the compiler for any architecture. GCC is free to change the alignment rules in any future versions. It seems rather silly to have the assert() which is meant to verify at runtime that your invalid assumption holds true. I would also suggest that you don't use structures to format packets for networking. Packets for networking should be treated as byte streams to avoid any alignment/padding/byte-order issues. A standard way of doing this is something like this: unsigned char buf[MaxPacketSize]; unsigned char *bp; int skt; size_t len; ... bp = buf; *bp++ = ...; *bp++ = ...; *bp++ = ...; ... len = send(skt, buf, bp - buf, 0); " The key realization is that Tom is right even when you're packing to memory. ron -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Where is the first instrucion?
Hi Zoran, thanks a lot for expending your time to help! I'll take a look. (It may take some time, but I will! ) Rafael R. Machado Em qua, 27 de jul de 2016 às 08:17, Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> escreveu: > Hello Rafael, > > I am looking into disassembly pointed by you: > > > f000:0fcb 66b9ff02mov ecx, 0x2ff > > f000:0fd1 0f32 rdmsr ; read register > 0x2ff (IA32_MTRR_DEF_TYPE) > > f000:0fd3 0fbae80b bts ax, 0xb ; Enable bit 11 (MTRR > Enable). > > f000:0fd7 0fbae80a bts ax, 0xa ; Enable bit 10 (Fixed > MTRR Enable). > > f000:0fdb 0f30 wrmsr; Write changes to > MTRR > > f000:0fdd 0f20c0 mov eax, cr0 > > f000:0fe0 660fbaf01e btr eax, 0x1e ; Bit 30 means CD - Cache > disabled. > > f000:0fe5 660fbaf01d btr eax, 0x1d ; Disable bit 29. NW - No > Write-through > > f000:0fea 0f22c0 mov cr0, eax ; Write changes to CR0 > > f000:0fed ffe7 jmp di > > f000:0fef 0f20c0 mov eax, cr0 > > f000:0ff2 660fbae81e bts eax, 0x1e > > f000:0ff7 660fbae81d bts eax, 0x1d > > f000:0ffc 0f22c0 mov cr0, eax > > Looks very similar like sequence in Coreboot ROMSTAGE ( > src/cpu/intel/car/cache_as_ram.inc): > > /* We don't need CAR from now on. */ > > /* Disable cache. */ > movl %cr0, %eax > orl $CR0_CacheDisable, %eax > movl %eax, %cr0 > > /* Clear sth. */ > movl $MTRR_FIX_4K_C8000, %ecx > xorl %edx, %edx > xorl %eax, %eax > wrmsr > > #if CONFIG_DCACHE_RAM_SIZE > 0x8000 > movl $MTRR_FIX_4K_C, %ecx > wrmsr > #endif > > /* > * Set the default memory type and disable fixed > * and enable variable MTRRs. > */ > movl $MTRR_DEF_TYPE_MSR, %ecx > xorl %edx, %edx > movl $MTRR_DEF_TYPE_EN, %eax /* Enable variable and disable fixed MTRRs. > */ > wrmsr > > /* Enable cache. */ > movl %cr0, %eax > andl $(~(CR0_CacheDisable | CR0_NoWriteThrough)), %eax > movl %eax, %cr0 > > __main: > > Please, check upon it. Please, pass to us your comments... If any? > > Best Regards, > Zoran > > On Tue, Jul 26, 2016 at 4:23 AM, Rafael Machado < > rafaelrodrigues.mach...@gmail.com> wrote: > >> Thanks a lot Zoran. >> I will! >> >> Rafael >> >> Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic < >> zoran.stojsavlje...@gmail.com> escreveu: >> >>> Hello Rafael, >>> >>> Let me try hard... ;-) >>> >>> Let us look into what actually we have here, in Coreboot: in bootblock >>> phase, at the very beginning. >>> Let me tell you what I am looking into (what cb tree): [zoran@localhost >>> coreboot-09.06.2016]$ git describe >>> 4.4-455-g538b324 >>> >>> Let us backtrace, to understand what is actual thread of execution: >>> src/arch/x86/prologue.inc >>> src/cpu/x86/16bit/entry16.inc >>> src/cpu/x86/16bit/reset16.inc >>> src/cpu/x86/32bit/entry32.inc >>> src/cpu/x86/sse_enable.inc >>> src/arch/x86/bootblock_simple.c >>> >>> Please, carefully examine what I pointed/presented here... And let us >>> know your thoughts. >>> >>> Best Regards, >>> Zoran >>> >>> On Mon, Jul 25, 2016 at 6:03 PM, Rafael Machado < >>> rafaelrodrigues.mach...@gmail.com> wrote: >>> Hi guys. Long time since my last e-mail. It's hard to synchronize my day work with my firmware studies. Since my projects are more UEFI related I usually do not have to much time to study the legacy way, but It's really cool and Ill not give up :) Since the last talk I was doing what everyone kindly proposed. (by the way thank you all for the guidance.) Now I'm disassembly an old systems bios I have, but I cannot understand what is happening in a specific section of the code. (I'm using radare2 for my studies) The code is: f000:0fcb 66b9ff02mov ecx, 0x2ff f000:0fd1 0f32 rdmsr ; read register 0x2ff (IA32_MTRR_DEF_TYPE) f000:0fd3 0fbae80b bts ax, 0xb ; Enable bit 11 (MTRR Enable). f000:0fd7 0fbae80a bts ax, 0xa ; Enable bit 10 (Fixed MTRR Enable). f000:0fdb 0f30 wrmsr; Write changes to MTRR f000:0fdd 0f20c0 mov eax, cr0 f000:0fe0 660fbaf01e btr eax, 0x1e ; Bit 30 means CD - Cache disabled. f000:0fe5 660fbaf01d btr eax, 0x1d ; Disable bit 29. NW - No Write-through f000:0fea 0f22c0 mov cr0, eax ; Write changes to CR0 f000:0fed ffe7 jmp di f000:0fef 0f20c0 mov eax, cr0 f000:0ff2 660fbae81e bts eax, 0x1e f000:0ff7 660fbae81d bts eax, 0x1d f000:0ffc 0f22c0 mov cr0, eax Here is the code with my notes. I understand that some MTRR were set, and now the processor will be "configured". We see at address f000:0fe0 and f000:0fe5 that the CR
[coreboot] initrd in 4.4 versus head
I see a difference in the way 4.4 handles initrd images for linux payloads versus the way it is done in head. With 4.4 my Linux kernel can not find the external initrd, so it is necessary to build it as part of the kernel. With head it works fine. It looks like 4.4 is adding the initrd as a separate section named "(empty)" with type "null" and the kernel can't find it: performing operation on 'COREBOOT' region... Name Offset Type Size cbfs master header 0x0cbfs header 32 cpu_microcode_blob.bin 0x80 microcode22528 cmos.default 0x5900 cmos_default 256 cmos_layout.bin0x5a40 cmos_layout 1948 fallback/dsdt.aml 0x6240 raw 13847 (empty)0x98c0 null 26264 fallback/romstage 0xff80 stage74020 (empty)0x22140null 56664 mrc.cache 0x2fec0mrc_cache65536 fallback/ramstage 0x3ff00stage84790 fallback/payload 0x54a80payload 1618769 (empty)0x1dfe40 null 2226328 bootblock 0x3ff700 bootblock1952 While in head it is bundling them together into the payload region (3.9 MB == bzImage + initrd.img) -- the kernel can find the image and use it: Performing operation on 'COREBOOT' region... Name Offset Type Size cbfs master header 0x0cbfs header 32 fallback/romstage 0x80 stage14620 cpu_microcode_blob.bin 0x3a00 microcode22528 fallback/ramstage 0x9280 stage43781 cmos_layout.bin0x13dc0cmos_layout 1948 fallback/dsdt.aml 0x145c0raw 4021 fallback/payload 0x155c0payload 3906169 (empty)0x3cf080 null 199256 bootblock 0x3ffb00 bootblock960 I don't see any changes in the util/cbfstool/cbfs-payload-linux.c file between these two versions. Is there something else that changed? -- Trammell -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Where is the first instrucion?
Hello Rafael, I am looking into disassembly pointed by you: > f000:0fcb 66b9ff02mov ecx, 0x2ff > f000:0fd1 0f32 rdmsr ; read register 0x2ff (IA32_MTRR_DEF_TYPE) > f000:0fd3 0fbae80b bts ax, 0xb ; Enable bit 11 (MTRR Enable). > f000:0fd7 0fbae80a bts ax, 0xa ; Enable bit 10 (Fixed MTRR Enable). > f000:0fdb 0f30 wrmsr; Write changes to MTRR > f000:0fdd 0f20c0 mov eax, cr0 > f000:0fe0 660fbaf01e btr eax, 0x1e ; Bit 30 means CD - Cache disabled. > f000:0fe5 660fbaf01d btr eax, 0x1d ; Disable bit 29. NW - No Write-through > f000:0fea 0f22c0 mov cr0, eax ; Write changes to CR0 > f000:0fed ffe7 jmp di > f000:0fef 0f20c0 mov eax, cr0 > f000:0ff2 660fbae81e bts eax, 0x1e > f000:0ff7 660fbae81d bts eax, 0x1d > f000:0ffc 0f22c0 mov cr0, eax Looks very similar like sequence in Coreboot ROMSTAGE ( src/cpu/intel/car/cache_as_ram.inc): /* We don't need CAR from now on. */ /* Disable cache. */ movl %cr0, %eax orl $CR0_CacheDisable, %eax movl %eax, %cr0 /* Clear sth. */ movl $MTRR_FIX_4K_C8000, %ecx xorl %edx, %edx xorl %eax, %eax wrmsr #if CONFIG_DCACHE_RAM_SIZE > 0x8000 movl $MTRR_FIX_4K_C, %ecx wrmsr #endif /* * Set the default memory type and disable fixed * and enable variable MTRRs. */ movl $MTRR_DEF_TYPE_MSR, %ecx xorl %edx, %edx movl $MTRR_DEF_TYPE_EN, %eax /* Enable variable and disable fixed MTRRs. */ wrmsr /* Enable cache. */ movl %cr0, %eax andl $(~(CR0_CacheDisable | CR0_NoWriteThrough)), %eax movl %eax, %cr0 __main: Please, check upon it. Please, pass to us your comments... If any? Best Regards, Zoran On Tue, Jul 26, 2016 at 4:23 AM, Rafael Machado < rafaelrodrigues.mach...@gmail.com> wrote: > Thanks a lot Zoran. > I will! > > Rafael > > Em seg, 25 de jul de 2016 14:13, Zoran Stojsavljevic < > zoran.stojsavlje...@gmail.com> escreveu: > >> Hello Rafael, >> >> Let me try hard... ;-) >> >> Let us look into what actually we have here, in Coreboot: in bootblock >> phase, at the very beginning. >> Let me tell you what I am looking into (what cb tree): [zoran@localhost >> coreboot-09.06.2016]$ git describe >> 4.4-455-g538b324 >> >> Let us backtrace, to understand what is actual thread of execution: >> src/arch/x86/prologue.inc >> src/cpu/x86/16bit/entry16.inc >> src/cpu/x86/16bit/reset16.inc >> src/cpu/x86/32bit/entry32.inc >> src/cpu/x86/sse_enable.inc >> src/arch/x86/bootblock_simple.c >> >> Please, carefully examine what I pointed/presented here... And let us >> know your thoughts. >> >> Best Regards, >> Zoran >> >> On Mon, Jul 25, 2016 at 6:03 PM, Rafael Machado < >> rafaelrodrigues.mach...@gmail.com> wrote: >> >>> Hi guys. Long time since my last e-mail. >>> >>> It's hard to synchronize my day work with my firmware studies. Since my >>> projects are more UEFI related I usually do not have to much time to study >>> the legacy way, but It's really cool and Ill not give up :) >>> >>> Since the last talk I was doing what everyone kindly proposed. (by the >>> way thank you all for the guidance.) >>> >>> Now I'm disassembly an old systems bios I have, but I cannot understand >>> what is happening in a specific section of the code. (I'm using radare2 for >>> my studies) >>> >>> The code is: >>> >>> f000:0fcb 66b9ff02mov ecx, 0x2ff >>> f000:0fd1 0f32 rdmsr ; read register >>> 0x2ff (IA32_MTRR_DEF_TYPE) >>> f000:0fd3 0fbae80b bts ax, 0xb ; Enable bit 11 (MTRR >>> Enable). >>> f000:0fd7 0fbae80a bts ax, 0xa ; Enable bit 10 (Fixed >>> MTRR Enable). >>> f000:0fdb 0f30 wrmsr; Write changes to >>> MTRR >>> f000:0fdd 0f20c0 mov eax, cr0 >>> f000:0fe0 660fbaf01e btr eax, 0x1e ; Bit 30 means CD - Cache >>> disabled. >>> f000:0fe5 660fbaf01d btr eax, 0x1d ; Disable bit 29. NW - No >>> Write-through >>> f000:0fea 0f22c0 mov cr0, eax ; Write changes to CR0 >>> f000:0fed ffe7 jmp di >>> f000:0fef 0f20c0 mov eax, cr0 >>> f000:0ff2 660fbae81e bts eax, 0x1e >>> f000:0ff7 660fbae81d bts eax, 0x1d >>> f000:0ffc 0f22c0 mov cr0, eax >>> >>> >>> Here is the code with my notes. I understand that some MTRR were set, >>> and now the processor will be "configured". >>> We see at address f000:0fe0 and f000:0fe5 that the CR0 register is >>> being changed and after that the changes are saved. >>> >>> Now I have two questions. >>> >>> 1 - After CR0 changes get completed there is a "jmp di" instruction. >>> This does not make any sense to me. Does anyone know why this is needed >>> ? As far as I could check di value is 0x0 at this point. I think >>> >>> 2 - After the "jmp di" a "CR0 Déjà vu" code is executed. Any idea why >>> this is needed ? >>> >>> Tha
Re: [coreboot] Microcode problem with Braswell CPU
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.boec...@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 > -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Microcode problem with Braswell CPU
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 -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Cable issue? Flashrom doesn't detect F2A-85M's flash chip (25Q64F)
Hi folks, for backup purposes, I am trying to do some flashing of the BIOS chip from my Asus F2A-85M (Winbond 25Q64F) by connecting it to a RPi2. In the past, I used the RPi2 setup successfully to flash the Macronix chip in the X200 using a 3M test clip and 15cm jumper cables, but I don't have a clip for Winbond chip on the F2A-85M so I am using the connectors which came bundled with a Buspirate (making the wires a little longer in total). Unfortunately, Flashrom does not detect the chip even when supplying the -c parameter. Here are some pictures of my setup: https://abload.de/img/dscn6511d8jh4.jpg https://abload.de/img/dscn6515vekdc.jpg https://abload.de/img/dscn6516n7j3f.jpg I tried several times, checked the pinout and tried attaching the connectors to different areas of the flash chip's heads. Is there anything I am doing obviously wrong? Cheers, Daniel -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
