• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by dimag0g

  1. Hello, I have several ARM boards in my possession and I want to be able to boot them all from a single SD card (I have commercial SW which requires activation and is tied to a particular SD card afterwards). So far, I have made this script which creates multiple /boot-boardname directories, replaces /boot with a symlink to one of those, and makes sure the right u-boot is written to the card. However, I have one little problem I couldn't yet solve: I would like to generate the correct /etc/modules file for a new board, and I don't know how. For example, Orange Pi Zero needs this xradio_wlan module for WIFI. Where do I find the info that this module is needed? As far as I understand, /etc/modules file doesn't belong to a package and is generated by installation scripts, but I couldn't find which ones. Could someone point me in the right direction?
  2. Well, that's what the tutorial tell you to do, right? Anyway, I believe there is a pre-built package for xf86-video-fbturbo in armbian, so it may be worth a try to use that.
  3. Hard to say why that is happening, since I don't use Ubuntu. My first guess would be that libGL.so.1 is stored elsewhere, or is named slightly differently, so you didn't actually replace it.
  4. Note that glshim cannot work until you have mali GLES driver working, so you should concentrate on making that mali test running. I'll try to look into your issue this weekend.
  5. Good to know. Feel free to report any OpenCPN-specific bugs if you encounter any. I cannot guarantee anything but I will take a look.
  6. You will need hardware GLES for glshim OpenGL wrapper, so you'll need sunxi-mali driver which only works with 3.x legacy kernel. glshim itself is just a library which can be built for virtually any distro (it was originally developed for Angstrom Linux).
  7. Banana Pi M1 has the same SoC as banana Pi Pro, so it should work just as well. I cannot help you without the exact error message you're getting. Please post the exact command which fails and its output. Note that Zador has already integrated this GL wrapper in mainstream build script, so it will be available in desktop version of Armbian soon.
  8. A few follow-up questions: Are you referring to 'extras-buildpkgs' directory? I'm having trouble using that. I have created a conf file and a package directory with a control file, but the package is not getting built. Now, I have noticed a line in 'main.sh' saying: main.sh:[[ $EXTERNAL_NEW == yes && $(lsb_release -sc) == xenial ]] && chroot_build_packages Does that mean I need to be on Ubuntu Xenial to get this working? Right now I'm building my package via a custom sh script in 'extras' folder. I didn't run into any compiler problems yet. I remember (from some time ago) that GCC 4.7 or 4.8 had troubles building a working ARM kernel, so one had to use either 4.3 or 4.9. I'm pretty sure the bug is now fixed. Honestly, I don't know. These lines were carried over from some tutorial, and I'm not sure they are needed. I'm building without this step and I will only do the file replacement if the problems arise. Edit: I've made a commit with the build script, based on similar scripts I've found in extras. I also had to modify 'desktop.sh' so it doesn't fail when my scripts leaves an unconfigured package over (it has to, since glshim depends on Mali driver and fbturbo). The scripts is to be used with BUILD_DESKTOP and works fine on both boards I have (bananapipro/sun7i and orangepi/sun8i).I will continue working towards a solution using 'extras-buildpkgs' folder.
  9. Discussion thread for github issue 423 - glshim packaging. Related discussion is here. Glshim development happens here. Current status: build script is mostly working, I'm fixing minor issues before making a github commit: - avoid hardcoded dependencies - make sure OpenGL apps can be built on target system Once these are resolved, I'll post a link to my commit for an eventual review and will be ready to create a pull request. ---------- Unrelated topic: armbian build script fixes for Debian Jessie Although only Ubuntu distribution is supported by armbian build scripts, Debian sid and above have all the necessary packages and should work fine. For Debian Jessie, emdebian repository should be added to apt sources, as described in cross toolchains wiki. Some of the cross toolchain packages have different names on Jessie as well. I have modified lib/general.sh file to account for those differences and be able to run armbian build scripts on my Debian Jessie machine. If there is interest, I could create an additional issue / pull request for this.
  10. That would certainly be useful for me. I'm not sure if covering all the cases is necessary, but at least there should be an option to refrain from extending root, or choose its future size. I had to shrink it back to 12 GB on my 32 GB card to accomodate the other partition I needed (/opt)
  11. It's enough to play Minecraft, OpenArena, Torcs and Nexuiz, just to name a few (when I say ehough I mean solely OpenGL API version, GPU and CPU performance can be sufficient or not for a decent gameplay).
  12. Pardon my ignorance, but what is CHIP (a very unfortunate name to google for)? Is it rockchip SoC? And yes, OpenGL is primarly needed for games (you have stuff like openscad, but I don't expect to meet many users here). You make it sound like games are not a big deal, or not normal usage. I bet many people would see it as a big advantage if they could run 3D games on their boards.
  13. I have a bunch of questions, (I hope I don't waste your time with these, feel free to tell if I do): Do you refer to "legacy" images here? Am I right that Mali is only usable with the old 3.x kernel? This is handled by desktop.sh when going from CLI to desktop, right? Is the rollback to be done manually when going from desktop to CLI? Well, I fully agree. I switched from bananian to armbian exactly because of how you guys have packaged everything nicely. I just wanted to show you what I've done to understand if people are interested in this. Also, I'm not familiar with debian packaging system, so it would be hard for me to share *.deb files from the start (and I'd do the double work for all the packages you already have, as it turned out)
  14. I didn't try any video players, though I'm pretty sure GLX won't beat VDPAU for video rendering. I tested X11 one.
  15. It's OpenGL (GLX to be precise) emulated via hardware-accelerated GLES. What would be the use of only GLES anyway? Most games in Debian repo require OpenGL, don't they? Well, it's far from perfect I admit, but it's definitely usable, and I don't see the alternative. It's not like OpenGL games are getting GLES ports soon. I don't have the intention to push anything though, only to share. If you feel that armbian is better off without OpenGL than with a buggy one, I won't argue. PS. It looks like I went through many unnecessary steps here by picking the wrong image. I didn't see a desktop image for Banana Pi and it felt like desktop images were not so stable yet.
  16. Hi, I've done some tweaks to make OpenGL games work on my Mali boards (simple games like billard-gl work, openarena does start but it's a strech to call it fully playable). It's not finished yet, but the results are already usable despite occasional bugs. Would you consider adding a package which is not 100% stable? I don't have any experience with packaging scripts, but I can try. I'm taking 2 weeks of holiday in July, I'm pretty sure I will have time to do it by the end of the month. Another question is about changing the kernel configuration. Since OpenGL is implemented via GLES, it's necessary to give a share of RAM to Mali GPU. How should my hypothetical package go about changing /boot/boot.scr? Disclamer: I'm not the author of this GL library, those guys are.
  17. Hello, I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well. Here are the commands I used to get OpenGL to work. 1. Install: # install GLX Gears, mesa GL and GLU libraries apt-get -y install mesa-utils # install development tools apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion # install required libraries apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev # get source code git clone https://github.com/robclark/libdri2 git clone https://github.com/linux-sunxi/libump git clone https://github.com/linux-sunxi/sunxi-mali git clone https://github.com/ssvb/xf86-video-fbturbo git clone https://github.com/ptitSeb/glshim # install mali driver cd sunxi-mali git submodule init git submodule update git pull wget http://pastebin.com/raw.php?i=hHKVQfrh -O ./include/GLES2/gl2.h wget http://pastebin.com/raw.php?i=ShQXc6jy -O ./include/GLES2/gl2ext.h make config ABI=armhf VERSION=r3p0 mkdir /usr/lib/mali echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf make -C include install make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install cd .. 2. Build # Step 1: build and install helper libraries cd libdri2 autoreconf -i ./configure --prefix=/usr make make install cd .. cd libump autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 2: build video driver cd xf86-video-fbturbo autoreconf -i ./configure --prefix=/usr make make install cd .. # Step 3: build GL wrapper cd glshim cmake . make cp lib/libGL.so.1 /usr/lib/ # replace the software GL library with the wrapper cd .. 3. Configure your system - configure your kernel to allocate memory for the GPU - make sure mali and mali_drm kernel modules are loaded - give your user permissions to access /dev/ump and /dev/mali - configure Xorg to use fbturbo driver 4. Test: # run a basic test glxgears # install and run a GL benchmark apt-get -y install globs /usr/lib/globs/benchmarks/GL_pointz/gl_pointz # try to run a real game apt-get -y install billard-gl billard-gl This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL. Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound): user@bananapi:~$ glxgears LIBGL: Initialising glshim libGL: built on Jun 12 2016 06:12:01 LIBGL: Current folder is:/home/user libGL:loaded: libGLESv1_CM.so libGL:loaded: libEGL.so 2074 frames in 5.0 seconds = 414.688 FPS 2071 frames in 5.0 seconds = 414.085 FPS 2070 frames in 5.0 seconds = 413.915 FPS ^C