Jump to content

More proper testing - better Armbian experience

Igor

By Igor
in Advanced users - Development

 Share

Recommended Posts

wildcat_paris

wildcat_paris

Posted
Posted

Please try rebuilding the kernel with updated config. Since kernel doesn't pick command line both from legacy and mainline u-boot, it must be a kernel issue.

@zador.blood.stain

You did good about the missing kernel options. it is running.

(Still need the update to rename or use xu4.dtb instead of xu3) but ok!!!!

http://pastebin.com/Gwyuh7Kv

http://pastebin.com/sVjga3bL

 

the diff http://pastebin.com/zyanC78b

probably we need to unify boot.cmd now both legacy/vanilla can boot with single partition uboot 2016.09

 

edit:

uboot 2016.09 & legacy kernel, the fan doesn't seem to work

 

edit2:

so both legacy/vanilla boots with uboot 2016.09 with the diff (on SD, eMMC to be confirmed)

Link to comment
Share on other sites
mrneilypops

mrneilypops

Posted
Posted

C2 Ubuntu 16.04.1 image installed to Hardkernel eMMC 32GB 

Screenshotfrom2016-10-2817-49-37.png

  Armbian_5.24.161028_Odroidc2_Ubuntu_xenial_3.14.79_desktArmbian_5.24.161028_Odroidc2_Ubuntu_xenial_3.14.79_desktop

[sudo dd bs=1M if=filename.img of=/dev/sdx sync]

 

Screenshot_2016-10-28_13-33-36.th.png

 

  •  
  • Firefox running OK. Chromium installed and running OK. Both play html5 OK.
  •  
  • Very fast responsive desktop.
  •  
  • Very fast boot! ...from power on to desktop in 10 seconds! [no boot messages-is this by design?]
  •  
  • [Radio Tray install required pytho-xdg + python-notify]
  •  

​

Memory usage running Chromium+radio tray;

 

Screenshot_2016-10-28_14-10-17.th.png

 

playing with mpv...nice!

 

Screenshot_2016-10-28_14-31-06.th.png

 

  •  
  • LibreOffice writer ugly interface... was missing libreoffice-gtk and libreoffice-style-tango (eg)
  •  

see also here -> http://askubuntu.com/questions/285089/why-does-my-xubuntu-libreoffice-look-ugly

 

I will EDIT as uptime increases and any issues become apparent...

 

Uptime > 3 hours and nearing the end of testing for today.

Nothing more to report at the moment...all stable and running temp of 42C with light load and crappy temporary heat sink addition....aluminium case en route...

 

Uptime = 4.5 hours test reboot initiated and completed in 20 seconds!

 

Conclusion thus far = the fastest most responsive ARM image I have used to date.  

I have to keep reminding myself I am using such a small form factor as a desktop!

Stunning work Armbian team!

 

Note: peripheral = USB DAC HiFime 9018D

http://hifimediy.com/9018D-dac

working out of the box...no issues observed...great sound!

 

1 default apps request;


this baby is gonna cook all night while I get my beauty sleep...update am...

 

EDIT: I did shutdown for the night but all is well after a fresh 10 second boot...

EDIT#2: later in the day...C2 dev image still running stable...no issues to report

 

 

[next target is the xu4 dev image - looking forward to testing and reporting back]

1
Link to comment
Share on other sites
mrneilypops

mrneilypops

Posted
Posted

Trying to test latest XU4 image;

Armbian_5.24.161029_Odroidxu4_Ubuntu_xenial_3.10.104_desktop.img

 

Screenshotfrom2016-10-2921-35-12.png

 

[sudo dd bs=1M if=filename.img of=/dev/sdx sync]

 

Ubuntu 16.04.1 image installed to Hardkernel eMMC 32GB

The same eMMC works fine with the current armbian release image;

http://docs.armbian.com/Release_Changelog/

 

 

gparted info

 

Screenshotfrom2016-10-2917-56-59.th.png

red light only on boot...no heartbeat light....

 

Any ideas appreciated...

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

Trying to test latest XU4 image;

Armbian_5.24.161029_Odroidxu4_Ubuntu_xenial_3.10.104_desktop.img

...

Any ideas appreciated...

Getting output from serial console would be ideal. And testing this image on SD to check if image is broken for both storage types or not.

There were some changes to board configurations, all newer images should have a single ext4 partition, so lack of FAT boot partition is normal.

Link to comment
Share on other sites
wildcat_paris

wildcat_paris

Posted
Posted

Getting output from serial console would be ideal. And testing this image on SD to check if image is broken for both storage types or not.

There were some changes to board configurations, all newer images should have a single ext4 partition, so lack of FAT boot partition is normal.

@zador.blood.stain @mrneilypops

 

XU4 : uboot 2012.07 needs a dual boot partition. So uboot 2016.09 is needed as https://github.com/igorpecovnik/lib/pull/520

or a switch back to dual partitions for legacy kernel

 

(with uboot 2016.09, a writing/booting to a SD card is needed, then somewhere in the SD card there is sd_fusing.sh to write the boot loader in "boot0" partition)

 

@zador.blood.stain: better switch back to dual partition for legacy kernel on XU4 for the moment.

Link to comment
Share on other sites
wildcat_paris

wildcat_paris

Posted
Posted

Who said that? Any u-boot that supports reading from ext4 can be "convinced" to use single partition scheme, we just need to get enough logs and feedback to properly implement this.

Me.

 

I haven't seen uboot 2012.07 working with a single partition. I can be wrong, of course.

And anyway, without overwriting boot0 partition on eMMC with a proper uboot & blobs, I have tested, you are not gonna make it working.

In the best case, SD could work.

 

my next step would have been to test more fully how uboot 2016.09 & legacy kernel works (HDMI stuff & so on) but...

 

read your words. A project is to attract people, not repeal them.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

I haven't seen uboot 2012.07 working with a single partition. I can be wrong, of course.

That's exactly why this topic exists - if logs confirm that it's not possible, then I will revert to separate FAT boot partition, but for now I would like to see why current images are failing to boot.

 

And anyway, without overwriting boot0 partition on eMMC with a proper uboot & blobs, I have tested, you are not gonna make it working.

Can you please elaborate on this - bootable parts on eMMC are write-protected or hidden even if you put it into a card reader via adapter?

All I can find is this: http://odroid.com/dokuwiki/doku.php?id=en:emmc_recovery_xu3

 

In the best case, SD could work.

If SD works then nand-sata-install can be used (in the future) to make a proper partition scheme on eMMC

 

read your words. A project is to attract people, not repeal them.

?!?

Link to comment
Share on other sites
wildcat_paris

wildcat_paris

Posted
Posted

Can you please elaborate on this - bootable parts on eMMC are write-protected or hidden even if you put it into a card reader via adapter?

All I can find is this: http://odroid.com/dokuwiki/doku.php?id=en:emmc_recovery_xu3

 

 

write protected? yes and no, that is the purpose of the sd_fusing.sh script to allow boot0 to be rewritten.

https://github.com/igorpecovnik/lib/blob/a82dc77aee0c286de600192365922dc74741185f/patch/u-boot/u-boot-odroidxu-next/xu4_sd_fusing.patch

 

1/ the eMMC2SD converter Hardkernel provides cannot see boot0/1/etc. internal partitions.

2/ Only a XU4 booted from SD card can do that & use sd_fusing.sh script

3/ if you don't overwrite boot0 of eMMC, you have a creepy uboot 2012.07 which will probably fail with single partion/vanilla kernel.

 

you cannot rely on Hardkernel for software, only Samsung Opensource Group does a great job.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

you cannot rely on Hardkernel for software, only Samsung Opensource Group does a great job.

This is a little bit off-topic, but they (Hardkernel) provide updates (both security fixes and new features) to u-boot and kernel, and provide good images at least for some boards, so this is already better than most of Allwinner-based boards manufacturers.

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted

I agree and I vote also for collecting feedback prior to start any work. I could imagine a simple HTML form accessible through GET method so a test mechanism can either submit data in an automated way or provide an URL that's ready for copy&paste.

 

