Slackstick reacted to Squatter in Orange Pi 3 Support?
Thank you Martin. 30 seconds hard work & wlan0 is fine. cpu seems to be running at the full 1.8GHz v. the throttled 1.5GHz of the OPi image. I can confirm armbian WIP cpu benchmark ~20% faster over OPi image which seems to be consistent with the throttling. And for some reason, the OPi image benchmark that I used only saw 3 of the 4 cpus so parallel performance is even higher.
Once over the wlan & HDMI hurdles, I now have a fully kitted out lxde environment accessible by rdp plus a full web development environment. I had a minimum set of criteria re. performance & capability & all have been exceeded as I never planned to use HDMI anyway, nor do I have any immediate plans for PCiE or the IO pins. I think I am now over comparing what the OPi image offered v. the armbian WIP.
The only glitches I encountered were related to rdp which appears to have stumbled universally on Ubuntu 18.04.2. And some strange intermittent behaviour re. wlan losing nameservers (resolv.conf not being populated) after a reboot ... trying to pin that one down. But these are software not hardware issues.
I will just press on assuming that everything I need to work just works ... as it does so far. After 29 years in the unix sysadmin/builder role world (on and off) its now just a hobby.
Slackstick reacted to mikaey in Frequency throttling on OPi PC2?
Ok, I think I got it! Had to learn a little bit about device trees in the process. BUT...here's what I did (and BTW -- I did this all directly on the PC2):
Step 1: Grab a copy of the Linux source:
$ sudo apt install linux-source-4.19.20-next-sunxi64 This will dump the Linux source tarballs (and a config file) into /usr/src.
Step 2: Unzip the tarball, and copy in the config file:
$ cd /usr/src $ sudo mkdir linux $ sudo chown `whoami`:`whoami` linux $ cd linux $ tar xvf ../linux-source-4.19.20-sunxi64.tar.xz $ xzcat ../linux-sunxi64-next_4.19.20_5.75_config.xz >.config Step 3: Download the attached patch and apply it:
$ patch -p1 <OrangePiPC2.patch Step 4: Build the new DTB:
$ make dtbs You should find your new DTB under arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb.
Step 5: Copy the new DTB into your DTBs folder:
$ sudo cp arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dtb /boot/dtb/allwinner Step 6: Reboot!
$ sudo reboot The PC2 will now throttle automatically when temps start getting too high!
Slackstick reacted to bschwehn in Armbian for OrangePi PC2, AllWinner H5
FWIW, these messages seem to go away when building the dev branch without patch /patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch
Not sure if this patch is compatible with the changes already done in the megous branch (like this patch)
Still, throttling is done only down to 1104 MHz (not an issue for me personally, for me this throttle is enough for mine to not go above 81C @100% CPU usage for 10 minutes).
Edit: Looks like I have it working now. I have basically added the patch ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch directly to linux-mainline/orange-pi-5.0/arch/arm/boot/dts/sunxi-h3-h5.dtsi (instead of
Not sure why that should make a difference, but throttling now seems to take the trips I have configured (though it seems to use a different cooling map:
after insulating the board to get the temperature up:
removing insulation lets temp drop again, and freq rise:
Slackstick reacted to jernej in Orangepi 3 h6 allwiner chip
@NicoD @johanvdw Actually with some of the out of tree patches is possible to make it work. After all, I have fully functional LibreELEC image for PineH64. Well, not completely everything, but HDMI audio works pretty well. Patches are here and here. Btw, dma patches are important for audio and you have to enable sun4i-i2s driver and simple audio card if it's not yet.
Slackstick reacted to Frank Kettenbeil in Orangepi 3 h6 allwiner chip
Thank you for your investigation and fix! - for those who could not do the build themselves yet - here you can find my updated image (Armbian_5.77_Orangepi3_Ubuntu_bionic_dev_5.0.4_desktop.img) with this patch included - please report, if the emmc works with this image, as I did not have the opportunity to replace my own one, yet. - Thank you!
Edited 2019-03-30: private built file no longer available. You will be better off with the nightly builds from armbian from now on: https://dl.armbian.com/orangepi3/
Thanks to @martinayotte !
Slackstick reacted to Igor in [Nanopi NEO2] Kernel update for patch (DVBSky S960)
It seems that it works:
[ 78.151703] usb 4-1: new high-speed USB device number 2 using ehci-platform [ 78.309657] usb 4-1: New USB device found, idVendor=0572, idProduct=6831, bcdDevice= 0.00 [ 78.309713] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 78.309752] usb 4-1: Product: S960 [ 78.309788] usb 4-1: Manufacturer: Bestunar [ 78.309825] usb 4-1: SerialNumber: 20120511 [ 78.739525] usb 4-1: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state [ 78.739775] usb 4-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 78.739797] dvbdev: DVB: registering new adapter (DVBSky S960/S860) [ 78.741097] usb 4-1: dvb_usb_v2: MAC address: 00:17:42:54:96:0c [ 78.749575] i2c i2c-2: Added multiplexed i2c bus 3 [ 78.807605] ts2020 3-0060: Montage Technology TS2022 successfully identified [ 78.807681] usb 4-1: DVB: registering adapter 0 frontend 0 (Montage Technology M88DS3103)... [ 78.839524] Registered IR keymap rc-dvbsky [ 78.839649] rc rc1: DVBSky S960/S860 as /devices/platform/soc/1c1c000.usb/usb4/4-1/rc/rc1 [ 78.839746] input: DVBSky S960/S860 as /devices/platform/soc/1c1c000.usb/usb4/4-1/rc/rc1/input6 [ 78.839936] rc rc1: lirc_dev: driver dvb_usb_dvbsky registered at minor = 1, scancode receiver, no transmitter [ 78.839943] usb 4-1: dvb_usb_v2: schedule remote query interval to 300 msecs [ 78.839949] usb 4-1: dvb_usb_v2: 'DVBSky S960/S860' successfully initialized and connected [ 78.840020] usbcore: registered new interface driver dvb_usb_dvbsky
Slackstick reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party
Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y
Slackstick reacted to TonyMac32 in Support of Raspberry Pi
If possible please use English on the forums, it is quite helpful to everyone, since all told there are probably over 10 (low estimate) languages spoken by the various members.
For the Pi there is no plan on supporting that family of boards. They embody many of the things we point to as fundamental problems with basic board design (micro USB power, horrible I/O bandwidth, propagandist marketing, just plain wrong benchmarking, I could go on. The 300 Mbps on the RPi will be significantly affected (negatively) by any other USB peripheral, like a storage drive. I would recommend researching other boards and finding one with GbE for your needs, the RK3328 boards, RK3288 boards, etc. They are pricier, but if you need the performance, you will have it.
Slackstick reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party
You already helped a LOT!
Indeed! Let's fix this Pinebook's troubles and we might slowly switch 4.19.y to nightly NEXT building ...
Slackstick reacted to jernej in Kickstarter: Allwinner VPU support in the official Linux kernel
Why it can't be both? I have commit rights for LE and I'm maintainer of allwinner branch (until it's merged in master). And everything I do is in my spare time. As it is the case for any other LibreELEC developer.
And 4.20 will be out around Christmas, so I guess I'll merge all HW decoding related patches to allwinner branch around then. But you can get my WIP stuff from my github.
BTW, merged version won't use libva-v4l2-request, but native ffmpeg integration.
Slackstick reacted to tkaiser in Support of Raspberry Pi
No. It's uninteresting for these reasons:
RPi is a closed source platform, the main operating system bringing up and fully controlling the hardware (ThreadX running on the dual core VideoCore IV main CPU) can not be altered since... closed source and proprietary. All the relevant stuff happens completely there (DVFS for the ARM CPU cores, video decoding and so on) and the secondary OS running on the ARM cores has not even an idea what's going on (see for example all those RPi installations that constantly suffer from 'frequency capping'). All we as Armbians could do is to fiddle around with a secondary OS running on the 'guest' ARM CPU cores while everything interesting happens solely on the proprietary and closed source VideoCore. The community driven tries to replace ThreadX with something open sourced have stopped since the developers involved lost interest (some details)
The new board is a power hog able to consume close to 1800mA by running some CPU intensive stuff alone (see at the bottom of this nice review). In the past due to poorly-designed power circuitry an RPi 3 was not able to exceed ~1.5A anyway (voltage drops then occured and under-voltage 'protection' kicked in). Now this has improved but unfortunately the Pi is still equipped with a Micro USB port to be powered (rated for 1800mA maximum!) so even more users will run into underpowering hassles.
Headless RPi users are usually not even aware that they run under-volted (example, example, example, example) and if even under-voltage 'protection' (frequency capping turning the RPi into a 600 MHz board) doesn't help crashes, freezes, kernel panics occur that are usually considered 'software issues' (example). I believe the RPi people are well aware that powering with Micro USB is a shitty idea. But they do a great job masquerading the problem and try really hard to keep their users clueless (see this funny 'Micro USB powering' thread and how it ended -- archived version here, they love to censor over in their forum).
TL;DR: it's not fun but simply boring to bring Armbian to the RPi and support situation for both users and us here will be a nightmare (users expecting everything Raspbian compatible while we would have to deal with the results of crappy Micro USB powering being reported as software bugs and users miseducated by RPi people not able to realize that under-voltage is the problem and their '3A PSU' won't help here anyway. RPi folks really try hard to let their users focus on BS amperage ratings instead of explaining the real problem.
BTW: I know a bit what I'm talking about since having maintained an OS image for RPi 2, 3 and 3+ that gets downloaded +10,000 times each month.
Slackstick reacted to jock in Mali support announced for mainline (Allwinner SOC's)
Hi hoskit, yes I was able to get the job done. I suggest you to take the very latest development armbian nightly which already has the HDMI bits in the device tree, just not to tinker about the kernel compilation and other messy things.
The guy (mripard) on github fixed some regression he introduced that broke the mali kernel driver compilation on slightly older kernel, so now compilation and installation should be pretty accessible.
I tried only the framebuffer version, and yes, it was working pretty well: I tried different OpenGLES2 demos from the official Mali SDK and they all worked without issues
Slackstick reacted to jernej in Next thread Custom HDMI timings/resolution hints in dev
You can't, yet. SimpleFB driver used for now doesn't support anything besides simple framebuffer. Actually, framebuffer is set up by U-Boot and Linux knows only where in memory is located and how big it is, that's all.
Proper HDMI driver is in the work by me (already written, but not yet functional, I have to fix all the issues first), which will allow to do all that.
Slackstick reacted to Igor in Orange Pi Plus 2E now available
They lack 100+ fixes and various additional features? Check release date of those "alternatives"! They are so outdated and buggy, that are not even on the level to be comparable. There are and there will be no updates or any type of support.
Next. Armbian is recommended general purpose OS in 9 out of 10 cases (estimated, probably more than that) on Facebook groups and other 3rd party media, the rest goes to few other systems, which are based on Armbian or from people who have absolutely no clue what's going on.
Small crew works daily on Armbian and provide support, updates, fixes, ... Providing such service costs lots of resources, usually its premium and that's why we have a donate button. People who understand the value of our work, use it, others help with their time and others, that we all benefit.
I could write a 10 page article on this, but I am not the right person to make such comparisons in first place ...