Re: [LinuxBIOS] Build broken?

[beneo]

Is gcc 3.4 a requirement?

If not, I would save the trouble and stay with 3.2.2. I didn't encounter any
trouble building LinuxBIOS using this version until now. In another word,
are you absulutely sure the issue I have stated is caused by gcc 3.2.2

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" 
To: "beneo" ; "Ronald G Minnich" 
Cc: 
Sent: Thursday, November 10, 2005 3:17 PM
Subject: RE: [LinuxBIOS] Build broken?

Why not use gcc 3.4....?

YH

-----Original Message-----
From: beneo [mailto:[e-mail]]
Sent: Thursday, November 10, 2005 3:14 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: [e-mail]
Subject: Re: [LinuxBIOS] Build broken?

I understand what you say. It matches what I see in the code. However,
my
questions are not addressed, or I didn't understand your explaination.

First, I'm using redhat Linux 9.0, my gcc -v output like this: "gcc
version
3.2.2 20030222 (Red Hat Linux 3.2.2-5)", I hopt it is good enough to
build
LinuxBIOS.

Second, tyan/s2891 build generate a section called .rodata.str1.32.  The
linker script doesn't have anything explict to handle this section. I
think
the Linker just patch this section at end of the last  section that are
explicitly specified in the Linker script. In tyan/s2891 build, it is
.id
section. The .id section is 0x70 bytes below .reset section. The
.rodata.str1.32 is larger than 0x70 bytes. Therefor, .rodata.str1.32
will
overlap with .reset section and cause the build to break. Are you saying
my
compiler caused this issue?

Third, I understand _start must be in the last 64K, are you saying
objcopy
would enforce this? To be more specific on my quesiton, when I'm useing
ROMCC, my crt0.o is larger than 64K, objcopy would compress certain
portion
of crt0.o and make sure _start is in the last 64k?

Thanks

beneo

----- Original Message ----- 
From: "Lu, Yinghai" 
To: "beneo" ; "Ronald G Minnich" 
Cc: 
Sent: Thursday, November 10, 2005 2:10 PM
Subject: Re: [LinuxBIOS] Build broken?
> OK, Let me explain that again:
>
> Final LinuxBIOS image = VGABIOS ROM + Normal Image + FallBack Image
>
> FallBack Image = PayLoad + linuxbios_ram.n2v + linuxbios_rom
>
> Linuxbios_rom  = crt0.S + init.o + id + reset_vector
>
> Reset_vector is sit on 0xfffffff0, and at the very beginning, reset
> happen, the ROM only can be accessed in 64K range. So need to make

sure
> _start in crt0.S need to stay in last 64 address range.
>
> The init.o will include cache_as_ram_auto.c in the fallback

amd64_main,
> it will enabled the access 4M flash access.
>
> When We were using ROMCC, the crt0.S will be very bigger (it include
> auto.inc), So for 8 way or 4 way system, It will push out the _start

out
> of last 64K.
>
> When We are using CAR, the init.o is all the same size for 8way and 2
> way system. ( because CAR use gcc, and have real stack for functional
> call, ROMCC can not have stack because of limited regs)
>
> Another problem is if put set ROM_IMAGE_SIZE too big, the current lds
> can not curbe crt0.S to stay in last 64K too...
>
> So you need to set your ROM_IMAGE_SIZE carefully for FALLBACK image.
> If it is too small, it could not fit Payload
> +linuxbios_ram.n2v+linuxbios.rom
>
> It it is too big, _start in crt0.S will out of last 64K....
>
> Later we could modify .lds to force crt0.S and init.o stay in last
> 64K....
>
> Or change Linuxbios_rom = init.o + crt0.S + id + reset_vector.... (

need
> make sure enable_rom in 64K too...)
>
> But is not high priority, because crt0.S+init.o for CAR are always
> small....
>
> Other problem is you must use Linux otherthan Redhat and Suse????
> And you need to upgrade your gcc
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:[e-mail]]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: [e-mail]
> Subject: Re: [LinuxBIOS] Build broken?
>
> Thanks. It works on one of issues I have encountered.
>
> My immidiate question is why my ROM_IMAGE_SIZE with larger value

0x20000
> won't work, but with 0x16380 would work? If you don't tell me this, I
> probably would never be able to figure out.
>
> My have another issue, It looks like a bug in target tyan/s2891. I'm
> trying
> to build tyan/s2891. No matter what I change, I always get a build

error
> like:
>
> gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
> crt0.o
> init.o
> /usr/bin/ld: section .rodata.str1.32 [fffbff80 -> fffc0091] overlaps
> section
> .reset [fffbfff0 -> fffbffff]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
>
> Then I looked at ldscript file, it included
> southbridge/nvidia/ck804/id.lds
> file, which looks like this:
>
> SECTIONS {
>         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x80) - (__id_end -
> __id_start);
>         .id (.): {
>                 *(.id)
>         }
> }
>
> There is no linker script would arrange section .rodata.str1.32. I

guess
> that just makes linker to patch section .rodata.str1.32 at end of .id
> section, which caused the overlap with .reset section.
>
> This looks to me is a bug in tyan/s2891. How do I fix this? is that OK
> to
> remove nvidia/ck804/id.lds?
>
> thanks
>
> beneo
>
> ----- Original Message ----- 
> From: "Lu, Yinghai" 
> To: "beneo" ; "Ronald G Minnich"

> Cc: 
> Sent: Wednesday, November 09, 2005 7:39 PM
> Subject: Re: [LinuxBIOS] Build broken?
> > Please change ROM_IMAGE_SIZE in romimage "fallback" section to

0x16380
> > YH