Embedded MIPS/Linux Needs

Embedded MIPS/Linux Needs

[Kevin D. Kissell]

Here at MIPS Technologies, we use Linux internally
for design verification, experiments, benchmarking,
etc., and as a consequence Carsten Langgaard and
myself have both been active in this forum, and have
tried to help the general Linux/MIPS community as
best we can with the limited time that we can dedicate
to the problem, in terms of suggested patches, bug
fixes, cleanups, integration of needed components
like the FPU emulator, etc.

I have a question for those of you who are doing
Linux work for *new* platforms (as opposed to the
SGI/DEC legacy box support people).  IF, and I
emphasize the word *if*, MIPS Technologies were
make a bigger investment in MIPS/Linux technology,
be it kernel enhancements, cross/native tools,
userland ports, libraries, or whatever, what would
be your prioritized "wish list"?

Feel free to respond by point-to-point email, though
responses that are also copied to the mailing list
might provoke some interesting and enlightening
debate.

            Regards,

            Kevin K.

Embedded MIPS/Linux Needs

[Kevin D. Kissell]

Here at MIPS Technologies, we use Linux internally
for design verification, experiments, benchmarking,
etc., and as a consequence Carsten Langgaard and
myself have both been active in this forum, and have
tried to help the general Linux/MIPS community as
best we can with the limited time that we can dedicate
to the problem, in terms of suggested patches, bug
fixes, cleanups, integration of needed components
like the FPU emulator, etc.

I have a question for those of you who are doing
Linux work for *new* platforms (as opposed to the
SGI/DEC legacy box support people).  IF, and I
emphasize the word *if*, MIPS Technologies were
make a bigger investment in MIPS/Linux technology,
be it kernel enhancements, cross/native tools,
userland ports, libraries, or whatever, what would
be your prioritized "wish list"?

Feel free to respond by point-to-point email, though
responses that are also copied to the mailing list
might provoke some interesting and enlightening
debate.

            Regards,

            Kevin K.

RE: Embedded MIPS/Linux Needs

[Jay Carlson]

Disclaimer: I'm just a hobbyist.

Kevin D. Kissell writes:

> Here at MIPS Technologies, we use Linux internally
> for design verification, experiments, benchmarking,
> etc., and as a consequence Carsten Langgaard and
> myself have both been active in this forum, and have
> tried to help the general Linux/MIPS community as
> best we can with the limited time that we can dedicate
> to the problem, in terms of suggested patches, bug
> fixes, cleanups, integration of needed components
> like the FPU emulator, etc.

Yes, and this is quite useful!

> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?

Some of these things can reasonably be done by third parties.  For instance,
mvista's in the business of nailing down particular toolchain versions and
doing relevant ports.  These days I'm mostly userland, so I get to assume
that working kernels are and will continue to be emitted from the smart
people on this list too :-)

My pet issue is code density and compiler quality.  I think it's in MIPS's
best interest to provide a really good compiler for their products, and I
think gcc does a good job for traditional embedded MIPS systems.  But the
gcc/gas-generated code for the SVR4 ABI is pretty bad, especially for the
low-end devices.  snow (see previous message) shows how much room for
improvement there is.

Individual embedded Linux companies don't have much motivation to attack
this problem alone, as it looks like it could involve extensive gcc hacking.
If a particular customer looks like they have code density issues, it'd be
easier for embedded linux companies to just recommend, say, ARM.  MIPS
Technologies on the other hand carries the banner for all devices licensing
their architecture, and any toolchain work may result in greater demand for
their own cores and licensee products.

ARM and Cygnus recently contributed a gcc ARM backend rewrite.  That's what
got me thinking about this.

Jay

RE: Embedded MIPS/Linux Needs

[Jay Carlson]

Disclaimer: I'm just a hobbyist.

Kevin D. Kissell writes:

> Here at MIPS Technologies, we use Linux internally
> for design verification, experiments, benchmarking,
> etc., and as a consequence Carsten Langgaard and
> myself have both been active in this forum, and have
> tried to help the general Linux/MIPS community as
> best we can with the limited time that we can dedicate
> to the problem, in terms of suggested patches, bug
> fixes, cleanups, integration of needed components
> like the FPU emulator, etc.

Yes, and this is quite useful!

> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?

Some of these things can reasonably be done by third parties.  For instance,
mvista's in the business of nailing down particular toolchain versions and
doing relevant ports.  These days I'm mostly userland, so I get to assume
that working kernels are and will continue to be emitted from the smart
people on this list too :-)

My pet issue is code density and compiler quality.  I think it's in MIPS's
best interest to provide a really good compiler for their products, and I
think gcc does a good job for traditional embedded MIPS systems.  But the
gcc/gas-generated code for the SVR4 ABI is pretty bad, especially for the
low-end devices.  snow (see previous message) shows how much room for
improvement there is.

Individual embedded Linux companies don't have much motivation to attack
this problem alone, as it looks like it could involve extensive gcc hacking.
If a particular customer looks like they have code density issues, it'd be
easier for embedded linux companies to just recommend, say, ARM.  MIPS
Technologies on the other hand carries the banner for all devices licensing
their architecture, and any toolchain work may result in greater demand for
their own cores and licensee products.

ARM and Cygnus recently contributed a gcc ARM backend rewrite.  That's what
got me thinking about this.

Jay

Re: Embedded MIPS/Linux Needs

[Jun Sun]

Jay Carlson wrote:
> 
> Disclaimer: I'm just a hobbyist.
>

Disclaimer: I am an MontaVista employee, but as always, this email only
represents my own opinion. :-)
 
> Kevin D. Kissell writes:
> 
> 
> Individual embedded Linux companies don't have much motivation to attack
> this problem alone, as it looks like it could involve extensive gcc hacking.
> If a particular customer looks like they have code density issues, it'd be
> easier for embedded linux companies to just recommend, say, ARM.  MIPS
> Technologies on the other hand carries the banner for all devices licensing
> their architecture, and any toolchain work may result in greater demand for
> their own cores and licensee products.
>

I agree.  Toolchain is the first step in the food chain.  It makes most sense
for MTI to invest in it and to make it better.  All companies that I heard of
switching from MIPS to PPC are due to toolchain (including debuggers). 
Sometimes it even has nothing to do with Linux.

I think kernel also needs improvement in terms of board/machine support.  I
wrote an email long time ago talking about introducing a board support
structure.  I predicted we would see 20 new MIPS boards added this year and
100 more down the road.  Apparently a better structure needs to be in place to
accomdate the growth. It will certainly make future porting much easier too.

While some of the improvement can be done incrementally (like time.c mess
clean-up), some (like irq, PCI?) is probably best to be done just in one shot.

Jun

Re: Embedded MIPS/Linux Needs

[Mike McDonald]

>From: "Kevin D. Kissell" <kevink@mips.com>
>To: <linux-mips@oss.sgi.com>
>Subject: Embedded MIPS/Linux Needs
>Date: Thu, 22 Mar 2001 12:48:19 +0100

>I have a question for those of you who are doing
>Linux work for *new* platforms (as opposed to the
>SGI/DEC legacy box support people).  IF, and I
>emphasize the word *if*, MIPS Technologies were
>make a bigger investment in MIPS/Linux technology,
>be it kernel enhancements, cross/native tools,
>userland ports, libraries, or whatever, what would
>be your prioritized "wish list"?

  A bootloader that runs under WinCE 3.0!

  Mike McDonald
  mikemac@mikemac.com

Re: Embedded MIPS/Linux Needs

[Jeff Harrell]

[-- Attachment #1.1: Type: text/plain, Size: 2318 bytes --]

"Kevin D. Kissell" wrote:

> Here at MIPS Technologies, we use Linux internally
> for design verification, experiments, benchmarking,
> etc., and as a consequence Carsten Langgaard and
> myself have both been active in this forum, and have
> tried to help the general Linux/MIPS community as
> best we can with the limited time that we can dedicate
> to the problem, in terms of suggested patches, bug
> fixes, cleanups, integration of needed components
> like the FPU emulator, etc.
>

I think that  one of the larger hurdles that we have had
to overcome is a common set of tools that can build a current
kernel and userland application set from a cross-developed
environment.  There seems to have been a
divergence between kernel tools and userland tools specifically in
the area of recent kernel 2.4.x and GLIBC 2.2.x that is a major
headache for delivering a toolchain that is on par with the
intel equivalent designs.  It is tough to offer a linux design that
requires multiple toolchains one to build the kernel, one to build
userland apps.


>
> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?
>

    1. A toolchain that will build 2.4.x version of the kernel as well
        as GLIBC 2.2 dependent applications.  Preferrably this would
        be a cross-development environment.  (This would require
         GLIBC 2.2 accessable as a cross-compiled environment

    2.  Userland app ports


>
> Feel free to respond by point-to-point email, though
> responses that are also copied to the mailing list
> might provoke some interesting and enlightening
> debate.
>
>             Regards,
>
>             Kevin K.

>From past experience it's easy to see that without a
solid set of development tools, it is hard to justify using
a particular CPU or hardware.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell                    Work:  (801) 619-6104
Broadband Access group/TI
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



[-- Attachment #1.2: Type: text/html, Size: 3127 bytes --]

[-- Attachment #2: Card for Jeff Harrell --]
[-- Type: text/x-vcard, Size: 376 bytes --]

begin:vcard 
n:Harrell;Jeff
tel;cell:(801) 597-6268
tel;fax:(801) 619-6150
tel;work:(801) 619-6104
x-mozilla-html:TRUE
url:http://www.ti.com
org:Broadband Access Group
version:2.1
email;internet:jharrell@ti.com
title:Texas Instruments
adr;quoted-printable:;;170 West Election Rd. Suite 100	=0D=0AMS 4106		;Draper;Utah;84020-6410;USA
x-mozilla-cpt:;0
fn:Jeff Harrell
end:vcard

Re: Embedded MIPS/Linux Needs

[Jeff Harrell]

[-- Attachment #1.1: Type: text/plain, Size: 2317 bytes --]

"Kevin D. Kissell" wrote:

> Here at MIPS Technologies, we use Linux internally
> for design verification, experiments, benchmarking,
> etc., and as a consequence Carsten Langgaard and
> myself have both been active in this forum, and have
> tried to help the general Linux/MIPS community as
> best we can with the limited time that we can dedicate
> to the problem, in terms of suggested patches, bug
> fixes, cleanups, integration of needed components
> like the FPU emulator, etc.
>

I think that  one of the larger hurdles that we have had
to overcome is a common set of tools that can build a current
kernel and userland application set from a cross-developed
environment.  There seems to have been a
divergence between kernel tools and userland tools specifically in
the area of recent kernel 2.4.x and GLIBC 2.2.x that is a major
headache for delivering a toolchain that is on par with the
intel equivalent designs.  It is tough to offer a linux design that
requires multiple toolchains one to build the kernel, one to build
userland apps.


>
> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?
>

    1. A toolchain that will build 2.4.x version of the kernel as well
        as GLIBC 2.2 dependent applications.  Preferrably this would
        be a cross-development environment.  (This would require
         GLIBC 2.2 accessable as a cross-compiled environment

    2.  Userland app ports


>
> Feel free to respond by point-to-point email, though
> responses that are also copied to the mailing list
> might provoke some interesting and enlightening
> debate.
>
>             Regards,
>
>             Kevin K.

From past experience it's easy to see that without a
solid set of development tools, it is hard to justify using
a particular CPU or hardware.



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell                    Work:  (801) 619-6104
Broadband Access group/TI
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



[-- Attachment #1.2: Type: text/html, Size: 3127 bytes --]

[-- Attachment #2: Card for Jeff Harrell --]
[-- Type: text/x-vcard, Size: 376 bytes --]

begin:vcard 
n:Harrell;Jeff
tel;cell:(801) 597-6268
tel;fax:(801) 619-6150
tel;work:(801) 619-6104
x-mozilla-html:TRUE
url:http://www.ti.com
org:Broadband Access Group
version:2.1
email;internet:jharrell@ti.com
title:Texas Instruments
adr;quoted-printable:;;170 West Election Rd. Suite 100	=0D=0AMS 4106		;Draper;Utah;84020-6410;USA
x-mozilla-cpt:;0
fn:Jeff Harrell
end:vcard

Re: Embedded MIPS/Linux Needs

[Joe deBlaquiere]

Hi Kevin,

	It's Sunday night, and I always have screwy suggestions for the world at 
the end of the weekend, so bear with me...

	And as another worthy collegue noted, these opinions are mine and do not 
necesarily represent the stance of my company.

Kevin D. Kissell wrote:

> Here at MIPS Technologies, we use Linux internally
> for design verification, experiments, benchmarking,
> etc., and as a consequence Carsten Langgaard and
> myself have both been active in this forum, and have
> tried to help the general Linux/MIPS community as
> best we can with the limited time that we can dedicate
> to the problem, in terms of suggested patches, bug
> fixes, cleanups, integration of needed components
> like the FPU emulator, etc.
> 

	I have to say that the answers I've gotten on MIPS issues on this list has been exceptionally good, both from the MIPS team and the various other individuals.

> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?
> 

Just some unsorted random ideas:

1. Would it be possible to lump some of the different MIPS variants together more closely? In my dream world I could build one kernel that would boot on every mips architecture. This way the work can be more general. As it stands now, if you want Tx39 or Vr41 variants you're working out of a different tree. With the number of SoC core products coming out at present, this predicament is only likely to get more serious. I know at one point in time you could boot a single ARM kernel on several different systems and it would adapt it's processor specifics at runtime. Such a design might help to bring the MIPS world together a bit.

2. Tools are always an issue, but as long as new cores keep coming along that have exceptions and additions to the ISA(s), it's going to be good business for gcc engineers... 

3. Using glibc in a cross development environment is slightly painful at this time for all architectures. MIPS is no different. Some general work on glibc would be good for the whole world. There has also been some work on other libraries (newlib and uClibc) for especially constrained environments. No MIPS/Linux support is available for either.

4. uClinux support for the systems without MMUs. There is considerable interest in this effort, but I think many people underestimate the magnitude of effort that will be required to have a truly solid port. This effort might be daunting for any one vendor, but could benefit all.

-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9257
fax   : (256)-837-3839

Re: Embedded MIPS/Linux Needs

[Keith Owens]

You like long lines, don't you ;)  Reflowed for readability.

On Sun, 25 Mar 2001 21:01:52 -0600, 
Joe deBlaquiere <jadb@redhat.com> wrote:
>1. Would it be possible to lump some of the different MIPS variants
>together more closely? In my dream world I could build one kernel that
>would boot on every mips architecture. This way the work can be more
>general. As it stands now, if you want Tx39 or Vr41 variants you're
>working out of a different tree.

FWIW I am working on a Makefile rewrite for 2.5 which will help with
this problem.  Instead of one 120Mb kernel source tree for each
architecture, 2.5 will support logical kernel source trees and separate
source and object directories.  The logical source is built up from
base kernel code (Linus's tarball) plus zero or more layers that
contain additional or different code.  So you compile

2.4.x -> ix86 object directory
2.4.x + common mips -> common mips object directory
2.4.x + common mips + Tx39 -> Tx39 object directory
2.4.x + common mips + Vr41 -> Vr41 object directory

All use the same untouched 2.4.x tarball as the base.  You can compile
multiple targets from the same source at the same time, using different
object directories.  A change to base 2.4.x or to common mips is
automatically seen by all the object directories.

Re: Embedded MIPS/Linux Needs

[Keith M Wesolowski]

On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote:

> 1. Would it be possible to lump some of the different MIPS variants
> together more closely? In my dream world I could build one kernel
> that would boot on every mips architecture. This way the work can be
> more general. As it stands now, if you want Tx39 or Vr41 variants
> you're working out of a different tree. With the number of SoC core
> products coming out at present, this predicament is only likely to
> get more serious. I know at one point in time you could boot a
> single ARM kernel on several different systems and it would adapt
> it's processor specifics at runtime. Such a design might help to
> bring the MIPS world together a bit.

I'm about 2/3 of the way through writing a patch that will bring
boot-time machine detection and parameters to mips - this is similar
to a scheme that was suggested some time ago by Jun and is also based
on a short discussion I had with Ralf about cleaning up proc.c.

This is only the first step, though, as there are a lot of ifdefs in
headers and such.  I will release this patch for review sometime in
the next week.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
"I should have crushed his marketing-addled skull with a fucking bat."

Re: Embedded MIPS/Linux Needs

[Florian Lohoff]

On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote:
> Just some unsorted random ideas:
> 
> 1. Would it be possible to lump some of the different MIPS variants
> together more closely? In my dream world I could build one kernel that
> would boot on every mips architecture. This way the work can be more
> general. As it stands now, if you want Tx39 or Vr41 variants you're
> working out of a different tree. With the number of SoC core products
> coming out at present, this predicament is only likely to get more
> serious. I know at one point in time you could boot a single ARM kernel on
> several different systems and it would adapt it's processor specifics at
> runtime. Such a design might help to bring the MIPS world together a bit.

There is at least a problem with endianess - I dont think there can be
a little and big endian kernel coexist in the same object or at least
not with major rework.

Why would you suggest having vr41 and TX39 in a seperat tree ? I had a
look in the linux-vr tree and i dont like some of their #ifdef spaghetti
stuff so i am currently working on TX39 stuff on top of the oss tree
which could be made cleanly. (Dont integrate all TX39 archs into one
subarch *grrr*)

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Embedded MIPS/Linux Needs

[Joe deBlaquiere]

Florian Lohoff wrote:

> On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote:
> 
>> Just some unsorted random ideas:
>> 
>> 1. Would it be possible to lump some of the different MIPS variants
>> together more closely? In my dream world I could build one kernel that
>> would boot on every mips architecture. This way the work can be more
>> general. As it stands now, if you want Tx39 or Vr41 variants you're
>> working out of a different tree. With the number of SoC core products
>> coming out at present, this predicament is only likely to get more
>> serious. I know at one point in time you could boot a single ARM kernel on
>> several different systems and it would adapt it's processor specifics at
>> runtime. Such a design might help to bring the MIPS world together a bit.
> 
> 
> There is at least a problem with endianess - I dont think there can be
> a little and big endian kernel coexist in the same object or at least
> not with major rework.
> 

Well, yes that would be a problem, but at least within endianess, there's no reason why the processor specific stuff can't be abstracted and attached at runtime.

> Why would you suggest having vr41 and TX39 in a seperat tree ? I had a
> look in the linux-vr tree and i dont like some of their #ifdef spaghetti
> stuff so i am currently working on TX39 stuff on top of the oss tree
> which could be made cleanly. (Dont integrate all TX39 archs into one
> subarch *grrr*)
> 

It's kinda ugly, but some of that is that the original architecture didn't scale to having many different target platforms. I think a little sane multi-platform infrastructure would make things cleaner and better in the future.

> Flo


-- 
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax   : (256)-837-3839

Re: Embedded MIPS/Linux Needs

[Jun Sun]

Joe deBlaquiere wrote:

> > Why would you suggest having vr41 and TX39 in a seperat tree ? I had a
> > look in the linux-vr tree and i dont like some of their #ifdef spaghetti
> > stuff so i am currently working on TX39 stuff on top of the oss tree
> > which could be made cleanly. (Dont integrate all TX39 archs into one
> > subarch *grrr*)
> >
> 
> It's kinda ugly, but some of that is that the original architecture didn't scale to having many different target platforms. I think a little sane multi-platform infrastructure would make things cleaner and better in the future.
> 

I was trying to move Vr41xx from linux-vr to oss tree and found a couple of
problems.  The most serious one that is that NEC Vr41xx TLB entry format is
slightly different from all other R4K-compatible CPUs.  Fixing this requires
either an ugly #ifdef in some common header files, or massively code
re-writing for all TLB related stuff.  Neither one is good.

I actually worked out a patch based on #ifdef approach, but a little too
"shameful" to submit it.  My feeling is that we need to separate TLB code from
cache code and introduce some way to plug in different TLB codes.  Then we can
get V41xx integrated nicely.

Jun

RE: Embedded MIPS/Linux Needs

[Phil Thompson]

I'm just starting out on this path, so my priorities might be off...

1. Packaging of a "stable" cross-development kit, including kernel,
toolchain and any other useful utilities. Saves me the time of assembling
the pieces myself and saves me asking questions about problems that were
fixed months ago. I know other companies provide this but I have yet to
evaluate them.

2. Provision of a framework (which may already be in place - I haven't got
that far yet) that provides me with a tick-list of hardware blocks that I
may need to provide code for to support my particular board, and to be
structured so that (as far as possible) I am adding files to the tree rather
than modifying them. The framework to be arranged so that I can do it
incrementally.

3. Support - not just for the development kit, but also as a source of
experience and suggestions for porting to new boards.

4. Work with chip manufacturers who are slow to provide Linux drivers.
Reference (rather than production quality) drivers would be better than
nothing. This is obviously not a MIPS specific issue.

Phil

-----Original Message-----
From: Kevin D. Kissell [mailto:kevink@mips.com]
Sent: 22 March 2001 11:48
To: linux-mips@oss.sgi.com
Subject: Embedded MIPS/Linux Needs


Here at MIPS Technologies, we use Linux internally
for design verification, experiments, benchmarking,
etc., and as a consequence Carsten Langgaard and
myself have both been active in this forum, and have
tried to help the general Linux/MIPS community as
best we can with the limited time that we can dedicate
to the problem, in terms of suggested patches, bug
fixes, cleanups, integration of needed components
like the FPU emulator, etc.

I have a question for those of you who are doing
Linux work for *new* platforms (as opposed to the
SGI/DEC legacy box support people).  IF, and I
emphasize the word *if*, MIPS Technologies were
make a bigger investment in MIPS/Linux technology,
be it kernel enhancements, cross/native tools,
userland ports, libraries, or whatever, what would
be your prioritized "wish list"?

Feel free to respond by point-to-point email, though
responses that are also copied to the mailing list
might provoke some interesting and enlightening
debate.

            Regards,

            Kevin K.

Re: Embedded MIPS/Linux Needs

[Justin Carlson]

On Thu, 22 Mar 2001, you wrote:

> I have a question for those of you who are doing
> Linux work for *new* platforms (as opposed to the
> SGI/DEC legacy box support people).  IF, and I
> emphasize the word *if*, MIPS Technologies were
> make a bigger investment in MIPS/Linux technology,
> be it kernel enhancements, cross/native tools,
> userland ports, libraries, or whatever, what would
> be your prioritized "wish list"?

1)  n64 support in the full current gnu toolchain 
2)  n64 support in the full current gnu toolchain. 
3)  n64...

I, of course, hold no biases whatsoever.  ;)

-Justin

Re: Embedded MIPS/Linux Needs

[nick]

I'd like to modify a couple of those requests...
1) Working 64bit support in the current gnu toolchain
.
.
.

<Grin>
	Nick
(It sorta produces useable code... usually..... on tuesdays... if it's a
blue moon)

On Thu, 22 Mar 2001, Justin Carlson wrote:

> On Thu, 22 Mar 2001, you wrote:
> 
> > I have a question for those of you who are doing
> > Linux work for *new* platforms (as opposed to the
> > SGI/DEC legacy box support people).  IF, and I
> > emphasize the word *if*, MIPS Technologies were
> > make a bigger investment in MIPS/Linux technology,
> > be it kernel enhancements, cross/native tools,
> > userland ports, libraries, or whatever, what would
> > be your prioritized "wish list"?
> 
> 1)  n64 support in the full current gnu toolchain 
> 2)  n64 support in the full current gnu toolchain. 
> 3)  n64...
> 
> I, of course, hold no biases whatsoever.  ;)
> 
> -Justin
> 

Re: Embedded MIPS/Linux Needs

[Keith M Wesolowski]

On Thu, Mar 22, 2001 at 02:03:43PM -0500, nick@snowman.net wrote:

> (It sorta produces useable code... usually..... on tuesdays... if it's a
> blue moon)

gcc 3.0 for mips64 requires hacks to even accept the arguments the
kernel compile wants to give, and even then it reliably produces
extremely incorrect code.  For example:

int i = 0;
prom_printf ("%d", i);

Might yield something like

-14777223

- basically, anything but 0.  The code that causes this is horribly
wrong that it wasn't even worth looking at.  There are all sorts of
similar, related, and dissimilar problems.

On the other hand, the same compiler for mips (not 64) reliably
produces working 2.4 kernels...

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
"I should have crushed his marketing-addled skull with a fucking bat."