linux-mips-kernel — Developers list to discuss MIPS issues

Re: [Linux-mips-kernel] ramdisks

[Pete P. <pp...@mv...>]

James Simmons wrote:

>>Well, ramdisks should be properly linked into the kernel during compile time.
>>
> 
> Okay.
> 
> 
>>Yeah, SourceForge is sucking as usual. It was working just fine up till about
>>3 this morning which was the last I used it. Upon trying to do anything right
>>now it dies with the same error. Maybe they'll get around to fixing it sometime
>>today.
>>
>>I'll hop on IRC and see if I can find out what's going on with it.
>>
> 
> Its fixed now. 
> 
> P.S
>    We have a default config directory, arch/mips/configs so creating
> standard configs for different devices should be easy. 
>    Pete can you give more info on converting drivers over to this new pci 
> sharing code. I like to convert the cobalt stuff over to it.  

Absolutely. I'll write something up over the weekend.  Should I commit 
it then?

Pete

Re: [Linux-mips-kernel] VR status

[Paul M. <pm...@mv...>]

On Fri, Jul 06, 2001 at 11:32:52AM -0700, Paul Mundt wrote:
> Okay, it's attached. Though portions of ruby will need to be adjusted to
> work properly under the tree.. this patch will only allow for building the
> vr4181fb under ruby on linux-mips. I'm not able to test anything, so please
> let me know if you run into any problems.
> 
> The patch itself is rather stupid, but it was the only really outstanding
> thing in the driver that needed changing, as I modified Jun's patch to use
> the same conventions that the VR tree did.
> 
Oops, wrong button.. here it is, attached this time..

Regards,

-- 
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] VR status

[Paul M. <pm...@mv...>]

On Fri, Jul 06, 2001 at 09:42:13AM -0700, James Simmons wrote:
> For the fbdev driver for linux-mips use fbgen2.c. It will ease the
> transition from the current tree to ruby and 2.5.X. Also the good news is=
=20
> russell king is looking over fbgen2.c and is planning to incorporate it
> into the arm tree.=20
>=20
Okay, I suppose I'll have to port from the VR tree to the linux-mips tree
then.. then when we migrate to ruby, we can just kill off the drivers in
the linux-mips tree and use the ones I've already ported to the ruby tree.

> That is good news. I didn't realize it was ready for testing. I have
> plenty of devices to test it on. A DoCoMo, NEC mobile pro, a agenda,
> helio. I also have a few cassiopea's laying around. I just have to make
> the flash to boot to.=20
>=20
Okay, please take care of VR4181 testing if you can. The only VR device I
have is my E-11. I suppose I should get around to picking up an Agenda or
something, though I don't quite feel like spending that much money for a
peice of trash.

> > If anyone wants the patch for vr4181fb in ruby to work with Jun's
> > patch, let me know.
>=20
> Please post for me to play with.
>=20
Okay, it's attached. Though portions of ruby will need to be adjusted to
work properly under the tree.. this patch will only allow for building the
vr4181fb under ruby on linux-mips. I'm not able to test anything, so please
let me know if you run into any problems.

The patch itself is rather stupid, but it was the only really outstanding
thing in the driver that needed changing, as I modified Jun's patch to use
the same conventions that the VR tree did.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] ramdisks

[James S. <jsi...@tr...>]

> Well, ramdisks should be properly linked into the kernel during compile time.

Okay.

> Yeah, SourceForge is sucking as usual. It was working just fine up till about
> 3 this morning which was the last I used it. Upon trying to do anything right
> now it dies with the same error. Maybe they'll get around to fixing it sometime
> today.
> 
> I'll hop on IRC and see if I can find out what's going on with it.

Its fixed now. 

P.S
   We have a default config directory, arch/mips/configs so creating
standard configs for different devices should be easy. 
   Pete can you give more info on converting drivers over to this new pci 
sharing code. I like to convert the cobalt stuff over to it.  

 

Re: [Linux-mips-kernel] ramdisks

[Paul M. <pm...@mv...>]

On Fri, Jul 06, 2001 at 09:49:08AM -0700, Paul Mundt wrote:
> Yeah, SourceForge is sucking as usual. It was working just fine up till a=
bout
> 3 this morning which was the last I used it. Upon trying to do anything r=
ight
> now it dies with the same error. Maybe they'll get around to fixing it so=
metime
> today.
>=20
> I'll hop on IRC and see if I can find out what's going on with it.
>=20
SourceForge CVS is back up again.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] ramdisks

[Paul M. <pm...@mv...>]

On Fri, Jul 06, 2001 at 09:16:13AM -0700, James Simmons wrote:
> > I often use ramdisk when I bring up a board; I see a ramdisk in=20
> > phillips/nino as well. Any reason why we can't generalize this and put=
=20
> > the ramdisk directory and Makefile in arch/mips?  Also, I can create a=
=20
> > few little and big endian ramdisk of different size, with different=20
> > number of utilities and upload them to sourceforge. No reason for havin=
g=20
> > everything build their own ramdisk from scratch...
>=20
> Please place it in CVS. It only makes sense that we have a gerneal
> ramdisk. As for ramdisk we should import a new module into the rtree then.
> Ramdisk seems a logical module name.
>=20
Well, ramdisks should be properly linked into the kernel during compile tim=
e.
Which requires tossing the ramdisk.gz image through a quick and dirty ld sc=
ript
to dump a ramdisk.o that can then be linked straight into the kernel.

It'd be more beneficial to have a stock ramdisk as just the filesystem image
itself so it can be mounted and people can read/write to it, before passing
it through the ld script to generate the ramdisk.o.

It might also be beneficial to maybe write a script that'd automate the
process of building a ramdisk.. ie, fetching source, building, and installi=
ng
necessary components, then setting it all up in a small compressed image.
This would have the benefit of us not having to worry about things like mip=
s32
and mips64 differences, as you could just build for your target.

Though providing a few ready-to-use images is a good idea as well.

> P.S
>=20
>   Is anyone having trouble getting to CVS on SF. I can't sync my tree up.
> I get a=20
>=20
> ssh_exchange_identification: Connection closed by remote host
> cvs [update aborted]: end of file from server (consult above messages if =
any)
>=20
> Any idea was this is about.
>=20
Yeah, SourceForge is sucking as usual. It was working just fine up till abo=
ut
3 this morning which was the last I used it. Upon trying to do anything rig=
ht
now it dies with the same error. Maybe they'll get around to fixing it some=
time
today.

I'll hop on IRC and see if I can find out what's going on with it.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] VR status

[James S. <jsi...@tr...>]

> I commited the port of the VR4181 fb driver to ruby a couple days ago,
> I've got it adjusted to work with the linux-mips tree, and have a patch
> for that if you want it.. I'm holding off on merging it into ruby as
> ruby isn't exactly mips safe at the moment.

For the fbdev driver for linux-mips use fbgen2.c. It will ease the
transition from the current tree to ruby and 2.5.X. Also the good news is 
russell king is looking over fbgen2.c and is planning to incorporate it
into the arm tree. 

> As the tree sits right now, it should be able to functional fairly
> sanely on anything VR4181 based. I've been working on getting things
> functional for the VR4111 (which is almost completed, patch should
> be ready in the next day or two), as I only have a VR4111 device for
> testing on.

That is good news. I didn't realize it was ready for testing. I have
plenty of devices to test it on. A DoCoMo, NEC mobile pro, a agenda,
helio. I also have a few cassiopea's laying around. I just have to make
the flash to boot to. 

> If anyone has a NEC Osprey sitting around, it'd be an ideal test
> platform for both the tree in its current state, and for ruby with
> the vr4181fb + my patch.

This I don't have :-(

> If anyone wants the patch for vr4181fb in ruby to work with Jun's
> patch, let me know.

Please post for me to play with.

> I'm also in the process of writing up some defconfig's for various
> PDAs.. Brad's tree had these all as options in the 1500 line Config.in,
> and they're much cleaner hidden away in a configs directory. I'll
> commit these when I finish.

Please do. I like to know what brad was smoking when he came up with that
idea.

Re: [Linux-mips-kernel] mips generic pci code

[James S. <jsi...@tr...>]

> I haven't committed this patch yet because the board won't compile 
> without the new pci code.  I realized Ijumped the gun with the ev96100 
> board because I already commited the board specific patches to make it 
> work with the new pci code.    I'm really itching to commit the pci 
> code, so I'm just waiting for some more feedback from others.

Unfortunely I don't have these boards :-/ Thus whty my lack in helping
develope this code.

Re: [Linux-mips-kernel] mips generic pci code

[James S. <jsi...@tr...>]

> > BTW, what's up with the 2.4.5 bootp support? The code doesn't appear to 
> > get called unless you specify "ip=<ipaddress>" on the kernel command line.
> > 
> That's a known 2.4.5 bug, it was fixed in Alan's tree for awhile.. I believe the
> fix is in 2.4.6. It was a rather trivial fix if I recall correctly.. if you're
> stuck on 2.4.5, you should be able to apply it without any issues.

I hope to sync our tree with 2.4.6 soemtime over the weekend. I plan to
talk to Ralph about syncing his tree as well so we all can keep in sync. 
Please a couple of important bug fixes went into Ralf's tree.

Re: [Linux-mips-kernel] ramdisks

[James S. <jsi...@tr...>]

> I often use ramdisk when I bring up a board; I see a ramdisk in 
> phillips/nino as well. Any reason why we can't generalize this and put 
> the ramdisk directory and Makefile in arch/mips?  Also, I can create a 
> few little and big endian ramdisk of different size, with different 
> number of utilities and upload them to sourceforge. No reason for having 
> everything build their own ramdisk from scratch...

Please place it in CVS. It only makes sense that we have a gerneal
ramdisk. As for ramdisk we should import a new module into the rtree then.
Ramdisk seems a logical module name.

P.S

  Is anyone having trouble getting to CVS on SF. I can't sync my tree up.
I get a 

ssh_exchange_identification: Connection closed by remote host
cvs [update aborted]: end of file from server (consult above messages if any)

Any idea was this is about.

[Linux-mips-kernel] Re: ramdisks

[Pete P. <pp...@pa...>]

Pete Popov wrote:

> I often use ramdisk when I bring up a board; I see a ramdisk in 
> phillips/nino as well. Any reason why we can't generalize this and put 
> the ramdisk directory and Makefile in arch/mips?  Also, I can create a 
> few little and big endian ramdisk of different size, with different 
> number of utilities and upload them to sourceforge. No reason for having 
> everything build their own ramdisk from scratch...
> 

s/everything/everyone

[Linux-mips-kernel] ramdisks

[Pete P. <pp...@mv...>]

I often use ramdisk when I bring up a board; I see a ramdisk in 
phillips/nino as well. Any reason why we can't generalize this and put 
the ramdisk directory and Makefile in arch/mips?  Also, I can create a 
few little and big endian ramdisk of different size, with different 
number of utilities and upload them to sourceforge. No reason for having 
everything build their own ramdisk from scratch...

Pete

Re: [Linux-mips-kernel] mips generic pci code

[Pete P. <pp...@mv...>]

Paul Mundt wrote:

