|
Message
From: brantley@m...
Date: Tue, 22 Apr 2003 05:50:09 -0100
Subject: Re: [openrisc] First steps
I have been dealing with a similar situation for the last few days so
I will share a few things that I have learned since I did not find a
lot of information on how to do this in the forum.
You will need to create a crt0.S to initialize your r2 reg for the
stack and jump to your main method.
When you compile and link your code use -T to set the locations of
your text and data sections.
Use objcopy to extract the text and data sections of your compiled
executable.
objdump is good for getting an assembly listing of your executeable.
In my case, I am experimenting using modelsim from the Xilinx webpack,
so I wrote a perl script to format the output from objcopy into a form
that can be used to initialize the blockram during synthesis and
simulation.
I also noticed in your code example your addressing of the UART is not
dword aligned. If you try to access 0x93 directly for example you will
get an alignment exception.
Best of luck,
Damon
----- Original Message -----
From: "Michael McAllister" <mmcallister@a... >
To: <openrisc@o... >
Date: Mon, 21 Apr 2003 09:37:44 -0400
Subject: [openrisc] First steps
>
>
> I am working on getting the OpenRISC 1200 (ORPsoc from the Xess
> Xsv-800
> demo) running on a Virtex 2000E-based FPGA board. This board also
> has
> SRAM & a serial port. The hardware & firmware guys have
> successfully
> synthesized and place & routed the microprocessor in the Viretx
> FPGA
> with the UART IP Core and w/o the MMU; it's my job to get the s/w
> working.
>
> I have the ability to read & write SRAM from a host computer,
> independent of the FPGA. My thought was to get a "hello world"
> kind of
> program running by loading the program into the FPGA board's SRAM,
> loading the FPGA with the OpenRISC processor, taking the processor
> out
> of reset, and seeing it write HELLO out to the serial port in an
> endless
> loop. For this initial test, I thought it might be easier if I
> write
> some code that directly sets up the UART, and NOT try to get
> uCLinux up
> and running right away (though that is the eventual goal).
>
> I am told by the firmware guy that the UART is at address 0x90h. I
> have
> recompiled the GNU tools & DDD & uCLinux & uclibc, etc,
> on a Linux box.
> I am wondering if I can just write a simple 'C' program:
>
> #define SERIAL_PORT_DATA 0x00000090ul /* Serial Prot Data
> Register
> */
> #define SERIAL_PORT_CONTROL 0x00000093ul /* Line Control Register
> (LCR) */
>
> int main ()
> {
> char *pDataPort;
> char *pControlPort;
>
> pControlPort = SERIAL_PORT_CONTROL;
> pDataPort = SERIAL_PORT_DATA;
>
> *pControlPort = 0x10; /* Set the LCR divisor latch (DL) bit */
> *(pDataPort+2)= 0x0;
> *(pDataPort+1)= 0x41; /* LSB of DL is set; internal counter
> starts */
> *pControlPort = 0x0; /* Clear the LCR divisor latch bit */
>
> while (1) {
> *pDataPort = 'H'; /* Send hello forever */
> *pDataPort = 'e';
> *pDataPort = 'l';
> *pDataPort = 'l';
> *pDataPort = 'o';
> *pDataPort = '\r';
> }
>
> return(0);
> }
>
> Load it into the SRAM, and see it start writing data to the output
> TX
> line?
>
> Any ideas if this will work? What intermediary steps must be done
> to
> the "a.out" ELF file from gcc... is there a utility to convert it
> to
> plain old machine code that can be directly executed? Is there a
> "newbie
> FAQ"? If not, I am volunteering to write one about my experiences.
>
>
> Sincerely,
> Michael McAllister
>
|
 |
Browse
