My name is Victor I learned Openadk about your sistemk recently
May you prompt to me I can use it for creation of ROOTFS for a system on the
basis of Cortex A9 to documentation it is written that yes. But there are no
examples? I use Intel cyclone 5 Cortex A9. Tried to compile constantly
errors. With whom it is possible to consult?
Hello,
I am using openadk on the raspberry pi 3, and have an appliance where I have one main application that is running all the time.
So I am using gcc 7.2.0 from openadk, and compilation starts to be *very slow* with gcc: 10 minutes for a full rebuild... So I am looking into having the clang toolchain available next to the gcc one so I can compile only my application with clang, which is faster.
I have several shared libraries I also compile myself as part of my application build, all using cmake.
So, I used the llvm package under the toolchain dir and modified it so it could build in another output directory like this:
BUILD_DIR_INITIAL:= $(WRKBUILD)-initial
BUILD_DIR_FINAL:= $(WRKBUILD)-final
TC_INSTALL_DIR:=$(TOOLCHAIN_DIR)
ifeq ($(ADK_BUILD_USERLAND_COMPILER_LLVM),y)
TC_INSTALL_DIR:=$(TOOLCHAIN_USERLAND_DIR)
BUILD_DIR_INITIAL:= $(WRKBUILD)-userland-llvm-initial
BUILD_DIR_FINAL:= $(WRKBUILD)-userland-llvn-final
endif
Then as llvm triple I used this:
LLVM_TRIPLE:=arm-openadk-linux-uclibceabihf
And the version I used was 5.0.2 of llvm.
So that compiled for me and I got indeed a toolchain in the TOOLCHAIN_USERLAND_DIR location, which I added in vars.mk. So then I needed a toolchain-userland.cmake file to be able to use it, and this is what I came up with:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(MY_GCC_TOOLCHAIN /Volumes/CASE/my-os-pi3/toolchain_raspberry-pi3-cm_uclibc-ng_cortex_a53_hard_eabihf)
set(MY_CLANG_TOOLCHAIN /Volumes/CASE/my-os-pi3/toolchain_userland_raspberry-pi3-cm_uclibc-ng_cortex_a53_hard_eabihf)
SET(CROSS_MACHINE_FLAGS "-marm -mcpu=cortex-a53 -mfloat-abi=hard -mfpu=vfp")
set(MY_COMMON_COMPILE_FLAGS "--target=arm-openadk-linux-uclibceabihf ${CROSS_MACHINE_FLAGS} --gcc-toolchain=${MY_GCC_TOOLCHAIN}/usr")
set(MY_COMMON_LINKER_FLAGS "--target=arm-openadk-linux-uclibceabihf -B ${MY_GCC_TOOLCHAIN}/usr/arm-openadk-linux-uclibceabihf/bin -fuse-ld=bfd -L${MY_GCC_TOOLCHAIN}/usr/lib -L${MY_GCC_TOOLCHAIN}/usr/lib/gcc/arm-openadk-linux-uclibceabihf/7.2.0 --gcc-toolchain=${MY_GCC_TOOLCHAIN}/usr")
set(CMAKE_C_COMPILER ${MY_CLANG_TOOLCHAIN}/usr/bin/clang)
set(CMAKE_CXX_COMPILER ${MY_CLANG_TOOLCHAIN}/usr/bin/clang++)
set(CMAKE_C_FLAGS "-fwrapv -fno-ident ${MY_COMMON_COMPILE_FLAGS} " CACHE STRING "OpenADK CFLAGS" FORCE)
set(CMAKE_CXX_FLAGS "-fwrapv -fno-ident -stdlib=libstdc++ -I${MY_GCC_TOOLCHAIN}/usr/arm-openadk-linux-uclibceabihf/include/c++/7.2.0 -I${MY_GCC_TOOLCHAIN}/usr/arm-openadk-linux-uclibceabihf/include/c++/7.2.0/arm-openadk-linux-uclibceabihf ${MY_COMMON_COMPILE_FLAGS}" CACHE STRING "OpenADK CXXFLAGS" FORCE)
set(CMAKE_EXE_LINKER_FLAGS ${MY_COMMON_LINKER_FLAGS} CACHE STRING "OpenADK LDFLAGS" FORCE)
set(CMAKE_MODULE_LINKER_FLAGS ${MY_COMMON_LINKER_FLAGS} CACHE STRING "OpenADK LDFLAGS" FORCE)
set(CMAKE_SHARED_LINKER_FLAGS ${MY_COMMON_LINKER_FLAGS} CACHE STRING "OpenADK LDFLAGS" FORCE)
set(CMAKE_STATIC_LINKER_FLAGS ${MY_COMMON_LINKER_FLAGS} CACHE STRING "OpenADK LDFLAGS" FORCE)
set(MY_SYSTEM_INCLUDE_DIRS ${MY_GCC_TOOLCHAIN}/usr/arm-openadk-linux-uclibceabihf/include/c++/7.2.0 ${MY_GCC_TOOLCHAIN}/usr/arm-openadk-linux-uclibceabihf/include/c++/7.2.0/arm-openadk-linux-uclibceabihf)
set(CMAKE_INSTALL_SO_NO_EXE 0)
set(CMAKE_PROGRAM_PATH "/Volumes/CASE/my-os-pi3/host_x86_64-apple-darwin16.7.0/usr/bin")
set(CMAKE_SYSROOT "/Volumes/CASE/my-os-pi3/target_raspberry-pi3-cm_uclibc-ng_cortex_a53_hard_eabihf")
set(CMAKE_FIND_ROOT_PATH "/Volumes/CASE/my-os-pi3/target_raspberry-pi3-cm_uclibc-ng_cortex_a53_hard_eabihf")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(ENV{PKG_CONFIG_SYSROOT_DIR} "/Volumes/CASE/my-os-pi3/target_raspberry-pi3-cm_uclibc-ng_cortex_a53_hard_eabihf")
set(ENV{PKG_CONFIG_LIBDIR} "/Volumes/CASE/my-os-pi3/target_raspberry-pi3-cm_uclibc-ng_cortex_a53_hard_eabihf/usr/lib/pkgconfig:@@STAGING_TARGET_DIR@@/usr/share/pkgconfig")
Note: First I tried using -fuse-ld=lld but it can not build the final app: it keeps searching in /lib/ on my host for libc.so.1 and 2 other libs(uclibc libs). If I then add -nostdlib then cmake can compile his testprograms for C and C++. And then all the shared libs of my app build fine, except when linking the final application with all of these libs, it does not find some cxx11 strings and sigint functions: it indicates several undefined references. Weird because I say -stdlib=libstdc++, and those undefined references look like libc++ ones.
So I switched to using the standard “bfd” linker and this compiles and links my libs+app fine. Compilation time is now down to 2 minutes, so I already like it ;)
But, running it failed, but the only thing that I had to do was add a symlink /lib/ld-linux-armhf.so.3 pointing to /lib/ld-uClibc-1.0.26.so and then it runs on my target system.
When I run it, it all seems to work, but an exception thrown from within one of the shared libraries is not caught in the main application. It just hangs there at that particular line. So I tried with the regular toolchain.cmake file (which uses gcc) and there that also didn’t work.
So then I removed the "-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables” options(hardcoded in vars.mk) and rebuild my entire os. Then using the gcc toolchain, it worked fine, and the exception coming from the shared lib was caught in the main application.
But trying that now with the clang toolchain, it still hangs in the shared lib… So try-catch and exceptions work inside these libs, but when one is uncaught, it just hangs there.
So now I have the situation where it almost works, but these exceptions are now the only remaining problem I have. Any clues what could be wrong still?
Thanks
Best regards,
Tom,
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.