>On Thu, Jul 05, 2001 at 06:36:00PM -0700, Pete Popov wrote:
>
>>>Very nice! Speaking of supported boards.. have you had a chance to test it
>>>out on the ITE IT8172? If not, I'll give it a try tomorrow and let you know
>>>my results.
>>>
>>Not yet. I tested it on the ev96100 and basically the same code is 
>>running on the ddb5477 board. I've got an ITE board sitting here in my 
>>home right now. I suspect some setup changes might have to be made to 
>>the ite code, but the pci code *should* just work. Matt has done a great 
>>job there, and it's been tested on pretty complex PPC CPCI systems (like 
>>I said though, we modified it slightly for mips, so I'm sure we'll 
>>evolve this over time).  The ITE can be a bit tricky because it's got 
>>discountinuous pci memory space regions.  Two of those regions are 64MB 
>>each; the others are smaller.  Globespan, for example, is using both 
>>64MB regions for their custom mpeg chip, so no other devices can be 
>>assigned from those regions.  But I don't think I'll worry about that on 
>>the ITE board.
>>
>I don't think that should be too much of an issue on the ITE board. Worst case
>scenario is that a few board specific fixups need to be existant in the code.
>
>The Globespan sounds like it's the bigger nuisance out of the two.. though
>watching out for discontinuous regions on the ITE might prove to be somewhat
>bothersome.
>
>I'd test it now, except I'm not at work, and the ATX power supply I have hooked
>up to the board doesn't like working properly with the NPS. Damned ATX design.
>
>I'll give it a try tomorrow and let you know my findings.
>

While I was at it, I just added the new pci support to the ite board. I 
love it -- it just worked and was so easy to hook in. I've attached the 
patch which fixes some tiny api problems with the new kernel, and adds 
the new pci support to the ite and globespan boards (I only tested ITE). 
You'll need to apply the mips_pci patch I sent easier to get this to work.

I haven't committed this patch yet because the board won't compile 
without the new pci code.  I realized Ijumped the gun with the ev96100 
board because I already commited the board specific patches to make it 
work with the new pci code.    I'm really itching to commit the pci 
code, so I'm just waiting for some more feedback from others.

Pete

Re: [Linux-mips-kernel] mips generic pci code

[Pete P. <pp...@mv...>]

Paul Mundt wrote:

>On Thu, Jul 05, 2001 at 06:36:00PM -0700, Pete Popov wrote:
>
>>>Very nice! Speaking of supported boards.. have you had a chance to test it
>>>out on the ITE IT8172? If not, I'll give it a try tomorrow and let you know
>>>my results.
>>>
>>Not yet. I tested it on the ev96100 and basically the same code is 
>>running on the ddb5477 board. I've got an ITE board sitting here in my 
>>home right now. I suspect some setup changes might have to be made to 
>>the ite code, but the pci code *should* just work. Matt has done a great 
>>job there, and it's been tested on pretty complex PPC CPCI systems (like 
>>I said though, we modified it slightly for mips, so I'm sure we'll 
>>evolve this over time).  The ITE can be a bit tricky because it's got 
>>discountinuous pci memory space regions.  Two of those regions are 64MB 
>>each; the others are smaller.  Globespan, for example, is using both 
>>64MB regions for their custom mpeg chip, so no other devices can be 
>>assigned from those regions.  But I don't think I'll worry about that on 
>>the ITE board.
>>
>I don't think that should be too much of an issue on the ITE board. Worst case
>scenario is that a few board specific fixups need to be existant in the code.
>
>The Globespan sounds like it's the bigger nuisance out of the two.. though
>watching out for discontinuous regions on the ITE might prove to be somewhat
>bothersome.
>
That's a very custom board anyway.

>I'd test it now, except I'm not at work, and the ATX power supply I have hooked
>up to the board doesn't like working properly with the NPS. Damned ATX design.
>
>I'll give it a try tomorrow and let you know my findings.
>

I might give it a shot tonight. We'll see. I'll let you know if I do.

>Next I need to include this pci support in the Alchemy board. The 
>problem is that right now I'm supposed to turn my attention to generic 
>mips kernel problems ...
>
>Try submitting it on Perseus and hope somebody fixes it before they realize it's
>not specific to the tree.
>
>Who's doing the alchemy work anyways?
>

Steve L. and I.

>BTW, what's up with the 2.4.5 bootp support? The code doesn't appear to 
>get called unless you specify "ip=<ipaddress>" on the kernel command line.
>
>That's a known 2.4.5 bug, it was fixed in Alan's tree for awhile.. I believe the
>fix is in 2.4.6. It was a rather trivial fix if I recall correctly.. if you're
>stuck on 2.4.5, you should be able to apply it without any issues.
>
OK, thanks.

Pete

Re: [Linux-mips-kernel] mips generic pci code

[Paul M. <pm...@mv...>]

On Thu, Jul 05, 2001 at 06:36:00PM -0700, Pete Popov wrote:
> > Very nice! Speaking of supported boards.. have you had a chance to test=
 it
> > out on the ITE IT8172? If not, I'll give it a try tomorrow and let you =
know
> > my results.
>=20
> Not yet. I tested it on the ev96100 and basically the same code is=20
> running on the ddb5477 board. I've got an ITE board sitting here in my=20
> home right now. I suspect some setup changes might have to be made to=20
> the ite code, but the pci code *should* just work. Matt has done a great=
=20
> job there, and it's been tested on pretty complex PPC CPCI systems (like=
=20
> I said though, we modified it slightly for mips, so I'm sure we'll=20
> evolve this over time).  The ITE can be a bit tricky because it's got=20
> discountinuous pci memory space regions.  Two of those regions are 64MB=
=20
> each; the others are smaller.  Globespan, for example, is using both=20
> 64MB regions for their custom mpeg chip, so no other devices can be=20
> assigned from those regions.  But I don't think I'll worry about that on=
=20
> the ITE board.
>=20
I don't think that should be too much of an issue on the ITE board. Worst c=
ase
scenario is that a few board specific fixups need to be existant in the cod=
e.

The Globespan sounds like it's the bigger nuisance out of the two.. though
watching out for discontinuous regions on the ITE might prove to be somewhat
bothersome.

I'd test it now, except I'm not at work, and the ATX power supply I have ho=
oked
up to the board doesn't like working properly with the NPS. Damned ATX desi=
gn.

I'll give it a try tomorrow and let you know my findings.

> Next I need to include this pci support in the Alchemy board. The=20
> problem is that right now I'm supposed to turn my attention to generic=20
> mips kernel problems ...
>=20
Try submitting it on Perseus and hope somebody fixes it before they realize=
 it's
not specific to the tree.

Who's doing the alchemy work anyways?

> BTW, what's up with the 2.4.5 bootp support? The code doesn't appear to=
=20
> get called unless you specify "ip=3D<ipaddress>" on the kernel command li=
ne.
>=20
That's a known 2.4.5 bug, it was fixed in Alan's tree for awhile.. I believ=
e the
fix is in 2.4.6. It was a rather trivial fix if I recall correctly.. if you=
're
stuck on 2.4.5, you should be able to apply it without any issues.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] mips generic pci code

[Pete P. <pp...@pa...>]

Paul Mundt wrote:

> On Thu, Jul 05, 2001 at 05:57:17PM -0700, Pete Popov wrote:
> 
>>  One of the things I would like to add to the mips tree is generic pci 
>>code.  Jun recently ported the PPC pci_auto.c and pci.c code to one of 
>>the DDB NEC boards.  Now I've taken that code and made it mips generic. 
>> I've tested it on one mips board so far; I will soon have it tested on 
>>a couple of more boards.The code has two components: pci_auto.c and 
>>pci.c.  The pci_auto (if enabled) scans the bus(es) and assigns all the 
>>resources. Thus, you don't need boot code to do that anymore. This code 
>>has been tested pretty well on PPC on some pretty complex CPCI systems 
>>with multiple P2P bridges and devices behind the bridges.  pci.c is the 
>>second part and that's just generic pci handling code that all boards 
>>should be able to use.
>>
>>We've modified the code somewhat from the PPC and it certainly needs a 
>>lot of testing. However, it's only enabled in arch/mips/config.in for 
>>boards that are tested so other boards can take their time moving over 
>>to this code.  I think this code is badly needed in the mips tree 
>>because right now every board is doing its own pci thing. Add to that 
>>different boot codes on different boards which don't necessarily 
>>initialize the bus correctly, and you've got a real mess.
>>
>>
> Very nice! Speaking of supported boards.. have you had a chance to test it
> out on the ITE IT8172? If not, I'll give it a try tomorrow and let you know
> my results.


Not yet. I tested it on the ev96100 and basically the same code is 
running on the ddb5477 board. I've got an ITE board sitting here in my 
home right now. I suspect some setup changes might have to be made to 
the ite code, but the pci code *should* just work. Matt has done a great 
job there, and it's been tested on pretty complex PPC CPCI systems (like 
I said though, we modified it slightly for mips, so I'm sure we'll 
evolve this over time).  The ITE can be a bit tricky because it's got 
discountinuous pci memory space regions.  Two of those regions are 64MB 
each; the others are smaller.  Globespan, for example, is using both 
64MB regions for their custom mpeg chip, so no other devices can be 
assigned from those regions.  But I don't think I'll worry about that on 
the ITE board.

Next I need to include this pci support in the Alchemy board. The 
problem is that right now I'm supposed to turn my attention to generic 
mips kernel problems ...

BTW, what's up with the 2.4.5 bootp support? The code doesn't appear to 
get called unless you specify "ip=<ipaddress>" on the kernel command line.

Pete

 

Re: [Linux-mips-kernel] mips generic pci code

[Paul M. <pm...@mv...>]

On Thu, Jul 05, 2001 at 05:57:17PM -0700, Pete Popov wrote:
>   One of the things I would like to add to the mips tree is generic pci=
=20
> code.  Jun recently ported the PPC pci_auto.c and pci.c code to one of=20
> the DDB NEC boards.  Now I've taken that code and made it mips generic.=
=20
>  I've tested it on one mips board so far; I will soon have it tested on=
=20
> a couple of more boards.The code has two components: pci_auto.c and=20
> pci.c.  The pci_auto (if enabled) scans the bus(es) and assigns all the=
=20
> resources. Thus, you don't need boot code to do that anymore. This code=
=20
> has been tested pretty well on PPC on some pretty complex CPCI systems=20
> with multiple P2P bridges and devices behind the bridges.  pci.c is the=
=20
> second part and that's just generic pci handling code that all boards=20
> should be able to use.
>=20
> We've modified the code somewhat from the PPC and it certainly needs a=20
> lot of testing. However, it's only enabled in arch/mips/config.in for=20
> boards that are tested so other boards can take their time moving over=20
> to this code.  I think this code is badly needed in the mips tree=20
> because right now every board is doing its own pci thing. Add to that=20
> different boot codes on different boards which don't necessarily=20
> initialize the bus correctly, and you've got a real mess.
>=20
Very nice! Speaking of supported boards.. have you had a chance to test it
out on the ITE IT8172? If not, I'll give it a try tomorrow and let you know
my results.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [Linux-mips-kernel] VR status

[Paul M. <pm...@mv...>]

On Thu, Jul 05, 2001 at 04:11:44PM -0700, James Simmons wrote:
> Paul, how far along is your work? Can you post what you have so far?
>=20
I commited the port of the VR4181 fb driver to ruby a couple days ago,
I've got it adjusted to work with the linux-mips tree, and have a patch
for that if you want it.. I'm holding off on merging it into ruby as
ruby isn't exactly mips safe at the moment.

As the tree sits right now, it should be able to functional fairly
sanely on anything VR4181 based. I've been working on getting things
functional for the VR4111 (which is almost completed, patch should
be ready in the next day or two), as I only have a VR4111 device for
testing on.

As far as fb drivers go, I've already ported the majority of the ones
from the VR tree to ruby.. once ruby works properly on MIPS, all that
will have to be done will be some minor tweaks to work with Jun's VR
patch.

