Re: [coreboot] (bug in toochains?) Data in memory changes unexpectedly ininitialize_cpus
Same here:
only this irrelevant diff
$ diff test.map.orig test.map
8c8
0010002c A _etext
---
0010003e A _etext
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-targets=all --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
best,
matthias
Bao, Zheng wrote:
I have narrowed my problem to a small test
project. It is quite easy for you to do a quick test.
Please check the test.map, and you will find
the sizes of stack and stackaaa are different. But
the only difference in the coreboot_ram.ld is CONFIG_MAX_CPU
in stack and a constant in stack. Can you guys build
the project on your machine to see if you can get the same
result with me? Do you think it is bug in binutils?
Coreboot_ram.ld:
/* INCLUDE ldoptions */
/* ENTRY(_start) */
SECTIONS
{
CONFIG_STACK_SIZE = 0x0002 ;
CONFIG_MAX_CPU = 2;
. = 0x10 ;
_stack = . ;
.stack . : {
. = ((CONFIG_STACK_SIZE) * CONFIG_MAX_CPU);
}
_estack = . ;
_text = . ;
.text . : {
*(.text) ;
}
_etext = . ;
/*. = ALIGN(0x1);*/
. = 0x40 ;
_stack = . ;
.stack . : {
. = ((CONFIG_STACK_SIZE) * 2);
}
_estack = . ;
.data : {
_data = . ;
*(.data) ;
_edata = . ;
}
/DISCARD/ : {
*(.comment)
*(.note)
*(.note.*)
}
}
My test.map:
0002 A CONFIG_MAX_CPU
0002 A CONFIG_STACK_SIZE
0010 A _stack
0014 A _estack
0014 A _text
0014 t test
00100016 T main
0010002c A _etext
0040 A _stack
00c4 A _estack
00c4 B _data
00c4 B _edata
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Zheng Bao
Sent: Sunday, February 14, 2010 10:12 AM
To: marcj...@gmail.com
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Data in memory changes unexpectedly
ininitialize_cpus
Date: Sat, 13 Feb 2010 11:23:49 -0700
Subject: Re: [coreboot] Data in memory changes unexpectedly
ininitialize_cpus
From: marcj...@gmail.com
To: fishb...@hotmail.com
CC: coreboot@coreboot.org
2010/2/12 Zheng Bao fishb...@hotmail.com:
Date: Fri, 12 Feb 2010 16:54:43 -0700
From: marcj...@gmail.com
To: zheng@amd.com
CC: coreboot@coreboot.org
Subject: Re: [coreboot] Data in memory changes unexpectedly
ininitialize_cpus
On Fri, Feb 12, 2010 at 4:48 PM, Marc Jones marcj...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 6:54 PM, Bao, Zheng zheng@amd.com
wrote:
I kept on finding the problem. Now it is narrowed down to the
line 108,
src/arch/i386/coreboot_ram.ld. It is very, very, very, very
confused.
My CONFIG_RAMBASE should be 0x20, which is more than
0x10, but
the location counter . is CONFIG_STACK_SIZE. Even if I
manually set
. = CONFIG_STACK_SIZE * 2 ;, I can not get the correct size.
But if I
set
. = 0x2000 * 2 ;, or . = CONFIG_STACK_SIZE 1, it is
right. I
kinda doubt the compiler and linker.
Can you try it on your building machine? Just try the
Serengeti_cheetah_fam10 and don't need the hardware. Just check
the
build/coreboot_ram.map to see if the _estack - _stack is
multiple of
CONFIG_STACK_SIZE. That problem should happen on all the fam10
board if
it is built on my building machine.
Is this due to the hard coded values in lapic_cpu_init. I don't
really
understand the comment or what it is doing. I would expect the AP
stacks to be setup based on estack as well.
// for all APs, let use stack after pgtbl, 20480 is the pgtbl
size for
every cpu
stack_end = 0x10+(20480 + CONFIG_STACK_SIZE)*CONFIG_MAX_CPUS
-
(CONFIG_STACK_SIZE*index);
This is what I get in my map file. It seems reasonable.
0023 A _stack
00238000 A _estack
00238000 A _heap
002f8000 A _eheap
002f8000 A _eram_seg
0100 A CONFIG_RAMTOP
what is the CONFIG_STACK_SIZE in your map file?
8000 A CONFIG_STACK_SIZE
This is not right.
I buillt svn head of serengeti_cheetah_fam10.
Marc
--
http://se-eng.com
Re: [coreboot] coreboot v2 support for Atom N450 @ 1.67GHz + ICH8M embedded board
Am Sonntag, den 14.02.2010, 15:29 +0200 schrieb eran shemi: I am a newbie in coreboot. so am I. I want to know if coreboot v2 support Atom N450 @ 1.67GHz + ICH8M embedded board. I do not think so. But please take a look at [1] on what information to provide. Both the N450 (Atom with integrated Northbridge, and intel graphics on one die, a.k.a. uncore, a.k.a. Pineview, a.k.a. Pinetrail) and the ICH8m southbridge are unsupported. However that's also one of the Platforms I dream to port coreboot to, but I didn't start a line of code in coreboot yet. But I wrote a small tool that allows you to dump the GbE BLOB and BIOS from your flash contents, that are not organized as a normal BIOS but in descriptor mode. This is (at least) related to ICH8 and ICH9, and when your board runs GbE, not only Fast ethernet, this is a good indicator your SPI flash's contents are in descriptor mode. Also with coreboot you'll need the GbE BLOB to have GbE operational. For porting and reversing you'll likely also need the BIOS itself. Sounds like you have one of the CES2010 new netbooks? which one? try running flasrom on it, then descriptormode the tool I wrote: http://github.com/mazzoo/descriptormode best, mazzoo -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] new descriptormode tool
hi list, I created a simple tool that for now parses a SPI image that comes in descriptor mode, and dumps infos and also the blobs as BIOS, GbE, ME into files. git clone g...@github.com:mazzoo/descriptormode.git http://github.com/mazzoo/descriptormode TODO is to also reverse the path and create descriptormode images from a BIOS, GbE-descriptor and/or ME. matthias -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [bios_extract] filenames patch for phoenix
Peter Stuge wrote:
Matthias Wenzel wrote:
+++ b/phoenix.c
..
@@ -117,10 +117,10 @@ PhoenixModule(unsigned char *BIOSImage, int
BIOSLength, int Offset)
ModuleName = PhoenixModuleNameGet(Module-Type);
if (ModuleName) {
-filename = malloc(strlen(ModuleName) + 7);
+filename = malloc(strlen(ModuleName) + 7 + 3);
sprintf(filename, %s_%1d.rom, ModuleName, Module-Id);
} else {
-filename = malloc(9);
+filename = malloc(9 + 3);
sprintf(filename, %02X_%1d.rom, Module-Type, Module-Id);
}
If everything (also Type) is u8 then the above is 1 byte extra :) but
better safe than sorry!
Both are u8, and yes, I was conservative as some C-libs (other than
glibc) might add a sign with the %1d. Maybe we should write %1u or
even %.3 to be clearer.
mazzoo
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [bios_extract] filenames patch for phoenix
Hi,
attached is a small patch for phoenix part in bios_extract to replace
terrible filenames containing '*', '?' or ''
also fixes 2 bufferoverflows in the filename handling.
mazzoo
diff --git a/phoenix.c b/phoenix.c
index dd630a1..83b86b4 100644
--- a/phoenix.c
+++ b/phoenix.c
@@ -61,9 +61,9 @@ PhoenixModuleNames[] = {
{'H', tcpa_H}, /* TCPA (Trusted Computing), USBKCLIB? */
{'K', tcpa_K}, /* TCPA (Trusted Computing), AUTH? */
{'Q', tcpa_Q}, /* TCPA (Trusted Computing), SROM? */
-{'', tcpa_},
-{'*', tcpa_*},
-{'?', tcpa_?},
+{'', tcpa_LT},
+{'*', tcpa_AS},
+{'?', tcpa_QM},
{'J', SmartCardPAS},
};
@@ -117,10 +117,10 @@ PhoenixModule(unsigned char *BIOSImage, int BIOSLength, int Offset)
ModuleName = PhoenixModuleNameGet(Module-Type);
if (ModuleName) {
- filename = malloc(strlen(ModuleName) + 7);
+ filename = malloc(strlen(ModuleName) + 7 + 3);
sprintf(filename, %s_%1d.rom, ModuleName, Module-Id);
} else {
- filename = malloc(9);
+ filename = malloc(9 + 3);
sprintf(filename, %02X_%1d.rom, Module-Type, Module-Id);
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
