1 1
Igor

Repository management

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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  :P  :huh: 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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

  • 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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
  • 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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
1 1