[uClinux-dev] Adding new board support [& other questions]

Tom Walsh tom at cyberiansoftware.com
Fri Nov 16 12:03:46 EST 2001


Bruce Paterson wrote:
> 
> Tom Walsh wrote:
> >
> > Bruce Paterson wrote:
> > >
> > > Tom Walsh wrote:
> 

Hello Bruce,

First of all, let me apologize for the tone of the reply, you deserved
more respect.  I was having a bad day and really should have been more
carefull in the wording.

Yes, the state of affairs with uClinux is pretty bad right now.  The
"official" website has very little information on it that would help
someone who is just starting out with uClinux.  There is an alternate
site, not "officially" sponsored, but Erwin Authried has devoted a lot
of time in collecting together information about uClinux.  His site is
at: http://uClinux.home.at

The current distro, done by Greg Ungerer, is a quantum leap above what
we had been working with before.  The distro is well put together of
apps, and kernels (2.0 & 2.4) that work together.  Before Greg started
issuing these distros, we had a hodge-podge of libraries and apps that
were problematic to use.

Porting to a new platform is not documented (AFAIK), but is relatively
easy.  One of the first platforms to use uClinux was the uCsimm.  When I
ported uClinux to my M68EZ328 platform, I simply did a:

find . -type f | xargs fgrep -l CONFIG_UCSIMM

in the root of the uClinux kernel source tree.  This gave me a list of
files to consider as to what changes I had to make for my platform (then
the CONFIG_EZ328SIMM).  I then edited the files, found the conditionals
for UCSIMM and added my own conditionals as needed.  The crt0.S (system
kernel startup) is the one file you will have to write to match your
platform (hardware initialization, placing the .bss, .text, and .data
sections into their proper place in RAM).  The adjustments / additions
made to the kernel source are  relatively minor and is just to map your
RAM to the kernel resources (memory management and romfs location).

