12:43 p.m.
"Yinghai Lu" <yhlu(a)tyan.com> writes:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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
3:01 p.m.
New subject: Merge/Cleanup status
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(a)lanl.gov;
'Stefan Reinauer'
Subject: Re: Merge/Cleanup status
"Yinghai Lu" <yhlu(a)tyan.com> writes:
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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
6:38 p.m.
New subject: Merge/Cleanup status
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
5693
days inactive
5694
days old
3 comments
2 participants
participants (2)
-
ebiederman＠lnxi.com -
Yinghai Lu