Jump to content

[WiP / Orange Pi One] Support for the upcoming Orange Pi One?

tkaiser

By tkaiser
in Armbian build framework

 Share

Recommended Posts

tkaiser

tkaiser

Posted
  • Author
Posted

Still no u-boot patch: 'sources/u-boot/branchless# find . -name sy8106a.c' returns nothing. Thx, Zador. Will try PL08 out on the weekend and keep you informed. 

Igor

Igor

Posted
Posted 
root@production:~/sources/u-boot/branchless# patch -p1 < /root/lib/patch/u-boot/u-boot-dev/sy8106a.patch 
patching file board/sunxi/Kconfig
patching file board/sunxi/board.c
patching file configs/orangepi_pc_defconfig
patching file drivers/power/Kconfig
patching file drivers/power/Makefile
patching file drivers/power/sy8106a.c
patching file include/configs/sunxi-common.h
patching file include/sy8106a.h

If you override TAG that doesn't mean you are in DEV branch so the patch must be in DEFAULT ... and it works. I also made wrong conclusion. Copy patch to default.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/18/2016 at 7:59 PM, Igor said:

If you override TAG that doesn't mean you are in DEV branch so the patch must be in DEFAULT ... and it works. I also made wrong conclusion. Copy patch to default.

 

 

Nah, that's too much for me/today. I'm really confident that someone else takes care of this patch to be applied for all SY8106A capable devices. ;)

 

I'm currently trying to burn my house down (unattended Orange Pi One benchmark runs with activated overvolting), try to relax and try also to stay away from the boards until sunday. :)

 

BTW: Jean-Luc from cnx-software.com might probably pick up the Orange Pi One overvolting issue once more (might depend on the results of the tests I run currently regarding potential damage to the boards), so it might be good to have as much images/boards ready when he awakens (his timezone is ITC AFAIK) 

tkaiser

tkaiser

Posted
  • Author
Posted

I finished a small series of tests regarding the new voltage regulator: TL;DR: There went something really wrong -- try to avoid voltage switching on Orange Pi One!

 

On Orange Pi One the new voltage regulator should switch the Vcore voltage between 1.1V (624 MHz) and 1.3V (everything above). What seems to happen in reality is that there's something seriously going wrong. The adjusted voltages seem to be way higher which leads to insane overclocking/overheating when we allow the SY8113B step-down converter to switch to the higher voltage.

 

On top we have a small problem regarding thermal readouts from the SoC. When combining mainline u-boot with the outdated lichee 3.4.x kernel reported internal temperatures are a bit too low (most probably due to some clock mismatches since higher temperatures are reported with lower DRAM freq -- pretty unlikely).

 

I started a set of tests constantly increasing CPU load and comparing thermal readouts and throttling between

  • u-boot 2011.09 (boot0) as used on Xunlong's and loboris' OS images for H3
  • mainline u-boot as used with Armbian and OpenELEC for H3

With fex settings that don't allow Orange Pi One to switch to the higher voltage everything is almost ok. Temperature differences aren't that much and throttling seems to work ok in both situations:

 

Disabled dvfs combined with boot0:

 

boot0.png

 

 

Disabled dvfs combined with mainline u-boot:

 

 

mainline-u-boot.png

 

When we allow voltage switching it gets weird. It seems the higher voltage is way beyond everything that's sane (still to be confirmed by someone with Orange Pi One and a Multimeter walking through the available testpoints on the PCB). The same benchmarks lead to heavy overheating now. With the somewhat calibrated temperature readouts when using boot0 the kernel decides already at 816MHz to kill all CPU cores but one!

 

When using mainline u-boot together with kernel 3.x then the few degrees make a huge difference. Here thermal throttling jumps in when H3 is running at 1008 MHz and CPU cores are killed way too late (when running cpuburn-a7 which does exactly what the name describes):

 

Enabled dvfs combined with boot0:

 

boot0-dvfs.png

 

Enabled dvfs combined with mainline u-boot:

 

mainline-u-boot_dvfs.png

 

Simple conclusion: Do not allow voltage switching on the Orange Pi One and stay on the lower voltage! Armbian's settings already take care.

szaflik

szaflik

Posted
Posted

Hello,

 

I've got some crash in dmesg on latest 5.01 Jessie (OrangePi One) build:

[   69.023650] BUG: Bad page state in process loadcpufreq  pfn:5301d
[   69.023677] page:c0df1414 count:0 mapcount:-16384 mapping:  (null) index:0x14
[   69.023687] page flags: 0x0()
[   69.023696] Modules linked in: w1_therm w1_gpio wire w1_sunxi gpio_sunxi
[   69.023768] [<c0016cdc>] (unwind_backtrace+0x0/0xe8) from [<c06d7840>] (dump_stack+0x20/0x24)
[   69.023801] [<c06d7840>] (dump_stack+0x20/0x24) from [<c00df084>] (bad_page+0xec/0x11c)
[   69.023824] [<c00df084>] (bad_page+0xec/0x11c) from [<c00df49c>] (get_page_from_freelist+0x24c/0x530)
[   69.023848] [<c00df49c>] (get_page_from_freelist+0x24c/0x530) from [<c00e04d8>] (__alloc_pages_nodemask+0x21c/0x8ac)
[   69.023878] [<c00e04d8>] (__alloc_pages_nodemask+0x21c/0x8ac) from [<c00fc1d4>] (do_wp_page+0x4ec/0x7a4)
[   69.023909] [<c00fc1d4>] (do_wp_page+0x4ec/0x7a4) from [<c00fd8bc>] (handle_pte_fault+0x52c/0x7e4)
[   69.023934] [<c00fd8bc>] (handle_pte_fault+0x52c/0x7e4) from [<c00fdc88>] (handle_mm_fault+0x114/0x150)
[   69.023959] [<c00fdc88>] (handle_mm_fault+0x114/0x150) from [<c001b43c>] (do_page_fault+0x118/0x344)
[   69.023984] [<c001b43c>] (do_page_fault+0x118/0x344) from [<c00083c0>] (do_DataAbort+0x44/0xa8)
[   69.024005] [<c00083c0>] (do_DataAbort+0x44/0xa8) from [<c000dc58>] (__dabt_usr+0x38/0x40)
[   69.024020] Exception stack(0xd4cd1fb0 to 0xd4cd1ff8)
[   69.024033] 1fa0:                                     00000183 00000000 00000000 00000181
[   69.024049] 1fc0: 00000183 be9d31e0 b6f3e390 be9d31f0 b6ef9000 b6f3e850 00000181 00000181
[   69.024068] 1fe0: 00000078 be9d31e0 b6e806d5 b6e8079a 600d0030 ffffffff
[   69.024081] Disabling lock debugging due to kernel taint
tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 7:21 AM, szaflik said:

I've got some crash in dmesg on latest 5.01 Jessie (OrangePi One) build

 

Well, without further information it's a bit hard to get a clue what's going wrong.

 

You could try to replace both script.bin and kernel package with the latest versions and report back. The process is outlined some posts before on page 3 of this thread and the packages are (caution: this only works if you also replace /boot/bin/orangepione.bin since this is the unified kernel that works on all H3 models but needs a little fex tweak)

 

orangepione.bin   (md5sum: b8397d78f76f1517fd496fae7b4b7bc2)

kernel_5.01_h3_unified.tgz   (md5sum: d0fc5f32b5f5291d324cb65b838d8432)

 

@Igor: sy8106a.patch seems to break u-boot compilation at the moment but I would believe you already know that? And then I can confirm that our desktop image provides no Mali acceleration currently (framerates horribly low but maybe I just missed something)

 

 

  Reveal hidden contents

 

 

But at least my peripherals work now! :)

Igor

Igor

Posted
Posted
  Quote

@Igor: sy8106a.patch seems to break u-boot compilation at the moment but I would believe you already know that? And then I can confirm that our desktop image provides no Mali acceleration currently (framerates horribly low but maybe I just missed something)

 

Actually I haven't try to compile. Was already half sleeping at the time ... will check up.

 

