Jump to content

offically support Khadas VIM?


ning

Recommended Posts

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.

Link to comment
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.

 

 

 

 

 

 

 

 

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
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'.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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

Link to comment
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. :)

Link to comment
Share on other sites

I have flashed Armbian to USB driver, I think there is an uboot on USB driver.

 

after I insert USB driver to device, and power on, directly boot into vendor uboot and go to vendor OS on emmc.

 

I know I can do something via UART, to manually boot OS on USB driver.

 

how could I directly run uboot on USB instead of uboot on EMMC?

 

 

Link to comment
Share on other sites

I'm wrong, I cant boot mainline linux with vendor uboot. could some tell me howto?


my boot cmd, device is khadas VIM1

Quote

 

setenv kernel_loadaddr "0x11000000"
setenv dtb_loadaddr "0x1000000"
setenv initrd_loadaddr "0x13000000"

usb start


fatload usb 0:2 ${kernel_loadaddr} vmlinuz
fatload usb 0:2 ${initrd_loadaddr} uInitrd

fatload usb 0:2 ${dtb_loadaddr} vim.dtb
fdt addr ${dtb_loadaddr}
fdt resize 65536

setenv bootargs "root=/dev/sda1 rootwait rootfstype=ext4 panic=10 console=ttyAML0,115200 consoleblank=0 loglevel=4"

booti ${kernel_loadaddr} ${initrd_loadaddr} ${dtb_loadaddr}

 

 

 

it return error: libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

Link to comment
Share on other sites

after break vendor uboot, I tried SD boot, everything get fine.... I plan to submit kvim1.csc....

 

SD boot OK

EMMC install OK

EMMC boot OK

display OK

WIFI OK

 

BT on going.

 

Audio maybe

HDMI audio maybe no

vdec no plan to check, waiting for upstream.

lima, cant boot to UI after enable.

 

after BT is OK and patches clean up, I will submit.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines