It is all about DOCUMENTATION

Hi,
I found this little product and was immediately blown away. Its a fantastic little device and powerful, generally better than a RPi etc.

However, I you want me or others to buy into this product (and I guess you do, because you are already thinking about releasing a V2 of this product) you MUST finish you the documentation.

My experience is annoying - I wanted to do one thing. Add a driver to the ubuntu build which added CH34x USB to serial support.

I followed what doumentation you had, and after dealing with the fact that I am running an x64 Ubuntu on an x86. I got all the compilation for the U-Boot, bootloader and RamFS working. So good. Now to build the most important part - RootFS…

That is where I fell flat.
The documentation is bad - not complete - or non existent.

comments like this in the documentation "Download the prebuilt image you wanted, " are not useful…

This :
Add the hwpacks
WIFI/BT
Mali
CEC TBD

Is useless is you do not tell me where to get or what versions etc…

You must get the documentation complete . This is more important than releasing the next version.

If your community cannot do what they want with the product - they will move on and you will not be able to sell on new products.

I want to be able to buy into this product, but if I cannot follow a guide to make it do what I want; or if I have to ask for someone to add a driver for a device and then wait. I, like many people, will move onto something that has far superior documentation, and perhaps put up with a slightly less powerful device.

Full and complete documentation will get you a community that will be unstoppable.
Full and complete documentation will get you a community all over instructables etc…
Full and complete documentation will get you the advertising that you want to make it so you cannot keep up with demand.
Full and complete documentation will get you a community that customised documentation to a point where you will not have to worry about it ever again.

Love the product - keep up the good work, and fix those docs…

Regards

5 Likes

we fully agree with that!
vim2 will start its life cycle from zero : no community support, no documentation, no published source, no bug list, etc…
we, osh and osw hobbyist public , want a linux device done the right way (like beaglebone, rpi or odroid), and not really another ordinary shenzei android tv box

Thanks for the feedback and suggestions, we will focus more on the Khadas Docs in the future.

Regarding ubuntu OS building, we have a one-stop built scripts, we will push it on our GitHub in the next few days

That certainly sounds excellent.

I have managed to make the most of the information currently available. I will look in the forums and perhaps post in a relevant section.

The troubles I ran into stem from:

./utils/aml_image_v2_packer -r upgrade/aml_upgrade_package.conf upgrade/ images/update.img
… no where does this aml_upgrade_package.conf file exist or get downloaded during the current instructions. As a result I have not been able to make the final image.
If I could find this, I could understand what would be happening, and modify it to my case of building a ubuntu system from scratch.

Then there is still the case of not finding any of the drivers. MAli, wifi bt etc… I guess we should be git cloning them from you (based on what I read from Mali documentation) because they are chip-implementation-specific?

With those exceptions, I have built a rootfs and bootfs (u-boot/kernel/ramdisk). I know they wont be perfect yet because of those drivers. But I cannot test because Im not sure of the next steps.

Also not sure how to img the whole lot up so I can the upload it with USB_burning_tool later.

I look forward to seeing the script(s).

As you probably guessed, I am very comfortable with linux etc. but this is my first serious
adventure into arm and firmware. So I am hoping you will afford me (along with everyone else who is on this journey!!) the best support possible to make the experience as painless as can be!

Thanks for the replies, appreciated. As I say, excellent product, and it would appear support is going to be excellent also :slight_smile:

10 posts were split to a new topic: Fenix: One Stop Scripts Set to build Ubuntu

To bad you are just focusing on Ubuntu and thinking that is everything from documentation.

Once everything you get pushed in mainline (kernel, drviers etc etc) it is easy to write documntation. Now you are just reusing kernel from amlogic i guess.

So my question would be: What did Khadas pushed to mainline? (I mean here Khadas as a company and not the other developers working on they own).

NOTE * I am focused on Linux - but same deal applies to doing Android - not my cup of tea, but I’d bet people are running into similar process problems…

It is very disappointing to see a product like this with a total lack of support and process…

Khadas team - You need to supply a step-by-step for ANY build that is fully functional. I honestly dont believe you can work like this efficiently.

You have half baked scripts that create a linux with NO drivers.
You have half baked scripts that COPY drivers (so useless to even attempt to generate a newer version since depmod will fail).
You have not created a ‘proper’ GUI version.

Eveything that has been posted to build a system -forgets something- and then when that is fixed - forgets something else-

At some point you built a Ubuntu with a kernel 4.9 (if I remember correctly) in both server and in GUI. So how come someone on your team can not post an absolutely definitive step-to-step to recreate that process?

This needs to include all the little quirk modifications (like tweaking DTS files). everything.
This needs to be from scratch - no downloading core ingredients from your github. DRIVERS/Linux Core/Kernel/ U-Boot/ etc must all come from the lowest common possible denominator. Mali might be the only exception, but it should still be buildable for any kernel version etc…

And completion to a eMMC image - (or TF card, but either way) - complete steps for both, because there are some differences…

If you had this - people would be able to logically change one step at a time and test everything properly starting from a base process.

Also your forums would not be taken up with so much of the simpler support…

You would be helping yourselves out here.

(I do get that stuff needs to end up in mainline etc. but when that happens it would be a modification of docs you already have - and also a much easier process.
But supporting the effort now, will give you a better chance, and a faster result of this becoming mainline)

Also, dont let the engineers divert your attention with all this ‘it will be easier to document when…’. The problem with engineering types is that they dont like actually doing documentation (I know this first hand!)

You have deep level enthusiasts helping debug like in the mainline topics, but that is what I’d consider ‘driver level improvements’ or bleeding edge testing.

Mainstream support is what I am refering to.

I will repeat myself.
If there is mainline kernel support all this would not be needed. Any distribution which supports arm would work with mirror modification (how to write Distribution image to mSD or eMMC).

ug!

I needed to build the kernel because I needed cifs in kernel and I needed to add a ch341 usb driver. I am also going to need to build an armhf version of the kernel for the device I ultimately select.

I will move to a documented device that I can use now. The power/performance of VIM is nice, but I dont need it.

You might want to read this article, it covers some aspects of building your own kernel from source.

Your choice should be linked with the requirements you have. There is a broad variety of devices (documentation might be the relevant if mainline kernel support is poor, but it’s not the documentation your are probably looking for).

The Armbian team has built a good coverage of devices they support. They use an automated build chain which gives reproducible results. IMHO you should start reading here and understand how the build chain works in general (build the firmware, build the kernel, set-up userland). The scripts are well documented and easy to understand (and they have documented their build chain). A community member (@balbes150) has started to modify the Armbian build chain in order to support the Khadas Vim and other devices with a similar SoC.

@umiddelb
I think you misread me.
I am good with kernel. Its arm that is new to me.
Never mind, I figured it all out.

@vrabac
Seriously? Khadas doesnt have mainline kernel support, but sells the product. Therefore support must come in whatever form is required for now.

@ravelo
I promised a script to build a fully functional ubuntu 16.04.2 including Mate, with kernel 4.9 in it, so I will deliver it in a separate post. I finally got some spare time to do what I wanted!

Here:

1 Like