Status of 440GP port

Status of 440GP port

[Eugene Surovegin]

Hello all!

Could anyone (probably MontaVista guys) give some information on status of
IBM 440GP port?

I checked yesterday bk://ppc.bkserver.net/linuxppc_2_4_devel tree and found
some preparations for this port (e.g. 4xx->40x renaming).

I understand that this effort is under way for quite some time but not yet
released (or am I wrong?).

We already have 440GP hardware and I'm eager to test linux on it (even be
alpha/beta tester for this port).

Any info will be greatly appreciated.


  Eugene Surovegin <mailto:ebs@innocent.com>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[Matt Porter]

On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
>
> Hello all!
>
> Could anyone (probably MontaVista guys) give some information on status of
> IBM 440GP port?
>
> I checked yesterday bk://ppc.bkserver.net/linuxppc_2_4_devel tree and found
> some preparations for this port (e.g. 4xx->40x renaming).

There will be a few more preparation changes before the rest arrives.

> I understand that this effort is under way for quite some time but not yet
> released (or am I wrong?).

I wouldn't say it has been underway for "quite some time".  4-5 working
weeks is a short amount of development time for a new processor (at least
for me). :)

> We already have 440GP hardware and I'm eager to test linux on it (even be
> alpha/beta tester for this port).
>
> Any info will be greatly appreciated.

My showstopper list is down to a 1-2 entries.  When those are exhausted,
it will be available for use/testing.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[andrew may]

On Tue, Apr 02, 2002 at 02:18:45PM -0700, Matt Porter wrote:
>
> On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
> >
> > I checked yesterday bk://ppc.bkserver.net/linuxppc_2_4_devel tree and found
> > some preparations for this port (e.g. 4xx->40x renaming).
>
> There will be a few more preparation changes before the rest arrives.
>
> > I understand that this effort is under way for quite some time but not yet
> > released (or am I wrong?).
>
> I wouldn't say it has been underway for "quite some time".  4-5 working
> weeks is a short amount of development time for a new processor (at least
> for me). :)

So are you useing your own repository to track your development? It sure
doesn't seem like the 2_4_devel tree is a development tree anymore. And
seeing how hard it has become to get changes into the "devel" tree also
suggests that the tree is not really a development tree.

Any particular reason you are keeping things "close to your chest"? I know
it is nice to be able to go through and makes changes where ever you
like without having to be confronted with them every checkin/merge, but
since there are change that will at least change the file structure of
other boards it seems like it should be kept more in the open.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[Matt Porter]

On Tue, Apr 02, 2002 at 01:41:09PM -0800, andrew may wrote:
> On Tue, Apr 02, 2002 at 02:18:45PM -0700, Matt Porter wrote:
> >
> > On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
> > >
> > > I checked yesterday bk://ppc.bkserver.net/linuxppc_2_4_devel tree and found
> > > some preparations for this port (e.g. 4xx->40x renaming).
> >
> > There will be a few more preparation changes before the rest arrives.
> >
> > > I understand that this effort is under way for quite some time but not yet
> > > released (or am I wrong?).
> >
> > I wouldn't say it has been underway for "quite some time".  4-5 working
> > weeks is a short amount of development time for a new processor (at least
> > for me). :)
>
> So are you useing your own repository to track your development? It sure
> doesn't seem like the 2_4_devel tree is a development tree anymore. And
> seeing how hard it has become to get changes into the "devel" tree also
> suggests that the tree is not really a development tree.

Hrm.  I've simply not checked in any files to my local _devel clone.
Unlike other developers, I choose not to push in non-tested and/or
non-working bits.  I can't comment on your problems with getting
changes in the _devel tree since I've only recently started following
the 4xx conversations and have never been involved with 4xx until
a little while ago.

> Any particular reason you are keeping things "close to your chest"? I know
> it is nice to be able to go through and makes changes where ever you
> like without having to be confronted with them every checkin/merge, but
> since there are change that will at least change the file structure of
> other boards it seems like it should be kept more in the open.

The first pass of the core 440 support has no changes that affect the
file structure of other boards (assuming you are concerned about 40x).
Again, this is I how do _devel work...I code some logical set of
functionality (in this case core + onboard serial/emac), make sure it's
pretty enough that I'm not embarassed, and then I push it out.  I've
also been asked not to push until paulus is satisfied with the low-level
booke support.

In my years of contributing to Linux/PPC, this is the first time I've
had someone question how/when I contribute my work back.  I've always
pushed stuff out as soon as it makes sense.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[andrew may]

