Re: Suggestions for how ARM Ltd could help Debian?
Wookey wrote:
Hello Wookey,
How about a master list of arm processors, the port location,
author/maintainer
toochain, peripherals supported, version of Linux kernel, device drivers
available, etc etc.
ALL specific to embedded linux ala-debian. That way somebody could
quickly research what ARM
chipsets to use for a new design, and the current state of the
Debian-ARM TOOLS.
I'm talking to a company right now about building an arm based router,
with embedded
DSU/CSU, and they are asking me which ARM chip I'd like on the board.
It's been almost a year since my last arm project, so I do not know who has
2.6 based kernels and tools. I did specifiy DEBIAN, because at the end of
the day, if I have to re-invent the wheel, It has to be DEBIAN....
That said I am frequently asked to be involved in ARM-DEBIAN decisions
by small embedded and manufacturing companies, because I have shown
some cool products in the past. HOWEVER, it is an uphill journey every
time. Most embedded vendors do not want to move to a 2.6 kernel base.
I'm very tired of proprietary embedded linux marketing. I think this is an
excellent place for ARM to set the standard, and what better platform
than DEBIAN..... It not that a vendor offeing embedded linux is a bad
idea, it's all of the crap that they inject, so as to make you think you
actually needs their confusion to be successful with embedded linux.
Many of us do not have to the ability to only work on embedded linux
or on a Debian development host. But, when we have a chance to
use that (optimal) platform, it needs to be quick for us to come up
to speed with the choices, the tool chains, and outsourcing options
( that is consulting dollars for persons who know this optimal platform
better than I do, so they can save my bacon for some quick cash!)
In my opinion this approach will put DEBIAN in the forefront
of embedded system development. I run my mouth quite a lot,
but, the problem is now they like what they here, and I struggle....
I'm evaluating a project for a company that uses a DSP bios
under "embedded linux". What a disaster, we reverse engineered
a phat-file system in a few hours for the DSP. The DSP vendor
could not even get phat-16 working. using their dsp-bios.
Why use there crap? 3 other device drivers were much simpler,
faster and less impact on the DSP, without their DSP-bios.
Similarly, embedded linux is being so infected by fortune 500
companies that it rediculous.....
James
+++ Adam C Powell IV [03-11-30 11:54 -0500]:
On Thu, 2003-11-27 at 13:07, Wookey wrote:
Just a side-note: mozilla still doesn't work properly, regxpcom and
regchrome segfault (see my 10/28 post for latest fix attempt details).
And there's a libc6/binutils/dpkg-shlibdeps bug preventing illuminator
from building (reported here 11/19, about to file a bug).
Ah OK, I hadn't properly appreciated that there were still hurdles.
Hmm -- which gets me thinking, should there be a clearinghouse of known
ARM-specific bugs? (Is there one already?) Then again, this might be
better done with BTS indexing, or tagging, or something like that.
I did set up an 'arm things that need doing' page at the now-defunct
armlinux.org, but it would be long out of date even if it was still there.
I grep the RC bugs list that get's posted weekly for 'arm' from time to
time, but something smarter than that would be useful. The problem with that
list is that there are lots of useful things that don't have much to do with
Debian itself so I'm not sure they belong in the Dewbian BTS (unsupported
architectures and hardware for example). Still such an index would be handy...
Otherwise, your wish-list looks good, can't think of anything else.
OK - thanx for the comments. I'll see what help is on offer/can be extracted.
Wookey
Reply to: