API for Cores

[salmansheikh]

I have successfully built the SOC on a de0_nano with FuseSOC, but is there any API for how to use the various cores that come with the default build? I can only get the UART to work...the GPIO is not working correctly. I searched the internet in vain for examples of programs for the various cores...they seem to be lacking.

Thanks.

Salman

[olofk]

Hi Salman,

Many of the cores are unfortunately poorly documented. I would also like to see some example code or a driver for each core, but I haven't had time to do any of that myself.

For the gpio core specifically, the registers are described here https://github.com/openrisc/orpsoc-cores/blob/master/cores/gpio/README.md though and this asm code (https://github.com/olofk/or1k_bootloaders/blob/master/led_blink.S) uses gpio to blink LEDs, but that's basically all available documentation for that core.

[salmansheikh]

Okay... I got work cut out for me...
On Sep 8, 2015 12:48 AM, "Olof Kindgren" notifications@github.com wrote:

Hi Salman,

Many of the cores are unfortunately poorly documented. I would also like
to see some example code or a driver for each core, but I haven't had time
to do any of that myself.

For the gpio core specifically, the registers are described here
https://github.com/openrisc/orpsoc-cores/blob/master/cores/gpio/README.md
though and this asm code (
https://github.com/olofk/or1k_bootloaders/blob/master/led_blink.S) uses
gpio to blink LEDs, but that's basically all available documentation for
that core.

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

[salmansheikh]

Is the right way to set the output LEDS to 0x15 on gpio0 for the de0_nano
on the FuseSOC (where gpio is mapped to 0x91000000)

On Tue, Sep 8, 2015 at 7:06 AM, Salman Sheikh salmanisheikh@gmail.com
wrote:

Okay... I got work cut out for me...
On Sep 8, 2015 12:48 AM, "Olof Kindgren" notifications@github.com wrote:

Hi Salman,

Many of the cores are unfortunately poorly documented. I would also like
to see some example code or a driver for each core, but I haven't had time
to do any of that myself.

For the gpio core specifically, the registers are described here
https://github.com/openrisc/orpsoc-cores/blob/master/cores/gpio/README.md
though and this asm code (
https://github.com/olofk/or1k_bootloaders/blob/master/led_blink.S) uses
gpio to blink LEDs, but that's basically all available documentation for
that core.

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

[salmansheikh]

Oops...sent before finish composing :

#include <or1k-support.h>
#include <stdio.h>
int main(int argc, char * argv[])
{
char* gpio_base = (char*) 0x91000000;

printf("Got OpenRisc processor working\n");

*(gpio_base+4) = 0xff;
*gpio_base = 0x15;
return 0;
}

On Thu, Sep 10, 2015 at 9:48 PM, Salman Sheikh salmanisheikh@gmail.com
wrote:

Is the right way to set the output LEDS to 0x15 on gpio0 for the de0_nano
on the FuseSOC (where gpio is mapped to 0x91000000)

On Tue, Sep 8, 2015 at 7:06 AM, Salman Sheikh salmanisheikh@gmail.com
wrote:

Okay... I got work cut out for me...
On Sep 8, 2015 12:48 AM, "Olof Kindgren" notifications@github.com
wrote:

Hi Salman,

Many of the cores are unfortunately poorly documented. I would also like
to see some example code or a driver for each core, but I haven't had time
to do any of that myself.

For the gpio core specifically, the registers are described here
https://github.com/openrisc/orpsoc-cores/blob/master/cores/gpio/README.md
though and this asm code (
https://github.com/olofk/or1k_bootloaders/blob/master/led_blink.S) uses
gpio to blink LEDs, but that's basically all available documentation for
that core.

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

Even a Smile is charity :)

• Prophet Muhammad

[fjullien]

It must be *(gpio_base+1) = 0xff;

[salmansheikh]

I found it actually works when I set reg_base to 0x00 but I thought '1'
meant output..maybe there is an inversion somewhere in the verilog code on
the value?

*(gpio_base+1) = 0x00;
*gpio_base = 0x06;

Also, when I tried changing the leds twice, I get this printing
continuously in both my telnet and ocd sessions (but the telnet doesn't say
Error: Just the part after that and it continues until I shut down the
openocd or telnet session..anyone have any clue? I build openocd 0.9 in
Scientific Linux 6.6 and I used the ftdi libraries from FTDI because
somewhere I read you need to use those with the usb blaster and I was
having problems with it compiling with the open source ftdi library

Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error
Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error
Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error
Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error

On Fri, Sep 11, 2015 at 2:49 AM, Franck Jullien notifications@github.com
wrote:

It must be *(gpio_base+1) = 0xff;

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

[salmansheikh]

Sorry, I meant reg+base + 0x1 so, it works when *(gpio_base+1) = 0x00
(which apparently means output, but that's not what the gpio.v
documentation said..

On Fri, Sep 11, 2015 at 4:49 PM, Salman Sheikh salmanisheikh@gmail.com
wrote:

I found it actually works when I set reg_base to 0x00 but I thought '1'
meant output..maybe there is an inversion somewhere in the verilog code on
the value?

*(gpio_base+1) = 0x00;
*gpio_base = 0x06;

Also, when I tried changing the leds twice, I get this printing
continuously in both my telnet and ocd sessions (but the telnet doesn't say
Error: Just the part after that and it continues until I shut down the
openocd or telnet session..anyone have any clue? I build openocd 0.9 in
Scientific Linux 6.6 and I used the ftdi libraries from FTDI because
somewhere I read you need to use those with the usb blaster and I was
having problems with it compiling with the open source ftdi library

Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error
Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error
Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error
Error: FT_Write returned: io error
Error: FT_Write returned: io error
Error: FT_Read returned: io error

On Fri, Sep 11, 2015 at 2:49 AM, Franck Jullien notifications@github.com
wrote:

It must be *(gpio_base+1) = 0xff;

—
Reply to this email directly or view it on GitHub
#87 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

Even a Smile is charity :)

• Prophet Muhammad

[olofk]

This sounds very strange. Setting bits on gpio_base+1 should definitely make them outputs. Could it be that the LEDs are active low, so that writing 0 to the bits in gpio_base actually turns them on?

[salmansheikh]

I checked the schematic and the led outputs from the FPGA definitely goto
the Anode of the led through a current limiting resistor...somewhere there
us an inversion...
On Sep 22, 2015 3:23 PM, "Olof Kindgren" notifications@github.com wrote:

This sounds very strange. Setting bits on gpio_base+1 should definitely
make them outputs. Could it be that the LEDs are active low, so that
writing 0 to the bits in gpio_base actually turns them on?

—
Reply to this email directly or view it on GitHub
#87 (comment)
.