On 10 Jan, Ronald G Minnich wrote:
> On Wed, 10 Jan 2001 [EMAIL PROTECTED] wrote:
>
>> Deleting all those old empty directories would make it a whole lot
>> easier for a newbie (as I am with the new stuff) to find his way around.
>
> AAAAAAAAAARRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHH
> yes, and I keep killing those things and CVS won't let them die.
My limited CVS knowledge says that you must actually delete directories
from the repository, using rm or rmdir. I don't know of any way to
delete a directory using cvs. Is this what you are doing?
> Please send me a list and I will try again.
ChangeLog - Contains only a few very obsolete comments
NEWS - Pure clutter
chip/ - empty
device/ - empty
doc/ - empty
fs/ - empty
include/ - empty
lib/ - empty
linuxbios/ - empty
mkrom/ - this isn't empty. shouldn't it be in util?
rom/ - empty
romimages/ - this isn't empty but you said obsolete
>> Deleting all the old READMEs and other docs would help eliminate
>> confusion.
>
> sorry, my fault.
>
>> There seems to be no documentation on how to use the new config tools.
>> There is information on what should go in a config file but nothing on
>> useing the tool unless you "use the source".
>
> yeah, I am trying to get that done. sorry.
>
>> I recall some emails going out that documented the new organization
>> when it was still a proposal. Including this information in the
>> Documentation directory would be quite useful.
>
> we have gotten close to getting a mail archive ready.
>
>> I think that the romimage/<blah> directories are intended to be where
>> you "make" and the output from LBConfig.py is supposed to be placed
>> there.
>
> sorry, no. Those romimage directories are historical. The best bet for how
> to do things is the check out the HOWTO for SiS630.
The config tool is NLBConfig.py. Make sure you use that and not
LBConfig.py, the older version.
Shouldn't LBConfig.py be deleted?
>> The mainboard directories will actually contain most of the interesting
>> configuration information but aren't intended to be the "top level".
>
> yeah that I think is right.
>
> Thanks Tyson for looking at this stuff.
>
> ron
I haven't gotten real deep yet but a couple of things I noticed:
mtrr.c is pretty agressive about caching in the 640K-1Meg region. For
my system and any system that has a real I/O device there sections of
it MUST be marked as uncachable in the fixed MTRRs. ...I spent a
couple of days on that one. There is no way to configure the code to
do this. If no one else already has a good solution this is one place
I will be submitting some patches.
l2_cache.c seems to be pre-coppermine stuff. What is its effect on a
coppermine that needs nothing more than setting up MTRRs to configure
cache? ...may need some patches to allow more flexible configuration.
In this case it might be nice to either eliminate the code at compile
time and/or have it auto-probe the CPU type and do the right thing.
mpspec.c - I'm not using an SMP system. All the same concerns at
l2_cache.c apply here, only more so.
Because cpu/p6 has a Config file that automatically uses l2_cache.c and
mpspec.c there is no way for me to create a Config file that doesn't
include these files. ...any suggestions?
microcode.c - The HOWTOs both list microcode.c as mandatory for
coppermines. I have been using a coppermine with no microcode update
and have not have problems. Note: the original GA6-BXC BIOS did upate
the microcode. What effect does the update have?
Does this file get updated with the latest microcode? How do we deal
with newer processors that need different microcode? ...are there any
yet?
Why not use the Linux driver to update the microcode after the system
is running?
Thanks!
Ty
--
Tyson D Sawyer iRobot Corporation
Senior Systems Engineer Real World Interface Div.
[EMAIL PROTECTED] Robots for the Real World
603-532-6900 ext 206 http://www.irobot.com