On Tue, Apr 02, 2002 at 03:21:47PM -0700, Matt Porter wrote:
> On Tue, Apr 02, 2002 at 01:41:09PM -0800, andrew may wrote:
> > On Tue, Apr 02, 2002 at 02:18:45PM -0700, Matt Porter wrote:
> > >
> > > On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
> > >
> > > I wouldn't say it has been underway for "quite some time".  4-5 working
> > > weeks is a short amount of development time for a new processor (at least
> > > for me). :)
> >
> > So are you useing your own repository to track your development? It sure
> > doesn't seem like the 2_4_devel tree is a development tree anymore. And
> > seeing how hard it has become to get changes into the "devel" tree also
> > suggests that the tree is not really a development tree.
>
> Hrm.  I've simply not checked in any files to my local _devel clone.
> Unlike other developers, I choose not to push in non-tested and/or
> non-working bits.  I can't comment on your problems with getting
> changes in the _devel tree since I've only recently started following
> the 4xx conversations and have never been involved with 4xx until
> a little while ago.

I would expect a development tree to contain non-working and non-tested
stuff. It becomes very help full to see things that get tried but don't
work in the history of a file. It makes a lot more sense to use the version
history to document quirks in hardware than to start putting comments in the
source on what does and doesn't work.

I would sure not want to work for 4-5 weeks between pushes. I like to be
able to make dangerous changes to code knowing that I can always fall back
to a few day older version that sort-of worked.

> > Any particular reason you are keeping things "close to your chest"? I know
> > it is nice to be able to go through and makes changes where ever you
> > like without having to be confronted with them every checkin/merge, but
> > since there are change that will at least change the file structure of
> > other boards it seems like it should be kept more in the open.
>
> The first pass of the core 440 support has no changes that affect the
> file structure of other boards (assuming you are concerned about 40x).
> Again, this is I how do _devel work...I code some logical set of
> functionality (in this case core + onboard serial/emac), make sure it's
> pretty enough that I'm not embarassed, and then I push it out.  I've
> also been asked not to push until paulus is satisfied with the low-level
> booke support.

I am sure most of us are understanding of potentially embarrassing code
and we may just lend a hand cleaning things up. It seems like a lot
of embarrassing code slips past people when it just works.

> In my years of contributing to Linux/PPC, this is the first time I've
> had someone question how/when I contribute my work back.  I've always
> pushed stuff out as soon as it makes sense.

It looks like Eugene wants to help try things out and he has hardware
and as long as you are the only one with the source he can either wait
or start redoing what you have already done.
In the past it may have been MVista got boards ahead of the rest of the
market, but it seems like the boards are hitting the rest of the world
the same time you get them. If some of those people with the boards
are capable of helping to bring them up or cleaning up the source (think
kernel janitors), then it starts to make sense to push stuff out as
soon as it is written.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[Matt Porter]

On Tue, Apr 02, 2002 at 02:54:00PM -0800, andrew may wrote:
> On Tue, Apr 02, 2002 at 03:21:47PM -0700, Matt Porter wrote:
> > On Tue, Apr 02, 2002 at 01:41:09PM -0800, andrew may wrote:
> > > On Tue, Apr 02, 2002 at 02:18:45PM -0700, Matt Porter wrote:
> > > >
> > > > On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
> > > >
> > > > I wouldn't say it has been underway for "quite some time".  4-5 working
> > > > weeks is a short amount of development time for a new processor (at least
> > > > for me). :)
> > >
> > > So are you useing your own repository to track your development? It sure
> > > doesn't seem like the 2_4_devel tree is a development tree anymore. And
> > > seeing how hard it has become to get changes into the "devel" tree also
> > > suggests that the tree is not really a development tree.
> >
> > Hrm.  I've simply not checked in any files to my local _devel clone.
> > Unlike other developers, I choose not to push in non-tested and/or
> > non-working bits.  I can't comment on your problems with getting
> > changes in the _devel tree since I've only recently started following
> > the 4xx conversations and have never been involved with 4xx until
> > a little while ago.
>
> I would expect a development tree to contain non-working and non-tested
> stuff. It becomes very help full to see things that get tried but don't
> work in the history of a file. It makes a lot more sense to use the version
> history to document quirks in hardware than to start putting comments in the
> source on what does and doesn't work.

So I don't use the tool the way you do.  That's the granularity I might
normally use for local checkins, but we've never really had that kind
of granularity on _devel pushes.  It's not used that way.

> I would sure not want to work for 4-5 weeks between pushes. I like to be
> able to make dangerous changes to code knowing that I can always fall back
> to a few day older version that sort-of worked.

Local backups, .origs, local checkins.  Again, different style of
development.  Luckily, nobody yet controls how develop on my own
machine.  4-5 weeks is just a one time initial seed of a starting
point.

> > > Any particular reason you are keeping things "close to your chest"? I know
> > > it is nice to be able to go through and makes changes where ever you
> > > like without having to be confronted with them every checkin/merge, but
> > > since there are change that will at least change the file structure of
> > > other boards it seems like it should be kept more in the open.
> >
> > The first pass of the core 440 support has no changes that affect the
> > file structure of other boards (assuming you are concerned about 40x).
> > Again, this is I how do _devel work...I code some logical set of
> > functionality (in this case core + onboard serial/emac), make sure it's
> > pretty enough that I'm not embarassed, and then I push it out.  I've
> > also been asked not to push until paulus is satisfied with the low-level
> > booke support.
>
> I am sure most of us are understanding of potentially embarrassing code
> and we may just lend a hand cleaning things up. It seems like a lot
> of embarrassing code slips past people when it just works.

It's actually more like FIXME reminders of hardcoded addresses and
stuff that would cause me too much time explaining to hoards of
people wanting a 440 port to play with.

> > In my years of contributing to Linux/PPC, this is the first time I've
> > had someone question how/when I contribute my work back.  I've always
> > pushed stuff out as soon as it makes sense.
>
> It looks like Eugene wants to help try things out and he has hardware
> and as long as you are the only one with the source he can either wait
> or start redoing what you have already done.

Those are the options.  I'll make it available when it makes sense
to open the floodgates of bug reports.

> In the past it may have been MVista got boards ahead of the rest of the
> market, but it seems like the boards are hitting the rest of the world
> the same time you get them. If some of those people with the boards
> are capable of helping to bring them up or cleaning up the source (think
> kernel janitors), then it starts to make sense to push stuff out as
> soon as it is written.

I'm looking forward to having lots of eyeballs on it...this is not a
new concept to me, thanks.

Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[Frank Rowand]

andrew may wrote:
>

< taken totally out of context >

> I would expect a development tree to contain non-working and non-tested
> stuff. It becomes very help full to see things that get tried but don't
> work in the history of a file. It makes a lot more sense to use the version
> history to document quirks in hardware than to start putting comments in the
> source on what does and doesn't work.

The version history does not seem to me a useful place to document quirks in
hardware.  The history is usually full of so much trivia that it is hard to
search.  The history also usually doesn't include much in the way of useful
information.  It seems to me that either the source, or the Documentation
directory is a good place to document quirks in hardware.

-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[Amit D. Chaudhary]

Hi,

After listening to the email thread so far, I have a rather simple
question, is there any difference current or planned between the bk
repositories?
linuxppc_2_4: the stable branch
linuxppc_2_4_devel: the stable branch testing tree

both seem to be based on 2.4.19-pre4.

Thanks
Amit

Frank Rowand wrote:
> andrew may wrote:
>
>
> < taken totally out of context >
>
>>I would expect a development tree to contain non-working and non-tested
>>stuff. It becomes very help full to see things that get tried but don't
>>work in the history of a file. It makes a lot more sense to use the version
>>history to document quirks in hardware than to start putting comments in the
>>source on what does and doesn't work.
>>
>
> The version history does not seem to me a useful place to document quirks in
> hardware.  The history is usually full of so much trivia that it is hard to
> search.  The history also usually doesn't include much in the way of useful
> information.  It seems to me that either the source, or the Documentation
> directory is a good place to document quirks in hardware.
>
> -Frank
> --
> Frank Rowand <frank_rowand@mvista.com>
> MontaVista Software, Inc
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Status of 440GP port

[andrew may]

On Tue, Apr 02, 2002 at 04:20:48PM -0700, Matt Porter wrote:
>
> On Tue, Apr 02, 2002 at 02:54:00PM -0800, andrew may wrote:
> > On Tue, Apr 02, 2002 at 03:21:47PM -0700, Matt Porter wrote:
> > > On Tue, Apr 02, 2002 at 01:41:09PM -0800, andrew may wrote:
> > > > On Tue, Apr 02, 2002 at 02:18:45PM -0700, Matt Porter wrote:
> > > > >
> > > > > On Tue, Apr 02, 2002 at 11:46:12AM -0800, Eugene Surovegin wrote:
> > > >
> > > > So are you useing your own repository to track your development? It sure
> > > > doesn't seem like the 2_4_devel tree is a development tree anymore. And

...

> So I don't use the tool the way you do.  That's the granularity I might
> normally use for local checkins, but we've never really had that kind
> of granularity on _devel pushes.  It's not used that way.

Well that would be my point, that _devel tree is not used for direct
development.

> > I would sure not want to work for 4-5 weeks between pushes. I like to be
> > able to make dangerous changes to code knowing that I can always fall back
> > to a few day older version that sort-of worked.
>
> Local backups, .origs, local checkins.  Again, different style of
> development.  Luckily, nobody yet controls how develop on my own
> machine.  4-5 weeks is just a one time initial seed of a starting
> point.

So that would be the answer to my first question of what you are useing
to track your own development. You didn't answer it the first time around
it would seem like you were using the _devl tree as your source control
method. I don't even use bitkeeper and I could care less if you did or not,
but I asked what you were using.

> Those are the options.  I'll make it available when it makes sense
> to open the floodgates of bug reports.

A bug report should never be written against a development tree. You can
always see a flood of problems on lkml, but most of them are just ignored
for being stupid user issues.

> I'm looking forward to having lots of eyeballs on it...this is not a
> new concept to me, thanks.

Well you seem to have the attitude that you are the only one that is
capable of working on things at the moment.

I would ask you to give some examples of people that are working on the Linux
kerenl that do 4-5 weeks of development without public review.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/