ning Posted August 22, 2019 Author Posted August 22, 2019 15 hours ago, ravelo said: hi all, i'm ravelo fom the khadas forum, does an armbian distro image with mainline 5.3 kernel exists and that is flashable on vim1's emmc using the window amlogic burning tool ? (or using dd) thanks a lot meson64-dev is 5.3-rc, you can build image yourself. amlogic burning tool is not support, you can use dd to SDcard, and finally install to emmc, khadas vendor image will be removed completely.
balbes150 Posted August 22, 2019 Posted August 22, 2019 1 hour ago, ning said: I didn't see armbian tvbox branch is already support S905x, when I submit Khadas VIM1 patches, and your image is not accessable in China. For the first time I hear that in China there are problems with obtaining images from the y-disk. I communicate with Khadas developers from China and they regularly download and test my images on all Khadas products. If you really want to help integrate all versions into a single build branch, you can take up the tvboxes branch. @Igor did the primary work, but he and I do not have enough time to bring everything to full readiness. By the way, how do you plan to run your image on VIM ?
ravelo Posted August 22, 2019 Posted August 22, 2019 Ok, understood ! but why is SD card (and USB) the only supported way to deploy the image I could build ?
ning Posted August 22, 2019 Author Posted August 22, 2019 52 minutes ago, balbes150 said: By the way, how do you plan to run your image on VIM ? meson64-dev supports VIM1, I have no plan to do other things.
TonyMac32 Posted August 22, 2019 Posted August 22, 2019 How else do you deploy 3rd party images to a board? Very few have UMS support to flash directly.Sent from my Pixel using Tapatalk
Igor Posted August 22, 2019 Posted August 22, 2019 2 hours ago, ning said: meson64-dev is 5.3-rc, you can build image yourself. Added (untested) nightly images:https://dl.armbian.com/kvim1/ 1
ravelo Posted August 22, 2019 Posted August 22, 2019 for an amlogic board that comes natively with some EMMC and because amlogic provides tools for flashing firmware images on said EMMC, I expect that we can build some mainline based kernel firmware image that we would directly flash to said EMMC
ravelo Posted August 22, 2019 Posted August 22, 2019 57 minutes ago, Igor said: Added (untested) nightly images:https://dl.armbian.com/kvim1/ thanks ! will test that , I'm new here, where do I find the instructions on how to flash it and boot it ?
TonyMac32 Posted August 22, 2019 Posted August 22, 2019 for an amlogic board that comes natively with some EMMC and because amlogic provides tools for flashing firmware images on said EMMC, I expect that we can build some mainline based kernel firmware image that we would directly flash to said EMMCTheir tools are designed around Android, and I've only used them in that context on TV boxes.Sent from my Pixel using Tapatalk
ravelo Posted August 22, 2019 Posted August 22, 2019 @TonyMac32 this tool https://androidpctv.com/amlogic-usb-burning-tool-v2170/ is maybe able to burn android firmwares to ATV boxes, I never used it for such a purpose, we do use it to flash official (and custom) ubuntu firmwares to VIM1's EMMC, and it works ok for that task; afaik, there is also a linux based binary that can do almost the same, from a shell command line.
Igor Posted August 22, 2019 Posted August 22, 2019 1 hour ago, ravelo said: I'm new here, where do I find the instructions https://docs.armbian.com/User-Guide_Getting-Started/ 1
TonyMac32 Posted August 22, 2019 Posted August 22, 2019 @Ravelo I'll have to take a look. Often these tools assume the Android partition structure, which we don't use, thus they throw errors.Sent from my Pixel using Tapatalk
ravelo Posted August 22, 2019 Posted August 22, 2019 @TonyMac32 I see armbian has an option to install itself totally in EMMC, once it has booted from an SD card. in that case, what kind of emmc partition structure did you choose to use and how different (and better?) is it compared to that android structure you mentionned ?
TonyMac32 Posted August 23, 2019 Posted August 23, 2019 Armbian uses a single partition for everything for basic usability. Android has all of these split up into a whole bunch of partitions. https://source.android.com/devices/bootloader/partitions-images OTA updates and sandboxing make that better for Android, for us it's more practical to have a normal desktop-style configuration. A lot of burning tools for ARM set-top box processors though expect that android layout, so it makes burning our image difficult if not impossible.
TonyMac32 Posted August 23, 2019 Posted August 23, 2019 13 hours ago, balbes150 said: If you really want to help integrate all versions into a single build branch I have not been tracking the TV boxes topic, I more or less thought it had gone stale. Mainline support is fairly good, the addition of VIM 1 in existing Meson64-dev was very straightforward. I merged it due to the simplicity, and the fact it is more SBC than TV box, and @ning had put in the work.
balbes150 Posted August 23, 2019 Posted August 23, 2019 15 hours ago, ning said: meson64-dev supports VIM1, I have no plan to do other things. I am asking about specific steps (instruction) for the end user so that he can run your image. 2 hours ago, TonyMac32 said: I merged it due to the simplicity, and the fact it is more SBC than TV box, and @ning had put in the work. An important fundamental difference between TV boxes (by the term TV box I mean all devices with built-in u-boot on eMMC or SPI) from the old variants of SBC , in the principles of starting the system. Khadas products belong to the category of TV boxes, with all the ensuing consequences in the development of systems for them. Again, how do you plan to run the system on Khadas products with AML chips (VIM 1 2 3)? By the way, the built-in u-boot gives a unique opportunity to use the TV boxes as a normal PC with the launch of the system from USB media. Given that modern chips support USB 3.0, which is significantly faster than SD cards, the use of USB to host the entire system is an important element. The ease of use of USB is many times higher than SD cards.
ravelo Posted August 23, 2019 Posted August 23, 2019 afaik, the official khadas ubuntu booted from the EMMC does use a single partition to host all files, here are a few command results maybe confirming my intuition.. could I be wrong ? The fact is that the mainline kernels cannot read the EMMC's partitions as of now (maybe some patches can solve that, as they did sometime in the past when we had made an ubuntu image based on a customized mainline kernel 4.12 that was directly burnt into the EMMC using the amlogic tools; and it booted and run fine) khadas@Khadas:~$ sudo blkid [sudo] password for khadas: /dev/rootfs: LABEL="ROOTFS" UUID="eb0ce16e-cb91-4523-9ed4-987eb7055203" TYPE="ext4" /dev/zram1: UUID="187ab012-22a1-4ca3-a131-2510250ab3a6" TYPE="swap" /dev/zram2: UUID="d52c3310-b45a-428e-886b-7cb98b2cbbbc" TYPE="swap" /dev/zram3: UUID="00e4ba55-8230-4200-8e2f-e4be338cb6ba" TYPE="swap" /dev/zram4: UUID="03039fa4-a3a7-46bf-9206-34fed389840d" TYPE="swap" khadas@Khadas:~$ mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=781856k,nr_inodes=195464,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=203572k,mode=755) /dev/rootfs on / type ext4 (rw,relatime,data=writeback) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/schedtune type cgroup (rw,nosuid,nodev,noexec,relatime,schedtune) cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=0,minproto=5,maxproto=5,direct) mqueue on /dev/mqueue type mqueue (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) configfs on /sys/kernel/config type configfs (rw,relatime) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=203568k,mode=700,uid=1000,gid=1000) khadas@Khadas:~$ cat /proc/partitions major minor #blocks name 179 0 15267840 mmcblk0 179 1 4096 mmcblk0p1 179 2 65536 mmcblk0p2 179 3 8192 mmcblk0p3 179 4 8192 mmcblk0p4 179 5 32768 mmcblk0p5 179 6 15083520 mmcblk0p6 179 96 4096 mmcblk0rpmb 179 64 4096 mmcblk0boot1 179 32 4096 mmcblk0boot0 251 1 254464 zram1 251 2 254464 zram2 251 3 254464 zram3 251 4 254464 zram4
balbes150 Posted August 23, 2019 Posted August 23, 2019 39 minutes ago, ravelo said: 179 1 4096 mmcblk0p1 179 2 65536 mmcblk0p2 179 3 8192 mmcblk0p3 179 4 8192 mmcblk0p4 179 5 32768 mmcblk0p5 179 6 15083520 mmcblk0p6 These are sections in the Android format. Khadas uses the old 4.9 kernel from Amlogic, which is heavily patched for this. In the main core there is no support for partitions of Android. If you want to install a new kernel in eMMC and keep the u-boot-2015 installed, you must use a special procedure to install the system in eMMC. This feature is present in Armbian images for TV boxes (and it works perfectly on all Khadas VIM 1 2 3 products).
ravelo Posted August 23, 2019 Posted August 23, 2019 once armbian would boot from SD, then writes itself entirely on the EMMC, does it replace change amlogic/khadas' EMMC "android" partitionning table to something more common like GPT ?
Z11ntal33r Posted August 23, 2019 Posted August 23, 2019 I was going to buy an ODROID-N2 to replace my RK3288, but given the mess around USB3 for the N2, which is one of the few important aspects that need to work perfectly, I'm thinking of buying a Vim3 instead. However, the perception that I have is that it will be a significant drawback in stability in regard of software maturity, and it doesn't help that it's neither official or unofficial supported as the N2. I want to use my VIM3 as a headless server with main functionality perfectly working as running OS from eMMC, gigabit ethernet, USB3 interface with several HDDs, HDMI (if I loose ssh connection and need to input commands local) etc, is balbes build running mainline kernel as Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821 the way you would go? I can't find any status of the current state of what's working and what is not. I don't need a rock solid state, but my VIM3 can't have issues every week either... I'm more passionate about mainline support and especially the recent development of g12 support compared to Khadas' 4.9 kernel, in addition to that I still want to stick with Armbian. I presume that the experience with Armbian using balbes build won't be much of a difference user functionality wise compared to example Armbian_5.94.190822_Tinkerboard_Debian_buster_dev_5.2.9_minimal? (disregarded that minimal has fewer packages installed etc).
balbes150 Posted August 23, 2019 Posted August 23, 2019 2 hours ago, ravelo said: once armbian would boot from SD, then writes itself entirely on the EMMC, does it replace change amlogic/khadas' EMMC "android" partitionning table to something more common like GPT ? During the installation, a regular MBR is created and then the main kernel works with eMMC, as with a conventional HDD\SSD (all utilities work as with conventional disks). If desired, after installation in eMMC, you can change partitions, add your own split and mount options. 1
balbes150 Posted August 23, 2019 Posted August 23, 2019 30 minutes ago, Z11ntal33r said: I presume that the experience with Armbian using balbes build won't be much of a difference user functionality wise compared to example Armbian_5.94.190822_Tinkerboard_Debian_buster_dev_5.2.9_minimal? (disregarded that minimal has fewer packages installed etc). Example: Will balbes build update the kernel when next mainline version is released and tested, or would I need to upgrade manually etc? While the kernel is being updated manually. This option has its pros and cons. Otherwise , support for Khadas from Armbian products is stable and complete (exception , support for some wifi models on VIM 2 \ 3).
Z11ntal33r Posted August 23, 2019 Posted August 23, 2019 3 minutes ago, balbes150 said: While the kernel is being updated manually. This option has its pros and cons. Otherwise , support for Khadas from Armbian products is stable and complete (exception , support for some wifi models on VIM 2 \ 3). I don't mind updating kernel manually, so that's fine for me. Since you use "default", "dev" and "Next" when naming your builds, are there any differences except the kernel? Given the g12 support added for kernel 5.3, I assume the user experience is better compared to 5.2 with your latest build Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821. So, do you advice that I use default Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821 and update kernel manually to 5.3 RC5 or just use next with Armbian_5.91_Aml-g12_Debian_buster_next_5.3.0-rc5-next-20190820?
balbes150 Posted August 23, 2019 Posted August 23, 2019 18 minutes ago, Z11ntal33r said: I don't mind updating kernel manually, so that's fine for me. Since you use "default", "dev" and "Next" when naming your builds, are there any differences except the kernel? Given the g12 support added for kernel 5.3, I assume the user experience is better compared to 5.2 with your latest build Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821. So, do you advice that I use default Armbian_5.94_Aml-g12_Debian_buster_default_5.2.1_20190821 and update kernel manually to 5.3 RC5 or just use next with Armbian_5.91_Aml-g12_Debian_buster_next_5.3.0-rc5-next-20190820? Yes, that's right, the difference between the default next and dev versions only in the kernel. The default version uses the most stable and proven kernel , with the best support for all hardware for Khadas. Version DEV - test version, with new options. NEXT is the official kernel from GIT Linux Next "as is" , without adding patches, used to assess the state of support for different hardware in the official sources.
ravelo Posted August 23, 2019 Posted August 23, 2019 1 hour ago, balbes150 said: During the installation, a regular MBR is created and then the main kernel works with eMMC, as with a conventional HDD\SSD (all utilities work as with conventional disks). so, once armbian is written into EMMC and boots from it, how do we upgrade , later, just the kernel (example from 5.3rcx to 5.3.y) without reflashing the full distro ?
balbes150 Posted August 23, 2019 Posted August 23, 2019 9 minutes ago, ravelo said: so, once armbian is written into EMMC and boots from it, how do we upgrade , later, just the kernel (example from 5.3rcx to 5.3.y) without reflashing the full distro ? As on a normal system, the dpkg command from the package with the new kernel. Or you build your own kernel and copy (install) new files into the system 1
ravelo Posted August 24, 2019 Posted August 24, 2019 On 8/23/2019 at 12:35 PM, balbes150 said: These are sections in the Android format. Khadas uses the old 4.9 kernel from Amlogic, which is heavily patched for this. in patch_mainline_kernel() in https://pastebin.com/BZLCyg5Q , the changes needed for 4.12 were not so heavy regarding emmc, i will try to apply the same to 5.3
Recommended Posts