OFOQ- TO DO -TASK LIST !(Revisitied)

Dear All, 
Please let us all read and digest this message sent 23rd of July
(Message number 54 OFOQ list) . It seems the message content is not
completely understood, hence there are some messages coming out after
this out of scope of what is listed . So at first , I need to get feed
back about what is vague to re-explain it clearly for us all. We are
gonna be so close of getting ready prototype if we know how to get the
steps mentioned done. 

Let me phrase it and conclude what we do have : 

1- Synthesized and implemented OR1k on the Altera Board. 
2- Software simulator for the OR1k with default UCLINUX kernel ported to
it.
3- A test for the LCD by a driver running on Linux. 
======
The 1st now to be done so as to start CPU testing is a porting or
DUMBING of UCLINUX kernel with the LCD driver on the prototyping board
suitable memory by using the JTAG. 

""We need first to study and practice how to let the DUMB on a Board
memory done by using the JTAG chain..."" If some one knows feed us back
to shorten time.... 

 Once, we got it dumbed "UCLINUX" on "SUITABLE" memory on the board. The
testing of the CPU (which is the last messages concern) should start. 
The scheme of testing is to start booting the kernel from its start
address in the memory. 
This needs the following : 
The OR1k connected and interfaced to the WB bus interface. 
The Memory-Controller (synthesized on board) and connected to the WB-BUS
from one side and the "Target" memory from the other side (the memory
that has UCLINUX KERNEL besides needed devices drivers ) 
I'll do my best in the next days to have the memory controller operating
in this scheme ( connection to WB bus and A memory model ). Then I'll
feed u back Jamil of what to be done for Synthesis. Hope i could get it
done easily!

The topic of priority to study (which has been mentioned in the message)
is that:  How are the BOARD PORTS defined for any implemented hardware
on the FPGAs. in other words ( How would the OR1k on the FPGA  addresses
the RS-232 or Ps/2 ... etc or any other available ports on board ) 

Please, I need  a feed back according to this context. We need to be
tuned and focused to avoid confusion .. We need all to be well
understanding for the message pointed at the start of the mail.

Waiting for your feed back .. correct me if I'm wrong ... It is all a
learning and practicing topics for me .... 

Best Regards,

Mohamed A.Salem
Handasa Arabia Organization 
www.handasarabia.org  


On Wed, 2003-07-23 at 12:31, Mohamed Salem wrote:
> 	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


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

Message number 66