Re: OFOQ- TO DO -TASK LIST !!

Thanks Mike ...This is Great work man!, 

	In the following comes my reply for your very important suggestions for
the over all software development of OFOQ : 

On Mon, 2003-07-14 at 22:49, Mike Rowehl wrote:
> 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?

LET ME HERE FRAME THE TASKS' duties OF SOFTWARE ACCORDING TO YOUR
SUGGESTION WHICH I AGREE COMPLETELY WITH IT :
 
   -"OR1Ksim" will be used as an emulation for the OpenRISC HARDWARE 
	architecture.
   -INTEGRATION OF  "TOOLCHAIN" AND THE "UCLINUX" ON OR1ksim.


> 
> > ***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:
That's very important to have the driver AS  "Frame Buffer Style
Compliant " . SO the Xfree Display server can interface with the kernel
using the "Frame buffer style "then the Kernel interfaces with this
"protocol like " way of communication with the DRIVER (which would be
framestyle compliant)  and finally directly the driver communicate with
the Hw IP controller of LCD device .. A good link for the frame style
device could be at
http://www.charmed.com/support/kernel/docs/framebuffer.txt

So let  us Build a Frame Style Compliant- LCD driver.. 
RUN the XFree server as a display server for OFOQ/


> 
> 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.

Let us Pick one the simplest Key board of this list and Start building a
Driver for it using the expertise involved in the previous works
conducted. Also our HW IP controller would be based on this simple key
board. The objective is not to re-invent the wheel . Just go on from
where others end. SO the task is : 

-- study of the key-boards and choice of one 1st .
-- Build the driver for it or re-use one of the Linux platform which
might be available. 
---Building the Hardware IP core based on the Key board choice . 
I think Farah could give us feed back about a key board studies.
> 
> > **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.

I absolutely agree with you MIke about this point. Port Linux, add
support for custom devices and the User space should make use of a
RUNNING existing projects as u mentioned. 
The peers around could then build on an Arabic user programs as the
platform is already Linux based . And i think that there should be an
Arabic open source programs that could be ported to OFOQ as well . I
think we need feed back from Desoky about this point as he roles
Linux-egypt and participate in Arab-Eyes Linux projects. 

Thanks very much Mike for this great effor. Keep Up the Good work my
dear friend .. 

WE are progressing ... STILL I NEED TO HEAR FROM THE GUYS AROUND WHO
WERE WAITING FOR WHEELS RUNNING HERE !!!! 
> 
>                                                     Mike
-- 
Mohamed Salem <[email protected]>
Handasa Arabia