Re: Re: OFOQ- TO DO -TASK LIST !!

I agree.. 
The objective is to get OFOQ running as simple as possible to prove our
concepts and meanwhile as soon as possible too!
I'd like to hint that Jamil testing of the LCD in details is documents
under OFOQ project files , hence interested members to integrate it to
OFOQ software could find the driver details right there. 
Let us keep the key board as simple as you suggest, but it needs a
decision. I also echo that we should minimize our memory size as
possible. 
Best Regards,
	Mohamed A. Salem
On Mon, 2003-07-21 at 14:42, Jamil Khatib wrote:
> I'll try to comment on this task list.
> 
> >> > ****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.
> 
> I agree on this but I think we need to define the memory size we need and try
> to minimize teh memory usage as much as we can.
> 
> 
> >
> >
> >>
> >> > ***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":
> >> >
> 
> 
> I am not sure which driever you are talking about. I found a free linux
> driver for the LCD and I tested it and it is working. I prepared the wishbone
> bridge between the LCD controller and the CPU. All what we need is to
> integrate it to the software system and may be add support for Arabic font.
> I do not think we need to have something like XFree server because we are not
> dealing with graphics in OFOQ-1. the on board lcd is too small it supports
> two lines of text. may be we can make small graphics but this can be done by
> text drawing and font creation usning the existing driver.
> 
> Moreover we are not going to build LCD controller in this phase because it is
> already exists on the board.
> 
> >> > **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"
> >> > ================
> 
> I think we can find any ps/2 keyboard driver for linux we do not need the
> complications in this stage. I think we will have good work if we manage to
> use stadard keyboard and write few notes to the lcd and save them in the
> flash.
> 
> The applications shpuld be so simple at this stage also.
> 
> Remember  that all other options should be reserved for OFOQ-2 and 3 
> 
> 
> Regards,
> Jamil Khatib
> 
> 
> 
> >>
> >> 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
> 
> -------------------------------
> OFOQ Mailing List
> Handasa Arabia Organization
> http://www.handasarabia.org
> 44
-- 
Mohamed A Salem
Handasa Arabia Organization 
www.handasarabia.org



-------------------------------
OFOQ Mailing List
Handasa Arabia Organization
http://www.handasarabia.org
45