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

	The following is the expected image for the scenario of how we could
progress the OFOQ development from a perspective based on the last
emails discussions; I need your comments and precious feed back as usual
:



      * The OR1kSim simulator default configuration includes booting of
        the UCLinux kernel.Therefore, The OR1ksim has the uclinux kernel
        ported to the openrisc1k architecture.(Software modeling)

      * The Altera board -JTAG interface would be used to download
        (DUMB) the UCLINUX kernel to the SDRAM included by default in
        the board JTAG configuration chain. (HW implementation )
      * 
                "JTAG"stands for "Joint Test Action Group"
                It is a hardware method of talking to memory and flash
                without requiring any app running on the hardware. In
                other words: mess up your bootloader and your device is
                a brick? Use JTAG to install a new working loader and
                get it working with a new one.
                
      *   The UCLINUX is originally compiled with taking the absolute
        reference addresses into account . It means that the start
        address and the end address of the compiled UCLINUX kernel in
        the terminal pc memory.
      * 
      * The JTAG will manage the dumb to the same addresses into the
        SDRAM memory of the board and inform the kernel ported of the
        starting address. 
      * 
      * The dumbed kernel will point to the start address in the memory
        which is the start of the compiled kernel. hence, the OR1K
        processor would run the boot-loader and starts up the system. 
      * 
      *   The RS232 serial port of the board will be used for command
        interface with the UCLINUX kernel dumbed through the JTAG in
        memory.
      * 
      * That means simply that the terminal (pc ) used will command the
        kernel through that serial interface. This imposes a particular
        configuration of the kernel to inform it with that serial RS232
        port connection used in command interface.
      * 
      * The Hitachi LCD device driver used and tested before would be
        dumbed with the UCLINUX kernel. This driver function is to
        display the bytes written to the kernel's LCD device allocated 
        node (by command from the terminal like : cat "Hello world"
        >/dev/lcd) on the LCD simple screen.
      * 
      * The keyboard of the system would be attached to a particular
        port of the Altera board may be the ps/2 one. The kernel should
        allocate a device node for the key board attached device.A
        suitable keyboard driver should be used in such a manner that
        allows a character written to the register interface of the
        board port to be transfered to the driver (the driver program
        accesses the register interface of the board ) then the driver
        would transfer the character to the Kernel Keyboard device node.
        Eventually, the kernel would pass the character to the proper
        process (program) that accesses the keyboard.
      * 
      * We may build our own custom driver for UcLinux that would use
        the keyboard as input side and the LCD as an output side.
      * 
      * This context requires that ; the identification of how ports on
        the board could be declared for any implemented cores on the
        platform.
      * for example : we synthesize OR1k on the FPGA. Now how would it
        addresses the different interface ports (RS232, KB port .. etc
        ). to be more clear how would the kernel knows the [address] of
        the RS232 (on board ) as a serial port connection. The same as
        how it defines a kernel node for the keyboard's interface
        register. 
      * 
The definition of the above( addressing method for ports on the board)
would lead us to emulate the peripherals of OFOQ to be added by a
modification of the OR1kSIm simulator that would implement the method
used in the board ports addressing.

I think more exhaustive discussion here would lead us so fast to getting
ready functional prototype of OFOQ.

Comments please and feed back as soon as possible .. I tried my best to
generate this image but it might have missing points (correct any if
wrong please .. thanks )

                Note : I'll be leaving for a vacation starting tomorrow
                and expected to be back by Sunday 3rd of August IN SHA
                ALLAH ... 

Thanks for your time ...

Best Regards,

	Mohamed A. Salem







          -----------

On Tue, 2003-07-22 at 21:04, Mike Rowehl wrote:
> 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
-- 
Mohamed A Salem
Handasa Arabia Organization 
www.handasarabia.org



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

Message number 54