zador.blood.stained Posted October 27, 2016 Posted October 27, 2016 yes it "kind of" boots, but the system cannot go any further with root=<null> Sure the dtb file renaming is a "detail" I can handle. 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. 1
wildcat_paris Posted October 28, 2016 Posted October 28, 2016 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)
mrneilypops Posted October 28, 2016 Posted October 28, 2016 C2 Ubuntu 16.04.1 image installed to Hardkernel eMMC 32GB 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] 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; playing with mpv...nice! 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; glances 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
mrneilypops Posted October 29, 2016 Posted October 29, 2016 Trying to test latest XU4 image; Armbian_5.24.161029_Odroidxu4_Ubuntu_xenial_3.10.104_desktop.img [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 red light only on boot...no heartbeat light.... Any ideas appreciated...
zador.blood.stained Posted October 29, 2016 Posted October 29, 2016 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.
mrneilypops Posted October 29, 2016 Posted October 29, 2016 Thanks for the info. I will try an SD install soon... hmm... gotta find a spare SD
wildcat_paris Posted October 29, 2016 Posted October 29, 2016 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.
zador.blood.stained Posted October 30, 2016 Posted October 30, 2016 XU4 : uboot 2012.07 needs a dual boot partition. 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. 1
wildcat_paris Posted October 30, 2016 Posted October 30, 2016 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.
zador.blood.stained Posted October 30, 2016 Posted October 30, 2016 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. ?!?
wildcat_paris Posted October 30, 2016 Posted October 30, 2016 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.
zador.blood.stained Posted October 31, 2016 Posted October 31, 2016 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.
zador.blood.stained Posted November 10, 2016 Posted November 10, 2016 @Igor Since you moved web stuff from XU4 can I assume that it's available for testing? Can you please check and collect logs from legacy image?
Igor Posted November 10, 2016 Author Posted November 10, 2016 Sure, ASAP. Need to mount it from the case
Igor Posted November 10, 2016 Author Posted November 10, 2016 Odroid XU4, latest desktop image from beta download. Booting normal but serial console login is not present. http://sprunge.us/FeWL
Igor Posted November 11, 2016 Author Posted November 11, 2016 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.
jeanrhum Posted November 11, 2016 Posted November 11, 2016 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 ) 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).
zador.blood.stained Posted November 11, 2016 Posted November 11, 2016 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.
jernej Posted November 11, 2016 Posted November 11, 2016 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
Igor Posted November 11, 2016 Author Posted November 11, 2016 Todays images and repository was rebuild after this: Add fixed Mali driver for sun8i. Needs testing
zador.blood.stained Posted November 11, 2016 Posted November 11, 2016 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.
Zammy Posted November 11, 2016 Posted November 11, 2016 Hi, could you please add images for Orange Pi One and Orange Pi Lite?
Igor Posted November 12, 2016 Author Posted November 12, 2016 @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 ]
manuti Posted November 16, 2016 Posted November 16, 2016 I want to try mainline kernel on Orange Pi One, which is the better image from testing? Armbian_5.24.161115_Orangepipc_Ubuntu_xenial_4.9.0.7z Armbian_5.24.161115_Nanopiair_Ubuntu_xenial_4.9.0.7z
Nixes Posted November 16, 2016 Posted November 16, 2016 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
jeanrhum Posted November 19, 2016 Posted November 19, 2016 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.
zador.blood.stained Posted November 19, 2016 Posted November 19, 2016 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.
manuti Posted November 25, 2016 Posted November 25, 2016 Hi, could you please add images for Orange Pi One and Orange Pi Lite? I'm using OrangePiPC beta Xenial mainline kernel for a couple of days
manuti Posted November 25, 2016 Posted November 25, 2016 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
Igor Posted November 29, 2016 Author Posted November 29, 2016 Odroid C2 and Opi PC, latest beta. I was already looking if we produced this problem and where ...
Recommended Posts