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

Salam,
I am so sorry for teh delay I will try to answer as much as I can.


=3D=3D>
How would this LCD test information be used? Would I need to get modelsim to
use these files to simulate the LCD? or1ksim says that it supports
peripherals under simulation, but I haven't looked at how they're modeled
yet.

Can you describe the testing process so as to check it on modelsim

=3D=3D>

Regarding the LCD and arabic, alas, it won't be possible to display Arabic
with the mentioned LCD, because of the shapping features of the Arabic
language.


I think allwhat we need to suport arabic is to draw the fonts and higher
level software can deal with them.

=3D=3D>

=3D=3D> Driver connection to hte CPU
All what we need from the driver is to know how to connect the LCD controller
to the CPU.=20
From the LCD there is a configuration file that map the pins but I do not
know from the software point of view CPU pins can be controlled mainly how to
wait for the busy signal because the driver does not depend on it. It assumes
that the external interface (which is parallal port but our case is CPU) is
too slow so I think we can just define a small delay between writing and
reading. or we can modify the driver to take busy signal in considersation.


=3D=3D>
there was a discussion about terminals I can not talk much about because I do
not have experience with it.
the driver enables writing the same as writing to VT terminal. or directing
the characters to /dev/lcd

=3D=3D>
I think the idea of using RS232 and terminal to connect the board to the PC
is good idea. we can easly debug linux and teh software.

If it is easy to start on porting the ulinux, dump it using the JTAG and use
terminal let us go for it.
Anyhow I do not know how can we use the JTAG to dump the kernel to the
memory.

I'll try to start studying the RS-232 from the HW point of view and see how
can we integrate it with the CPU

Please let me know if you have comments
Jamil


On 7/23/2003, "Mohamed Salem" <[email protected]> wrote:

>=09The 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,
>
>=09Mohamed 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

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

Message number 56