I have committed so many files today I can barely track what I am doing. The result is that all of my oustanding code has now been pushed to the LinuxBIOS tree. So the supermicro/p4dpr and supermicro/p4dpe should now be stable ports of linuxBIOS. I would say so in the status file, but there isn't a single one in the whole tree.
Things other people will notice. The upx compressor code was integrated and is on by default. So you will get smaller linuxbios rom images. I accomplished this by explicitly factoring linuxbios into a C part that runs in ram and an assembly part that runs directly out of flash. The seperation was there before but now it is explicit. This greatly simplifies the linker scripts, so we are actually less likely to run into LD bugs now than before.
The config option is CONFIG_COMPRESS if you want to turn it off.
Other things of note. cmos.conf was renamed cmos.layout to reduce confusion. And a new checksum entry was added to the LinuxBIOS table so external programs can find the checksum that protects the LinuxBIOS options.
My code has been synced with the changes Steve James made for the Clearwater port.
There are microcode updates in the tree, and some other cpu fixups for the pentium 4.
Have fun, and hopefully nothing broke except the p4dc6, as they way it utilized the cache as ram trick depended on the muddy watters between code that ran in rom and ram. The code is fixable, if I turn off compression. It just requires a little magic to find the cache as ram entry point...
Eric
Greetings,
I just tried an update/build/test for Clearwater and all is well there (except that slow spot check I still can't explain).
G'day, sjames
On 25 Oct 2002, Eric W. Biederman wrote:
I have committed so many files today I can barely track what I am doing. The result is that all of my oustanding code has now been pushed to the LinuxBIOS tree. So the supermicro/p4dpr and supermicro/p4dpe should now be stable ports of linuxBIOS. I would say so in the status file, but there isn't a single one in the whole tree.
Things other people will notice. The upx compressor code was integrated and is on by default. So you will get smaller linuxbios rom images. I accomplished this by explicitly factoring linuxbios into a C part that runs in ram and an assembly part that runs directly out of flash. The seperation was there before but now it is explicit. This greatly simplifies the linker scripts, so we are actually less likely to run into LD bugs now than before.
The config option is CONFIG_COMPRESS if you want to turn it off.
Other things of note. cmos.conf was renamed cmos.layout to reduce confusion. And a new checksum entry was added to the LinuxBIOS table so external programs can find the checksum that protects the LinuxBIOS options.
My code has been synced with the changes Steve James made for the Clearwater port.
There are microcode updates in the tree, and some other cpu fixups for the pentium 4.
Have fun, and hopefully nothing broke except the p4dc6, as they way it utilized the cache as ram trick depended on the muddy watters between code that ran in rom and ram. The code is fixable, if I turn off compression. It just requires a little magic to find the cache as ram entry point...
Eric _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
steven james pyro@linuxlabs.com writes:
Greetings,
I just tried an update/build/test for Clearwater and all is well there (except that slow spot check I still can't explain).
A couple of thoughts - What is your memory configuration? - Is ECC SDRAM being scrubbed? - Have you run memtest86? - Have you tried other ram? - Are you certain there is not a mux on the i2c channel to memory? Enough checks are present so you should not see a problem but... - Does it only go fast for me because I am caching the ROM chip someplace? And you do not have that code?
Eric
Greetings,
Thanks! I had early_mtrr turned off at one point, and never re-included it. The spot check flies right through now.
G'day, sjames
On 26 Oct 2002, Eric W. Biederman wrote:
steven james pyro@linuxlabs.com writes:
Greetings,
I just tried an update/build/test for Clearwater and all is well there (except that slow spot check I still can't explain).
A couple of thoughts
- What is your memory configuration?
- Is ECC SDRAM being scrubbed?
- Have you run memtest86?
- Have you tried other ram?
- Are you certain there is not a mux on the i2c channel to memory? Enough checks are present so you should not see a problem but...
- Does it only go fast for me because I am caching the ROM chip someplace? And you do not have that code?
Eric
Has anyone tackled the Westville (SE7500WV2)? Is there likely to be much difference between that and the Clearwater? I'm considering using some of these boards.
Thanks, --Bob
On Sat, Oct 26, 2002 at 10:02:55AM -0400, steven james wrote:
Greetings,
I just tried an update/build/test for Clearwater and all is well there (except that slow spot check I still can't explain).
G'day, sjames
On 25 Oct 2002, Eric W. Biederman wrote:
I have committed so many files today I can barely track what I am doing. The result is that all of my oustanding code has now been pushed to the LinuxBIOS tree. So the supermicro/p4dpr and supermicro/p4dpe should now be stable ports of linuxBIOS. I would say so in the status file, but there isn't a single one in the whole tree.
I hope to get that in this week, sorry.
Eric I assume you have my mptable in for the p4dpe? Has to be different from the p4dpr.
many thanks for this, this is terrific news.
ron
Ronald G Minnich rminnich@lanl.gov writes:
On 25 Oct 2002, Eric W. Biederman wrote:
I have committed so many files today I can barely track what I am doing. The result is that all of my oustanding code has now been pushed to the LinuxBIOS tree. So the supermicro/p4dpr and supermicro/p4dpe should now be stable ports of linuxBIOS. I would say so in the status file, but there isn't a single one in the whole tree.
I hope to get that in this week, sorry.
Eric I assume you have my mptable in for the p4dpe? Has to be different from the p4dpr.
I have the mptable for the p4dpe I have hear, that is mcr, and that I know works. My memory is that it was substatially similiar to the p4dpr it just had more interrupts.
If you have a different p4dpe we need to add another directory something like p4dpe-xyz (To match the motherboard) and add that to the tree. But I haven't a clue how stable that will be.
When I did the initial port I thought there was only one p4dpe variant.
Eric
On 26 Oct 2002, Eric W. Biederman wrote:
I have the mptable for the p4dpe I have hear, that is mcr, and that I know works. My memory is that it was substatially similiar to the p4dpr it just had more interrupts.
OK I will compare and see. I'll just build for dpe and see what happens.
ron
-
Bob Drzyzgula -
ebiederman＠lnxi.com -
Ronald G Minnich -
steven james