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
2010/1/15 Peter Stuge pe...@stuge.se:
0x2018 = 0x100770144840
0x2019 = 0x18006a7332a3
0x201a = 0x130cd101
0x201b = 0x
0x201c = 0x00ff00ff
0x201d = 0x1000
0x4c0f = 0x83f100aa569603c4
0x4c14 =
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
Piotr Piwko wrote:
./msrtool 0x20{18,19,1a,1b,1c,1d} 0x4c{0f,14}
OK, here is my output:
0x2018 = 0x100770144840
0x2019 = 0x18006a7332a3
0x201a = 0x130cd101
0x201b = 0x
0x201c = 0x00ff00ff
0x201d =
2010/1/13 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net:
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
2010/1/14 Peter Stuge pe...@stuge.se:
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
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(0x,
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
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
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
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
On 12.01.2010 09:35, Piotr Piwko wrote:
2010/1/12 Piotr Piwko piotr.pi...@gmail.com:
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
2010/1/12 Piotr Piwko piotr.pi...@gmail.com:
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
2010/1/12 Piotr Piwko piotr.pi...@gmail.com:
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
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
2010/1/12 Stefan Reinauer ste...@coresystems.de:
//#define DIMM1 ((u8) 0xA2)
#define DIMM1 DIMM0
This is wrong. Unless you use two equal DIMMs every time you will end up
with incorrectly set up RAM and RAM controller
(which will likely result in behavior such as the one you are seeing)
So
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
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
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 =
On Mon, Jan 11, 2010 at 2:24 PM, Peter Stuge pe...@stuge.se 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
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
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 (0x400) is wrong but which one is
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
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
Am 08.01.2010 18:32, schrieb Piotr Piwko:
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
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
Hello,
I am preparing the coreboot version for MSM800BEV board from Digital
Logic. This is the same branch as MSM800SEV board so, I've decided
that is a good starting point.
So, I built and loaded it to my flash memory and finally run.
Unfortunately, it stops at Uncompressing coreboot to ram
Dear Piotr,
Your SPD rom can not be read correctly, hence your RAM controller is
not set up correctly...
Stefan
On 07.01.2010, at 14:22, Piotr Piwko piotr.pi...@gmail.com wrote:
Hello,
I am preparing the coreboot version for MSM800BEV board from Digital
Logic. This is the same branch
This is very bad:
SMBUS READ ERROR:03 device:a2
You can run smbus test code in user mode on linux under standard bios,
but make sure your superio is the right one.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
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
On Thu, Jan 7, 2010 at 10:46 AM, Nils njaco...@hetnet.nl 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
2010/1/7 ron minnich rminn...@gmail.com:
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
29 matches
Mail list logo