Please note that some ideas exist already -- please see https://github.com/igorpecovnik/lib/issues/512 and https://github.com/igorpecovnik/lib/issues/511#issuecomment-256420416. We must ease helping users testing through new releases and upgrade procedure so exactly this sort of feedback has to be collected NOW.

 

A simple way of getting just enough(?) feedback.

 

- armbianmonitor -u result is stored to our server by default (or by extra switch)

- we build a parser, which renders collected data into human readable format.

 

I suppose using php or python would be best to handle this job.

Link to comment
Share on other sites
jeanrhum

jeanrhum

Posted
Posted

I tested 11-9-2016 desktop image for pine64+.

 

armbianmonitor - u uploaded data to : http://sprunge.us/LQeH

 

I don't know if you also want such format for feedback, but here it is:

 

Card                        Boot         Network         HDMI         Install           Date          Performed by
-----------------------------------------------------------------------------------------------------------------------------
Pine64+(1GB)        yes             yes                 yes             yes            11.9.2016          jeanrhum
 

My fealing about using this sbc and image:

Desktop experience is not too bad. I'm writting this post from pine64 using firefox, while uploading a file (~2.3MB/s) to my nas (BPRO with armbian :D) and while downloading another file from the internet (~500kB/s). Wireless card works out of the box and I directly connect to my personal wireless network without any problem. The main issue is the screen resolution, since I use an old screen (4:3 1280x960) and I have a resolution of 1280x720. I try to watch a video with pre-installed mpv, but it's a bit laggy in 720p (big buck bunny sample in mp4 and mkv).

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

The main issue is the screen resolution, since I use an old screen (4:3 1280x960) and I have a resolution of 1280x720. I try to watch a video with pre-installed mpv, but it's a bit laggy in 720p (big buck bunny sample in mp4 and mkv).

There is no video acceleration preinstalled for Pine64 yet. It may be added later.

Regarding resolutions - it may be solved later with experimental EDID capable driver from H3.

Link to comment
Share on other sites
jernej

jernej

Posted
Posted

Regarding resolutions - it may be solved later with experimental EDID capable driver from H3.

 

I just learned on U-Boot HDMI driver example that kernel implementation is not complete. Most importantly, it is missing code for changing PLL_VIDEO clock, which is important code for supporting otherwise non suported resolutions.

2
Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

Todays images and repository was rebuild after this:

Add fixed Mali driver for sun8i. Needs testing

This needs testing with any of 512MB RAM and with any of 1GB RAM boards since I'm too busy/lazy to do it today. Running mali-triangle from mali-sunxi-utils package and ex2gears from mesa-utils-extra package on any desktop image should be enough.

Link to comment
Share on other sites
Igor

Igor

Posted
  • Author
Posted

@zammy

 

Those boards are all very similar ... try Opi Zero image.

 

@zador.blood.stained

 

[ warn ] Following packages failed to build:

[ .... ] libglshim:jessie:armhf

[ .... ] libglshim:xenial:armhf

 

 

 

[ .... ] Building package
dpkg-buildpackage: source package glshim
dpkg-buildpackage: source version 1.0-1~armbian5.24.161112+1
dpkg-buildpackage: source distribution UNRELEASED
dpkg-buildpackage: source changed by Igor Pecovnik <igor.pecovnik@****l.com>
dpkg-buildpackage: host architecture armhf
dpkg-buildpackage: warning: debian/rules is not executable; fixing that
 dpkg-source --before-build libglshim
 debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 debian/rules build
dh build
   dh_testdir
   dh_update_autotools_config
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/root/build/libglshim'
dh_auto_configure -- -DCMAKE_VERBOSE_MAKEFILE=OFF -DPRIVATEDIR=glshim
        cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_VERBOSE_MAKEFILE=OFF -DPRIVATEDIR=glshim
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/lib/ccache/arm-linux-gnueabihf-gcc
-- Check for working C compiler: /usr/lib/ccache/arm-linux-gnueabihf-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib/ccache/arm-linux-gnueabihf-g++
-- Check for working CXX compiler: /usr/lib/ccache/arm-linux-gnueabihf-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_INSTALL_LOCALSTATEDIR
    CMAKE_INSTALL_SYSCONFDIR
    PRIVATEDIR


