Re: OFOQ Memory issues

Hi,
First of all I'd like to say the OR1K does not use external SRAM for cache
memory. I checked it again so the on board SRAM can be used as main memory.

as far as I know that SDRAM needs to be programmed in order to operate so I
do not think that wishbone to SDRAM is enough to operate it, the CPU must be
active to program some internal registers in the SDRAM.

Now for thedebug port. I have not studied the debug port of the opencores
design but I do not think we need it now we have just to download the
software to the sram and let the CPU start from there.
What I am planing to do is to download the software from the PC to SRAM via
paralel port. During download the parallel port will set the CPU in reset
mode and after download completion the CPU should start up and take the
control over the SRAM and the parallel port will be disconnected internalley
on the FPGA.
What do you think about this???



Mohamed Salem, can you prepare a document for the SRAM as what you did for
the SDRAM?

Regards,
Jamil Khatib


>
>I think the goal here is to be able to download a program to the board
without
>any prior software on the board at all.  That means we don't have anything
>for the CPU to execute, so it doesn't know how to bridge Wishbone to SDRAM.
>If I understand the proposal correctly we're going to have a core that
accepts
>a file downloaded from a PC and uses a bridge from Wishbone to SDRAM to
write
>that file into memory.  The process of bringing up the board from a
completely
>"clean" state would then mean leaving the CPU disabled while using this
>download core to place an executable image in SDRAM.  Once the file is
>downloaded to the proper boot location for the CPU we can start the OR1K up
>and it'll be running our program.
>
>Some processors do have interfaces available that let you manipulate the
state
>of the core and use it to bridge out to other peripherals.  This is how the
>ARM devices (at least the ones I've run across) provide testing and
debugging
>interfaces.  The JTAG interface can be used to start and stop the CPU,
write
>into SRAM, query and set the registers.  The hardware debugger that I've
used
>only allowed for directly downloading to SRAM, not SDRAM.  I'm not sure if
>that's because of some inherent limitation of the JTAG interface, or just
>because we had a cheap debugger.  What we did was write a program that we
>could download to SRAM using the JTAG interface.  When run the program
would
>setup the memory controller so that the SDRAM was functioning and then
accept
>an image from another CPU interface (serial line, network, MMC) and write
the
>image into SDRAM.  Once downloaded the CPU would branch to the start of
SDRAM
>and execute the code we provided.  There was only a small ammount of SRAM
>available, I think only 60k.  So downloading even the smallest of Linux
>kernels directly through JTAG into the SRAM would have been impossible, and
>that says nothing for the filesystems needed.
>
>We must not have a system like this available with the OR1K, or it must be
>impractical to use.  Either way, being able to download an image directly
>from a PC to SDRAM and starting it up is much more pleasant than the two
step
>shuffle we had to do on our systems.  But in order to do that download it
>probably has to be done with the CPU held in reset (or otherwise disabled
or
>detached from the SDRAM interface), which means the Wishbone devices can't
>rely on the OR1K to provide the SDRAM access for them.
>
>                                                            Mike
>
>-------------------------------
>OFOQ Mailing List
>Handasa Arabia Organization
>http://www.handasarabia.org
>[email protected]
>
>Message number 88

-------------------------------
OFOQ Mailing List
Handasa Arabia Organization
http://www.handasarabia.org
[email protected] 

Message number 90