[wplug] uCLinux

[Michael M Delaney]

I may have asked part of this before, but I don't rembember getting the
answer.
If you are looking to just do the porting as kind of a "fun" project, but
haven't ever done embedded development and uClinux development, I would
strongly suggest first getting a supported Coldfire board (then again, I
don't know how much they cost) first, and learning some of the ins and
outs of both Coldfire and uClinux.  Check the mailing list for
Coldfire, and see if anyone has started work on the port.  And check
uCdot, in particular http://www.ucdot.org/search.pl?topic=9 is a list of
deve boards people have submitted.  (Thats assuming you don't have a
board, and don't already have a specific one in mind, but it may still be
worth a look).

Mike


On Thu, 7 Oct 2004, Darin Ingimarson wrote:

> Weber, Larry A wrote:
>
> >Freescale (Motorola) has recently released several new Coldfire processors (MCP523x) and an evaluation board.  I thought it might be a good learning experience to try to port uCLinux to the board.
> >
> Yeah, it would definately be a learning experience for you ;-)
>
>  From my experience in porting RTOS's (probably applicable to general
> embedded OS ports), the most frustrating part will involve setting up
> the initial cross-developmnet platfom and toolchain. This is not
> entirely trivial, and you need to make sure that your processor of
> interest is supported by your compiler. Check the GNU site for this info.
>
> The way I would approach this project is first by answering a few questions:
> - Check out toolchain support for the processor (at the very least you
> will need  gcc/gas). Has anyone built a toolchain (i.e. with precompiled
> libraries) you can download and use, or will you have to build your own?
> - How close to existing, supported processors is the new one? What are
> the differences? Can you leverage existing code, binaries, or online
> docs in your project?
> - What type of memory protection (if any) does the processor support? Is
> this different in any appreciable way from the existing supported
> processors. This will affect the complexity in porting the uCLinux stuff.
> - Do you require any major changes to the remaining  assembler-based
> modules in uClinux (in the RT variants of Linux I have worked with this
> is mainly located in the boot and context switch code, so at least your
> problems should be confined to a relatively limited module set). If not,
> your port should be very straightforward.
> - Determine the boot and storage facilities (FLASH, disk, etc) on your
> development kit and find out if you have to write any specific drivers
> to support them.
> - Determine the mechanism for loading and running a binary on your dev
> kit. How difficult is it? Will you need special hardware or software
> available only under Windows? How you will load and run the very first
> binary you compile?
> - Determine what the feasability for a debug (user AND kernel mode)
> connection to the dev kit is (i.e. RS-232, JTAG, etc).
>
> If you investigate the above, I think you will get an idea as to the
> scope of project you are considering.
>
> > I know it has been done with other versions of Coldfire processor eval. boards but this board is quite a bit different.  I just don't want to waste time on something that can't be done or would take forever to get right.
> >
> >
> I have no doubt that it can be done, but the "get right" part is up to
> the engineer involved ;-)
>
> Good luck. If you have any other questions, you can email me directly if
> you like.
>
>   -darin
> _______________________________________________
> wplug mailing list
> wplug at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug
>