0
ning

offically support Khadas VIM?

Recommended Posts

Hi @balbes150

 

thank you for a lot of great work on Khadas VIM. could you make it offically support by Armbian?

 

 

Share this post


Link to post
Share on other sites

@balbes150
 

4 hours ago, ning said:

Hi @balbes150

 

thank you for a lot of great work on Khadas VIM. could you make it offically support by Armbian?

 

I approve this message :)
Great work done by @balbes150 . I'll need it to benchmark the Khadas Vim2 Max in a decent OS.

Share this post


Link to post
Share on other sites

Balbes has done an amazing work supporting Sxxx devices, but it would still be nice to see Vim as officially supported device, becuause it doesn't belong to tv boxes subforum, it isn't a tv box.

Share this post


Link to post
Share on other sites
26 minutes ago, TonyMac32 said:

and Khadas has a wide range of OS options already.

Ubuntu Xenial vs. Armbian Bionic. I know what to chose. I'll now do my tests on Bionic. Already done the official Ubuntu Xenial. I bet there's going to be a nice difference in performance.
 

 

3 minutes ago, Tommy21 said:

Balbes has done an amazing work supporting Sxxx devices, but it would still be nice to see Vim as officially supported device, becuause it doesn't belong to tv boxes subforum, it isn't a tv box.

It's actually sold as being a TV-Box. Don't know why. I think to attract a wider audience.
https://www.gearbest.com/promotion-khadas-vim2-tv-box-special-1531.html
That's also why Linux wasn't a priority for the Khadas team, but Android was.

Share this post


Link to post
Share on other sites

It has great community support thanks to Balbes150 and Kszaq(Libreelec), but official Khadas team support is not so good, most of the work they've done was forking community images and images based on Amlogic buildroot.

 

I know it's sold as tv box, but when Khadas Vim1 came out, they've promised 4k linux support and many more things, can't remember exactly.

 

If you run fenix scripts on Khadas github, there is also Debian image with kernel 4.17 ready to be made.

 

 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites
21 hours ago, ning said:

could you make it officially support by Armbian?

 

One great options is to help make it. I am pretty sure that all current maintainers have a big pile of hardware and very little time. More load is almost impossible to add ... I talked with @balbes150 about this problem long time ago. He is having boxes, I am having boards. Have it or have a free access to them. This is still the same. We as a community, not just he and I, wants to see project develop further. We (those few people who stands out with their work) can't produce more and more. It doesn't go that way ... it's more, more, more ... and once nothing more :( That is bad for all. The one wants to work but he can't and community lost one of the prime contributors.

If you or someone else wants to see this and that board/hardware supported, become its maintainer. It's a long term micro job and we can arrange samples or other random boards from our (over)stock and donations cuts for compensation/motivation.

 

Making board officially supported means answering to its problems over longer period of time. Someone has to take that prime responsibility and someone has to serve as a backup. IMO current maintainers could jump on backup roles at best.

Share this post


Link to post
Share on other sites

I completely agree: the core team is overwhelmed with work, if someone wants to see new boards supported, community contributions is the way to go.

 

However, I've always been curious why @balbes150 is maintaining a separate fork, with different boot method etc., instead of making Vim work on regular Armbian. Is it in order to be able to support more TV boxes with a single image?

Share this post


Link to post
Share on other sites
6 minutes ago, JMCC said:

, instead of making Vim work on regular Armbian. Is it in order to be able to support more TV boxes with a single image?

I think it`s a good easy way. We just need to change a line in a file and done.
Wouldn`t it be easier for you guys to do it this way?(turn the question around) 1 image for al boards. If only the image could check board type and chose the right file itself, then we even wouldn`t need to change that file. And maybe even using the same image on different sbc`s could be possible then.
Just a thought. I don`t know.

Share this post


Link to post
Share on other sites
2 minutes ago, NicoD said:

I think it`s a good easy way. We just need to change a line in a file and done.
Wouldn`t it be easier for you guys to do it this way?(turn the question around) 1 image for al boards. If only the image could check board type and chose the right file itself, then we even wouldn`t need to change that file. And maybe even using the same image on different sbc`s could be possible then.
Just a thought. I don`t know.

Well, that is in a sense what is done now with "board families". All the boards in the same family share the kernel and most filesystem tweaks, and differ only in the device tree and some adjustments for specific hardware. But it is only possible when all the boards share the same SoC or a very close one. With completely different SoC's, that is not possible, each one needs a different kernel. Notice that all different boxes supported by balbes150's images have some Amlogic Meson SoC, and that is why they can use the same image with minor tweaks.

Share this post


Link to post
Share on other sites

You won't be able to build one universal image. Many boards load their firmware from uSD or eMMC, so the board's firmware has to be part of the image. And even if they share a common SoC platform like the AmLogic GX  S9**, the firmware blobs are different. 

And even if you manage to build an universal image for boards with flash memory based firmware, you still want to impose some kind of standard like SBSA. And even then you have to become specific at some point in order to apply the appropriate optimization / configuration for the board. In other words, you're just carrying complexity from 'build time' to 'run time'.

Share this post


Link to post
Share on other sites

Sorry for the delay in answering. I just now happened to see this topic (alas, my barely enough time to read via translator sub-forum about TV boxes). Igor correctly pointed out that the main problem is the lack of time. You can do any thing, but it takes extra time, which, alas, is always very lacking. It is possible to add to the official GIT Assembly for TV boxes, but it requires additional work of all real participants who are working on the creation of Armbian.

Share this post


Link to post
Share on other sites

@Igor

 

I decided to go back to the question of integrating the build options for TV boxes into the overall git. Alternatively, at the first stage, you can make an additional branch (for example, "tv-box") and put all the code from my git "Build-Armbian/master" into it (with minimal fixes author, etc.). I am ready to support a set of basic images (which I am currently releasing) for a number of models that I have in stock (Khadas VIM\VIM2\EDGE , MVR9 etc).

 

If there are other options - I am ready to discuss them.

Share this post


Link to post
Share on other sites

@balbes150 If you think it's appropriate, boards like the Vim (and I would guess Vim2/edge) which don't need as much "special care" from the user to load linux on like the standard TV boxes (Vim(2) has configurations in both U-boot and linux kernel if I remember correctly), those could be moved to the Meson64 part of the script, and we add the Mali/etc as per the usual Armbian method.  I would like to get the Mali driver patched into the kernel source rather than building it separately, but haven't had the time to sit down and go through the configuration to make that happen, so I don't include it in the images yet.

Share this post


Link to post
Share on other sites

 

12 hours ago, balbes150 said:

you can make an additional branch


Yes, let's do that and compare a bit to understand changes you made.  I can do some observation earlier next week to figure out what adjustments do we need to make.

 

@TonyMac32


This can be done in a second phase. The same as we did with, perhaps some older kernel might as well be abandoned ... but I don't have this know-how.

Share this post


Link to post
Share on other sites

@igor no problem, I just wanted to point out that the current Meson64 has all the BayLibre patches for mainline support of the VIM at least, and a lot of VIM2. I only held off adding it because of Balbes's separate work, it seemed redundant. If, however, we are to reunite the build systems, I don't see any reason to keep from just adding those to Meson64, at least for the upcoming 4.19LTS once it's ready

Sent from my Pixel using Tapatalk

Share this post


Link to post
Share on other sites
13 hours ago, Igor said:

Yes, let's do that and compare a bit to understand changes you made.  I can do some observation earlier next week to figure out what adjustments do we need to make. 

You can try this option steps. You'll add a new empty  branch (add readme.md) to git build, I'll be able to clone it, add my changes to the new branch, and send a merge request.

 

17 hours ago, TonyMac32 said:

If you think it's appropriate, boards like the Vim (and I would guess Vim2/edge) which don't need as much "special care" from the user to load linux on like the standard TV boxes (Vim(2) has configurations in both U-boot and linux kernel if I remember correctly), those could be moved to the Meson64 part of the script, and we add the Mali/etc as per the usual Armbian method.  I would like to get the Mali driver patched into the kernel source rather than building it separately, but haven't had the time to sit down and go through the configuration to make that happen, so I don't include it in the images yet.

Between the existing system of images for models without built-in memory (eMMC) and TV boxes, there is a fundamental difference in the principle of starting the system. I wouldn't want to break the existing system. For TV boxes do not need u-boot, they can use the standard u-boot, it is safe for users and much easier. Therefore, I propose separate branches, so they do not interfere with each other. :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
0