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