Hi guys!
Thanks for you development board, it seems very exciting for a good price!
I just ordered my VIM2 card and one thing that decided me is the UEFI support.
So just a “simple” question: when will the UEFI firmware be released?
I think that UEFI will be based on TianoCore version, isn’t it?
And as this is an OpenSource board I hope that the source code will be released too 
Cheers!
It’s not the only way for UEFI:
Currently we still cannot got the timeline yet, we also need the help & support from the open source community, of cource, we will full open the source code at the same time then.
Hi Gouwa,
UEFI through U-Boot is not really UEFI 
I agree that you can payload GRUB2 and then start EFI binary through it, for booting openSUSE (that’s what I want) it’s ok. Your board will act like RPi3: https://youtu.be/bNL1pd-rwCU.
But if you choose this way, for me you can’t tell that your board is using/supporting UEFI.
I agree that porting TianoCore can be difficult. Again, I’ve heard of RPi3 version but not fully operational: http://www.workofard.com/2017/02/uefi-on-the-pi/.
PS: is the Alex from your email work for SUSE?
Also, I don’t know what it’s easier: porting U-Boot UEFI support from mainline U-Boot to the old version for S9xx or to port S9xx support to newer U-Boot… 
i am also interesed in this as EFI support would make mkimage obsolete as “Image” could be booted via EFI directly. Or getting mainline u-boot running on VIM2
Yes, he is from SUSE. 
and of course, UEFI has nothing to do with the “server” segment. it doesn’t matter what use cases are for your board, UEFI is a booting firmware designed to fit not only the server range, but desktop, mobile embedded too, every computing device boots. don’t let confuse yourself. “even RHEL” shouldn’t be even a goal, again firmware standrads exist for exactly opposite purposes - namely give the easiest way to support booting of everything following the standard. not just a specific distribution of something. we already have uboot - a linux only loader. UEFI is for giving the possibility for booting everything from Linux to Windows.
I understand it might be challenging to get it working even having a solid baseground as edk2 is, but don’t give up, it will pay off in much more later. as Cthugha mentioned uboot mimicking UEFI isn’t really UEFI.
Any news regarding UEFI?
What are the bottlenecks here?
I probably would buy one of these devices if it came with a respectable UEFI firmware, but not until.
I’m guessing at the following and would love to be corrected:
AMLogic has not released enough information about the components of the S912 to create appropriate ACPI tables
UEFI requires a bunch of lore and Khadas doesn’t have the experience
(not a barrier) I think that there is freely available generic UIFI code
perhaps UEFI eats a lot of space, in ROM and RAM, and the market seems small
perhaps Android doesn’t happily live on top of UEFI
perhaps Khadas gets much of its software in binary form and that software cannot run on top of UEFI
perhaps there is no open source driver for the Mali 820 GPU, blocking open source OSes (except for servers)
Hi, HughR:
Yep, Amlogic didn’t put any efforts on ACPI or EUFI and our team also come with zero experience on this.
And as you said it does require a bunch of lore
Bad news is that we still cannot figure out a timeline for this yet at the moment so if you wanna buy VIM2 as an UEFI device, you might should wait some time
Thanks for the professional comments.
Hi guys,
Official U-Boot support has been added for Khadas VIM: http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005410.html.
UEFI boot protocol is supported in U-Boot, so UEFI boot works on Khadas VIM (tested by myself with openSUSE Tumbleweed). And more EFI parts will be added in U-Boot (support of EFI Shell should be possible in the future).
So, as S912 CPU is close to S905 CPU, support for it should also be possible in the future.
Ironically, support of UEFI boot has been implemented for Khadas VIM before VIM2
The good thing is that mainline U-Boot can be use on Khadas VIM, and that should also be the case for VIM2.
@Gouwa: could it be possible for you to add your specifics U-Boot development for VIM2 (kvim command, if I remember) to official U-Boot instead of the old Amlogic version? Could be more useful for the OpenSource community
Hi, Cthugha:
Thanks for the great news!
Yep, we will check the mainline U-Boot for better VIMs user experience. @Terry @numbqq
Thanks!
@Gouwa: I think that Khadas team could send a big thanks to @narmstrong and all guys from BayLibre!
Yep, it’s the power of upstreaming, the work was initially done for the LibreTech-CC board, but for no cost it worked for the Khadas Vim aswell, and the VIM2 support should not be far away.
Taking advantage of the SPI flash is crucial to be able to use GPT partitions on the eMMC, so what is missing:
and you’ll have EFI support by default !
The missing point would be to generate some EFI install images with a kernel with the kvim2 support, this may be harder.
Should be possible with openSUSE Tumbleweed, as this version is a rolling-release.
I was able to test VIM on it, I can try to do the same for VIM2 and submit the needed changes in it.
Yes, that’s why Khadas team should now work closer to official U-Boot!
@Gouwa: I saw the VIM2 Lite based on S905D on your website, is it already available? And why you don’t have used the S905X? It could have been easier to use an already supported SoC (supported by U-Boot and the Linux kernel).
S905D is full pin-to-pin with S912, it means that VIM2 Lite is same PCB board with VIM2 Basic/Pro/Max.
Make sense. And when it will be available?
We were planing to launch at XMas, check out website the the update
What bottlenecks? It’s a firmware for booting an OS of your choice. It is much much more capable than uboot. If implemented in its full potential, it lets you boot from anything. What bottlenecks? It’s not like you are choosing your future wife. :lol:
ACPI isn’t part of UEFI, technically you don’t need it for having UEFI. But, of course, the SoC vendor not sharing HW info is the PITA. for implementing anything, it’s not UEFI specific.
As everything.
Not true. It depends on abilities of an implementer, how bloated he/she can do it.
UEFI is an industry standard, if something doesn’t want to “happily” live with the industry standard, then that something should go away from the industry. This is especially true for android. 