Tido

I am technically finished my 1st week of my summer vacations and there was not a single day that I worked less than 10 hours. If you wait for me ... my only possible time slot with access to hardware and do something about - is August 5-7th, but this is not the only thing that is waiting for me. Then I am traveling for two weeks, office time for a week, traveling again. Somebody else will need to solve this problem or it will take 2-3 weeks at best.

lima userspace driver is merged to mesa 19.1, and latest develop lima is based on 18.3.0. and the good news is mesa used in debian 10 is 18.3.6. so its very easy to rebuild mesa debs for debian 10.
 
I have done ARM64 debs build, and ARM debs is on going.
 
https://github.com/zhangn1985/lima_gpu_drv

Not quite accurate - 2G (GSM/GPRS) is a completely different radio access network, including waveforms and modulation scheme.
 
2G was turned down some time back here in the US, and now the major operators have scheduled the 3G sunset in the next couple.

Maybe with some kind of hack by having DTB copied under both /boot/dtb/sun50i-h3-orangepi-zero-plus2.dtb and /boot/dtb/sun50i-h3-orangepi-zeroplus2.dtb names...

A priori, the price of a set of RPI will always be higher than the price of comparable TV box. This is an objective reality, because SbS have a number of "extra" elements and not the optimal design in comparison with the TV box. TV box is a specialized device in which everything is sharpened to perform a specific function. Therefore, it will always be cheaper than a similar "multifunctional" device. If this were not so, no manufacturer TV boxes would not have to spend time for their production, and stupidly  would take the SbS and turn it into these TV boxes.
 
No need to juggle and substitute concepts. Don't mix Android system development and Linux-based system development. It is a completely different direction. The main system for TV boxes is Android and it has all the necessary documentation and access to all technical resources. By the way, Your information about support for a number of ARM platforms in the main core is very outdated. Confirmation of this, the release in the near future of new images of Libreelec with a new kernel on the platforms Amlogic Rockchip and Allwiner.
 
You confirm that the "clean" RPi is not suitable for standard use as a TV box. And you have to spend extra money to get the necessary functionality. For example, it put the module WiFi\Bt, but there is no normal antenna, without which it will not work properly.
 
I see that You are very prone to distort and replace concepts. The design and parameters of RPI 1 and 2 have nothing to do with RPi 4. It is a completely different platform, having a very different thermopowers.
 
p.s. You are always trying to distort the essence of the discussion, so I see no point in continuing the discussion with You.
 

