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

Mike Rowehl <[email protected]> Tue, 22 Jul 2003 11:04:16 -0700
Newsgroups gmane.org.handasarabia.ofoq
Message-ID <[email protected]>
On  0, Mohamed Salem <[email protected]> wrote:
> >>Is this version 1 hardware a temporary prototype which
> >>>we're going to use to make sure that we can make a functional unit?
> 
> >From my point of view, The answer is Yes. 
> 
> Upon this Yes, Mike would suggest that we use a serial interface to an
> external terminal so as to simplify the overall development of the
> system. 
> The objective is to dump the Linux and start up the system, and develop
> the simplest form for proving our OFOQ functionality. 
> 
> Mike , would post here the advantages of this and how could it be
> achieve. 
> 
> Jamil, I think you have passed through a similar experience while you
> were testing the LCD. I need your comments on this .... 
> 
> The question is now what about verification of OFOQ functionality by
> communication with a linux terminal ( Dumping Linux to OFOQ). would this
> be good for fast development for a prototype or what ?... I need your
> feed back with the most details ... This technical discussion is the
> best to get the most right path for our project.
> 

I think we still have some confusion here.  I've been looking at the Altera
board (http://www.altera.com/literature/ug/sopcug.pdf).  If this is what we're
going to be using for our development I think we should use a dumb terminal
attached to the rs232 interface to do our initial work on the system.  I think,
but I'm not sure, that we'll be able to download the kernel and filesystem
images using the EJTag interface.  Based on what I've read there so far the
sdram banks are included in the configuration chain.  We should be able to 
write what we want into memory and start execution.  This is the way that I've 
seen many new Linux ports do their first startup, booting through the debugging
interface.  Then normally to ease development other techniques come into play 
(booting the kernel off the network or mounting root via NFS, writing the 
partitions into flash and including a small loader to move them to ram as
necessary).

Looking at that prototyping board we should have many of the interfaces we
need to start running quickly.  If we use the rs232 style interface (described
on page 39 of the datasheet) we can attach an external terminal to the
prototype board and use that to enter commands into it as soon as we have linux
booting and starting userspace programs.  Other options would be using the USB
devices and putting IO on it, same for the PS/2 interfaces.  But both of those 
would probably also include using the VGA interface.  Using the rs232 interface
we should be able to boot uclinux without writing any new software.  I need to 
check on the interface to the ports to ensure that.  But if they provide normal
UART interfaces, all we have tto do is tell the kernel there's a serial port of
a certain type with registers accessed at a certain address, and that's all
there should be to it.

But since I haven't had time to read too much of the OpenRISC docs yet, and 
this is really the first time I'm trying to read though the Altera specs, there
could be something in there that I missed.  Serial ports are generally kept as
simple as they can be whenever possible, I had assumed this was because they're
frequently used for debugging operations and testing interfaces.  The Altera 
board doesn't seem to do anything special with it's rs232 port, but I see
nothing about how the port is accessed.  How would this port be mapped for 
control from within the OpenRISC core?  I haven't even read far enough into the
openrisc architecture docs to know how the address spaces are setup.  Does it
use a unified memory and IO map?  How would peripherals normaly be accessed?
And would this be effected at all by the use of the Wishbone bus?  Is there any
MMU in the design we're planning to use?  All of this stuff I'm hoping to be 
able to know after reading.  But since I don't know it now, I'm going to guess
that rs232 is the best initial command interface, and I'll try to refine that
guess as I read some more and learn more about the prototype.

                                                        Mike

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

Message number 53