Should be sometime next half year 
And the new SoC with NPU will be pin to pin compatible.
1 Like
It’s linux 5.4 for VIM4.
Regarding the mainline supports might still take some more time 
To take the guess work out for people, here is the Vim4 running Android 32 bit .
Now you have a idea of real use 
2 Likes
We are actually working on android 64 bit 
4 Likes
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.
1 Like
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
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 
1 Like
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.
1 Like
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.
3 Likes
Hello,
Could you please confirm that VIM4 will be compatible with the new-m2x-extension ?
Thanks.
@pea13 M2X is compatible and can also be used on VIM4
1 Like
Cool !
Thanks for the answer.
Couple quesitons
Android TV?
Remote control? I guess any universal generic bluetooth remove would do the job perfectly fine
- Third-party firmware will be supported one after another, but currently there is no third-party firmware.
- About the remote control, we will consider making a separate accessory, it has not yet been determined
Gouwa. Could you send me a sample to test? We have a great market in India for SBC now. Good timing as RK 3588 is in shortage and the price is roof top hgh.