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

Bruce Paterson bruce at tele-ip.com
Thu Nov 15 02:03:01 EST 2001


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

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
--------------------------------------------------------------------------
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list