Why not use gcc 3.4....?
YH
-----Original Message-----
From: beneo [mailto:beneo@comcast.net]
Sent: Thursday, November 10, 2005 3:14 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios(a)openbios.org
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" <yinghai.lu(a)amd.com>
To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich" <rminnich(a)lanl.gov>
Cc: <linuxbios(a)openbios.org>
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:beneo@comcast.net]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios(a)openbios.org
> 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" <yinghai.lu(a)AMD.COM>
> To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich"
<rminnich(a)lanl.gov>
> Cc: <linuxbios(a)openbios.org>
> 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
> >
> >
> >
> > --
> > LinuxBIOS mailing list
> > LinuxBIOS(a)openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS(a)openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
Hello.
I have ADLO shipped with LinuxBIOS v1. My working box has
bcc: version 0.16.14
gcc version 3.3.4
as86 version: 0.16.15
I tried to compile bochs rom like this:
# cd ~/ADLO/bochs/bios
# make distclean
# make
gcc -E rombios.c > _rombios_.c
rombios.c:2662:50: pasting "(" and ""ata_cmd_data_in : read error\n"" does not give a valid preprocessing token
rombios.c:2665:84: pasting "(" and ""ata_cmd_data_in : DRQ not set (status %02x)\n"" does not give a valid preprocessing token
rombios.c dated 01 May, 2005, size 276323 (freebios--devel--1.0--base-0.tar.bz2).
Anyone succeded to compile ADLO recently?
--
Sincerely, Anton Borisov
Can any one give me a quick run down and the Up/Downs of using a DOC or
CF as the primary boot device in a Linux BIOS system. I know there are
both based on nand technology, and I know that the CF is on the ATA
bus... I know that both have a limited number of writes, but that is
where i run out of info. What else is there, why would some one use a
CF or DOC over the other?
-Adam
Did you use my new ldscripts.lds?
Also you need to change you FALLBACK_SIZE in MB Option.lb to 0x40000
YH
-----Original Message-----
From: beneo [mailto:beneo@comcast.net]
Sent: Thursday, November 10, 2005 5:26 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios(a)openbios.org
Subject: Re: [LinuxBIOS] Build broken?
thanks for the help, otherwise, I probably would spend days to figure
out. I
create a cace_as_ram.lds in my directory which handles the section not
in
standard lds, I can build now.
Only mystery still remain is why when I have ROM_IMAGE_SIZE set to
0x20000
in fallback, it won't build, but set to smaller 0x16380, it builds. It
seems
caused objcopy to generate a different size of linuxbios.strip file. I
think
objcopy should have nothing to do with it. but something went wrong
before
that. It should be a bug in the code, I just don't know what it is.
Thanks
beneo
----- Original Message -----
From: "Lu, Yinghai" <yinghai.lu(a)AMD.COM>
To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich" <rminnich(a)lanl.gov>
Cc: <linuxbios(a)openbios.org>
Sent: Thursday, November 10, 2005 3:29 PM
Subject: Re: [LinuxBIOS] Build broken?
> You can change section name in arch/i386/Config.lb if you have strange
> compiler that produce werid section name.
>
> YH
>
> -----Original Message-----
> From: beneo [mailto:beneo@comcast.net]
> Sent: Thursday, November 10, 2005 3:22 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios(a)openbios.org
> Subject: Re: [LinuxBIOS] Build broken?
>
> 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" <yinghai.lu(a)AMD.COM>
> To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich"
<rminnich(a)lanl.gov>
> Cc: <linuxbios(a)openbios.org>
> 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:beneo@comcast.net]
> Sent: Thursday, November 10, 2005 3:14 PM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios(a)openbios.org
> 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" <yinghai.lu(a)amd.com>
> To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich"
<rminnich(a)lanl.gov>
> Cc: <linuxbios(a)openbios.org>
> 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:beneo@comcast.net]
> > Sent: Thursday, November 10, 2005 11:54 AM
> > To: Lu, Yinghai; Ronald G Minnich
> > Cc: linuxbios(a)openbios.org
> > 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" <yinghai.lu(a)AMD.COM>
> > To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich"
> <rminnich(a)lanl.gov>
> > Cc: <linuxbios(a)openbios.org>
> > 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
> > >
> > >
> > >
> > > --
> > > LinuxBIOS mailing list
> > > LinuxBIOS(a)openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> >
> >
> >
> >
> > --
> > LinuxBIOS mailing list
> > LinuxBIOS(a)openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS(a)openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
You can change section name in arch/i386/Config.lb if you have strange
compiler that produce werid section name.
YH
-----Original Message-----
From: beneo [mailto:beneo@comcast.net]
Sent: Thursday, November 10, 2005 3:22 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios(a)openbios.org
Subject: Re: [LinuxBIOS] Build broken?
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" <yinghai.lu(a)AMD.COM>
To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich" <rminnich(a)lanl.gov>
Cc: <linuxbios(a)openbios.org>
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:beneo@comcast.net]
Sent: Thursday, November 10, 2005 3:14 PM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios(a)openbios.org
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" <yinghai.lu(a)amd.com>
To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich" <rminnich(a)lanl.gov>
Cc: <linuxbios(a)openbios.org>
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:beneo@comcast.net]
> Sent: Thursday, November 10, 2005 11:54 AM
> To: Lu, Yinghai; Ronald G Minnich
> Cc: linuxbios(a)openbios.org
> 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" <yinghai.lu(a)AMD.COM>
> To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich"
<rminnich(a)lanl.gov>
> Cc: <linuxbios(a)openbios.org>
> 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
> >
> >
> >
> > --
> > LinuxBIOS mailing list
> > LinuxBIOS(a)openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
>
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS(a)openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
With this change, We can fix all K8 MB
ROM_IMAGE_SIZE=0x20000 #128K
FALLBACK_SIZE=0x40000 #256K
[ffff0000, ffffffff) : rom (64K)
[fffe0000, fffeffff) : ram (64K)
[fffc0000, fffdffff) : payload (128K) too big...
XIP_ROM_SIZE will be equal to ROM_IMAGE_SIZE...
All fixed address....
YH
-----Original Message-----
From: linuxbios-bounces(a)openbios.org
[mailto:linuxbios-bounces@openbios.org] On Behalf Of Lu, Yinghai
Sent: Thursday, November 10, 2005 2:58 PM
To: beneo; Ronald G Minnich
Cc: linuxbios(a)openbios.org
Subject: Re: [LinuxBIOS] Build broken?
With attach lds, the linuxbios_rom will be fixed on 0x0xffff0000 for
fallback image.
Anyway address is fixed, leave last 64k for crt0.s and init.o now....
YH
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:beneo@comcast.net]
Sent: Thursday, November 10, 2005 11:54 AM
To: Lu, Yinghai; Ronald G Minnich
Cc: linuxbios(a)openbios.org
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" <yinghai.lu(a)AMD.COM>
To: "beneo" <beneo(a)comcast.net>; "Ronald G Minnich" <rminnich(a)lanl.gov>
Cc: <linuxbios(a)openbios.org>
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
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS(a)openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
With attach lds, the linuxbios_rom will be fixed on 0x0xffff0000 for
fallback image.
Anyway address is fixed, leave last 64k for crt0.s and init.o now....
YH