If anyone has a NEC Osprey sitting around, it'd be an ideal test
platform for both the tree in its current state, and for ruby with
the vr4181fb + my patch.

If anyone wants the patch for vr4181fb in ruby to work with Jun's
patch, let me know.

I'm also in the process of writing up some defconfig's for various
PDAs.. Brad's tree had these all as options in the 1500 line Config.in,
and they're much cleaner hidden away in a configs directory. I'll
commit these when I finish.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

[Linux-mips-kernel] mips generic pci code

[Pete P. <pp...@pa...>]

  One of the things I would like to add to the mips tree is generic pci 
code.  Jun recently ported the PPC pci_auto.c and pci.c code to one of 
the DDB NEC boards.  Now I've taken that code and made it mips generic. 
 I've tested it on one mips board so far; I will soon have it tested on 
a couple of more boards.The code has two components: pci_auto.c and 
pci.c.  The pci_auto (if enabled) scans the bus(es) and assigns all the 
resources. Thus, you don't need boot code to do that anymore. This code 
has been tested pretty well on PPC on some pretty complex CPCI systems 
with multiple P2P bridges and devices behind the bridges.  pci.c is the 
second part and that's just generic pci handling code that all boards 
should be able to use.

We've modified the code somewhat from the PPC and it certainly needs a 
lot of testing. However, it's only enabled in arch/mips/config.in for 
boards that are tested so other boards can take their time moving over 
to this code.  I think this code is badly needed in the mips tree 
because right now every board is doing its own pci thing. Add to that 
different boot codes on different boards which don't necessarily 
initialize the bus correctly, and you've got a real mess.

Comments?

Pete

[Linux-mips-kernel] VR status

[James S. <jsi...@tr...>]

Paul, how far along is your work? Can you post what you have so far?

Re: [Linux-mips-kernel] cvs remove

[James S. <jsi...@tr...>]

> I'm using the ev96100 board for some pci testing, so I'm doing some 
> general cleanup of that board.  I'll remove a couple of unneeded ev96100 
> files along the way. Is there going to be a problem when we sync up with 
>   Ralf if we remove files from the linux-mips tree?

Unneeded in that they are obsolute with the new code? Well I don't think
it will be problem unless it breaks other things.

Re: [Linux-mips-kernel] cvs remove

[James S. <jsi...@tr...>]

> Yes, and/or because it was not necessary to have code is all those files 
> to begin with.
> 
> > Well I don't think
> > it will be problem unless it breaks other things.
> 
> Nop, it's ev96100 only and I'll test it pretty well.

Then I haev no problem. Commit and delete what you need to.

Re: [Linux-mips-kernel] cvs remove

[Pete P. <pp...@pa...>]

James Simmons wrote:

>>I'm using the ev96100 board for some pci testing, so I'm doing some 
>>general cleanup of that board.  I'll remove a couple of unneeded ev96100 
>>files along the way. Is there going to be a problem when we sync up with 
>>  Ralf if we remove files from the linux-mips tree?
>>
> 
> Unneeded in that they are obsolute with the new code? 


Yes, and/or because it was not necessary to have code is all those files 
to begin with.

> Well I don't think
> it will be problem unless it breaks other things.


Nop, it's ev96100 only and I'll test it pretty well.

Pete

[Linux-mips-kernel] cvs remove

[Pete P. <pp...@pa...>]

I'm using the ev96100 board for some pci testing, so I'm doing some 
general cleanup of that board.  I'll remove a couple of unneeded ev96100 
files along the way. Is there going to be a problem when we sync up with 
  Ralf if we remove files from the linux-mips tree?

Pete

Re: [Linux-mips-kernel] helper script

[James S. <jsi...@tr...>]

> Nice work on the script. 

Here here!!

> Anyways, unless anyone has any issues with the patch, I'll shove it into
> CVS.

Please commit :-)