-- Build files have been written to: /root/build/libglshim/obj-arm-linux-gnueabihf
make[1]: Leaving directory '/root/build/libglshim'
   debian/rules override_dh_auto_build
make[1]: Entering directory '/root/build/libglshim'
dh_auto_build -- GL preload
        make -j1 GL preload
make[2]: Entering directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
make[3]: Entering directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
make[4]: Entering directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
make[5]: Entering directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
Scanning dependencies of target GL
make[5]: Leaving directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
make[5]: Entering directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
[  2%] Building C object src/CMakeFiles/GL.dir/gl/array.c.o
[  5%] Building C object src/CMakeFiles/GL.dir/gl/buffers.c.o
[  8%] Building C object src/CMakeFiles/GL.dir/gl/debug.c.o
[ 11%] Building C object src/CMakeFiles/GL.dir/gl/decompress.c.o
[ 13%] Building C object src/CMakeFiles/GL.dir/gl/directstate.c.o
[ 16%] Building C object src/CMakeFiles/GL.dir/gl/eval.c.o
[ 19%] Building C object src/CMakeFiles/GL.dir/gl/framebuffers.c.o
[ 22%] Building C object src/CMakeFiles/GL.dir/gl/getter.c.o
[ 25%] Building C object src/CMakeFiles/GL.dir/gl/gl.c.o
[ 27%] Building C object src/CMakeFiles/GL.dir/gl/hint.c.o
[ 30%] Building C object src/CMakeFiles/GL.dir/gl/init.c.o
/root/build/libglshim/src/gl/init.c:62:95: warning: macro "__DATE__" might prevent reproducible builds [-Wdate-time]
     SHUT(LOGD("LIBGL: v%d.%d.%d built on %s %s\n", MAJOR, MINOR, REVISION, __DATE__, __TIME__));
                                                                                               ^
/root/build/libglshim/src/gl/init.c:62:95: warning: macro "__TIME__" might prevent reproducible builds [-Wdate-time]
[ 33%] Building C object src/CMakeFiles/GL.dir/gl/light.c.o
[ 36%] Building C object src/CMakeFiles/GL.dir/gl/line.c.o
[ 38%] Building C object src/CMakeFiles/GL.dir/gl/list.c.o
[ 41%] Building C object src/CMakeFiles/GL.dir/gl/loader.c.o
[ 44%] Building C object src/CMakeFiles/GL.dir/gl/matrix.c.o
[ 47%] Building C object src/CMakeFiles/GL.dir/gl/matvec.c.o
[ 50%] Building C object src/CMakeFiles/GL.dir/gl/pixel.c.o
[ 52%] Building C object src/CMakeFiles/GL.dir/gl/queries.c.o
[ 55%] Building C object src/CMakeFiles/GL.dir/gl/raster.c.o
[ 58%] Building C object src/CMakeFiles/GL.dir/gl/render.c.o
[ 61%] Building C object src/CMakeFiles/GL.dir/gl/stack.c.o
[ 63%] Building C object src/CMakeFiles/GL.dir/gl/texgen.c.o
[ 66%] Building C object src/CMakeFiles/GL.dir/gl/texture.c.o
[ 69%] Building C object src/CMakeFiles/GL.dir/gl/wrap/gl.c.o
[ 72%] Building C object src/CMakeFiles/GL.dir/gl/wrap/gles.c.o
[ 75%] Building C object src/CMakeFiles/GL.dir/gl/wrap/gles2.c.o
[ 77%] Building C object src/CMakeFiles/GL.dir/gl/wrap/glesext.c.o
[ 80%] Building C object src/CMakeFiles/GL.dir/gl/wrap/glstub.c.o
[ 83%] Building C object src/CMakeFiles/GL.dir/gl/math/eval.c.o
[ 86%] Building C object src/CMakeFiles/GL.dir/glx/hardext.c.o
[ 88%] Building C object src/CMakeFiles/GL.dir/glx/glx.c.o
[ 91%] Building C object src/CMakeFiles/GL.dir/glx/lookup.c.o
[ 94%] Building C object src/CMakeFiles/GL.dir/glx/streaming.c.o
[ 97%] Building C object src/CMakeFiles/GL.dir/glx/utils.c.o
[100%] Linking C shared library ../lib/libGL.so.1
make[5]: Leaving directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
[100%] Built target GL
make[4]: Leaving directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
make[3]: Leaving directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
make[2]: *** No rule to make target 'preload'.  Stop.
make[2]: Leaving directory '/root/build/libglshim/obj-arm-linux-gnueabihf'
dh_auto_build: make -j1 GL preload returned exit code 2
debian/rules:17: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/root/build/libglshim'
debian/rules:25: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
[ error ] Failed building [ libglshim xenial armhf ]

 

Link to comment
Share on other sites
Nixes

Nixes

Posted
Posted

So I just tested the "Armbian_5.24.161115_Orangepipc_Ubuntu_xenial_3.4.113_desktop" image on my OrangePiPC

 

Tests:

    mali-triangle: worked

    es2gears: worked (250fps)

 

Observations:

Firefox was MUCH smoother then last time I used it in an armbian desktop package. I think more hardware acceleration is kicking in than in previous builds.

 

I still have the install running if there are any other tests wanted.

1
Link to comment
Share on other sites
jeanrhum

jeanrhum

Posted
Posted

New test for pine64 with image from yesterday (18/11/2016): http://sprunge.us/BOfN

 

es2gears output:

libEGL warning: DRI2: failed to authenticate
EGL_VERSION = 1.4 (DRI2)
vertex shader info: 
fragment shader info: 
info: 
596 frames in 5.0 seconds = 119.105 FPS
543 frames in 5.0 seconds = 108.448 FPS
600 frames in 5.0 seconds = 119.856 FPS
623 frames in 5.0 seconds = 124.525 FPS

I was unable to install mali-sunxi-utils due to an error in installing libmali-sunxi-r3p0_1.0-1~armbian5.23+1_armhf.deb even if i use apt-get install -f.

 

As for previous versions, the current desktop has several bugs with gtk elements: several items within windows like checkboxes are not visible until checked. Obviously, it makes it difficult to select the corresponding items (eg: show password of the wireless connection window or other some items of the download window within firefox).

 

Playing videos seems much more smoother than in my previous test.

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted

New test for pine64 with image from yesterday (18/11/2016): http://sprunge.us/BOfN

 

es2gears output:

libEGL warning: DRI2: failed to authenticate
EGL_VERSION = 1.4 (DRI2)
vertex shader info: 
fragment shader info: 
info: 
596 frames in 5.0 seconds = 119.105 FPS
543 frames in 5.0 seconds = 108.448 FPS
600 frames in 5.0 seconds = 119.856 FPS
623 frames in 5.0 seconds = 124.525 FPS

I was unable to install mali-sunxi-utils due to an error in installing libmali-sunxi-r3p0_1.0-1~armbian5.23+1_armhf.deb even if i use apt-get install -f.

There is no Mali on Pine64 yet, and I think this situation won't change in the near future. Only video decoding with preinstalled mpv was enabled recently.

 

As for previous versions, the current desktop has several bugs with gtk elements: several items within windows like checkboxes are not visible until checked. Obviously, it makes it difficult to select the corresponding items (eg: show password of the wireless connection window or other some items of the download window within firefox).

Hm. Missing GTK themes or packages? This needs to be checked in the future. Thanks for the report.

Link to comment
Share on other sites
manuti

manuti

Posted
Posted

I tested Orange Pi PC on Orange Pi One, I don't know if this is useful:

uname -a shows:

orangepipc 4.9.0-sun8i #56 SMP Wed Nov 23 01:04:34 CET 2016 armv7l armv7l armv7l GNU/Linux

armbianmonitor - u uploaded data to : http://sprunge.us/UPAE

 

I don't know if you also want such format for feedback, but here it is:

 

Card                        Boot         Network         HDMI         Install         Date                  Performed by
-----------------------------------------------------------------------------------------------------------------------------
Orange Pi One        yes             yes               no               yes            25.11.2016        manuti

 

I update the image and install docker from the default repositories, in the webpage from armbianmonitor I can't see the temperature and of course the HDMI is not working.

 

2
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept