Re: OFOQ- TO DO -TASK LIST !!

Mike Rowehl <[email protected]> Mon, 14 Jul 2003 12:49:44 -0700
Newsgroups gmane.org.handasarabia.ofoq
Message-ID <[email protected]>
On  0, Mohamed Salem <[email protected]> wrote:
----- 8< --- 8< -----
> ****PORTING UCLINUX operating system to the OPENRISC CPU : 
> 
> ==============
> The task title is inherent descriptive. The target is to port the linux
> kernel on the openrisc CPU implemented. This has been done before the
> the ORISC so it needs to be studied then applied. This is of great
> interest to run Linux on the openrisc.
> =====================

There is a lot of information available about this at the openrisc
project page (http://www.opencores.com/projects/or1k/).  For those
interested in the software side of this effort I suggest downloading and
compiling the toolchain and ucLinux packages.  Instructions are
available at
http://www.opencores.com/projects/or1k/GNU%20Toolchain%20Port
I'm just trying out the process on a RedHat based system, I'll post the
results once I've made it through the whole thing.  I expect we'll be
able to get going right away using or1ksim to experiment with the images
from ucLinux, but this is going to be my first attempt at using this
environment.  Has anyone had experience with using or1ksim before?

> ***Devices' DRIVERS : 
> 
> **LCD Driver : 
> The driver will run on the OR and interface with Linux kernel. The
> driver will send control signals and data to the hw device "LCD
> controller": 
> 
> **KEYBOARD Driver :
> The driver will run on the OR and interface with Linux kernel. The
> driver will send control signals and data to the hw device "KeyBOard
> controller"
> ================

Device driver work such as this normally isn't hard to get going.  Our
best bet for the LCD interface might be to make a framebuffer style
driver for it, this seems to be the preference for video interface within
the embedded Linux systems space.  Once we've decided on a kernel
interface for the LCD there are already some projects that use the
standard XFree server platform for handheld linux.  There's some 
discussion of the issues at:

http://www.handhelds.org/minihowto/building-x.html

In general, the "custom hacks" needed for PDAs running X have already
been fed back into the mainline.  There's also prior art available for
making custom keyboard interfaces for handhelds look like standard
Linux input devices:

http://www.handhelds.org/handhelds-faq/keyboards.html

We should be able to base whatever work we need to do off of those
devices.  If possible, I vote for actually using one of those keyboards
if we can.  That can help to take some of the guesswork out of the
process if the keyboard manufacturer doesn't feel like being
cooperative.

> **SOFTWARE Applications : 
> 
> The following program will be used as the software that interact with
> OFOQ user : 
> Simple calculator
> Small Phone Book 
> To DO list 
> Alarm, clock. 
> The target of these application programs is JUST to prove functionality.
> Then the door would be open for more complex application that addresses
> the Linux platform. 
> =======================

Much of this class of applications have been made available in different
packaging systems for the handhelds.org distributions:

http://familiar.handhelds.org/
http://opie.handhelds.org/
http://gpe.handhelds.org/

My suggestion for the application work is that we prepare to treat OFOQ
as another platform used with a project such as opie or gpe.  We need to
do the work to port the base Linux operating system to our environment
and add support for custom devices, but I suggest that once we get to
user space applications we concentrate on using an existing project to
fulfill this role.  Of course, we need to work in order to add the
necessary enhancements for Arabic support.  But I think where possible
that work should be done along with (or at least fed back into) the
existing projects.  This is something I think I'm only going to be able
to contribute to a little bit, because I don't speak Arabic and I'm
unfamiliar with the requirements.  It would be great if we could have
someone to take charge of this area and make sure it's getting
addressed.  If we plan to use a project like Opie or GRE for our 
userspace apps that also means that the applications work can start
development right away using an existing supported platform.

                                                    Mike