coreboot and MSM800BEV

[Nils]

Hi Piotr,
I am not a specialist as Stephan and Ron, so don`t shoot me if i`m wrong!
But despite the fact that Stephan and Ron are probably right that (part of ?) 
your RAM is not setup correct, i would think looking at the  RAM test output
that there is some  RAM available.
I had the same error on my (non-CAR) board at revision r4992 and the 
problem disappeared at r4995.
So it might be worth a try to test a newer revision.

Good luck!,Nils.

[ron minnich]

On Thu, Jan 7, 2010 at 10:46 AM, Nils  wrote:
> But despite the fact that Stephan and Ron are probably right that (part of ?)
> your RAM is not setup correct, i would think looking at the  RAM test output
> that there is some  RAM available.

But those SMB errors really should be fixed. That's just a very bad
thing to happen.

ron

[Piotr Piwko]

2010/1/7 ron minnich :
> But those SMB errors really should be fixed. That's just a very bad
> thing to happen.

Yes, I agree. I suppose that the mentioned error is related with wrong
SMB initialization function. I am going to look at values of SMB
registers when my board is booted from vendor BIOS and compare they
with coreboot values. I hope it will point me.

But first, I will check this coreboot BIOS on MSM800SEV board. It
should work correctly, isn't it?

Thank you all for your engagement. I will inform about progress in this case.

Have a nice day!

[Piotr Piwko]

2010/1/8 Piotr Piwko :
> But first, I will check this coreboot BIOS on MSM800SEV board. It
> should work correctly, isn't it?

Unfortunately, it isn't. There is the same scenario: "SMBUS READ
ERROR:03 device:a2". Has this port of coreboot been tested on the
MSM800SEV target board? It seems it not.

I am going to fix it. Please wish me good luck :)

[Piotr Piwko]

OK, I removed all references to DIMM1 memory (there is only DIMM0 on
MSM800BEV board)  and the "SMBUS READ ERROR:03 device:a2" error
doesn't occur - please see attached log.

My booting process as previously hangs on "Uncompressing coreboot to
ram". I suppose this situation is related with copying data from cache
into RAM memory in cpu/amd/car/cache_as_ram.inc file, the suitable
part:

----------------- [ cpu/amd/car/cache_as_ram.inc ] -----------------
__main:
    CONSOLE_DEBUG_TX_STRING($str_copying_to_ram)

/*
     *	Copy data into RAM and clear the BSS. Since these segments
     *	isn't really that big we just copy/clear using bytes, not
     *	double words.
     */
    intel_chip_post_macro(0x11)		/* post 11 */

cld				/* clear direction flag */

/* copy coreboot from it's initial load location to
     * the location it is compiled to run at.
     * Normally this is copying from FLASH ROM to RAM.
     */
    movl	%ebp, %esi
    
    /* FIXME: look for a proper place for the stack */
    movl	$0x4000000, %esp
    movl	%esp, %ebp
    
    pushl	%esi
    pushl $str_coreboot_ram_name
    
    call cbfs_and_run_core
----------------------------------------------------------------------

It prints $str_coreboot_ram_name ("Uncompressing coreboot to ram") and
hangs after calling cbfs_and_run_core function. I think that I should
set a proper memory address for stack. As we can see the default
address (0x4000000) is wrong but which one is correct? Can you give my
any hints?

Thanks in advance

[Patrick Georgi]

Am 08.01.2010 13:57, schrieb Piotr Piwko:
> It prints $str_coreboot_ram_name ("Uncompressing coreboot to ram") and
> hangs after calling cbfs_and_run_core function. I think that I should
> set a proper memory address for stack. As we can see the default
> address (0x4000000) is wrong but which one is correct? Can you give my
> any hints?

It's not wrong, it's just an issue once suspend-to-ram etc. come into
play - that's why I added this remark to the arbitrary value I used there.
This value will be an issue if you have <64MB RAM (and with 64MB it
might be a problem, too)

How long did you wait? it _might_ be that it merely takes a very long
time. That must of course be fixed, but is not the same problem as a
hanging system.

Patrick

[Piotr Piwko]

2010/1/8 Patrick Georgi :
> How long did you wait? it _might_ be that it merely takes a very long
> time. That must of course be fixed, but is not the same problem as a
> hanging system.

I wait for about 15-20 min and nothing special. I put some 'postcode'
functions for debug capability and I've found out that it hangs on
'cbfs_load_stage' function when it calls cbfs_find_file:

---------[ lib/cbfs.c ]--------
// ...

void * cbfs_load_stage(const char *name)
{
    struct cbfs_stage *stage = (struct cbfs_stage *)
    	cbfs_find_file(name, CBFS_TYPE_STAGE);
    /* this is a mess. There is no ntohll. */
    /* for now, assume compatible byte order until we solve this. */
    u32 entry;

outb(0xaa, 0x80);        // <--------------- It doesn't occur

if (stage == NULL)
    	return (void *) -1;

printk_info("Stage: loading %s @ 0x%x (%d bytes), entry @ 0x%llx\n",
    		name,
    		(u32) stage->load, stage->memlen,
    		stage->entry);
    memset((void *) (u32) stage->load, 0, stage->memlen);

if (cbfs_decompress(stage->compression,
    		     ((unsigned char *) stage) +
    		     sizeof(struct cbfs_stage),
    		     (void *) (u32) stage->load,
    		     stage->len))
    	return (void *) -1;

printk_debug("Stage: done loading.\n");

entry = stage->entry;
    // entry = ntohl((u32) stage->entry);

return (void *) entry;
}

// ...
---------------------------------------------------

On Monday I will test the cbfs_find_file function. I hope I will found
something.

Have a good weekend!

[Patrick Georgi]

Am 08.01.2010 18:32, schrieb Piotr Piwko:
> 2010/1/8 Patrick Georgi :
> > How long did you wait? it _might_ be that it merely takes a very long
> > time. That must of course be fixed, but is not the same problem as a
> > hanging system.
>
> I wait for about 15-20 min and nothing special. I put some 'postcode'
> functions for debug capability and I've found out that it hangs on
> 'cbfs_load_stage' function when it calls cbfs_find_file:
>
> ---------[ lib/cbfs.c ]--------
> // ...
>
> void * cbfs_load_stage(const char *name)
> {
>    struct cbfs_stage *stage = (struct cbfs_stage *)
>    	cbfs_find_file(name, CBFS_TYPE_STAGE);
>    /* this is a mess. There is no ntohll. */
>    /* for now, assume compatible byte order until we solve this. */
>    u32 entry;
>
> outb(0xaa, 0x80);        // <--------------- It doesn't occur

In that case, your ROM is probably not entirely mapped yet. That's an
issue that has to be fixed per chipset (southbridge mostly).
I see explicit support for it in cs5530 (even though that _might_
require some more changes), and somewhere in the code of cs5535. I don't
know if this is applicable to cs5536, too. If you want to try, this hack
might help you (untested, as I don't have the hardware). Maybe the call
must be moved around a bit.

Thanks for your effort,
Patrick

--- src/mainboard/digitallogic/msm800sev/auto.c (revision 5003)
+++ src/mainboard/digitallogic/msm800sev/auto.c (working copy)
@@ -14,6 +14,7 @@
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
+#include "southbridge/amd/cs5530/cs5530_enable_rom.c"

//#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)

@@ -114,6 +115,7 @@

msr_init();                                     //GX3 OK

+       cs5530_enable_rom();
        cs5536_early_setup();           //GX3 OK

/* NOTE: must do this AFTER the early_setup!

[Piotr Piwko]

2010/1/8 Patrick Georgi :
> In that case, your ROM is probably not entirely mapped yet. That's an
> issue that has to be fixed per chipset (southbridge mostly).
> I see explicit support for it in cs5530 (even though that _might_
> require some more changes), and somewhere in the code of cs5535. I don't
> know if this is applicable to cs5536, too. If you want to try, this hack
> might help you (untested, as I don't have the hardware). Maybe the call
> must be moved around a bit.

Unfortunately it didn't help. When I use cs5530_enable_rom() function,
the booting process didn't event execute cbfs_load_stage(). Please
note that the src/mainboard/digitallogic/msm800sev/auto.c file is not
in compilation chain - against it the
coreboot/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c is
used. Maybe it has to be fixed?

I've found that the booting process hangs on this part of
cbfs_master_header() function (src/lib/cbfs.c):

...
outb(0xa1, 0x80);  // <------- It is printed

void *ptr = (void *)*((unsigned long *) CBFS_HEADPTR_ADDR);
printk_spew("Check CBFS header at %p\n", ptr);
header = (struct cbfs_header *) ptr;

outb(0xa2, 0x80);  // <- It is NOT printed
...

I don't know exactly where I need to begin make changes ...

Thanks for your interest.

[Peter Stuge]

Piotr Piwko wrote:
> I've found that the booting process hangs on this part of
> cbfs_master_header() function (src/lib/cbfs.c):
>
> ...
> outb(0xa1, 0x80);  // <------- It is printed
>
> void *ptr = (void *)*((unsigned long *) CBFS_HEADPTR_ADDR);
> printk_spew("Check CBFS header at %p\n", ptr);
> header = (struct cbfs_header *) ptr;
>
> outb(0xa2, 0x80);  // <- It is NOT printed
> ...
>
> I don't know exactly where I need to begin make changes ...

Do you see the printk message?

Could you also add outb() before and after the printk?

If it hangs on the printk call I guess it's a stack issue.

Did you already try the v3 support for adl/msm800sev?

//Peter

[ron minnich]

On Mon, Jan 11, 2010 at 2:24 PM, Peter Stuge  wrote:
> Did you already try the v3 support for adl/msm800sev?

yes, try this first. See if it goes. Then you'll need to match up what
v3 does with what v2 does, and if you get it fixed, I will thank you A
LOT.

Would be nice to have the msm800 working in v2 :-)

ron

[Piotr Piwko]

2010/1/11 Peter Stuge :
> Do you see the printk message?

No, I don't.
> Could you also add outb() before and after the printk?

It doesn't return from print_spew() function.
> If it hangs on the printk call I guess it's a stack issue.

Yes, I agree. I think at the same begining that is a stack issue.
First I thought that an 0x4000000 address is not valid for stack, but
it seems ok.
> Did you already try the v3 support for adl/msm800sev?

No I didn't. I am just going to try it. Of course, I will report my
progress here :)

Thanks for your help,

[Piotr Piwko]

2010/1/12 Piotr Piwko :
> > Did you already try the v3 support for adl/msm800sev?
>
> No I didn't. I am just going to try it. Of course, I will report my
> progress here :)

So, here we go :)

I attached the first log of coreboot-v3 booting process for
adl/msm800sev board. As we can see there are the same errors with SMB.
I suppose they are related as previously with the references to DIMM1
which are not present in this board.

In the other hand, these lines make me worried:

...
LAR: seen member bootblock@0xffffafc0, size 20480
LAR: File not found!
LAR: Run file fallback/initram/segment0 failed: No such file.
Fallback failed. Try normal boot
...

[Piotr Piwko]

2010/1/12 Piotr Piwko :
> I attached the first log of coreboot-v3 booting process for
> adl/msm800sev board. As we can see there are the same errors with SMB.
> I suppose they are related as previously with the references to DIMM1
> which are not present in this board.

OK, I fixed it by assigning the DIMM0 device address to the DIMM1
definition in mainboard/adl/msm800sev/initram.c file:

//#define DIMM1 ((u8) 0xA2)
#define DIMM1 DIMM0
> LAR: Run file fallback/initram/segment0 failed: No such file.
> Fallback failed. Try normal boot

It seems that my coreboot image was built in normal boot mode while it
tries use fallback boot. How can I enable the fallback mode in
building process or enforce the use of the normal mode in booting
process?

Thanks in advance,

[Piotr Piwko]

I've found the way to force the normal boot mode in boot process. I
just set the
RTC_NORMAL_BOOT_FLAG_SET bit in check_normal_boot_flag() function
(patch is attached).

Now the boot process seems to be ok, but it still hangs on the
execution __asm__("wbinvd\n"); in main function of
mainboard/adl/msm800sev/initram.c file ... (please, see attached log).

PS. Let me know if I am too verbose in this thread. I just want to
help future users.

[Carl-Daniel Hailfinger]

On 12.01.2010 09:35, Piotr Piwko wrote:
> 2010/1/12 Piotr Piwko :
> > > Did you already try the v3 support for adl/msm800sev?
> >
> > No I didn't. I am just going to try it. Of course, I will report my
> > progress here :)
>
> So, here we go :)
>
> I attached the first log of coreboot-v3 booting process for
> adl/msm800sev board. As we can see there are the same errors with SMB.
> I suppose they are related as previously with the references to DIMM1
> which are not present in this board.
>
> In the other hand, these lines make me worried:
>
> ...
> LAR: seen member bootblock@0xffffafc0, size 20480
> LAR: File not found!
> LAR: Run file fallback/initram/segment0 failed: No such file.
> Fallback failed. Try normal boot
> ...

That error message is harmless. Basically, we usually try fallback
first, and if no fallback image is present, we use the normal image.

Regards,
Carl-Daniel

[Piotr Piwko]

Hello,

I had removed the the 'wbinvd' cache invalidation function, and then a
boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'.
In order to fix it I've added VSA to my coreboot image by following
command:

build/util/lar/lar -C lzma -a build/bios.bin ./build/gpl_vsa_lx_102.bin:blob/vsa

After that, the boot process hangs on 'Done printk() buffer move'. It
seems like the VSA is not placed in a proper place in the whole bios
image. Do you know any other possibilities to include the VSA in
coreboot image?

Thanks in advance for interest.

[Knut Kujat]

Piotr Piwko escribió:
> Hello,
>
> I had removed the the 'wbinvd' cache invalidation function, and then a
> boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'.
> In order to fix it I've added VSA to my coreboot image by following
> command:
>
> build/util/lar/lar -C lzma -a build/bios.bin ./build/gpl_vsa_lx_102.bin:blob/vsa
>
> After that, the boot process hangs on 'Done printk() buffer move'. It
> seems like the VSA is not placed in a proper place in the whole bios
> image. Do you know any other possibilities to include the VSA in
> coreboot image?
>
> Thanks in advance for interest.

Hi,
I use: "./cbfstool coreboot.rom add vga.bin pci1002,515e.rom 99" and
where 1002 is the vendor id (ATI) and 515e the device id (ES1000) obtain
from a lspci -tvnn (+-06.0-[01]----01.0  ATI Technologies Inc ES1000
[1002:515e]) not sure what 99 is :P.

ciao.

[Carl-Daniel Hailfinger]

On 13.01.2010 15:45, Piotr Piwko wrote:
> I had removed the the 'wbinvd' cache invalidation function, and then a
> boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'.

Hm. I know the that piece of v3 code rather well and if wbinvd fails (or
your code does unexpected things like hanging after wbinvd) it is a
pretty sure sign that RAM is not working correctly.

I can test my GeodeLX systems with current v3 once I get a chance (will
take a few weeks, though, because I'm preparing for final exams).

Regards,
Carl-Daniel

[Piotr Piwko]

2010/1/13 Carl-Daniel Hailfinger :
> On 13.01.2010 15:45, Piotr Piwko wrote:
> > I had removed the the 'wbinvd' cache invalidation function, and then a
> > boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'.
>
> Hm. I know the that piece of v3 code rather well and if wbinvd fails (or
> your code does unexpected things like hanging after wbinvd) it is a
> pretty sure sign that RAM is not working correctly.

I'm agree. I think that my RAM initialization is not correct. I am
going to fix it today. Anyway, could you provide my any better
solution to include the VSA to coreboot image?

Thanks for you interest.

[Piotr Piwko]

2010/1/13 Carl-Daniel Hailfinger :
> On 13.01.2010 15:45, Piotr Piwko wrote:
> > I had removed the the 'wbinvd' cache invalidation function, and then a
> > boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'.
>
> Hm. I know the that piece of v3 code rather well and if wbinvd fails (or
> your code does unexpected things like hanging after wbinvd) it is a
> pretty sure sign that RAM is not working correctly.

I am almost certain that the RAM memory is not initialized correctly.
I wrote a simple RAM test function which writes some pattern data into
0x0 - 0x400 address range and then reads it. The difference occurs
already at the first cell. There is 0x00, but should be 0xFF.

Conclusion is that RAM initialization for adl/msm800sev target is not valid.

[Peter Stuge]

Piotr Piwko wrote:
> Anyway, could you provide my any better solution to include the VSA
> to coreboot image?

I believe you're doing it the correct way already.

Piotr Piwko wrote:
> I am almost certain that the RAM memory is not initialized correctly.
> I wrote a simple RAM test function which writes some pattern data into
> 0x0 - 0x400 address range and then reads it.

There is a similar function ram_check() in lib/ramtest.c.
> Conclusion is that RAM initialization for adl/msm800sev target is
> not valid.

Can you try with several different model DIMMs?

//Peter

[ron minnich]

On Thu, Jan 14, 2010 at 7:41 AM, Peter Stuge  wrote:
> Piotr Piwko wrote:
> > Conclusion is that RAM initialization for adl/msm800sev target is
> > not valid.
>
> Can you try with several different model DIMMs?

it's never that simple. The ram init WAS correct several years ago.
Something has changed, but it's hard to say what.

ron

[Piotr Piwko]

2010/1/14 Peter Stuge :
> Piotr Piwko wrote:
> > Anyway, could you provide my any better solution to include the VSA
> > to coreboot image?
>
> I believe you're doing it the correct way already.

I hope so too :)
> There is a similar function ram_check() in lib/ramtest.c.

Yes, but I don't know how I can force a compilation of /lib/ramtest.c
file during building process.
> > Conclusion is that RAM initialization for adl/msm800sev target is
> > not valid.
>
> Can you try with several different model DIMMs?

It is good hint. I will make some test tomorrow with different model of DIMMs.

[Stefan Reinauer]

On 1/14/10 8:45 PM, Piotr Piwko wrote:
> > There is a similar function ram_check() in lib/ramtest.c.
>
> Yes, but I don't know how I can force a compilation of /lib/ramtest.c
> file during building process.

It already is included in cache_as_ram_auto.c
Just add a line
ram_check(0x00000000, 0x000a0000);
at the end of cache_as_ram_main()
(assuming you use cache as ram)
> > > Conclusion is that RAM initialization for adl/msm800sev target is
> > > not valid.
> >
> > Can you try with several different model DIMMs?
>
> It is good hint. I will make some test tomorrow with different model of DIMMs.

You can also try to use SerialICE (http://www.serialice.com) on the
target to see how the original BIOS is configuring the RAM controller.

Stefan

[Piotr Piwko]

2010/1/14 Stefan Reinauer :
> It already is included in cache_as_ram_auto.c
> Just add a line
> ram_check(0x00000000, 0x000a0000);
> at the end of cache_as_ram_main()
> (assuming you use cache as ram)

Strange. I've added the ram_check() execution in mian() function in
adl/msm800sev/initram.c file and the linker couldn't find reference to
it.
> You can also try to use SerialICE (http://www.serialice.com) on the
> target to see how the original BIOS is configuring the RAM controller.

Thanks for this hint! I've planned to write the simple application on
Linux which will print values of given registers. Now it is not
necessary :)

[Stefan Reinauer]

On 1/14/10 9:34 PM, Piotr Piwko wrote:
> 2010/1/14 Stefan Reinauer :
> > It already is included in cache_as_ram_auto.c
> > Just add a line
> > ram_check(0x00000000, 0x000a0000);
> > at the end of cache_as_ram_main()
> > (assuming you use cache as ram)
>
> Strange. I've added the ram_check() execution in mian() function in
> adl/msm800sev/initram.c file and the linker couldn't find reference to
> it.

Ah, this was for v2. No idea how it works for v3...
> > You can also try to use SerialICE (http://www.serialice.com) on the
> > target to see how the original BIOS is configuring the RAM controller.
>
> Thanks for this hint! I've planned to write the simple application on
> Linux which will print values of given registers. Now it is not
> necessary :)

That might still be worthwhile.
But: Most config registers on Geode are set via MSRs, so you might get
quite far with Peter Stuge's "msrtool" (coreboot/util/msrtool)

Stefan

[Peter Stuge]

Stefan Reinauer wrote:
> > I've planned to write the simple application on Linux which will
> > print values of given registers. Now it is not necessary :)
>
> That might still be worthwhile.
> But: Most config registers on Geode are set via MSRs, so you might
> get quite far with Peter Stuge's "msrtool" (coreboot/util/msrtool)

Good point. Try running:

./msrtool 0x200000{18,19,1a,1b,1c,1d} 0x4c0000{0f,14}

in Linux started by factory BIOS. Note that you need /dev/cpu/*/msr
available to run msrtool in Linux. Unfortunately, msrtool is not
currently available as payload, but perhaps coreinfo can be used to
display MSRs?

(It would be nice to have msrtool diff mode available in coreinfo,
using a file stored in cbfs for comparison!)

//Peter

[Stefan Reinauer]

On 1/15/10 12:57 AM, Peter Stuge wrote:
> Unfortunately, msrtool is not
> currently available as payload, but perhaps coreinfo can be used to
> display MSRs?
>
> (It would be nice to have msrtool diff mode available in coreinfo,
> using a file stored in cbfs for comparison!)

I think a diff mode would be better implemented in msrtool itself -- If
the machine is able to boot coreinfo, it's quite likely already that it
can also boot a kernel. If not, you're stuck with printk debugging anyways.

Stefan

msrtool: Read both values in diff mode from file [was: coreboot and MSM800BEV]

[Peter Stuge]

Stefan Reinauer wrote:
> > (It would be nice to have msrtool diff mode available in coreinfo,
> > using a file stored in cbfs for comparison!)
>
> I think a diff mode would be better implemented in msrtool itself

The diff mode has been implemented in msrtool already since first
committed rc1. :) But currently it assumes that diff should always be
between a file and the machine that msrtool is running on.
> -- If the machine is able to boot coreinfo, it's quite likely
> already that it can also boot a kernel.

This is true!
> If not, you're stuck with printk debugging anyways.

Yep. Patches attached for reading both values from the file.

//Peter

msrtool: Read both values in diff mode from file [was: coreboot and MSM800BEV]

[Stefan Reinauer]

Very nice!

Peter Stuge wrote:
> This also introduces a small change in the user interface for immediate
> mode (-i). Previously, whitespace could separate high and low words in
> an MSR as such:
>
> msrtool -i 4c00000f='f2f100ff 56960004'
>
> That is no longer allowed, a space character now ends the MSR value. Any
> other character can still be used as separator however, so the following
> syntax still works as expected:
>
> msrtool -i 4c00000f=f2f100ff:56960004
>
> Signed-off-by: Peter Stuge

Acked-by: Stefan Reinauer
> Previously, msrtool would assume that MSR values should be compared
> between stored value in file and current value in hardware which msrtool
> was running on. This does not always fit the use case and with this
> change msrtool can now compare two sets of MSR values stored in a file.
> If only one MSR value is stored in the file, msrtool will behave as
> previously and read the second MSR value from hardware.
>
> This change means that msrtool does not always need access to the system
> MSR functions so it can now be run as a regular user when using diff
> mode with both MSR values stored in the file.
>
> Signed-off-by: Peter Stuge

Acked-by: Stefan Reinauer

Best regards,
Stefan

msrtool: Read both values in diff mode from file [was: coreboot and MSM800BEV]

[Peter Stuge]

Stefan Reinauer wrote:
> Very nice!
> Acked-by: Stefan Reinauer

Thanks! r5032-r5033

//Peter

[Piotr Piwko]

2010/1/15 Peter Stuge :
> ./msrtool 0x200000{18,19,1a,1b,1c,1d} 0x4c0000{0f,14}

OK, here is my output:

0x20000018 = 0x1007701400004840
0x20000019 = 0x180000006a7332a3
0x2000001a = 0x00000000130cd101
0x2000001b = 0x0000000000000000
0x2000001c = 0x0000000000ff00ff
0x2000001d = 0x0000000000001000
0x4c00000f = 0x83f100aa569603c4
0x4c000014 = 0x0000049c07de000c

I am going to analyze it ...

Thanks once again for this software

[Peter Stuge]

Piotr Piwko wrote:
> > ./msrtool 0x200000{18,19,1a,1b,1c,1d} 0x4c0000{0f,14}
>
> OK, here is my output:
>
> 0x20000018 = 0x1007701400004840
> 0x20000019 = 0x180000006a7332a3
> 0x2000001a = 0x00000000130cd101
> 0x2000001b = 0x0000000000000000
> 0x2000001c = 0x0000000000ff00ff
> 0x2000001d = 0x0000000000001000
> 0x4c00000f = 0x83f100aa569603c4
> 0x4c000014 = 0x0000049c07de000c
>
> I am going to analyze it ...

If msrtool didn't decode these for you then that's a bug. Did you get
something similar to the following output?

# MC_CF07_DATA 0x20000018 = 0x1007701400004840
# 63:60 D1_SZ DIMM1 Size = 0001: 8 MB
#    56 D1_MB DIMM1 Module Banks = 0: 1 Module bank
#    52 D1_CB DIMM1 Component Banks = 0: 2 Component banks
# 50:48 D1_PSZ DIMM1 Page Size = 111: DIMM1 Not Installed
# 47:44 D0_SZ DIMM0 Size = 0111: 512 MB
#    40 D0_MB DIMM0 Module Banks = 0: 1 Module bank
#    36 D0_CB DIMM0 Component Banks = 1: 4 Component banks
# 34:32 D0_PSZ DIMM0 Page Size = 100: 16 KB
# 29:28 MSR_BA Mode Register Set Bank Address = 00: Program the DIMM Mode Register
#    27 RST_DLL Mode Register Reset DLL = 0: Do not reset DLL
#    26 EMR_QFC Extended Mode Register FET Control = 0: Enable
#    25 EMR_DRV Extended Mode Register Drive Strength Control = 0: Normal
#    24 EMR_DLL Extended Mode Register DLL = 0: Enable
#  23:8 REF_INT Refresh Interval = 72
#   7:4 REF_STAG Refresh Staggering = 4
#     3 REF_TST Test Refresh = 0
#     1 SOFT_RST Software Reset = 0
#     0 PROG_DRAM Program Mode Register in SDRAM = 0

# MC_CF8F_DATA 0x20000019 = 0x180000006a7332a3
# 63:56 STALE_REQ GLIU Max Stale Request Count = 24
# 52:51 XOR_BIT_SEL XOR Bit Select = 00: ADDR[18]
#    50 XOR_MB0 XOR MB0 Enable = 0: Disabled
#    49 XOR_BA1 XOR BA1 Enable = 0: Disabled
#    48 XOR_BA0 XOR BA0 Enable = 0: Disabled
#    41 TRUNC_DIS Burst Truncate Disable = 0: Bursts Enabled
#    40 REORDER_DIS Reorder Disable = 0: Reordering Enabled
#    33 HOI_LOI High / Low Order Interleave Select = 0: Low Order Interleave
#    31 THZ_DLY tHZ Delay = 0
# 30:28 CAS_LAT Read CAS Latency = 110: 2.5
# 27:24 ACT2ACTREF ACT to ACT/REF Period. tRC = 10
# 23:20 ACT2PRE ACT to PRE Period. tRAS = 7
# 18:16 PRE2ACT PRE to ACT Period. tRP = 3
# 14:12 ACT2CMD Delay Time from ACT to Read/Write. tRCD = 3
#  11:8 ACT2ACT ACT(0) to ACT(1) Period. tRRD = 2
#   7:6 DPLWR Data-in to PRE Period. tDPLW = 2: 2
#   5:4 DPLRD Data-in to PRE Period. tDPLR = 2: 2

# MC_CF1017_DATA 0x2000001a = 0x00000000130cd101
# 29:28 WR_TO_RD Write to Read Delay. tWTR = 1
# 26:24 RD_TMG_CTL Read Timing Control = 3
# 20:16 REF2ACT Refresh to Activate Delay. tRFC = 12
#  15:8 PM1_UP_DLY PMode1 Up Delay = 209
#   2:0 WR2DAT Write Command to Data Latency = 1: 1-clock delay for unbuffered DIMMs

# MC_CFPERF_CNT1 0x2000001b = 0x0000000000000000
# 63:32 CNT0 Counter 0 = 0
#  31:0 CNT1 Counter 1 = 0

# MC_PERFCNT2 0x2000001c = 0x0000000000ff00ff
#    35 STOP_CNT1 Stop Counter 1 = 0
#    34 RST_CNT1 Reset Counter 1 = 0
#    33 STOP_CNT0 Stop Counter 0 = 0
#    32 RST_CNT0 Reset Counter 0 = 0

# MC_CFCLK_DBUG 0x2000001d = 0x0000000000001000
#    34 B2B_DIS Back-to-Back Command Disable = 0: Allow back-to-back commands
#    33 MTEST_RBEX_EN MTEST RBEX Enable = 0: Disable
#    32 MTEST_EN MTEST Enable = 0: Disable
#    16 FORCE_PRE Force Precharge-all = 0: Disable
#    12 TRISTATE_DIS TRI-STATE Disable = 1: Tri-stating disabled
#     9 MASK_CKE1 CKE1 Mask = 0: CKE1 output enable unmasked
#     8 MASK_CKE0 CKE0 Mask = 0: CKE0 output enable unmasked
#     7 CNTL_MSK1 Control Mask 1 = 0: DIMM1 CAS1# RAS1# WE1# CS[3:2]# output enable unmasked
#     6 CNTL_MSK0 Control Mask 0 = 0: DIMM0 CAS0# RAS0# WE0# CS[1:0]# output enable unmasked
#     5 ADRS_MSK Address Mask = 0: MA and BA output enable unmasked

# GLCP_DELAY_CONTROLS 0x4c00000f = 0x83f100aa569603c4
#    63 EN Enable = 1: Use value in bits [62:0]
#    62 B_DQ Buffer Control for DQ DQS DQM TLA drive = 0: Quarter power
#    61 B_CMD Buffer Control for RAS CAS CKE CS WE drive = 0: Quarter power
#    60 B_MA Buffer Control for MA BA drive = 0: Half power
#    59 SDCLK_SET SDCLK Setup = 0: Full SDCLK setup
# 58:56 DDR_RLE DDR read latch enable position = 3
#    55 SDCLK_DIS SDCLK disable [1,3,5] = 1: SDCLK[0,2,4] output only
# 54:52 TLA1_OA TLA hint pin output adjust = 7
# 51:50 D_TLA1 Output delay for TLA1 = 0
# 49:48 D_TLA0 Output delay for TLA0 = 1
# 47:46 D_DQ_E Output delay for DQ DQM - even byte lanes = 0
# 45:44 D_DQ_O Output delay for DQ DQM - odd byte lanes = 0
# 41:40 D_SDCLK Output delay for SDCLK = 0
# 39:38 D_CMD_O Output delay for CKE CS RAS CAS WE - odd bits = 2
# 37:36 D_CMD_E Output delay for CKE CS RAS CAS WE - even bits = 2
# 35:34 D_MA_O Output delay for BA MA - odd bits = 2
# 33:32 D_MA_E Output delay for BA MA - even bits = 2
# 31:30 D_PCI_O Output delay for pci_ad IRQ13 SUSPA# INTA# - odd bits = 1
# 29:28 D_PCI_E Output delay for pci_ad IRQ13 SUSPA# INTA# - even bits = 1
# 27:26 D_DOTCLK Output delay for DOTCLK = 1
# 25:24 D_DRGB_O Output delay for DRGB[31:0] - odd bits = 2
# 23:22 D_DRGB_E Output delay for DRGB[31:0] HSYNC VSYNC DISPEN VDDEN LDE_MOD - even bits = 2
# 21:20 D_PCI_IN Input delay for pci_ad CBE# PAR STOP# FRAME# IRDY# TRDY# DEVSEL# REQ# GNT# CIS = 1
# 19:18 D_TDBGI Input delay for TDBGI = 1
# 17:16 D_VIP Input delay for VID[15:0] VIP_HSYNC VIP_VSYNC = 2
# 15:14 D_VIPCLK Input delay for VIPCLK = 0
#    13 H_SDCLK Half SDCLK hold select (for cmd addr) = 0: Full SDCLK setup
# 12:11 PLL_FD_DEL PLL Feedback Delay = 00: No feedback delay
#     5 DLL_OV DLL Override (to DLL) = 0
#   4:0 DLL_OVS/RSDA DLL Override Setting or Read Strobe Delay Adjust = 4

# GLCP_SYS_RSTPLL 0x4c000014 = 0x0000049c07de000c
# 43:39 GLIUMULT GLIU Multiplier = 9
#    38 GLIUDIV GLIU Divide = 0: Do not predivide input
# 37:33 COREMULT CPU Core Multiplier = 14
#    32 COREDIV CPU Core Divide = 0: Do not predivide input
# 31:26 SWFLAGS Flags = 000001
#    25 GLIULOCK GLIU PLL Lock = 1: PLL locked
#    24 CORELOCK CPU Core PLL Lock = 1: PLL locked
# 23:16 HOLD_COUNT Hold Count, divided by 16 = 222
#    14 GLIUPD GLIU PLL Power Down mode = 0
#    13 COREPD CPU Core PLL Power Down mode = 0
#    12 GLIUBYPASS GLIU PLL Bypass = 0: DOTPLL drives the GLIU clock
#    11 COREBYPASS CPU Core PLL Bypass = 0: DOTPLL drives the CPU Core clock
#    10 LPFEN Loop Filter = 0: Disabled
#     9 VA_SEMI_SYNC_MODE CPU-GLIU Sync Mode = 0: The GLIU FIFO is used by the CPU
#     8 PCI_SEMI_SYNC_MODE PCI-GLIU Sync Mode = 0: Falling edges on mb_func_clk and pci_func_clk are used by PCI
#     7 BOOTSTRAP_PW1 PW1 bootstrap = 0: 33MHz PCI clock
#     6 BOOTSTRAP_IRQ13 IRQ13 bootstrap = 0: No stall
#   5:1 BOOTSTRAPS CPU/GLIU frequency select = 00110
#     0 CHIP_RESET Chip Reset = 0

//Peter

[Piotr Piwko]

2010/1/15 Peter Stuge :
> > 0x20000018 = 0x1007701400004840
> > 0x20000019 = 0x180000006a7332a3
> > 0x2000001a = 0x00000000130cd101
> > 0x2000001b = 0x0000000000000000
> > 0x2000001c = 0x0000000000ff00ff
> > 0x2000001d = 0x0000000000001000
> > 0x4c00000f = 0x83f100aa569603c4
> > 0x4c000014 = 0x0000049c07de000c
> >
> > I am going to analyze it ...
>
> If msrtool didn't decode these for you then that's a bug. Did you get
> something similar to the following output?
>
> # MC_CF07_DATA 0x20000018 = 0x1007701400004840
> ...

No, I didn't. I just got that lines with information about
unrecognized registers. It seems that msrtool doesn't have suitable
definitions in its database.

[Peter Stuge]

Piotr Piwko wrote:
> > If msrtool didn't decode these for you then that's a bug. Did you
> > get something similar to the following output?
>
> No, I didn't. I just got that lines with information about
> unrecognized registers. It seems that msrtool doesn't have suitable
> definitions in its database.

The GeodeLX MSR definitions were added in r4951 and r4957 in November
2009. The revision you have is printed on the first line when msrtool
is executed:

./msrtool -t geodelx 0
msrtool 5009
Detected system linux: Linux with /dev/cpu/*/msr
...

//Peter

[Piotr Piwko]

Hello again,

I've wrote my own RAM initialization function which based on factory
BIOS setting and AMD Geode LX Data Book. Unfortunately it didn't bring
any result. As previous, the booting process hangs on executing wbinvd
function.

I noticed that when I try to write some data into desired stack
address range (pointed by CONFIG_CARBASE=0x80000 value in .config
file) the booting process hangs on it. This situation occurs when I
use the coreboot RAM initialization function and my own function as
well. It is very strange to me.

Could you give me any advice how solve this situation?

Thanks in advance for your engagement.