With a basic build of OpenADK for the Raspberry Pi 3, I'm getting the
following error when I try to bring up wlan0.
# ifup wlan0
ip: SIOCGIFFLAGS: No such device
command failed: No such device (-19)
Successfully initialized wpa_supplicant
Could not read interface wlan0 flags: No such device
nl80211: Driver does not support authentication/association or connect
commands
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Could not read interface wlan0 flags: No such device
wlan0: Failed to initialize driver interface
ip: SIOCGIFFLAGS: No such device
In /etc/network/interface, I have the following configured:
auto wlan0
iface wlan0 inet dhcp
wireless-ssid HomeWiFi
wireless-mode sta
wireless-security wpa2
wireless-passphrase XXXXXXXXXXXX
I presume there is an additional configuration for OpenADK required to
enable wlan0 on the Raspberry Pi 3, but I don't see anything obvious. I
have the 'iw' and 'wpa_supplicant' packages enabled, but that doesn't seem
to be the issue.
Any tips on what I might be missing?
Thanks,
Mike Thompson
I'm very interested in determining the effort to create a port of OpenADK
to the ASUS Tinker Board. Does anyone have experience with OpenADK on this
or other Rockchip based hardware to use as a template to get started from?
Let me explain a little where I'm coming from with this.
Two years ago as a consultant I did a port of OpenADK to support the Google
"Project Blocks" tangible programming system for children. See:
https://projectbloks.withgoogle.com/
The "Brain Block" in the Project Block system was powered by the recently
released Raspberry Pi Zero and I chose OpenADK was the OS. I'm the
original creator of Raspbian, but with a bit of irony, I had to make the
decision that Raspbian was not the right fit for this project. The fact
that OpenADK with stripped down kernel could boot almost instantly and
the rootfs being read-only were extremely compelling features for an
embedded Linux system that had to be VERY robust in the hands of children.
At the time I was under heavy non-disclosure agreements with Google
regarding my work with the project so I couldn't say anything about it at
the time, but I found OpenADK to be very pleasant to work with. I don't
know the current status of things since finishing my work in 2016, but I
hope that they are continuing to use OpenADK with their research in
tangible computing.
Now two years later I'm an employee at a 3D printing start-up company where
we have the need to create some robust Linux based embedded systems for
robot control using Rockchip based ARM systems -- the ASUS Tinker Board
being a fairly computationally powerful system to start with. I could use
a stripped down Ubuntu system (kids won't be anywhere near these robots),
but I think OpenADK or Yocto would be a better embedded solution where the
system just needs to work with minimal management that a heavy Debian or
Ubuntu system might entail.
If a port doesn't exist, I'm assuming I would have to get a good
understanding of the Rockchip boot process to create the first stage and
second stage bootloader (probably Uboot), a custom kernel for this
hardware, the image requirements for an SDK card and figure out how to put
it all together within OpenADK. I think I have the skills to do this, but
I'm a little weary of the time it might take to figure it all out. Also,
being a start-up, my budget is rather slim to pull in outside help.
I wanted to get some guidance from the folks on this mailing list to see
what I might expect with regards to such a porting effort for OpenADK.
Sorry for the long email on this question.
Thanks,
Mike Thompson
When building under Ubuntu 18.04 the flex package for the host will
fail with the following error:
[stage1scan.c] Segmentation fault (core dumped)
This seems to be because Ubuntu 18.04 uses glibc 2.26 or newer as
described in the following URL:
https://git.busybox.net/buildroot/commit/?id=c128c5f3c79b31d89256ffbc5c650b…
This fix to configure.ac in the flex package will work around this
error.
Signed-off-by: Mike Thompson <mpthompson(a)gmail.com>
---
package/flex/patches/patch-configure_ac | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/package/flex/patches/patch-configure_ac b/package/flex/patches/patch-configure_ac
index 2f7599357..3660fc684 100644
--- a/package/flex/patches/patch-configure_ac
+++ b/package/flex/patches/patch-configure_ac
@@ -1,6 +1,17 @@
---- flex-2.6.4.orig/configure.ac 2017-05-03 21:16:37.000000000 +0100
-+++ flex-2.6.4/configure.ac 2018-03-14 05:11:52.278756139 +0100
-@@ -37,8 +37,6 @@ AC_SUBST(SHARED_VERSION_INFO)
+--- flex-2.6.4.orig/configure.ac 2017-05-03 13:16:37.000000000 -0700
++++ flex-2.6.4/configure.ac 2018-05-26 15:05:50.426997650 -0700
+@@ -25,8 +25,10 @@
+ # autoconf requirements and initialization
+
+ AC_INIT([the fast lexical analyser generator],[2.6.4],[flex-help(a)lists.sourceforge.net],[flex])
++AC_PREREQ([2.60])
+ AC_CONFIG_SRCDIR([src/scan.l])
+ AC_CONFIG_AUX_DIR([build-aux])
++AC_USE_SYSTEM_EXTENSIONS
+ LT_INIT
+ AM_INIT_AUTOMAKE([1.11.3 -Wno-portability foreign check-news std-options dist-lzip parallel-tests subdir-objects])
+ AC_CONFIG_HEADER([src/config.h])
+@@ -37,8 +39,6 @@ AC_SUBST(SHARED_VERSION_INFO)
# checks for programs
--
2.17.0
Hello friends
After my Pi 2 broke recently I decided to get the new Pi 3 Model B+.
After a few modifications OpenADK is now running on it really well.
So I thought I would run some video performance tests to see how well it
can play back 1080p material. As a reference I also looked tried
libreelec. I guess this should show 'what is possible' on the device.
First of all, blu-ray style 1080p is working really well in adk! :-)
With the license keys for VC-1 and MPEG2 purchased and installed, all
the relevant codecs, H264, VC-1 and MPEG2 play smoothly with negligible
CPU load.
Kodi shows what codec is being used for decoding. So here is what it is
showing in adk (with the license keys installed!):
H264: mmal-mvc (HW)
VC-1: mmal-vc1 (HW)
MPEG2: mmal-mpeg2 (HW)
Not that in libreelec, the same codecs are shown with the exception of
H264, where 'mmal-h264 (HW) is shown. Playback is smooth for all cases.
Let's look at H264 a little more closely. This site
<http://jell.yfish.us/> offers test files with various bitrates.
It turns out the files with bitrates up to 70 mbps play smoothly on adk.
At 80 mbps it begins to stutter, anything higher is hopeless. CPU load
stays low though, so this might be related to memory bandwidth.
Libreelec can play even the 80 mbps smoothly, but beyond that it gets
very stuttery. Maybe the difference between the two is due to a
different codec being used. However I don't think this difference is
relevant in practise, as most 1080p material has much lower bitrates.
Maybe it gets some more importance with 4k material (which I didn't test).
So my conclusion for H264 is that the Pi3B+ plays it really, really well
both on adk and on libreelec.
Now what about H26*5*?
Unfortunately the Raspberry Pi does not support hardware acceleration
for decoding H265. From googling and reading some forum posts I learned
that it support for using some neon features for H265 decoding is
apparently implemented in newer versions of openelec and libreelec,
though I could not find the details.
Luckily the site linked above also offers the test files in H265, so I
tested these as well.
On adk none of the H265 files play anywhere near smooth (revision
44cbb78fa that includes ffmpeg libx265 support). The decoder shown by
kodi is:
ff-hevc-mmal (HW)
which can't be right, because hardware decoding is not supported. The
CPU load is at 100% constantly on one core and not much on the others.
So at the time of writing, H265 playback is not possible in adk-kodi.
How about libreelec (8.2.4)?
On libreelec both the 3 and 5 mbps files play smoothly! The latter with
significant CPU load (40-70%) on all cores. The 10 mbps sample is not
smooth anymore, with 90%+ load on all cores.
The decoder shown is:
ff-hevc-mmal (SW) which makes sense.
So bottom line it seems possible to play moderate-bitrate H265 material
in the B+.
From what I read online the Pi3B also works relatively well when
overclocked, but is likely to run into thermal problems then, while the
B+ works well and has much less thermal problems (having a higher clock
than the 3B from stock). I don't now if this information is trustworthy,
and I did not look at temperature at all (but I do have a heat sink on
the CPU).
What's next?
Obviously it would be great to have kodi on adk use the decoder as does
libreelec. Does anybody have an idea how to do this/where to look?
Other test results, e.g. from a Pi3B or a Pi2 would also be interesting,
and any ideas or comments are highly welcome! :-)
Hope to have inspired some folks!
All the best
Oliver
P.S.
Please note I did not (yet) do any long term playback testing or look at
dropped frames etc. What I did was rather a first test using the files
mentioned and a few more judging the playback quality by eye.