There is a lot of information scattered around the net (most of it still
inside people's heads :-) and the list server is the best place to get
started collecting info to launch your project.  There are a number of
development boards supported by uClinux and it may be useful to you to
purchase one of them to tinker with it?

I hope that I have been more helpfull this time...

Regards,

TomW


> I'm sorry, but that really didn't help me much at all. You are correct,
> however, that
> I did not make my questions specific enough.
> I am only a "newbie" with respect to uClinux. I have a large amount of
> embedded experience
> and unix systems development, including Linux.
> 
> > You have to be able to read the contents of Makefile rules to see how
> 
> Yes I can do this. The Makefile system for uClinux is rather extensive,
> however,
> with many layers of Makefiles so this isn't a trivial task unless you
> already have
> a general knowledge of the make layout. I have found the Vendor area in
> the main
> Makefile now, however, and a Readme I'd missed before.
> 
> > > Are there any leads somewhere of what versions of an application have
> > > different
> > > characteristics ? eg. boa Vs httpd Vs httpd-tiny Vs ... sash Vs ash Vs
> > > bash Vs hash etc.
> > > snmpd Vs cmu-snmpd and so on.
> 
> > Agreed, for a really new nebie something like 'chroot' is a puzzle:
> > "what the heck is 'chroot'?", but to someone that has been using Linux
> 
> I can only assume from your reply the answer the to my question "Are
> there
> any leads ?" is No. Therefore I will try to craft up some specific
> questions
> about each instance. I was hoping there might be something other than
> the
> code itself where I might be able to gain some more knowledge so I can
> ask
> less vague questions. I even know what "chroot" is, but I don't think
> it's
> going to help me.
> 
> > > It would certainly help if every module had a footprint size (rom & ram)
> > > and an
> > > indicator of functionality (maybe peg standard linux distribution
> > > versions as 100%)
> > > and what important stuff might be missing. Some of the descriptions are
> > > better than
> > > others. Some have none. It would actually be better if one person (who
> > > didn't develop
> > > any of the options) were to rate all the options in a class.
> > > Of course I can suck it and see, but this would take a age, and I'm sure
> > > others
> > > have been down this path already.
> >
> > Systems' Engineering has never been a "push the button" environment...
> > If you think it is, you have been badly informed!  Systems' Engineering
> 
> I can only assume you've had a bad day or something. It was only a
> suggestion
> as a nice thing to aim towards. I can't see what is wrong with
> suggesting
> something like this, especially as I'm going through that learning curve
> stage it is easy to dismiss and forget about. I am not fan of obsurity
> for obsurities sake.
> 
> > is a discipline that few people are capable of doing, some do
> > engineering, others are mechanics that follow those that can do it..
> >
> > Typically, engineers have a lot of trouble lowering themselves down to
> > the level of competance (incompetance?) that end-(l)users have.  It has
> 
> I'm not entirely sure how to take all that.
> 
> > been 24+ years since I wrapped my mind around my first systems' design,
> > a Z80 + 16K of DRAM, since then, I have designed a lot of stuff
> 
> Look I'm still using a Z80 embedded system in an RDF application. I've
> seen
> no reason to change it. Unfortunately it doesn't help me choose which
> uClinux application varient is better in the absence of information.
> In terms of uClinux I am a complete newbie (about 2 weeks), and I
> reserve
> the right to ask stupid newbie questions :-)
> 
> > (hardware & software), I do not remember what it was like to be a
> > newbie.  I cannot fathom just what concepts a newbie understands and
> > what they don't know!  The concepts that I work with today are such that
> 
> Which is why I'm telling you. It might help other newbies after me. We
> *do* want as large a user base of uClinux as possible, surely ?
> 
> > I find the average electronics technician has trouble understanding the
> > basics.
> >
> > The trouble with Linux (and uClinux) is that this stuff is evolving so
> > rapidly that no-one has the time to document stuff.  By the time you
> > write the stuff down, it changes, and the document is no longer valid!
> 
> Putting on my team leader hat; this is a very poor reason for not
> documenting.
> I have heard it before. Old doco can be misleading at times (such as the
> FAQ at
> uclinux.org) but it is better than no doco. Sometimes the mistake is to
> make
> the doco too specific, another is to write it and hide it somewhere
> no-one
> will think of looking. One small piece of doco that a newbie can find
> could
> ultimately save hours in answering bewildered mailing-list questioners.
> 
> Commercially available o/s options are rarely better in the doco
> department.
> They also have mailing lists filled with "stupid" newbies like me.
> They're even worse because you can't even resort to looking at the
> source.
> 
> > > I started adding MK48T08 real time clock support to the clock module in
> > > userland (cvs), but
> > > after seeing the vendor-config also found rtc-ds1302 & rtc-m42t11
> > > directories that use
> > > /dev/rtc (?). The mk48t08 is parallel rather than serial, but at the end
> > > of the day needs all
> > > the same BCD<->BINARY conversions. I'm confused now !  How should I be
> > > proceeding ?
> >
> > Exactly how the rest of us have done it: make some assumptions as to how
> > things work, dive in and start to craft a software system to meet your
> > needs, ask questions like "I tried to do this (detailed example), but,
> > this shit happens, what did I not understand?".  The worst question in
> 
> I went in and did a module as I thought seemed reasonable given what I
> found.
> I now suspect I was wasting my time because there is a new and better
> way to
> do it. Is it so unreasonable to ask what this new approach is before I
> leap in again ?
> 
> > the world is the one that simply wants to know "how can I do this",
> > instead of asking "what was it that I didn't understand".
> 
> I think it's a damm good idea to ask first, just in case someone has
> already
> done it, or be working on it already. Why re-invent the wheel over and
> over ?
> "We don't have time to do it right the first time, but always time to do
> it
> over and over and over again" :-((
> 
> Cheers,
> Bruce
> -------------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> intended
> solely for the use of the individual or entity to whom they are
> addressed.
> If you have received this email in error please notify the system
> manager.
> 
>     /\\\/\\\/\\\    /   /    Bruce Paterson          VK3TJN
>    /  \\\ \\\ \\\  /   /     Senior Design Engineer
>   /   /\\\/\\\/\\\/   /      87 Peters Ave, Mulgrave, Vic, 3170
>  /   /  \\\ \\\ \\\  /       PO Box 4112, Mulgrave, Vic, 3170, AUSTRALIA
> /   /    \\\/\\\ \\\/        Ph: +61 3 8561 4232  Fax: +61 3 9560 9055
>       Tele-IP Ltd.           Email: bruce at tele-ip.com    Icq: #32015991
>                              WWW:   http://www.tele-ip.com
> --------------------------------------------------------------------------

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list