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

On Sat, Jun 09, 2018 At 17:23:09 +0200, Johannes Krottmayer wrote:
> 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.
> 
> On Fri, Jun 08, 2018 At 22:35:24 +0200, Johannes Krottmayer wrote:
>> Oh... Sorry, i have over read your text where you have
>> explained the state of the rkgpio.
>>
>> On Fri, Jun 08, 2018 At 22:28:10 +0200, Johannes Krottmayer wrote:
>>> 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?
>>>
>>> On Fri, Jun 08, 2018 At 11:47:13 +0200, Mark Kettenis wrote:
>>>>> From: Johannes Krottmayer <krj...@gmail.com>
>>>>> 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
>>>>
>>>>> On Fri, Jun 08, 2018 At 03:42:11 +0200, Johannes Krottmayer wrote:
>>>>>> Hello Mark,
>>>>>>
>>>>>> I just installed OpenBSD sucessfully on the ROCK64 media board.
>>>>>> That's very cool. Thanks for your good statement.
>>>>>>
>>>>>> Best reagards,
>>>>>> Johannes
>>>>>>
>>>>>> On Fri, Jun 08, 2018 At 00:52:51 +0200, Johannes Krottmayer wrote:
>>>>>>> Hello Mark,
>>>>>>>
>>>>>>> I have an additional question. Don't want start a new thread for
>>>>>>> this.
>>>>>>>
>>>>>>> Are the GPIO, the I2C and the SPI interface working?
>>>>>>> An how can i use this. Is there a short example code available?
>>>>>>>
>>>>>>> I'm new in this. I have experience in bare-metal programming
>>>>>>> with AVR devices. Now I want use the ARM port of OpenBSD for my
>>>>>>> further electronic projects.
>>>>>>>
>>>>>>> Best reagards,
>>>>>>> Johannes Krottmayer
>>>>>>>
>>>>>>> On Fri, Jun 08, 2018 At 00:28:30 +0200, Johannes Krottmayer wrote:
>>>>>>>> Hello Mark,
>>>>>>>>
>>>>>>>> Thanks for the fast reply and this information!
>>>>>>>> I will try this steps.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Johannes Krottmayer
>>>>>>>>
>>>>>>>> On Fri, Jun 08, 2018 At 00:20:30 +0200, Mark Kettenis wrote:
>>>>>>>>>> From: Johannes Krottmayer <krj...@gmail.com>
>>>>>>>>>> Date: Thu, 7 Jun 2018 23:23:21 +0200
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Currently the Gigabit network of the ROCK64 media board
>>>>>>>>>> doesn't work with OpenBSD 6.3.
>>>>>>>>>>
>>>>>>>>>> Is there a chance in further releases to get this work?
>>>>>>>>>> It would be great!
>>>>>>>>>
>>>>>>>>> It works in -current.  There is also DMA support for eMMV and uSD card
>>>>>>>>> in -current.
>>>>>>>>>
>>>>>>>>> I flashed my board with the firmware provided by "ayufan" that can be
>>>>>>>>> found at:
>>>>>>>>>
>>>>>>>>>   https://github.com/ayufan-rock64/linux-build/releases
>>>>>>>>>
>>>>>>>>> The device tree embedded in that firmware doesn't provide the proper
>>>>>>>>> speed for the serial console.  Therefore when you boot the board after
>>>>>>>>> installing it the boot messages will not show up on the serial
>>>>>>>>> console.  You can fix this by installing the dtb package and doing
>>>>>>>>>
>>>>>>>>>   # mount /dev/sdXi /mnt
>>>>>>>>>   # mkdir /mnt/rockchip
>>>>>>>>>   # cp /usr/local/share/dtb/arm64/rockchip/rk3328-rock64.dtb 
>>>>>>>>> /mnt/rockchip
>>>>>>>>>   # umount /mnt
>>>>>>>>>
>>>>>>>>> You should also check the /etc/ttys file and change the console entry
>>>>>>>>> from std.115200 into std.1500000 if necessary.
>>>>>>>>>
>>>>>>>>> I'll see if I can get that issue fixed.
>>>>>>>>>
>>>>>>>>> Cheers.
>>>>>>>>>
>>>>>>>>> Mark
>>>>>>>>>
>>>>>
>>>>>

Reply via email to