Discussion:
PINE64 ROCK64 Board - Gigabit Network
Johannes Krottmayer
7 years ago
Permalink
Hello Mark!

I have found the necessary information to control the GPIO.
But what about the I2C and SPI interface?

I don't find usefull information about this. I want native
support for my projects. Don't want to make a software based
(bit-bang) I2C or SPI interface with the GPIO pins.

Best regards,
Johannes
...
Mark Kettenis
7 years ago
Permalink
Date: Fri, 8 Jun 2018 03:54:37 +0200
Hello Mark!
I have found the necessary information to control the GPIO.
But what about the I2C and SPI interface?
I don't find usefull information about this. I want native
support for my projects. Don't want to make a software based
(bit-bang) I2C or SPI interface with the GPIO pins.
There currently is no SPI support at all in OpenBSD.

I2C is available within the kernel. For armv7 and arm64 the
recommended practice is to modify the device tree to include any
additional I2C devices you add to your board. Ideally you'd be able
to use device tree overlays, but that is not implemented yet. We
quite deliberately don't allow userland access to the I2C bus.

Currently the rkgpio(4) driver does not expose itself to userland
either, so the information in the gpio(4) and gpioctl(8) manual pages
doesn't applt.. That shouldn't be hard to implement though,
preferably in a similar way as in sxigpio(4) where only pins that
aren't claimed by other devices and left unconfigured by the firmware
are exposed.

Cheers,

Mark
...
Johannes Krottmayer
7 years ago
Permalink
Hi Mark!

Thanks for the answer. That's very pity.

But i run in a other problem with the GPIO. I have written
the follwing small piece of code:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>

int main(int argc, char *argv[])
{
int fd;

printf("Open GPIO port\n");
fd = open("/dev/gpio0", O_RDWR | O_NDELAY);

if (fd == -1) {
printf("Couldn't open GPIO port (%s)\n", strerror(errno));
return 1;
}

printf("GPIO port successfully opened. Closing...\n");
close(fd);

return 0;
}

I always get the error message "device is not configured".
Also when i try the devices gpio1 and gpio2.
How can I fix this?
...
Johannes Krottmayer
7 years ago
Permalink
Oh... Sorry, i have over read your text where you have
explained the state of the rkgpio.
...
Johannes Krottmayer
7 years ago
Permalink
Hi Mark!

I have installed the dtb package. And copied the rk3328-rock64.dtb in
the FAT boot partition. Now I see all boot messages from the kernel.

But with this dtb file, the ethernet is unstable:

$ ping 10.42.42.1
PING 10.42.42.1 (10.42.42.1): 56 data bytes
64 bytes from 10.42.42.1: icmp_seq=9 ttl=64 time=0.853 ms
64 bytes from 10.42.42.1: icmp_seq=31 ttl=64 time=0.708 ms
^C
--- 10.42.42.1 ping statistics ---
40 packets transmitted, 2 packets received, 95.0% packet loss
round-trip min/avg/max/std-dev = 0.708/0.780/0.853/0.072 ms
$

I removed the file and the ethernet works great again:

$ ping 10.42.42.1
PING 10.42.42.1 (10.42.42.1): 56 data bytes
64 bytes from 10.42.42.1: icmp_seq=0 ttl=64 time=1.499 ms
64 bytes from 10.42.42.1: icmp_seq=1 ttl=64 time=0.827 ms
64 bytes from 10.42.42.1: icmp_seq=2 ttl=64 time=0.786 ms
64 bytes from 10.42.42.1: icmp_seq=3 ttl=64 time=0.770 ms
64 bytes from 10.42.42.1: icmp_seq=4 ttl=64 time=0.979 ms
64 bytes from 10.42.42.1: icmp_seq=5 ttl=64 time=0.783 ms
64 bytes from 10.42.42.1: icmp_seq=6 ttl=64 time=0.977 ms
64 bytes from 10.42.42.1: icmp_seq=7 ttl=64 time=0.785 ms
64 bytes from 10.42.42.1: icmp_seq=8 ttl=64 time=0.803 ms
64 bytes from 10.42.42.1: icmp_seq=9 ttl=64 time=0.766 ms
64 bytes from 10.42.42.1: icmp_seq=10 ttl=64 time=0.768 ms
^C
--- 10.42.42.1 ping statistics ---
11 packets transmitted, 11 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.766/0.886/1.499/0.208 ms
$

Seems to me that there is a bug.
...
Johannes Krottmayer
7 years ago
Permalink
Hi Mark!

I inform you that I try to write a spi driver for the rk3328. Called
it rkspi (rkspi.c). Currently I have implement a early version of the
match and attach functions and it works.

It is based on your rkiic driver.

_The match function_

int
rkspi_match(struct device *parent, void *match, void *aux)
{
struct fdt_attach_args *faa = aux;

return (OF_is_compatible(faa->fa_node, "rockchip,rk3328-spi"));
}

_The attach function_

void
rkspi_attach(struct device *parent, struct device *self, void *aux)
{
struct rkspi_softc *sc = (struct rkspi_softc *) self;
struct fdt_attach_args *faa = aux;

if (faa->fa_nreg < 1) {
printf(": no registers\n");
return;
}

sc->sc_iot = faa->fa_iot;
sc->sc_node = faa->fa_node;

if (bus_space_map(sc->sc_iot, faa->fa_reg[0].addr,
faa->fa_reg[0].size, 0, &sc->sc_ioh)) {
printf(": can't map registers\n");
return;
}

printf("rkspi_attach success\n");
}

And this piece of code works:
$ dmesg | grep rkspi
rkspi0 at mainbus0
rkspi_attach success
$

My next step is, to configure the spi bus and add a read and
write function.

What do you think about my intention?

Best reagrds
Johannes
...
Mark Kettenis
7 years ago
Permalink
...
That's a very basic start in the right direction.
Johannes Krottmayer
7 years ago
Permalink
Post by Mark Kettenis
That's a very basic start in the right direction.
Thanks!

I'm new in OpenBSD driver and ARM development. I have
experience with AVR microcontroller and now I want use
OpenBSD for my embedded projects.

But today it is enough with driver development, because I
can't get the datasheet of the RK3328. rock-chip.com
seems to be down.

Good night!

Best regards
Johannes

Mark Kettenis
7 years ago
Permalink
...
Works fine for me, but my board is connected to a 100Mbit/s switch.

I suspect this is related to the tx_delay settings in the device tree.
The firmware has:

tx_delay: 00000018

whereas the linux device tree has:

tx_delay: 00000024

You could try and change that number and see if things improve.

Cheers.

Mark
Johannes Krottmayer
7 years ago
Permalink
Post by Mark Kettenis
Works fine for me, but my board is connected to a 100Mbit/s switch.
I suspect this is related to the tx_delay settings in the device tree.
tx_delay: 00000018
tx_delay: 00000024
You could try and change that number and see if things improve.
Cheers.
Mark
You are right!
I have made a quick and dirty workaround. I have hardcoded the
value 18 for the TX delay in the if_dwge_fdt.c driver.
Now the ethernet works with my 1000Mbit switch.
Thanks!
Best regards
Johannes