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
>>>>>>>>
>>>>
>>>>