- 4 big cores on 28 nm, see the Tinker Board for a lesson in cooling that form factor.  (the Pi seems oddly underclocked, if I'm being honest, a 3288 will go 1.8 GHz, @wtarreau will tell you 2.0+)
 
- As far as USB3/Gb, the tunnel-vision Pi people would have seen an insane improvement with just 4x USB2 on their own channels and a 100 Mb PHY.  So yes, they are going to think they're lighting the world on fire performance wise.
 
- That USB-C does not appear to be intelligent PD type, so I'd be interested to see when people use smart supplies with it, if it will run on the 500 mA they'll probably limit to.  (correct me if I've gotten it mixed up)
 
It looks more interesting than the Pi 3, I bought a few 3's and have since let them rot.  I still used a 2 until recently for music.

No ! The 'm' means 'module' ...

@JohnnyWednesday, having people like you in our community is great and appreciated.
Just don't try to convince us that SinoVoip is a great manufacturer - because the past and current proof different.
And please, when you find errors and patch fixed it, send pull requests to SinoVoip and report back when they were added. I say this because we have seen it for more than 2years, not months, not days.
 

Hello reader
 
I will report here about my experience to watch Netflix as written in the title. To do so, I got a current LE image from @balbes150 (thank you).
 
You may be asking the same question as I do (did), why using the image from balbes and not the official one from the download page ?

It is actually quite simple, balbes integrates the latest Kernel for his LE builds. While on a x86 system the kernel isn't so interesting, it is on ARM systems, because a lot of the development happens 1 or 2 year later of the release of the SoC.
 
I have asked him about the different versions he offers for Le Potato:
 
All versions of libreElec (LE) use the common core of aarch64 (64 bits).
There is only one 32-bit library (arm) for Netflix. Therefore, I am releasing two versions of LE.
ARM version = core of aarch64 + the whole ARM system. aarch64 = core aarch64 + whole system aarch64, this version runs 20-30 % faster than ARM.  By the way, it would be interesting to check if Netflix works on Armbian, it may be possible to run it in the environment aarch64 + 32 bit library.
 
So I chose this image: LibreELEC-AMLGX.arm-9.1-devel-20190604084103-a41fdf1-lepotato
 
After writing the image on the SDcard I had to walk through the basic configuration of LE (by the way no SSH - you must use a Display and Keyboard) you find more information here:
https://forum.libreelec.tv/board/38-amlogic/
  https://libreelec.wiki/
 
YouTube
A german screenshot film, that guides you through the process of installing the Netflix addon from libdev + jojo + asciidisco https://youtu.be/gyue62JWEkc
 
Netflix addons; the Kodinerds repository is already part of LE, that saves you some time, update this first.
The update and install of the Netflix addon (libdev + jojo + asciidisco), which has some dependencies, is tricky. I had repeated this process several times and a reboot once, because it would only install a few, but not all of the 9 dependencies at once. After 4 or 5 times it confirmed: installed.  Now, keep following the YouTube film mentioned above.
 
Adding your credtials to get access to Netflix.
 
WideVine for digital rights mgmnt (DRM), is extracted from ChromeOS - this will download 2Gb
 
Load on the hardware
Press the "O" key on the keyboard when playing the video and the service information about the video will be displayed on the screen. It is Software-Decoding for Netflix.
2 cores were running at around 50%  and  2 cores were idle (1280 x 720). Testing it on my TV it switched to FullHD at which point it got useless audio and picture were no longer insync.
 
SSH (Secure Shell)
During configuration you will see the SSH menu item. You can turn on SSH and you should then change the password!!
However, reading the Wiki I got the feeling that this implementation is a bit weird... that said, I would turn it off if you don't need it.
 
WiFi
For to me unkown reason the binaries for the USB-WiFi Sticks were removed in 2017: https://github.com/LibreELEC/LibreELEC.tv/pull/1635 , luckily it is easy to add the driver.
cd /storage/.config/  and here you do: mkdir -p firmware  and now  cd firmware/
unplug your USB-WiFi Stick, plug it in again and do: dmesg | tail -7   you can now see your stick and which binary is missing. Search the binary on this website and complete the line with your binary link:
wget https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware...
reboot
 
no APT
There is no working 'apt-get'.  TIP: use XBMC's addon browser to enhance your LibreELEC system
 
 
to be continued
 

... which is delivered in parts
 
 
 
 

one of the maintainer of this project (dealing with rockchip and amlogic)?
 
Who has not the right to remind you that the discussion is pointless? The decision that current RPis are note supported by armbian was made a long time ago and it still stands. And for the who started first on throwing dirt to each other here doesn't matter to me.. If it's not working on a acceptable level I'll simply end it (without needing dirt.. but with something I don't like, means closing the thread).
 
and if you go through this whole thread.. You get some 'objective' and probably also a lot of subjective answers to that.. And just a last one.. Guess what happens if a platform gets added in which no developer has an interest in? Exactly, nobody cares about enhancing the support for it.. Means spending hours of hours of their spare time to make things better, following upstream to pick up stuff like this: https://lkml.org/lkml/2019/5/20/431 integrate it and test if it solves the crippled mailbox system the RPi has? Dealing with the blob bootloader the RPi needs and check after every update of this blob if the new one behaves similar or if they add new thermal throttling behavior which was barley annotated when the RPi3b+ came out? This stuff needs time. It's not only adding a few lines to the buildscript and you're done.. And further Pi1 and Zero is ARMv6, pi 2 is ARMv7 and some ARMv8, pi3 is ARMv8. By default we provide userspace matching to CPU architecture.. It will be a nightmare to explain again and again (and again) that a RPi2 image might not work on a RPi3. That by using RPi3 a bunch of the things which make the Pi useful (e.g. the decoder stuff) might not work cause all the userspace stuff isn't armhf on armbian for 64bit CPUs.
 
With Raspian, there's a decent image out for RPis, it gets updates it supports the hardware. It's not armbian but also a debian derivative. And if, for whatever reason you want a Armbian userspace but don't want to deal with kernel work nor bootloader etc. @tkaiser provides a OS layer to frankenstein a 'Armbian on RPi' together (https://github.com/ThomasKaiser/OMV_for_Raspberries). And if you want to deal with kernel as well.. Fork armbian, add the needed configs for kernel bootloader etc. Glue everything together and deal with the FAT partition the RPi needs for its bootloader (basically the buildscript should allow such FAT partitions). Find a suitable Kernel (probably the one RPi provides on their GitHub - or if you really want to deal with it.. go for a mainline) and craft your own image, based on armbians buildscript (it's on github, everyone can fork it). But don't expect that someone does the work for you especially if those people are simply not interested in the currently available iterations of the RPi. 
And don't expect as well that they always take as much time as I took this time to explain it again and again, when someone shows up complaining that we don't provide Armbian for RPi... I needed a break from writing serious stuff..
 
 

