I try to build amd/serengeti_cheetah, but I get a message like this:
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios_apc -T
/usr/bin/ld: linuxbios_apc is too big
collect2: ld returned 1 exit status
make: *** [linuxbios_apc] Error 1
The DCACHE_SIZE is set at 0x8000, linuxbios_apc.o has a size about 20K.
Do you know where I did wrong? I have gcc 3.2.2.
----- Original Message -----
From: "yhlu" <yinghailu(a)gmail.com>
To: "Stefan Reinauer" <stepan(a)coresystems.de>
Cc: "Carl-Daniel Hailfinger" <c-d.hailfinger.devel.2006(a)gmx.net>et>;
Sent: Tuesday, May 23, 2006 12:53 PM
Subject: Re: [LinuxBIOS] selection of compression algorithm
linuxbios_apc.rom is the code for ap. The code is in it's own cache.
So BSP is executing the code in ROM and RAM, and at the same time the
APs executing code in cache.
The AP uncompress the linuxbios_apc.rom from rom to it's cache before
jump it. At that time the RAM on BSP is ready already.
On 5/23/06, Stefan Reinauer <stepan(a)coresystems.de> wrote:
* yhlu <yinghailu(a)gmail.com> [060523 11:26]:
I may only want to lzma for payload if we can
sqush tiny kernel and
initrd in 1M with LinuxBIOS.
Thats why we all would want to see this, yes. But using nrv2b if lzma is
so much more efficient makes not much sense in any other case either.
I may need to use nrv2b for linuxbios_ram.rom
* What's linuxbios_ap_code.rom?
These too can share the code in car stage. and
code in cache can not have too much space for lzma properties array.
When we're uncompressing, we do have memory. So cache sizes are no
restriction at this point anymore.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info(a)coresystems.de • http://www.coresystems.de/
linuxbios mailing list