Igor Posted August 16, 2016 Posted August 16, 2016 To continue from here.Actually it works the way repository is build together: host Debian Jessie, and then I changed release, update. Now we only have jessie desktop packages, so it looks ok. # armbian.list deb http://apt.armbian.com jessie main utils desktop ... Ign http://apt.armbian.com jessie/desktop Translation-en_US Ign http://apt.armbian.com jessie/desktop Translation-en Ign http://apt.armbian.com jessie/desktop Translation-en_US.UTF-8 Ign http://apt.armbian.com jessie/main Translation-en_US Ign http://apt.armbian.com jessie/main Translation-en Ign http://apt.armbian.com jessie/main Translation-en_US.UTF-8 Ign http://apt.armbian.com jessie/utils Translation-en_US Ign http://apt.armbian.com jessie/utils Translation-en Ign http://apt.armbian.com jessie/utils Translation-en_US.UTF-8 # armbian.list deb http://apt.armbian.com xenial main utils desktop ... Ign http://apt.armbian.com xenial/main Translation-en Ign http://apt.armbian.com xenial/main Translation-en_US.UTF-8 Ign http://apt.armbian.com xenial/utils Translation-en_US Ign http://apt.armbian.com xenial/utils Translation-en Ign http://apt.armbian.com xenial/utils Translation-en_US.UTF-8
zador.blood.stained Posted August 16, 2016 Posted August 16, 2016 Packages have exact same names and file names, so importing packages built for Xenial overwrites ones from Jessie. While "utils" part should be fine (and I should revert to building only for one target and having only one component for all distributions), desktop packages should be separated to "jessie-desktop" and "xenial-desktop" components.
wildcat_paris Posted August 16, 2016 Posted August 16, 2016 zador.blood.stain : Second, speaking of wireless drivers, ideally they should be packaged with dkms similar to existing r8168-dkms and rtl8812au-dkms. This should improve reliability of kernel upgrades (if dkms works correctly, needs to be tested). FYI : we get to dkms "my" frandom-dkms debian package doesn't work properly with Armbian but works fine with Ubuntu (x86) so I guess there is a dkms configuration (or keeping at least one previous kernel... I have seen on TJoe channel something about uboot and grub2)... the source for frandom-dkms is the same for ARM and x86 short: when the last active kernel is removed (as when a new kernel is installed on Armbian) the remaining dkms packages are removed as considered "useless" (there is no longer any kernel suitable) so for months I had to dpkg -i frandom-dkms*.deb after an Armbian kernel upgrade I have no solution excepted on Ubuntu there is always the previous kernel installed as a failover so frandom-dkms is not removed.
Igor Posted August 16, 2016 Author Posted August 16, 2016 Packages have exact same names and file names, so importing packages built for Xenial overwrites ones from Jessie. While "utils" part should be fine (and I should revert to building only for one target and having only one component for all distributions), desktop packages should be separated to "jessie-desktop" and "xenial-desktop" components. Huh. I actually prepared this way, but forgot and now I only merged utils into one. Summary example: [ o.k. ] List of local repos [ local ] * [jessie-desktop]: Armbian desktop (packages: 41) * [jessie]: Armbian main repository (packages: 36) * [trusty-desktop]: Armbian desktop (packages: 41) * [trusty]: Armbian main repository (packages: 36) * [utils]: Armbian utilities (packages: 7) * [wheezy-desktop]: Armbian desktop (packages: 0) * [wheezy]: Armbian main repository (packages: 36) * [xenial-desktop]: Armbian desktop (packages: 0) * [xenial]: Armbian main repository (packages: 36) I guess it should work now. Which issues are still regarding repo? dkms - agree it would be nice to do the proper way but I won't touch this at the moment. 1
zador.blood.stained Posted August 16, 2016 Posted August 16, 2016 There should not be any issues, but there are small fixes/adjustments pending: Disable building utils on Xenial Rebuild FFmpeg and mpv since I bumped upstream versions Disable extras/hostapd building and delete unused files Disable building sunxi-tools in armbian-utils Add new repository components during debootstrap process If user wants to build desktop images, make an option to use existing packages from apt.armbian.com instead of building all from scratch
zador.blood.stained Posted August 16, 2016 Posted August 16, 2016 "my" frandom-dkms debian package doesn't work properly with Armbian but works fine with Ubuntu (x86) so I guess there is a dkms configuration (or keeping at least one previous kernel... I have seen on TJoe channel something about uboot and grub2)... the source for frandom-dkms is the same for ARM and x86 short: when the last active kernel is removed (as when a new kernel is installed on Armbian) the remaining dkms packages are removed as considered "useless" (there is no longer any kernel suitable) so for months I had to dpkg -i frandom-dkms*.deb after an Armbian kernel upgrade I have no solution excepted on Ubuntu there is always the previous kernel installed as a failover so frandom-dkms is not removed. Assuming your package name is "frandom-dkms", can you provide output of apt-cache show frandom-dkms dpkg -L frandom-dkms and output from upgrading the kernel (or simulation aka "apt-get -s") when it removes the package?
wildcat_paris Posted August 16, 2016 Posted August 16, 2016 Assuming your package name is "frandom-dkms", can you provide output of apt-cache show frandom-dkms dpkg -L frandom-dkms and output from upgrading the kernel (or simulation aka "apt-get -s") when it removes the package? so if I can help a bit Authenticating with public key "clef_golfromeo2015" from agent _ _ ____ _ | | __ _ _ __ ___ ___ | |__ ___ | _ \/ | | | / _` | '_ ` _ \ / _ \| '_ \ / _ \ | |_) | | | |__| (_| | | | | | | (_) | |_) | (_) | | _ <| | |_____\__,_|_| |_| |_|\___/|_.__/ \___/ |_| \_\_| Welcome to ARMBIAN Ubuntu 14.04.5 LTS 4.6.4-sunxi 0 updates to install. 0 are security updates. System load: 0.15 Up time: 2 days Memory usage: 18 % of 1000Mb IP: 192.168.xx.xx 86.xx.xx.xx CPU temp: 37°C HDD temp: 43°C Usage of /: 39% of 15G storage/: 3% of 116G Last login: Tue Aug 16 17:43:43 2016 [gr@bpi:~] $ apt-cache show frandom-dkms Package: frandom-dkms Status: install ok installed Priority: extra Section: contrib/kernel Installed-Size: 76 Maintainer: Centrych Packages <packages@centrych.org> Architecture: armhf Source: frandom Version: 1.1-0centrych4 Depends: dkms (>= 2.1.0.0), make Conffiles: /etc/init.d/frandom 41d05425ddc1deb73ae7b96b98a9fa52 Description: kernel module for a fast random number generator Both frandom and erandom generate random data very fast, with the algorithm that is used in the alledged RC4 cipher. Description-md5: aa2d3a2e035ecbf609f0e3358ae8015f [gr@bpi:~] $ dpkg -L frandom-dkms /. /etc /etc/init.d /etc/init.d/frandom /lib /lib/udev /lib/udev/rules.d /lib/udev/rules.d/10-frandom.rules /usr /usr/share /usr/share/doc /usr/share/doc/frandom-dkms /usr/share/doc/frandom-dkms/README.gz /usr/share/doc/frandom-dkms/changelog.Debian.gz /usr/share/doc/frandom-dkms/copyright /usr/share/frandom /usr/share/frandom/test.sh /usr/src /usr/src/frandom-1.1 /usr/src/frandom-1.1/frandom.c /usr/src/frandom-1.1/dkms.conf /usr/src/frandom-1.1/Makefile dpkg dry-run is not very useful [gr@bpi:/armbian_kernel/kern_4.6.4_1] $ ls linux-dtb-next-sunxi_5.17_armhf.deb linux-headers-next-sunxi_5.17_armhf.deb linux-trusty-root-next-lamobo-r1_5.17_armhf.deb linux-firmware-image-next-sunxi_5.17_armhf.deb linux-image-next-sunxi_5.17_armhf.deb linux-u-boot-next-lamobo-r1_5.17_armhf.deb [gr@bpi:/armbian_kernel/kern_4.6.4_1] $ sudo apt-get -s [sudo] password for gr: E: Command line option 's' [from -s] is not known. [gr@bpi:/armbian_kernel/kern_4.6.4_1] 100 $ man apt-get You have new mail in /var/mail/gr [gr@bpi:/armbian_kernel/kern_4.6.4_1] $ man dpkg [gr@bpi:/armbian_kernel/kern_4.6.4_1] $ sudo dpkg -i --dry-run *.deb (Reading database ... 175622 files and directories currently installed.) Preparing to unpack linux-dtb-next-sunxi_5.17_armhf.deb ... Preparing to unpack linux-firmware-image-next-sunxi_5.17_armhf.deb ... Preparing to unpack linux-headers-next-sunxi_5.17_armhf.deb ... Preparing to unpack linux-image-next-sunxi_5.17_armhf.deb ... Preparing to unpack linux-trusty-root-next-lamobo-r1_5.17_armhf.deb ... Preparing to unpack linux-u-boot-next-lamobo-r1_5.17_armhf.deb ... it is probably time I create a new set of Armbian kernel deb for my lamobo-R1 (kernel 4.6.4 is old), I post the dpkg execution when possible just out of curiosity dkms.conf file contains [gr@bpi:/armbian_kernel/kern_4.6.4_1] 130 $ cat /usr/src/frandom-1.1/dkms.conf PACKAGE_NAME="frandom" PACKAGE_VERSION="1.1" BUILT_MODULE_NAME[0]=frandom DEST_MODULE_LOCATION[0]=/updates/dkms AUTOINSTALL=yes
wildcat_paris Posted August 16, 2016 Posted August 16, 2016 Here are the logs of the kernel 4.6.7 upgrade (removal of frandom-dkms, then reinstall of frandom-dkms) note: I have only noticed now the dkms files were removed but not the package in deb packaging system. [gr@bpi:/armbian_kernel/kern_4.6.7_1] $ ls linux-dtb-next-sunxi_5.17-GRO_armhf.deb linux-image-next-sunxi_5.17-GRO_armhf.deb linux-firmware-image-next-sunxi_5.17-GRO_armhf.deb linux-trusty-root-next-lamobo-r1_5.17-GRO_armhf.deb linux-headers-next-sunxi_5.17-GRO_armhf.deb linux-u-boot-next-lamobo-r1_5.17-GRO_armhf.deb [gr@bpi:/armbian_kernel/kern_4.6.7_1] $ sudo dpkg -i *.deb [sudo] password for gr: (Reading database ... 175622 files and directories currently installed.) Preparing to unpack linux-dtb-next-sunxi_5.17-GRO_armhf.deb ... Unpacking linux-dtb-next-sunxi (5.17-GRO) over (5.17) ... Preparing to unpack linux-firmware-image-next-sunxi_5.17-GRO_armhf.deb ... Unpacking linux-firmware-image-next-sunxi (5.17-GRO) over (5.17) ... Preparing to unpack linux-headers-next-sunxi_5.17-GRO_armhf.deb ... Unpacking linux-headers-next-sunxi (5.17-GRO) over (5.17) ... dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/scripts/basic': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/scripts/kconfig': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/scripts/dtc': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/scripts/mod': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/scripts': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/arch/arm/include/generated': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/arch/arm/include': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/arch/arm': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi/arch': Directory not empty dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.6.4-sunxi': Directory not empty Preparing to unpack linux-image-next-sunxi_5.17-GRO_armhf.deb ... dkms: removing: frandom 1.1 (4.6.4-sunxi) (armhf) -------- Uninstall Beginning -------- Module: frandom Version: 1.1 Kernel: 4.6.4-sunxi (armhf) ------------------------------------- Status: Before uninstall, this module version was ACTIVE on this kernel. frandom.ko: - Uninstallation - Deleting from: /lib/modules/4.6.4-sunxi/updates/dkms/ - Original module - No original module was found for this module on this kernel. - Use the dkms install command to reinstall any previous module version. depmod.... DKMS: uninstall completed. ------------------------------ Deleting module version: 1.1 completely from the DKMS tree. ------------------------------ Done. Removing obsolete file initrd.img-4.6.4-sunxi Unpacking linux-image-next-sunxi (5.17-GRO) over (5.17) ... Preparing to unpack linux-trusty-root-next-lamobo-r1_5.17-GRO_armhf.deb ... mv: cannot move ‘/boot/bin’ to ‘/boot/bin.old/bin’: Directory not empty Unpacking linux-trusty-root-next-lamobo-r1 (5.17-GRO) over (5.17) ... Preparing to unpack linux-u-boot-next-lamobo-r1_5.17-GRO_armhf.deb ... Unpacking linux-u-boot-lamobo-r1-next (5.17-GRO) over (5.17) ... Setting up linux-dtb-next-sunxi (5.17-GRO) ... Setting up linux-firmware-image-next-sunxi (5.17-GRO) ... Setting up linux-headers-next-sunxi (5.17-GRO) ... Compiling headers - please wait ... Setting up linux-image-next-sunxi (5.17-GRO) ... update-initramfs: Generating /boot/initrd.img-4.6.7-sunxi cryptsetup: WARNING: failed to detect canonical device of /dev/mmcblk0p1 cryptsetup: WARNING: could not determine root device from /etc/fstab Setting up linux-trusty-root-next-lamobo-r1 (5.17-GRO) ... Setting up linux-u-boot-lamobo-r1-next (5.17-GRO) ... Processing triggers for initramfs-tools (0.103ubuntu4.4) ... update-initramfs: Generating /boot/initrd.img-4.6.7-sunxi cryptsetup: WARNING: failed to detect canonical device of /dev/mmcblk0p1 cryptsetup: WARNING: could not determine root device from /etc/fstab Processing triggers for ureadahead (0.100.0-16) ... [gr@bpi:/armbian_kernel/kern_4.6.7_1] $ cd .. [gr@bpi:/armbian_kernel] $ ls dpsysquery.sh kern_4.5.3_1 kern_4.6.2_1 kern_4.6.3_1 kern_4.6.7_1 mod_noreboot.sh~ frandom-dkms_1.1-0centrych4_armhf.deb kern_4.5.5_3 kern_4.6.2_2 kern_4.6.4_1 mod_noreboot.sh mod_noreboot.sh.keep [gr@bpi:/armbian_kernel] 1 $ sudo dpkg -i frandom-dkms_1.1-0centrych4_armhf.deb (Reading database ... 175622 files and directories currently installed.) Preparing to unpack frandom-dkms_1.1-0centrych4_armhf.deb ... Removing any system startup links for /etc/init.d/frandom ... /etc/rc0.d/K20frandom /etc/rc1.d/K20frandom /etc/rc2.d/S99frandom /etc/rc3.d/S99frandom /etc/rc4.d/S99frandom /etc/rc5.d/S99frandom /etc/rc6.d/K20frandom Unpacking frandom-dkms (1.1-0centrych4) over (1.1-0centrych4) ... Setting up frandom-dkms (1.1-0centrych4) ... Adding system startup for /etc/init.d/frandom ... /etc/rc0.d/K20frandom -> ../init.d/frandom /etc/rc1.d/K20frandom -> ../init.d/frandom /etc/rc6.d/K20frandom -> ../init.d/frandom /etc/rc2.d/S99frandom -> ../init.d/frandom /etc/rc3.d/S99frandom -> ../init.d/frandom /etc/rc4.d/S99frandom -> ../init.d/frandom /etc/rc5.d/S99frandom -> ../init.d/frandom Loading new frandom-1.1 DKMS files... It is likely that 4.6.4-sunxi belongs to a chroot's host Building only for 4.6.7-sunxi Building for architecture armhf Building initial module for 4.6.7-sunxi Done. frandom: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.6.7-sunxi/updates/dkms/ depmod.... DKMS: install completed. Processing triggers for initramfs-tools (0.103ubuntu4.4) ... update-initramfs: Generating /boot/initrd.img-4.6.7-sunxi cryptsetup: WARNING: failed to detect canonical device of /dev/mmcblk0p1 cryptsetup: WARNING: could not determine root device from /etc/fstab Processing triggers for ureadahead (0.100.0-16) ... [gr@bpi:/armbian_kernel] $
Wazou Posted August 17, 2016 Posted August 17, 2016 Hi, got this warning on apt-get update with the new armbian Jessie image. W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease Unable to find expected entry 'jessie-utils/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file) Something to worry about ?
Igor Posted August 17, 2016 Author Posted August 17, 2016 Disable building utils on Xenial Where? Rebuild FFmpeg and mpv since I bumped upstream versions will be done together with repository correction Disable extras/hostapd building and delete unused files done Disable building sunxi-tools in armbian-utils done Add new repository components during debootstrap process done If user wants to build desktop images, make an option to use existing packages from apt.armbian.com instead of building all from scratch After repo will be fixed
Igor Posted August 17, 2016 Author Posted August 17, 2016 Hi, got this warning on apt-get update with the new armbian Jessie image. W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease Unable to find expected entry 'jessie-utils/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file) Something to worry about ? No, minor issues with our repository - related to this topic. Will be fixed ASAP.
borsti67 Posted August 17, 2016 Posted August 17, 2016 Disable extras/hostapd building and delete unused files done Did you miss some lines in the scripts by chance? (latest lib, lime2, 3.4.112, jessie, with extras and desktop) [ o.k. ] Applying common tweaks install: cannot stat '/[...]/lib/config/hostapd/hostapd.conf': No such file or directory install: cannot stat '/[...]/lib/config/hostapd/hostapd.realtek.conf': No such file or directory 1
Igor Posted August 17, 2016 Author Posted August 17, 2016 Repository recreated, now also those errors should be gone @Wazou * [jessie-desktop]: Armbian desktop (packages: 41) * [jessie]: Armbian main repository (packages: 1403) * [trusty-desktop]: Armbian desktop (packages: 0) * [trusty]: Armbian main repository (packages: 1389) * [utils]: Armbian utilities (packages: 4) * [wheezy-desktop]: Armbian desktop (packages: 0) * [wheezy]: Armbian main repository (packages: 1357) * [xenial-desktop]: Armbian desktop (packages: 41) * [xenial]: Armbian main repository (packages: 1151) Next tomorrow. 1
wildcat_paris Posted August 17, 2016 Posted August 17, 2016 just FYI (you probably already know) Xavier setup up a new rpimonitor repo for v2.11 # RPi-Monitor official repositorydeb http://giteduberger.fr rpimonitor/
zador.blood.stained Posted August 17, 2016 Posted August 17, 2016 Repository recreated, now also those errors should be gone @Wazou Some old repository components should be deleted (manually?) http://apt.armbian.com/dists/$RELEASE/desktop/ 1
Igor Posted August 18, 2016 Author Posted August 18, 2016 It's beta, so let's test https://rawgit.com/XavierBerger/RPi-Monitor-deb/devel/repo/rpimonitor_2.11-beta8_all.deb and wait for release.
tkaiser Posted August 18, 2016 Posted August 18, 2016 It's beta, so let's test https://rawgit.com/XavierBerger/RPi-Monitor-deb/devel/repo/rpimonitor_2.11-beta8_all.deb and wait for release. 2.11 contains an outdated version of my sunxi-temp-daemon that will be started by rpimonitord: https://github.com/XavierBerger/RPi-Monitor/blob/devel/src/usr/lib/systemd/system/sunxi-temp-daemon.service When installing 2.11 and our sun8i adoptions (armbianmonitor -r) then RPi-Monitor's /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh and our /usr/local/sbin/rpimonitor-helper.sh will conflict (at least /tmp/disktemp will cause troubles). Better postpone any RPi-Monitor upgrades until armbianmonitor-daemon is ready (will then take care of stuff like this and disable sunxi-temp-daemon since the whole daemon is useless when RPi-Monitor runs on Armbian). For the moment having the stable 2.10 in our repo this is the best solution possible. 1
Igor Posted August 19, 2016 Author Posted August 19, 2016 PACKAGE_LIST_DESKTOP="xserver-xorg xserver-xorg-video-fbdev gvfs-backends gvfs-fuse xfonts-base xinit nodm x11-xserver-utils xfce4 lxtask xterm mirage radiotray thunar-volman galculator \ gtk2-engines gtk2-engines-murrine gtk2-engines-pixbuf libgtk2.0-bin gcj-jre-headless xfce4-screenshooter libgnome2-perl gksu bluetooth \ network-manager network-manager-gnome xfce4-notifyd gnome-keyring gcr libgck-1-0 libgcr-3-common libgcr-base-3-1 libgcr-ui-3-1 p11-kit p11-kit-modules \ pasystray pavucontrol pulseaudio paman paprefs pavumeter pulseaudio-module-gconf pulseaudio-module-zeroconf" @zador.blood.stained This is the left over diff to desktop-test, other changes were pushed to master. What else prevent us to merge?
zador.blood.stained Posted August 19, 2016 Posted August 19, 2016 I'm testing some changes, if all works OK I'll merge desktop-test into master. This is the main thing I want to test: If user wants to build desktop images, make an option to use existing packages from apt.armbian.com instead of building all from scratch After repo will be fixed
zador.blood.stained Posted August 19, 2016 Posted August 19, 2016 W: Failed to fetch http://apt.armbian.com/dists/jessie/InRelease Unable to find expected entry 'jessie-utils/binary-armhf/Packages' in Release file (Wrong sources.list entry or malformed file) Looks like something needs to be cleaned up in aptly repository Edit: sorry, used old rootfs cache with old armbian.list. All works fine
zador.blood.stained Posted August 21, 2016 Posted August 21, 2016 Hm. Tried to test Mali binary driver today. Looks like Mali kernel driver for H3 is broken, tested with OPi+2E on freshly built 5.18 image and on old 5.14 from download page. Running test application ("colorful triangle") or es2gears results in black window and spam in dmesg: [ 482.157953] Mali: ERR: drivers/gpu/mali/mali/common/mali_gp.c [ 482.157976] mali_gp_stop_bus_wait() 162 [ 482.157980] Mali GP: Failed to stop bus on Mali-400 GP Both programs (es2gears and test) worked on freshly built image on cubietruck.
tkaiser Posted August 21, 2016 Posted August 21, 2016 Looks like Mali kernel driver for H3 is broken, tested with OPi+2E Did you try it on any other H3 device with less than 2GB DRAM? IIRC we had the same problem with lima-memtester and ssvb told me back then that a few years ago for CT (also 2 GB DRAM) were some sun7i modifications necessary. He meant also he would look into when he has an OPi Plus 2E in his hands but at least I haven't heard about any progress.
Igor Posted August 21, 2016 Author Posted August 21, 2016 I'll test on A20 asap ... btw: we are missing this in xorg.conf ... how to add this new packaging system? I am not sure for H3 but this is a must on A10 / A20. Section "Monitor" Identifier "Monitor0" Option "DPMS" "false" EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection
zador.blood.stained Posted August 21, 2016 Posted August 21, 2016 @Igor Just put this to board support package (makeboarddeb.sh) for all boards, including non-Allwinner ones. fbturbo specific Xorg config is packaged as part of fbturbo. /etc/X11/xorg.conf.d/01-armbian-defaults.conf is a good place for this setttings. @tkaiser Tested on OPi PC. es2gears and test work fine...
Igor Posted August 21, 2016 Author Posted August 21, 2016 - conf added - Cubietruck MALI test test/test EGL Version: "1.4 Linux-r3p0-04rel0" EGL Vendor: "ARM" EGL Extensions: "EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_lock_surface EGL_KHR_lock_surface2 " Surface size: 480x480 GL Vendor: "ARM" GL Renderer: "Mali-400 MP" GL Version: "OpenGL ES 2.0" GL Extensions: "GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_EXT_shader_texture_lod "
zador.blood.stained Posted August 21, 2016 Posted August 21, 2016 - Cubietruck MALI test Worked for me too: Both programs (es2gears and test) worked on freshly built image on cubietruck. IIRC we had the same problem with lima-memtester and ssvb told me back then that a few years ago for CT (also 2 GB DRAM) were some sun7i modifications necessary. He meant also he would look into when he has an OPi Plus 2E in his hands but at least I haven't heard about any progress. Yes, looks exactly like this issue: https://github.com/ssvb/xf86-video-fbturbo/issues/27 I'll see if something like this patch can be applied to H3 kernel tree. 1
zador.blood.stained Posted August 21, 2016 Posted August 21, 2016 I'll see if something like this patch can be applied to H3 kernel tree. It definitely looks like Mali issue, but our mali driver is already patched like in sun[47]i kernel. It's better to ask/remind @ssvb since the issue may be easier to pinpoint with lima-memtester. @Igor: can you put all device pages from armbian.com/download to documentation repo? We need to put info about non-working mali on OPi+2E, new page for Pine64 and edit page for i.MX6 boards ( Serial console only -> Serial console only - no HDMI output!).
Igor Posted August 22, 2016 Author Posted August 22, 2016 Specifics information moved to docs for CT and Opi+2e ... check if this way is O.K.
Igor Posted August 22, 2016 Author Posted August 22, 2016 And cleaned Cubietruck page. http://www.armbian.com/cubietruck/
Recommended Posts