Thanks for work on armbian!
 
I've got nanopim4 recently, stable build worked like a charm out of the box (maybe w/o bluetooth)
I digged into all build scripts, tried out the dev and even got a step forward.
 
I'm actually ready to support further development with this board
See my reports, attempts and links here: https://gist.github.com/razum2um/8e2bfbcffdcdb3a832a4862339330867
Would be glad if @Igor , @chwe or someone else helps with the wifi question there
 
p.s. sorry for posting here, but I'm unable to post into `development` forum section for rk3399

I really appreciate your work and understand the current situation, thanks for such quick replies as well.
But I feel like it's an autoreply after grep for /help/, I mentioned branches and I'd like to help you, to contribute, *not* asking solving problems *on request*
 
Really, right now I can do pull request which advances nightly rockchip from 5.0 to 5.1
And this is *not* a trivial bump, since mainline kernel dts files for rockchip have been changed and the board won't boot just after bump.
My branch boots it at least.
 
Just now not doing pull request, because I'd like to push either a ready version with wifi or ensure that it's not possible.
In my previous experience with linux during several years on gentoo - I do understand the process,
but at that times I just needed and compile the proper module to get networking, now I'm a bit stuck.
 
p.s. I also *read* the rules and understand why I cannot post into development, still preferred to start a topic instead of pushing this into replies, is something wrong with that?
 

An RPi is not

1) reliable
2) the most cost-effective
3) worth $35
4) worth any more discussion.

The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.

Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.

Sent from my Pixel using Tapatalk

Greetings everyone,
 
A couple years ago, I did my research and followed the recommendation here and on linux-sunxi to purchase a Cubietruck and have had excellent results.
 
I use my small low power GNU/Linux sever for all manner of things including self hosted "cloud" (contact, calendar, file synchronization), XMPP messaging server, media server, etc...  It has been such a success in fact that we are putting more and more of our valuable personal files on there like pictures, etc. and that has me thinking more and more about reliability, backup, etc...
 
I became very interested in ZFS but my understanding is that it requires 64-bit, but the state of 64-bit ARM devices seems... well, not quite ready for prime time just yet?
 
I have spoken to some friends and family about my self-hosted solution, and a few of them are interested now in doing something similar. So now I am thinking along the lines of purchasing a second (and/or third...) Cubietruck and putting together a sort of distributed cluster of little servers at different locations where we each back up one another's data.
 
So I guess my question is, should I pull the trigger now and purchase additional Cubietruck(s), or just sit tight and wait a little longer until 64-bit ARM matures? Or perhaps there is some other option I am not aware of (hardware recommendation)?
 
My primary concerns are privacy, including keeping my own data on devices I physically control or have access to. Also the whole state of affairs with blob bootloaders is very troubling to me, but it has been difficult for me to find specific info on this, at least with regard to specific ARM based hardware. Maybe I am not looking in the right place(s)? Any pointers about where to find such information would also be greatly appreciated.
 
To give you an idea of where I am coming from, I spent years and hundreds of dollars acquiring a number of KGPE-D16 motherboards and related hardware (ECC RAM, etc.) to run Libreboot and ZFS, only to measure the power consumption and realize that at hundreds of watts it was totally unfit for the purpose of a 24/7/365 server. I just don't want to make any more really bad mistakes like that. I know there are some very knowledgeable people here, and I am hoping some of you can contribute to a discussion that would get me (and others who think similarly) looking in the right direction.
 
TRS-80
 
P.S. - I just want to thank everyone here who is doing such a fine job. The developers as well as those who help in answering questions in the forums, etc. I am very short on time these days and cannot help out in that way myself currently, however I did make a small monthly financial commitment in the form of a membership. It is not a lot but is the least I can do. I feel that those of you who spend your valuable time on development, support, etc. should not have to come out of pocket for server costs and other small expenditures. I know that I personally greatly appreciate your work, I'm sure others do as well, even if they don't say so as often as they should. Cheers!

If you are familiar with IRC, I would carefully try to get some hints over here: https://linux-sunxi.org/IRC
 

Thanks, @Tido for the links.
 
[20149.090066] [<bfb2d42d>] (wsm_handle_rx [xradio_wlan]) from [<bfb29e05>] (xradio_bh_exchange+0x27c/0x588 [xradio_wlan])
In the error logs, it seems program stalled on wsm_handle_rx in xradio_wlan.
 
I found the official xradio_wlan driver to be fifteenhex
http://linux-sunxi.org/Wifi

 
 
I checked the fifteenhex wlan_driver code for "wsm_handle_rx" and found this line in wsm.c

https://github.com/fifteenhex/xradio/blob/master/wsm.c
 
It seems like kernel hang is done on purpose.
 
After commenting out this section, I recompiled the xradio_wlan.ko module driver and retested.
After running 11 the OrangePi Zeros with the new xradio driver, connected to a router which changes its channel occasionally when multiple devices are connected, 5 OPis stop responding. 
I ran the test overnight. I tested after connecting all OPis through the serial port (COM).
 

 
@zador.blood.stained @Tido @martinayotte any idea how I can further test the driver to stop the kernel hang?
p.s: I am ok with the dropped packets of the driver.
 
Thank You.
 
Sanju.
 
 

because new user write into the dev forum instead of  review their own actions and look for a solution.
Because of that there is an own section in the forum:
Board doesn't start
 SD card and PSU issues
Or if you want to read a current posting that goes in that direction.
 
So until you have gathered some basic experience,  supporting others,  you are blocked from writing to the dev forum, but everywhere else is open.
If you are here for a couple months on a regular basis, you will understand.
 

because new user write into the dev forum instead of  review their own actions and look for a solution.
Because of that there is an own section in the forum:
Board doesn't start
 SD card and PSU issues
Or if you want to read a current posting that goes in that direction.
 
So until you have gathered some basic experience,  supporting others,  you are blocked from writing to the dev forum, but everywhere else is open.
If you are here for a couple months on a regular basis, you will understand.
 

well, I added writing into the second gigabyte in my loader and it showed this result:
first, the code has been writing into every 8-byte word, starting at the 2nd gigabyte. and it failed at the 37th 8-byte word inside of the 129th page or passing ~512KB. I ran it twice and it failed at the same position. The fail is "synchronous abort" exception. second, the code has been changed to write first 8-byte word on every 4KB page starting from the 2nd gigabyte up to the last page (bffff000). I run this code twice and it passed it successfully both times. After the loop, the code read back the starting word and it matched. So, I suppose, it's not that bad as a bad soldered bank. instead, there are some bad pages, maybe even just 1. Too bad uboot doesn't do any testing or at least doesn't report bad pages as for example UEFI does, passing this for an OS. Basically because of some broken bits, maybe not more than occupying just one page,  entire gigabyte is cut off... that sucks. 
Well, thanks @Igor and @martinayotte for your advices.

Yesterday i did install Armbian_5.86_Aml-s905_Debian_buster_default_5.1.0_20190514.img from @balbes150
on my Sunvell T95KPro (S912).
 
While installing Pihole the Installation does break when trying to start lighttpd.

After checking with journalctl -u lighttpd  it turns out that the file /usr/share/lighttpd/create-mime.assign.pl 
is missing, because in the newer lighttpd-version of debian buster the file has be renamed
to /usr/share/lighttpd/create-mime.conf.pl 
(see also https://discourse.pi-hole.net/t/lighttpd-does-not-start/6207/11 )
 
Pihole doesnt know/use the new name with debian buster, so it fails to start the lighttpd
 
So I did find 2 ways to resolve the problem.
 
First (quick and dirty?) way:
cp /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl or ln -s /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl
read also:
Pihole breaks lighttpd on Debian Buster #2557
https://github.com/pi-hole/pi-hole/issues/2557
 
the second way (found it at https://forum.kuketz-blog.de/viewtopic.php?t=3067 ) is to edit /etc/lighttpd/lighttpd.conf 
and search for the 2 following lines and comment them out (found the 2nd one at the end of the file):
 
#include_shell "/usr/share/lighttpd/create-mime.assign.pl" #include_shell "cat external.conf 2>/dev/null" and add the follwoing line to the file:
include_shell "/usr/share/lighttpd/create-mime.conf.pl" After saving the file you should be able to restart lighttpd via
sudo /etc/init.d/lighttpd restart or sudo service lighttpd restart or sudo service lighttpd stop sudo service lighttpd start  
BUT second way does not work good with updating or repair-install of pihole, because I think this will set the config-file to the old state
(also for server.error-handler-404)

So maybe the first way will work better while pihole doenst know the new file-name - or you also can do both ways
 
BTW: If you are experience a 400 Bad Request while  only using the IP for getting to the Pihole-Webpage
(and the redirect should ask you if you want to use the /admin page - but it doenst)
then try the follwing small resolution - edit a line in the file /etc/lighttpd/lighttpd.conf
from: server.error-handler-404 = "pihole/index.php" to: server.error-handler-404 = "/pihole/index.php"  
 
lighttpd.conf

I think @Igor added that restriction few days ago : new comers with less then 5 posts can't post in Development subforum.
 

Neil finished u-boot UMS support for us. So, soon you will be able to flash the eMMC by exposing it as a mass storage device to your PC.

You received valuable hints how to possibly solve this problem. Armbian gave you opportunity to install the driver (working kernel headers), but if the driver is broken or lack functionality you want, there is nothing folks around - a few people that make Linux running on those cheap boards possible - can do about. Solving your problem would costs perhaps a hundred hours, perhaps way more? Perhaps "just" ten, but I can only afford to blow few minutes. I have to remind you that overall contribution from your side to cover your questions is far below 1%. Any relevant response you get is pure gold.

A recommended way of solving the problem is actually the best, perhaps the only way, besides hiring people to do the homework instead of you.

Samsung SSD 840 Pro 256 GB @ Cubietruck iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Kernel 3.4.y random random reclen write rewrite read reread read write 102400 4 10714 15285 31921 32280 16328 14767 102400 16 21757 25767 57812 58010 45695 25201 102400 512 33403 32429 128245 116062 109591 33595 102400 1024 34846 35240 129965 131121 129515 35227 102400 16384 37895 37918 207564 204627 204340 38019 Kernel 4.19.y with SATA improvement patch 102400 4 22876 32704 37686 39143 22571 30990 102400 16 54254 69325 94749 97225 61354 68529 102400 512 110670 113325 190346 163677 186012 112679 102400 1024 113971 115928 206044 207406 184936 115069 102400 16384 127084 127588 243400 253305 252148 127611 without 102400 4 18053 22336 45249 46338 24860 22292 102400 16 30692 32188 106052 106577 71526 32746 102400 512 39632 39978 186433 185444 178097 39939 102400 1024 39860 40163 189900 191076 188446 40098 102400 16384 38875 41508 241939 244088 243405 41314