Khadas VIM4 is coming soon!

Yep, existing version VIM4 do not with NPU.

I was looking forward to switch to VIM4 with better or same NPU.

Is their an estimate when NPU will be added to VIM4? will be come in higher version like VIM4 Pro?

I’m not entirely getting it. What hasn’t been decided about the 4.9 kernel? Ubuntu 22.04 uses a 5.15 Linux kernel. And Ubuntu 20.04 uses a 5.4 Linux kernel.

It runs fine on 4.9 linux kernel. The image for 20.04 and 4.9 kernel provided on the dl.khadas site is solid.

Please excuse me. I know that ARM mainline (both mainline kernel, and mainline Ubuntu support) is brand new, and I appreciate that I shouldn’t take these sorts of thing for granted.


That may well be so. But it won’t be true for 22.04 if you’re using a 4.9 kernel (since USB audio support won’t be up to date).


You’re using mainline in a sense that I’m unfamiliar with. Mainline what exactly? My question would be: does mainline Ubuntu 22.04 (with a 5.15 kernel) support this device? Are there an plans or roadmaps for getting Amlogic device drivers into mainline (kernel or Ubuntu)?

VIM4 needs vendor u-boot 2019.10 and Linux 5.4 kernel sources, which similar to the vendor Linux 4.9 kernel used with VIM1/2/3 might require nip/tuck but should be usable with recent Ubuntu userspace versions. There is currently no upstream (mainline) kernel support for what Amlogic calls the T7 platform and while A311D2 has a similar name to the A311D used in VIM3 it’s really a new SoC generation and there are some major IP differences that will require all-new code. The 5.4 base moves the vendor kernel closer to a number of modern kernel frameworks, although it sadly remains too-old to sensibly support panfrost (which needs 5.10 or an improbable amount of DRM backporting) so Mali blobs are needed, and the media drivers have been reworked towards V4L2 (amcodec is dropped). Amlogic started to upstream core peripheral support for S4 (S805X2) which is more of an evolution to G12B/SM1 but should be a precursor to SC2 (S905X4) which is closer to T7 (A311D2). From my own conversations with some senior people I’d say that Amlogic is similarly not-quite-committed to upstream support for this generation of hardware as they have been for previous ones; so it will probably happen, but not quickly, and emotive terminology like ‘plans’ and ‘roadmap’ should be skipped to avoid setting expectations :slight_smile:


Should be sometime next half year :slight_smile:

And the new SoC with NPU will be pin to pin compatible.

It’s linux 5.4 for VIM4.

Regarding the mainline supports might still take some more time :blush:

To take the guess work out for people, here is the Vim4 running Android 32 bit .

Now you have a idea of real use :grinning:


We are actually working on android 64 bit :face_with_peeking_eye:


That’s on a Raspberry Pi running Raspberry Pi OS?

Ignoring that ‘free RAM’ is a concept that doesn’t exist on Linux (unused RAM is useless RAM so processes allocate more RAM if it’s available and the kernel tries to make use of unused RAM for filesystem caches/buffers) once you switch to distros/settings that make better use of your RAM you are cured from the desire to run that little software with 8 GB RAM or even more.

Khadas guys copied zram usage from Armbian (relying on the same wrong assumptions about parameters) so once you switch from Raspberry OS to something more advanced you might be already fine with 4 GB of RAM running same software.

And then there’s always zswap if zram isn’t sufficient so there’s really not that much need for more than 8 GB once you let the computer ‘work smarter not harder’ by choosing intelligent settings.

And no: zram and zswap are neither the same nor similar but mutually exclusive. With a SSD especially when accessing it via NVMe and not USB you’re probably able to run your software stack with as less as 2 GB RAM without degraded performance.

Do you know of other T7 familiy members?

Thank you for the thorough explanation about software situation with A311D2 and current Amlogic in general.

But I still fear someone like @Robin_Davies who seems to be familiar more with amd64/x64 Linux situation (where distro maintainers coordinate both userland and kernel) needs some additional explanations to get why situation with Linux distros like Ubuntu on ARM platforms that originate from an ‘Android only’ design pattern differ that much. I think When will we see a VIM4? - #45 by chewitt is a good starter :slight_smile:


Actually, I completely got it. chewitt’s answer lays out that landscape efficiently and effectively, as well as the scope of issues, and the parties involved. It was very much appreciated,

My expectations have been moderated accordingly.

I am aware that ARM64 (and Raspberry Pi’s) upstream support, and Ubuntu mainline support is brand new. chewitt’s answer explains why I shouldn’t expect the present situation to resolve itself immediately.

The idea that kernel versions and distro versions are separable, however, is a completely new idea to me. One that I find quite unsettling to say the least – the idea that not one of the mainline packages will use one of the matching kernel version features seems improbable to me. And unsettling because I have used at least two 5.x kernel features in my app, and was planning on using a third.

Maybe I’ll take a look at the 5.10 USB Audio commits to see if I can backport them (he said naively). They are, unfortunately, not optional for me.

(My experience, btw, is Mac/Windows/Android/various containers, with a smattering of Linux experience, all of it Raspberry Pi, so thank you for your patience and generosity).

Since we’re talking Ubuntu only here (at least that’s what Khadas is providing as ‘Linux support’) it’s as easy as:

  • Canonical takes care of kernel and userspace matching on amd64 basing on an appropriate version of Linux mainline kernel. Made for every 64-bit capable x64 hardware out there
  • Canonical takes care of kernel and userspace matching on arm64 basing on an appropriate version of Linux mainline kernel. Made just for the few aarch64 server platforms that are compliant to certain standards like ACPI and UEFI.
  • Canonical takes care of primary OS, Linux kernel and userspace on 64-bit VideoCore platforms. That’s RPi 3 (VideoCore IV) and RPi 4 (VideoCore VI). Raspberries are not built with ARM SoCs but VideoCore SoCs with somehow integrated ARM cores. Special care must be taken by Canonical to match primary OS (an RTOS called ThreadX) and the secondary OS called Ubuntu. Kernel features must match ThreadX capabilities. Canonical goes the extra mile here and provides both an 64-bit and 32-bit userland. The latter a way better choice for memory constrained systems since an arm64 userland needs way more RAM to perform the same (that’s why Android even on 64-bit SoCs usually is still 32-bit since an 64-bit Android is just wasting RAM for no other reason than consumers being trained to think ‘the bigger the better’)
  • Nobody except the SBC maker or community projects is involved in taking care about all the other ‘meant for Android only’ ARM devices. When the Khadas guys provide an OS image for any of their boards kernel/driver wise initially they take what they get from the SoC vendor (an Amlogic SDK hopefully for Linux, sometimes only for Android – this matters mostly wrt to media capabilities) and assemble it with a Linux/Ubuntu userland. Kernel version the userland has been built against (‘designed for’) is Canonical’s choice, real kernel version depends on the SoC vendor’s SDK, problems guaranteed.

When a new ‘Android only’ ARM SoC is released usually it’s based on an ancient kernel version Google requires for the Android version the SoC maker wants to target. So with T7/A311D2 and Android 11 this ends up with an Amlogic 5.4 BSP kernel which is rather pointless since majority of Amlogic drivers are just forward ported from a way older kernel version and as such incompatible with mainline/upstream 5.4 kernel APIs/frameworks (not having stable APIs in Linux adds to the problem ofc).

The good news: once the hardware is almost obsolete and after community enthusiasts or paid entities like Collabora, BayLibre, Bootlin and the likes worked really hard for approx. half a decade mainline Linux kernel support might be there.

TL;DR: Linux on ARM sucks :wink:


I was too polite to ask. Thank you. I think that fills in all the missing pieces.

The other reason to use aarch64, by the way: compute-intense 64-bit code runs about 40% faster than 32-bit code on an ARM Cortex A-72. Even when GCC optimization is specifically targeted at 32-bit Cortex A-72 – I did check that. (The 64-bit code ran with default optimization options). The performance difference is not subtle. And a particular piece of Neon-targeted code (not included in the above sample) ran twice as fast. Just so you know.

That’s not the case in general, please see here, there (see RPi 4B 7-zip and openssl entries) and there. The last link also demonstrates that an arm64 userland needs way more RAM compared to armhf.

Those specs are only of interest to hobbyists.

Bottom line comes down to what board is reliable and performs best running the target application in the end product.

1 Like

Only A311D2 surfaced so far…

1 Like

any idea about “t7_an400” ? by chance is it the serial code for the A311D2 ?

I believe AN400 is the codename for the T7 (A311D2) reference design; similar to how W400 is/was the reference design for G12B (S922X). Just a guess though.