"Yinghai Lu" yhlu@tyan.com writes:
- Using ROMCC to do propresser will help the size reduction?
Not directly. But it does cleanup the header files and increase the exposure to romcc. There are a small handful of things this make more maintainable.
- what is usage for MOVNTI? It is for GDB....
Look at ramtest.c. movnti is a non-teporal move (bypasses the cache). In some cases it can noticeably increase store performance. Last I measured in the cases it mattered it increased store performance by 3X.
- How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
Correct. Either an exception must be taken or a call to gdb_stub_breakpoint() needs to be made. At that point LinuxBIOS will stop and wait for the debugger. Assuming CONFIG_GDB_STUB is compiled in. For details on the gdb side, read up on the gdb remote serial protocol.
I'm not really a fan, I am still more productive with printf debugging. But implement ion exception handling support is a general win. And the support was easy to add.
- You will use llshell for crt0.s or auto.c debug?
That is the idea. Again I added it because it is available. It would not be hard to call out to it with an appropriate asm directive. If people find llshell useful.
- Current romcc only take constant parameters for non inline function? It
that right?
There is something weird going on that affects the generated code, so things don't work as smoothly as they should.
That said in theory function can be non-inline.
- Anyone has tried to compile LinuxBIOS under Suse 9.1? what's the
recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not compile Etherboot properly. I am always using RH9 to do the work. And just found I can not compile LB for S2885, (size>65536), but I can do it in Suse 9.1 pro.
The goal is to have LinuxBIOS compiling as many places as possible. As for recommendations we can call out specific revisions of the tool chain that are known good but I won't call out distros.
Size wise I know gcc-3.4 is about 2% better than gcc-3.3.
Interesting. On the purely size issue you can bump ROM_IMAGE_SIZE a little and see if it the build works.
As for etherboot I don't know what your compile failure is. So I don't know how to diagnose that.
Eric
I'm not really a fan, I am still more productive with printf debugging.
Yes, also post code to port 80 is useful before the console is setup.
Regards
YH
After increase the ROM_IMAGE_SIZE beyond 64K, Do you need to change DXIP_ROM_SIZE?
Regards
YH
-----Original Message----- From: Eric W. Biederman [mailto:eric@lnxi.com] On Behalf Of Eric W. Biederman Sent: Sunday, October 31, 2004 10:06 AM To: Yinghai Lu Cc: 'LinuxBIOS'; 'Ronald G. Minnich'; 'Richard Smith'; ollie@lanl.gov; 'Stefan Reinauer' Subject: Re: Merge/Cleanup status
"Yinghai Lu" yhlu@tyan.com writes:
- Using ROMCC to do propresser will help the size reduction?
Not directly. But it does cleanup the header files and increase the exposure to romcc. There are a small handful of things this make more maintainable.
- what is usage for MOVNTI? It is for GDB....
Look at ramtest.c. movnti is a non-teporal move (bypasses the cache). In some cases it can noticeably increase store performance. Last I measured in the cases it mattered it increased store performance by 3X.
- How to use GDB to debug LinuxBIOS? Is it only for linuxbios_ram?
Correct. Either an exception must be taken or a call to gdb_stub_breakpoint() needs to be made. At that point LinuxBIOS will stop and wait for the debugger. Assuming CONFIG_GDB_STUB is compiled in. For details on the gdb side, read up on the gdb remote serial protocol.
I'm not really a fan, I am still more productive with printf debugging. But implement ion exception handling support is a general win. And the support was easy to add.
- You will use llshell for crt0.s or auto.c debug?
That is the idea. Again I added it because it is available. It would not be hard to call out to it with an appropriate asm directive. If people find llshell useful.
- Current romcc only take constant parameters for non inline function? It
that right?
There is something weird going on that affects the generated code, so things don't work as smoothly as they should.
That said in theory function can be non-inline.
- Anyone has tried to compile LinuxBIOS under Suse 9.1? what's the
recommended platform for LinuxBIOS compliation? It seems Suse 9.1 can not compile Etherboot properly. I am always using RH9 to do the work. And just found I can not compile LB for S2885, (size>65536), but I can do it in
Suse
9.1 pro.
The goal is to have LinuxBIOS compiling as many places as possible. As for recommendations we can call out specific revisions of the tool chain that are known good but I won't call out distros.
Size wise I know gcc-3.4 is about 2% better than gcc-3.3.
Interesting. On the purely size issue you can bump ROM_IMAGE_SIZE a little and see if it the build works.
As for etherboot I don't know what your compile failure is. So I don't know how to diagnose that.
Eric
Eric,
What the reasons that you set MTRRs for one CPU two times.? amd_setup_mtrrs of amd_mtrr.c call x86_setup_mtrrs...
regards
Yinghai Lu
APIC_CLUSTER: 0 init Initializing CPU #0 CPU: vendor AMD device f5a Enabling cache
Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs
Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 512MB, type WB Setting variable MTRR 3, base: 3584MB, range: 256MB, type WB Setting variable MTRR 4, base: 3840MB, range: 128MB, type WB Setting variable MTRR 5, base: 4096MB, range: 4096MB, type WB Setting variable MTRR 6, base: 8192MB, range: 8192MB, type WB DONE variable MTRRs Clear out the extra MTRR's
MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled
-
ebiederman＠lnxi.com -
Yinghai Lu