Eric,
I can build the linuxbios. But it is too large and it is around 60k, and tg3.zelf is about 22k, and tg3--ide_disk.zelf is about 24k, then the sum is above 65k.So I can not build the images.
The Ram conf costs 20k ???
Any advise.
Regards
Yinghai Lu
-----邮件原件----- 发件人: YhLu 发送时间: 2003年7月21日 10:31 收件人: 'ebiederman@lnxi.com' 抄送: ron minnich; Stefan Reinauer; linuxbios@clustermatic.org 主题: Re: K8 + 2.4.21 + Tyan S2880
Eric,
Thanks info about ROMCC option about -mcpu=k8. I will try and make the RAM can be configurable.
My CPU is C0, In Opteron We may need to manipulate the MSR to enable the apic.
Regards
Yinghai Lu
YhLu YhLu@tyan.com writes:
Eric,
My boss has said that I can release the source code to you.
Please find out the patch I made. Make the diff to today's tree.
I didn't test RON new script and still use the old scripts tools.
I strip out the LSI scsi support, because I don't know if there is any license problem, and I have referred to their documents and may need put their FW in the ROM.
Ah, an interesting problem.
It's greater you add ops->enable function that make it easy to handle special device. To some device if it is not gotten magic code, it will not get the resource allocate to it. Before that I have to do it in init function and re-allocate the resource to it again.
Welcome.
Please refer to my old amd8131_ioapic.c in southbridge/amd8111.
Also you init the io_base, upper16 reg, otherwise the device in PCIX will not got io port allocated to them, and will not work.
Sorry I don't quite parse that sentence.
I have tested Stefan's the code about coherent_ht.c, and add some hardcode to it. coherent_ht.o.c is the original one. Coherent_ht.1.c is total hardcode
one.
coherent_ht.c and coherent_ht.2.c are modified with some hardcode ones.
Interesting looking at this code are you working with C0 stepping Opterons? I have the stock B3 and am having fun getting the memory resets in all of the proper places.
raminit.c and raminit.1.c are till the hardcode one, and I have tried to
use
the configurable one, but auto.c can not be compiled, it is too big and
used
up REG?
Looking. It is your romcc options. By default romcc will not use mmx or sse registers unless you tell it that you have them. I have been doing this with -mcpu=k8. The register pressure is much less when you have 24 registers to work with instead of just 8.
The old one has been renamed to raminit.o.c.
To start other cpus, in auto.c We must enable apic and make sure all apic_id is right. Please refer to mainboard/tyan/s2880/auto.c boot_cpu function.
Yep, an interesting way of doing it.
Again, thank you all to answer my questions to help Tyan s2880 work with LinuxBIOS.
Ron, Stefan. Could one of you help with merging Yinghai's code? I might have time, but I don't think I will manage it before I leave for OLS on Tuesday.
Eric
On Mon, 21 Jul 2003, YhLu wrote:
I can build the linuxbios. But it is too large and it is around 60k, and tg3.zelf is about 22k, and tg3--ide_disk.zelf is about 24k, then the sum is above 65k.So I can not build the images.
I now routinely set my linuxbios size for 64K with payload size of 32k.
romcc is WONDERFUL but it does grow things a bit.
ron
ron minnich rminnich@lanl.gov writes:
On Mon, 21 Jul 2003, YhLu wrote:
I can build the linuxbios. But it is too large and it is around 60k, and tg3.zelf is about 22k, and tg3--ide_disk.zelf is about 24k, then the sum is above 65k.So I can not build the images.
I now routinely set my linuxbios size for 64K with payload size of 32k.
romcc is WONDERFUL but it does grow things a bit.
Next time I get to it I intend to start honoring the inline keyword. The problem is that it inlines everything and creates code bloat.
So far it is working well enough and there are other priorities that I have not come back to it. It is my goal that before the 2.0 release I can fit everything back into 64K for fallback again. It is not critical now but it is a warning sign of troubles ahead.
Eric
On 21 Jul 2003, Eric W. Biederman wrote:
Next time I get to it I intend to start honoring the inline keyword. The problem is that it inlines everything and creates code bloat.
hmm, I'll be wanting to see how you solve the call stack problem :-)
So far it is working well enough and there are other priorities that I have not come back to it. It is my goal that before the 2.0 release I can fit everything back into 64K for fallback again. It is not critical now but it is a warning sign of troubles ahead.
Personally, for now, I think it's fine.
ron
ron minnich rminnich@lanl.gov writes:
On 21 Jul 2003, Eric W. Biederman wrote:
Next time I get to it I intend to start honoring the inline keyword. The problem is that it inlines everything and creates code bloat.
hmm, I'll be wanting to see how you solve the call stack problem :-)
Well routines that are only called once will still get inlined.
And with 24 registers I have a lot more freedom, than with just 8.
Historically Fortran did not have a call stack and it made procedure and function calls just fine. The same techniques with registers instead of hard coded memory locations should work fine.
So far it is working well enough and there are other priorities that I have not come back to it. It is my goal that before the 2.0 release I can fit everything back into 64K for fallback again. It is not critical now but it is a warning sign of troubles ahead.
Personally, for now, I think it's fine.
You haven't had your debug code fail to compile because linuxbios goes over the 64K limit yet either.
Eric
On 21 Jul 2003, Eric W. Biederman wrote:
You haven't had your debug code fail to compile because linuxbios goes over the 64K limit yet either.
I just did :-)
ron
-
ebiederman＠lnxi.com -
ron minnich -
YhLu