Not working MALI could be related to kernel command line, again ;) We are setting some no_video_memory ... etc by default.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 9:23 AM, Igor said:

Not working MALI could be related to kernel command line, again ;) We are setting some no_video_memory ... etc by default.

 

Ok, I think the whole trusty/desktop approach needs a rework (X running not as root, optimised settings). There are also packages missing in trusty (sunxi-tools and man just to mention two). I will stay on trusty the next time (just to get an idea what's missing when trying to finalise armbianmonitor) but won't pay any attention to desktop/GUI/acceleration issues. Maybe someone else who's interested in this area might jump in so we end up with a performant desktop as well...

 

It would be also great if we get volunteers/maintainers of stuff like WiringOP on board (providing it as a .deb and so on) but for now I'm already happy that we got safe thermal/dvfs settings for the One and everything up and running with a single kernel image to start providing upgradeable images (we have to take care now since without exchanging script.bin a kernel update will render Ethernet unuseable on PC/2/One)

gilsken

gilsken

Posted
Posted

Hi,

I've just tried the last debian jessie in your release 5.01 on my orange pi pc and so far it's everything fine except that only one usb port is working and after installing the lxde I can't change my screen desktop resolution to FullHD 1920*1800.

 

Maybe it comes from my board or myself.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 10:13 AM, gilsken said:

except that only one usb port is working and after installing the lxde I can't change my screen desktop resolution to FullHD 1920*1800.

 

The USB issue is a bit strange (and normally a sign for wrong fex/script.bin settings). Changing resolution unfortunately requires also fex changes at the moment. In case you're a bit experienced then follow the steps on page 3 of this thread to install most recent fixes for 5.01 from this morning (also replace script.bin!) and then you would've to use bin2fex and fex2bin to convert /boot/bin/orangepipc.bin into a temporary fex file, then adjust the following (replace 4 with 10 two times) and convert back to orangepipc.bin afterwards:

screen0_output_mode = 10
screen1_output_type = 3
screen1_output_mode = 10

10 is 1080p (the default was 4 = 720p): http://linux-sunxi.org/Fex_Guide#disp_init_configuration

 

Later we will provide a utility called h3disp that adjusts that on the fly and we'll also try to get display config dynamically working so that every display resolution can be used. But at the moment our OS images are just preliminary test images and i doubt you'll have fun using X windows (at least my experience based on a short test this morning -- unbelievable slow since we didn't took care about desktop optimisation already)

jmarcelino

jmarcelino

Posted
Posted

Hi all,

I'm very new to Armbian, actually got interested due to the Orange Pi One. Looks like a cool project  :)

 

I compiled a Jessie build on Feb 14 which was working well on the One board and after reading the latest messages decided to try a newer build. 

However both the image on the site (  Jessie  ) and compiled from github (with all the latest commits) don't seem to boot.

 

Serial console just shows the below and hangs before showing a login prompt. Ethernet also never comes up.

After reverting to the Feb 14 image everything works well again.

 

 

  Reveal hidden contents

 

Any ideas or something I can try? I understand things are still shifting around but some of the replies above make me think this should be working on the One board at the moment.

Cheers

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 11:09 AM, jmarcelino said:

Serial console just shows the below and hangs before showing a login prompt. Ethernet also never comes up.

 

I would suspect that's the issue I described above: New unified kernel without fex tweaks. For the new kernel on Orange Pi PC/2/One two additional lines in the fex file are needed:

[gmac_phy_power]
gmac_phy_power_en   = port:PL08<1><default><default><0>

I updated an 5.00 image successfully with the debs and orangepione.bin from here: http://forum.armbian.com/index.php/topic/617-wip-support-for-the-upcoming-orange-pi-one/?p=5224

 

So please give this a try first and when building stuff on your own remember that you'll also need a modified script.bin containing the stuff above to work on PC/2/One from now on.

Igor

Igor

Posted
Posted

First change console to serial and loglevel to 8 that we will see something in the bootlog.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 11:25 AM, Igor said:

First change console to serial and loglevel to 8 that we will see something in the bootlog.

 

Maybe it's a good idea to enable this by default on the H3 images unless we consider them stable? And maybe adding "disp.screen0_output_mode=10" to boot.cmd (see new pull request)

1
jmarcelino

jmarcelino

Posted
Posted
  On 2/19/2016 at 11:24 AM, tkaiser said:

I would suspect that's the issue I described above: New unified kernel without fex tweaks. For the new kernel on Orange Pi PC/2/One two additional lines in the fex file are needed:

[gmac_phy_power]
gmac_phy_power_en   = port:PL08<1><default><default><0>

 

I think this setting is already in the tree? My latest build has this already.

 

  On 2/19/2016 at 11:25 AM, Igor said:

First change console to serial and loglevel to 8 that we will see something in the bootlog.

 

 

Thanks, just did that. Appreciate your help and patience while I learn the ropes.. 

 

I'm now seeing that the board is "crashing" in different ways, on one run I got this:

 

 

  Reveal hidden contents

 

 

on another it seemed worse:

 

 

  Reveal hidden contents

 

 

I'm guessing these are related to the voltage/speed changes?

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 1:19 PM, jmarcelino said:

I'm guessing these are related to the voltage/speed changes?

 

First thing I would check is whether /boot/script.bin is really linking to /boot/bin/orangepione.bin. You could also provide the whole boot output (put it on pastebin or use spoiler to hide it by default) also including u-boot messages since whether the correct script.bin was read can already be determinded there:

** File not found .next **
35704 bytes read in 684 ms (50.8 KiB/s)
4768760 bytes read in 4926 ms (945.3 KiB/s)

The size in the 2nd line has to match the size of /boot/bin/orangepione.bin.

 

Then I would immediately check the SD card you're booting off (just because I already wasted hours of my live searching problems in software when the hardware was to blame for. And fake/faulty SD cards are pretty common). Please check your card using either one of these tools before doing further investigation: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-prepare-sd-card

jernej

jernej

Posted
Posted

I hope you don't mind if I join your party :P

 

  On 2/18/2016 at 11:50 AM, tkaiser said:
There's still a bit to do. I'm already preparing h3disp (an utility that's only useful with 3.4.x since it will take script.bin and modify [hdmi_para] section to support different HDMI resolutions, patch the fex and convert back -- to be useable with Xunlong/loboris images too) but will first have a look into OpenELEC's/jernej's last patches that are display related since it would also be great to get fbset support to be able to use any display resolution possible.

My fbdev patch allows changing only to already supported resolutions on the fly, but you must be aware of two things:

1. video memory gets reserved at boot, so you can't change to resolution bigger than it was set at boot,

2. fbset changes only framebuffer resolution info, but doesn't actually switch to it in HW - that can be done via debugfs or disp2's ioctl interface

 

debugfs method:

sudo su
cd /sys/kernel/debug/dispdbg/
echo "switch" > command
echo "disp" > name
echo "4 5" > param
echo "1" > start

where 4 means HDMI output and 5 has the same meaning as in script.bin. For ioctl variant, which is more C friendly, you can check my Kodi patch.

 

Also one note on your unifying attempt and gmac patch / script.bin dilemma. Please check my github for updated patch. Idea behind it is that driver doesn't fail if there is no [gmac_phy_power] section in script.bin. That way you don't need to change script.bin at all.

 

And last but not least, if you want to use sy8106a patch on u-boot, you must update u-boot to version 2016.03-rc2.

2
tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 4:22 PM, jernej said:

I hope you don't mind if I join your party :P

 

Great, Igor already merged a pull request that's made totally of your stuff. Would also be great if someone else could look into your fallback for inappropriate script.bin settings (running out of time seriously)

 

I just wanted you to ask where the changes in script.bin regarding the GPIO pin definitions origin from? I thought the definition in loboris' script.bin would match already http://linux-sunxi.org/File:Xunlong_OrangePi_expansion_header_pinout.png

 

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

EDIT: Woohoo, changing resolution through /sys/kernel/debug/dispdbg/ really worked (from 1080p down to 720p). But I guess we need to figure out correct /etc/fb.mode entries since the display's contents were rather garbled afterwards :)

Igor

Igor

Posted
Posted
  Quote

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

Yes, I also noticed on Pi+ but haven't got time to check up what's going on... we are going very fast ;)

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 2/19/2016 at 5:00 PM, tkaiser said:

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

On Jessie it was related to default service stop timeout (90s) combined with wi-fi module unloading fail, so it was jessie and systemd specific problem, and shutdown/reboot still worked after that timeout.

 

I guess log from serial console should be the first thing to check.

jernej

jernej

Posted
Posted
  On 2/19/2016 at 5:00 PM, tkaiser said:

Great, Igor already merged a pull request that's made totally of your stuff. Would also be great if someone else could look into your fallback for inappropriate script.bin settings (running out of time seriously)

 

I just wanted you to ask where the changes in script.bin regarding the GPIO pin definitions origin from? I thought the definition in loboris' script.bin would match already http://linux-sunxi.org/File:Xunlong_OrangePi_expansion_header_pinout.png

 

@Igor: With trusty we have a nasty reboot problem. System hangs prior to rebooting. I can remember there was a similiar problem with jessie a while ago? But this might bug people since they never see firstrun being finished properly.

 

I made it myself. It's simple. Pin can be defined either as GPIO or something else, e.g. I2C, but not both at the same time. On orange pi forum was one idea, that at least one SPI and one I2C should be defined by default instead of GPIO. That's it.

 

I also won't have much time for developing in following days, but I will be able to write some posts.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 5:26 PM, jernej said:

I made it myself. It's simple. Pin can be defined either as GPIO or something else, e.g. I2C, but not both at the same time. On orange pi forum was one idea, that at least one SPI and one I2C should be defined by default instead of GPIO. That's it.

 

Ok, i'm concerned about the situation that different OS images use different pin definitions (if unfortunate users try a tutorial for RPi and fail on OPi that's one thing but if they follow one for OPi just to realise that they've to check which OS image they use... you get the idea?)

 

I always thought there would a 'common' definition (most probably made by loboris) exist. Already containing of strange exceptions (1-Wire on GPIO connector 37 instead of 7 for example). But I thought it would be a good idea to stay with this since there exist other projects like WiringOP too.

 

Until now I never dig deep into this, I just wanted to avoid reinventing the wheel with Armbian and being incompatible to 'pseudo standards'. And now I'm even more confused :)

 

I think still we should try to define as much pins as possible like on RPi and maintain compatibility somewhat. But have no idea how... Will try your modifications out next week anyway.

 

In the end it would be nice to have a coloured picture of all 40 pins on the GPIO header with function names that match reality.

 

  On 2/19/2016 at 5:23 PM, zador.blood.stained said:

I guess log from serial console should be the first thing to check.

 

Unfortunately there's not that much to see (no change the last 10 minutes):

 

 

  Reveal hidden contents

 

tkaiser

tkaiser

Posted
  • Author
Posted

BTW: Since I'm still curious regarding thermal behaviour on the different Orange Pis I simplified installation of RPi-Monitor a bit.

 

This script should do everything automagically and you can enjoy RPi-Monitor on Port 8888 afterwards (won't be in conflict with our future armbianmonitor approach so feel free to get a clue what your device does even today!)

 

If you trust me the most easy way to install is as root

wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-h3.sh | /bin/bash

But I would better download it and look through whether it's the same stuff as published here. Should also run flawlessly on any of the Debian based Xunlong or loboris images (many clueless Orange Pi One users over there in the forums might not have the slightest idea how they fry their boards without adopting sane dvfs settings)

jmarcelino

jmarcelino

Posted
Posted
  On 2/19/2016 at 1:33 PM, tkaiser said:

First thing I would check is whether /boot/script.bin is really linking to /boot/bin/orangepione.bin. You could also provide the whole boot output (put it on pastebin or use spoiler to hide it by default) also including u-boot messages since whether the correct script.bin was read can already be determinded there:

 

Then I would immediately check the SD card you're booting off (just because I already wasted hours of my live searching problems in software when the hardware was to blame for. And fake/faulty SD cards are pretty common). Please check your card using either one of these tools before doing further investigation: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-prepare-sd-card

 

Thanks for all the tips. I checked the microSD card using F3 to make sure - it found no problems. In fact the same card has no problems in the Feb 14 build of Armbian, I can just flash the old image and it works perfectly. I'm aware of the fakes but this is a Sandisk Ultra 32Gb UHS-I U1 from a reputable company.

 

I also checked the script.bin and it is linking correctly to /boot/bin/orangepione.bin

 

I'm attaching three full logs since it crashes for apparently random reasons, the first two terminate with "unable to handle kernel paging request at address" errors while another starts throwing lots of MMC errors - but as I explained the SD card tests perfectly.

 

I then flashed this same card immediately after the tests with the old Feb 14 build and the Orange Pi One booted without a hickup.

 

Just to make sure I then repeated the same with another - brand new - SanDisk Ultra SD card with exactly the same result.

 

http://pastebin.com/3aBd6xrY

http://pastebin.com/K8vWQcXs

http://pastebin.com/Z8jymkbP

 

Not sure if it matters but I'm powering the Orange Pi One via the 5V and GND pins (1 and 3) on the 40 pin connector from a 3A power supply.

 

I'm happy to test out any other ideas as I'm keen to get this working.

 

Cheers

tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 6:47 PM, jmarcelino said:

I'm happy to test out any other ideas as I'm keen to get this working.

 

Hmm... just some sort of 'brute force' attempt: Trying out an image that is known to work just to ensure that nothing in your build process corrupts anything: http://www.armbian.com/orange-pi-one/ Ok, realised that you already tried that. Unfortunately no idea what's going wrong. The image has been downloaded over a hundred times so I'm really clueless why it doesn't work for you.

zador.blood.stained

zador.blood.stained

Posted
Posted

@jmarcelino

Only common things for all 3 crashes - error messages start right after

Starting LSB: Tune IDE hard disks...

which is, I believe, startup of hdparm service. Can you try removing hdparm (or removing /etc/init.d/hdparm startup script) and check if anything changes?

jernej

jernej

Posted
Posted

@tkaiser,

I saw your talk on IRC about camera module. Be aware that "SATA fix" also enabled CSI port (well, one pin on it). It could be that this was (part of) the problem. I can't test it, because I don't have a camera module.

 

I really don't know what to do about GPIO configuration. RPi is in advantage here because you don't need to set functionality at boot AFAIK. I'm very glad that mainline kernel is coming along

jmarcelino

jmarcelino

Posted
Posted
  On 2/19/2016 at 7:02 PM, zador.blood.stained said: 
which is, I believe, startup of hdparm service. Can you try removing hdparm (or removing /etc/init.d/hdparm startup script) and check if anything changes?

Thanks Zador,

Unfortunately removing it didn't help, but you're right about the consistent location of the errors, the problems seem to start around:

 

 

  Reveal hidden contents

 
Do these values seem correct to you? This is using the latest build of the https://github.com/igorpecovnik/libtree.
 
I've also now tried a third, different brand and slower (Class 4) μSD card - hdparm removed - and the problem still persists but again slightly different output: http://pastebin.com/8wKpnwXz
 
I'll keep trying, maybe the next step is going back, reverting some of the patches to see which one caused these problems.
tkaiser

tkaiser

Posted
  • Author
Posted
  On 2/19/2016 at 8:16 PM, jernej said:

Be aware that "SATA fix" also enabled CSI port [...] I really don't know what to do about GPIO configuration.

 

Hmm... I applied your 'SATA fix' pretty late today so this seems not to be the culprit. I've to test on my own a bit more but fear that I'm not able to due to lack of spare time.

 

Regarding this GPIO thing. If we want to come up with something useful for all OPi users decisions have to be taken. Unfortunately I'm not that familiar with this stuff (user level -- I want to be able to use I2C, 1-Wire and SPI) so maybe the wrong people are talking here.

 

BTW: Do you guys (Igor and you) meet next week at Nuremberg or somewhere else (I ask since the only other guy called Jernej I know is from Slovenia -- one of the best times of my live being there working and constantly 'party hard')

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept