Re: OFOQ Memory issues

On  0, Mohamed Salem <[email protected]> wrote:
> Dear ALl,
> Note : This reply was sent by Thursday but there was an error from the
> web-mail . sorry for being blocked through an web-mail error ...
> ================================
> OK.. Here we go .... 
> This is a reply for Jamil's last message ... 
> 
> >I hope that someone from the list
> > can do a bridge between SDRAM and wishbone bus may be we can put it in our
> > todo list.
> 
> ---- I have a query here: cann't the memory-controller interface
> *directly* with the SDRAM without going through a wish-bone bus?
> 
> I think , there would be a wish-bone interface to the memory controller
> from the "OR1K" CPU side only. OR1k is wish-bone compliant, hence what I do
> understand so far is that we will need a wish-bone interface with the
> "cores" that would communicate directly  with the "OR1k" CPU. referring to the system
> block diagram in OFOQ specs - the Wish-Bone bus is from the CPU side only.

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