Jump to content

offically support Khadas VIM?


ning

Recommended Posts

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
Their tools are designed around Android, and I've only used them in that context on TV boxes.

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

@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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?  

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • NicoD featured and unfeatured this topic
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines