right, I should try this script when I have fallback ROM_IMAGE_SIZE larger than 64k. Otherwise I would not be able to build. I will try it.
beneo. ----- Original Message ----- From: "Lu, Yinghai" <[EMAIL PROTECTED]> To: "beneo" <[EMAIL PROTECTED]>; "Ronald G Minnich" <[email protected]> Cc: <[email protected]> Sent: Thursday, November 10, 2005 5:32 PM Subject: RE: [LinuxBIOS] Build broken? 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:[EMAIL PROTECTED] Sent: Thursday, November 10, 2005 5:26 PM To: Lu, Yinghai; Ronald G Minnich Cc: [email protected] 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" <[EMAIL PROTECTED]> To: "beneo" <[EMAIL PROTECTED]>; "Ronald G Minnich" <[email protected]> Cc: <[email protected]> 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:[EMAIL PROTECTED] > Sent: Thursday, November 10, 2005 3:22 PM > To: Lu, Yinghai; Ronald G Minnich > Cc: [email protected] > 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" <[EMAIL PROTECTED]> > To: "beneo" <[EMAIL PROTECTED]>; "Ronald G Minnich" <[email protected]> > Cc: <[email protected]> > 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:[EMAIL PROTECTED] > Sent: Thursday, November 10, 2005 3:14 PM > To: Lu, Yinghai; Ronald G Minnich > Cc: [email protected] > 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" <[EMAIL PROTECTED]> > To: "beneo" <[EMAIL PROTECTED]>; "Ronald G Minnich" <[email protected]> > Cc: <[email protected]> > 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:[EMAIL PROTECTED] > > Sent: Thursday, November 10, 2005 11:54 AM > > To: Lu, Yinghai; Ronald G Minnich > > Cc: [email protected] > > 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" <[EMAIL PROTECTED]> > > To: "beneo" <[EMAIL PROTECTED]>; "Ronald G Minnich" > <[email protected]> > > Cc: <[email protected]> > > 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 > > > [email protected] > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > -- > > LinuxBIOS mailing list > > [email protected] > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > -- > LinuxBIOS mailing list > [email protected] > http://www.openbios.org/mailman/listinfo/linuxbios -- LinuxBIOS mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
