• Posts

  • Joined

  • Last visited

Everything posted by Ucino

  1. I'm newbie about drivers and compiling things, so becarefull of what I'm writting, it's certainly wrong. You maybe have 3 possibilities : 1) - copy and past a file (this what I have done one time : 2) - compiling the full armbian and adding to him the patch during compiling ( cf. https://docs.armbian.com/Developer-Guide_Build-Preparation/ ) 3) - or compiling inside your armbian. When we are looking in https://github.com/avafinger/gc2035 we can see at the end of the page an example of compiling for BSP, so it seems that the right way is the option 3). It seems that you will have to adapt things of the compiling step : make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j2 INSTALL_MOD_PATH=output SUBDIRS=drivers/media/video/sunxi-vfe/device modules CC [M] drivers/media/video/sunxi-vfe/device/gc2035.o Building modules, stage 2. MODPOST 40 modules CC drivers/media/video/sunxi-vfe/device/gc2035.mod.o LD [M] drivers/media/video/sunxi-vfe/device/gc2035.ko But I'm sorry, I have no idea on how you can adapt this for armbian. Maybe, after you have done a backup of your files and OS, you can give it a try, and tell us the result ?
  2. Cool if it works. Sorry I didn't remember about the content of gc2035 on github . If it's works fine for you, maybe you have nothing to do ? Why do you think you have to care about it, maybe you have some other problems with the video ?
  3. Thanks for your feedback. As olivluca suggest, I think the first step you can try to do is using the 3.X kernel : https://www.armbian.com/orange-pi-lite/ at the end of the page : https://dl.armbian.com/orangepilite/Ubuntu_xenial_default_desktop.7z I hope it will works, please tell us the result.
  4. Hello, An other way to have Firefox working easily : using synaptic we can downgrade from 61 to 45 and firefox don't crash, on OPiPC+ with Armbian_5.38_Orangepipcplus_Ubuntu_xenial_default_3.4.113_desktop
  5. Hello, Could you tell us which nano computer you are using, which version of armbian, and which camera ? thanks
  6. Hello, Have you tried to connect the ribbon differently ? For me only as this it was working : https://lightpics.net/i/PyuE
  7. Ok thanks a lot for these informations.
  8. Thanks a lot for your reply. As I'm using CSI camera, it seems that I need for the moment legacy. On https://dl.armbian.com/orangepipcplus/ Debian Strech next is mainline, no ? So the best choice could be Debian Jessy Default for motion eye + CSI camera ?
  9. Very nice ! Have you made some special setup of motioneye ? I'm using armbian ubuntu desktop (but without screen), maybe you use a headless version ? Or maybe it's because of I'm using wifi with an important distance ?
  10. I have made some tests. It's not with USB but with CSI camera of orange pi, on orange pipc+ + armbian ubuntu desktop (but used without screen) & using a debian laptop to connect to the opipc+ If I do : General settings > advanced settings > on Video device > Frame rate > 20 Resolution > 640 x 480 (was by default) I have a better framerate : 10 / 12 fps.
  11. Ok I think I have understood the problem : There is a difference between boot and reboot... nano /etc/rc.local is for booting but not for reboot. So if I add : sunxi-pio -m "PG11<1><0><1><1>" modprobe gc2035 modprobe vfe_v4l2 exit 0 to /etc/rc.local with root user AND I shutdown the system, it's working, If iI just reboot, it's not working after having edited /etc/rc.local , we have to shutdown and boot...
  12. Thanks for this information, that's good news that there is these progress. Using CSI or USB the framerates are both identical and low (3 - 5fps) using only streaming , i have also no idea if it's because of motionEye default configuration, because I use OrangePiPC+, or other reasons :/ However it's enough for what I'm trying to do (a camera to put in birdhouse for the school project with orangepipc+). oh ok, thanks for your feedback.
  13. @Tom_Neverwinter With ubuntu desktop armbian legacy and following this : the orange pi CSI camera worked for me with motioneye.
  14. Hello, I'm trying to use the CSI Orange Pi camera on orange Pi PC+, with motionEye, with Armbian Legacy Ubuntu desktop stable for OrangePiPC+ ( 5.38 | armhf | armv7l | 3.4.113-sun8i ) here is the armbianmonitor -u http://ix.io/YDB I wasn't able to use the camera but running with this in the terminal, it works ! Thanks. su root sunxi-pio -m "PG11<1><0><1><1>" modprobe gc2035 modprobe vfe_v4l2 However, when I reboot it is not working, and I have to reenter these commands. Doing this : su root nano /etc/rc.local I tried all the modification described in this thread (copy past, without modifying it, and alwas leaving the "exit 0" at the end) of rc.local but it's not working by defaut, I have to manually enter su root sunxi-pio -m "PG11<1><0><1><1>" modprobe gc2035 modprobe vfe_v4l2 in order to use the camera. Someone have any tips on how can I make the camera working by default ? Maybe I have to adapt the commands of the rc.local ? If yes, someone know I can find some information in order to adapt it ? @StuxNet here a photo : https://lightpics.net/i/PyuE Thanks
  15. @Moklev thanks a lot for yours indications it has worked very fine for me Important to know : CSI seems not be supported yet in mainline, so the orange pi camera will not work in armbian debian mainline ([edit] maybe it works now, and maybe this was because of a problem with the driver, please see the second reply below.)
  16. I have made some tests on OrangePi PC+ with : * Armbian_5.38_Orangepipcplus_Ubuntu_xenial_default_3.4.113_desktop * Armbian_5.38_Orangepipcplus_Debian_stretch_next_4.14.14_desktop For the moment I will choose Debian, for this reasons with my tests: * the policies of the debian project ; * launching for the fist time debian, there is no need to run the screen sizing tool and reboot, and Ubuntu nned it, so it's more KISS for non geek users; * launching for the fist time debian, there is no need to adjust horizontally and vertically the screen, ubuntu need it; * tested on 2 VGA screen with distinct resolutions, debian desktop was displayed perfectly, and ubuntu desktop not (it was resized). This new debian version for OpiPC+ is really a big improvement for the project for schools. It seems that there is nothing to do with the screen resolutions, it will be very much easier to deploy in schools for non geek user, thanks a lot to the armbian team!
  17. @richard1937 hello From my little experience, running CAD & slice software on arm is not very easy for the moment. But using appimage could be a nice way. On OPiPC+, OpenScad can run with appimage but for the slic3r prusa edition slicers it seems that is not possible for the moment. If you want more information about these 2 tools, please tell me.
  18. Hello, I'm following this project : I was recently spending time on the activities to do with children, 3D printing and robotics, and in order to be able to try to follow https://docs.armbian.com/Developer-Guide_Build-Preparation/ i have bought a new laptop which respect the requirements (SSD, ram...). So now my next goal is to try to make a custom version of armbian dedicated to the schools. To start, for the first step, I would like to try make a localized version of armbian in French by default, in order to be more easier for the French speaking user. With the new evolutions of armbian for OrangePiPC+, there is an ubuntu desktop version, and now a Debian version (thanks for the armbian team for these improvements). I would like to know if there is recommendations, pros and cons for choosing ubuntu or Debian. The context that can maybe have an impact on the choice could be : - the compatibility with VGA screen (as it's for schools lot of old screen are used) ; - the computer will be used for 3D activities (blender, openscad...) ; - I have never made a compilation of an OS (but I'm motivate to learn it with the armbian doc). Is there any advice to choose ubuntu legacy or Debian stretch ? Thanks, Best regards
  19. Here the instructions to build openscad for armf (workaround) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797816#37 (openscad build log for debian stretch raspbian on armhf pi3 was able to successfully build with qt4.)
  20. Big thanks to t-paul that just greatly solved the problem, he made an appimage of OpenScad using OBS : https://github.com/openscad/openscad/issues/1849#issuecomment-340319476 that works perfectly on armbian for OrangePiPC+.
  21. Here the reply of Chrysn that have participate on this report: openscad FTBFS in armhf due to conflict declaration of headers gl3.h and glew.h https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797816 Thanks a lot for his help. >>But openscad 2015 or after versions seems so to not be able to run on it, because there isn't armhf. " >> it seems that we have a build for arm64, but not armel and armhf. armel and armhf support are missing because cgal's qt5 support apparently can't run on >>those architectures due to missing OpenGL ES support. >>TL;DR: If you get cgal working on your architectures of interest, openscad should work too. OpenSCAD may need some changes of its own, but yes, much of the GLES conflict comes from CGAL, and the ARM boards only supporting GLES and not OpenGL 2 on their GPUs. Unless your boards support full OpenGL (in which case building an alternative set of GLES-free qt packages, ideally from within Debian, might become an option), IMO your best bet is to talk to OpenSCAD authors directly as to * what needs to be done on their side to get GLES support * whether they intend to stick with CGAL for rendering or whether that will be replaced anyway (there's a hint about that at [1]). The ticket for that at OpenSCAD is at [1]. I have not found anything on GLES at CGAL itself[2], might be worth opening an issue there if OpenSCAD sticks with CGAL. If, as you suggested, you have funds or the team for pushing this through a crowdfunding run, I think you'd best directly get involved with the (OpenSCAD and possibly CGAL) authors; the software not being available with GLES is not something that the distributions chose not to do, but a consequence of several programs/libraries not being GLES compatible. (If, as mentioned, you *do* have full OpenGL 2 support on those boards, things are different and we probably can do something on the distribution side.) Best regards chrysn [1]: https://github.com/openscad/openscad/issues/292 [2]: https://github.com/CGAL/cgal/issues?utf8=✓&q=gles And here my reply : [...] It seems that the first thing that I have to do is checking if there is a full OpenGL 2 support on those boards. The actual card I'm thinking about is OprangePIPC+ (I'm actually trying to see if they are agree to add an open hardware licence on their design files). I'm sorry I'm newbie for a lot of these things, but it seems that : Reading this https://www.aliexpress.com/store/product/Orange-Pi-PC-Plus-ubuntu-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32668618847.html I can see that they use "Mali400MP2 GPU@600MHz - support OpenGL ES 2.0" Following the advice of a member of the armbian community, I have used the armbian legacy ubuntu desktop, that seems to support the Mali GPU (it seems that the mainline doesn't, for the moment). It seems that running glmark2-es2 could give us more information about the support of OpenGL. This is what i have when running it on this card : https://framabin.org/?8be45841bb8b2f22#2Zvv+aSMD1q5IVC6qKEwCo9bxPrBUbDaeR9FImX1qzM= (3 errors and a glmark2 score of 77). Do you know if it means that we have a full support on this card of OpenGL 2, and so the things are different, or it's not supported, and so I have to contact OpenScad author as you told me ?
  22. The AppImage way is explored here : https://github.com/openscad/openscad/issues/1849#issuecomment-336590336 Thanks a lot to t-paul that will help to investigate this way. t-paul have used OBS to build openscad package : https://build.opensuse.org/package/show/home:t-paul/OpenSCAD
  23. Here is the answer of Joachim, the CGAL maintainer, thanks a lot to him for his reply : About armel: CGAL does not work on this platform since it does not have FPU rounding mode support. I doubt that anyone will implement this ever, and even if it happened, it will probably way too slow anyway. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838496 About armhf: Interesting to see that there are people interested in CGAL for armhf. However, I'm just the Debian maintainer for CGAL, and I believe this is not a Debian-specific issue, but support for OpenGL ES (on armhf and/or other platforms) should be implemented in CGAL itself. I'd suggest that you write to their user mailing list cgal-discuss@inria.fr and state your case. See https://www.cgal.org/mailing_list.html This technical feature is probably not that interesting from the point of view of researchers. But there is also a company called GeometryFactory (members are also on that mailinglist) that provides paid services around CGAL. Maybe that's an option ... I have no idea about the complexity of this feature. You should probably check whether your processor is fast enough for the planned use case. However, I don't know how to do in a good way without implementing the feature. It seems that libqglviewer does not (yet) support armhf either. At least for recent versions of the software there is no Debian package for armhf: https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=libqglviewer