Subject: Embedded MIPS/Linux Needs

From: "Kevin D. Kissell" <[email-masked]>
Date: Thu, 22 Mar 2001 12:48:19 +0100

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.

---

From: "Jay Carlson" <[email-masked]>
Date: Thu, 22 Mar 2001 09:01:47 -0500

Disclaimer: I'm just a hobbyist.

> like the FPU emulator, etc.

Yes, and this is quite useful!

> 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

---

From: Mike McDonald <[email-masked]>
Date: Thu, 22 Mar 2001 06:17:28 -0800

>From: "Kevin D. Kissell" <[email-masked]>
>To: <[email-masked]>
>Subject: Embedded MIPS/Linux Needs
>Date: Thu, 22 Mar 2001 12:48:19 +0100

>be your prioritized "wish list"?

  A bootloader that runs under WinCE 3.0!

  Mike McDonald
  [email-masked]

---

From: Jeff Harrell <[email-masked]>
Date: Thu, 22 Mar 2001 11:23:10 -0700

> 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.

> 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

>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
[email-masked]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Jun Sun <[email-masked]>
Date: Thu, 22 Mar 2001 10:32:25 -0800

> Disclaimer: I'm just a hobbyist.

Disclaimer: I am an MontaVista employee, but as always, this email only
represents my own opinion. :-)
 
> 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

---

From: Joe deBlaquiere <[email-masked]>
Date: Sun, 25 Mar 2001 21:01:52 -0600

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.

> 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.

> 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

---

From: Keith Owens <[email-masked]>
Date: Mon, 26 Mar 2001 13:23:15 +1000

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

On Sun, 25 Mar 2001 21:01:52 -0600, 
Joe deBlaquiere <[email-masked]> 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.

---

From: Keith M Wesolowski <[email-masked]>
Date: Sun, 25 Mar 2001 20:06:42 -0800

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

> 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 <[email-masked]> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
"I should have crushed his marketing-addled skull with a fucking bat."

---

From: Florian Lohoff <[email-masked]>
Date: Mon, 26 Mar 2001 19:25:59 +0200

On Sun, Mar 25, 2001 at 09:01:52PM -0600, Joe deBlaquiere wrote:
> 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                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: Joe deBlaquiere <[email-masked]>
Date: Mon, 26 Mar 2001 12:47:49 -0600

> a little and big endian kernel coexist in the same object or at least

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.

> which could be made cleanly. (Dont integrate all TX39 archs into one

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.

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

---

From: Jun Sun <[email-masked]>
Date: Mon, 26 Mar 2001 15:24:11 -0800

> 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 cle…

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