For your concern, please try to download and update your X86 to the latest BIOS following this: http://wiki.seeedstudio.com/ODYSSEY-X86J4105-Installing-OS/#how-to-upgrade-the-bios
Once updated, check the settings on BIOS, try enabling the CSM support on BIOS to see if you can see the emmc on boot up.
Thanks for the location of the bios. I have been in CSM but thank again for the heads up.
Bios ran completed verified and unit has no video now. Nothing
What now?
So is there a way to side load bios? Or was my erratic usb and failure to mount eMMC a sign of the current issues?
So we are bricked than? Without ever getting a proper install of linux?
So after you updated to the latest BIOS, X86 doesnt have video output now? For the eMMC question, so you cant mount it as boot up, but can you see the storage once inside a OS that you installed? Still trying to locate the issues here, sorry for all the hazards.
Video is back not sure what I did other than give up with battery + power disconnected for some time. Running on live usb image at the moment.
Have not had the USB drop again since bios flash which is a +.
As far as booting Linux from eMMc it’s a no go is is not recognised until os is running from live usb or sata SSD.
I can see the eMMc once booted however and instillation to ssd was seamless. I even attempted to put boot partition on usb to boot eMMc and that failed at boot also. Got the “add bootable media message”
Okay so emmc is not working when trying to boot up from it. Have you also try to use the emmc storage once booted up, like just putting some stuff in the emmc and see if there is any more errors?
I have successfully installed from a live image UEFI distro only. I did not attempt from usb to eMMc. Qubes OS seems to be a no go on the eMMc as it is not willing to run in UEFI mode and needs to be installed under bios.
Successfully installed with boot to eMMc:
Mint UEFI from live desktop 
Fedora UEFI from live desktop “posting from unit at the moment”
Successfully installed with boot to sata SSD:
Qubes OS NON-UEFI from usb.
Qubes would install to eMMc but not be recognised at boot time. 
Thanks for your feedback 
very helpful for future users
I successfully installed Debian, in order to avoid issues on boot: you need to answer yes to install a copy of grub2 to avoid buggy UEFI, when asked.
Let me know if you can get that to work with Qubes OS , Debian , Ubuntu, Mint might as well all be the same with the latter basing themselves off of Deb. Qubes OS off of Fedora for DOM as the base for further Qubes “Linux/win7/ect.”. I am pritty happ with Fedora on this as Qubes works but needs just a bit more power than this board can muster. It works but video output is poor.
it works fine with ubuntu 19 here. you have to make sure that you DISABLE SECURE BOOT.
charlesb@odyssey:~$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 3.6G 0 3.6G 0% /dev
tmpfs tmpfs 736M 1.4M 735M 1% /run
/dev/mmcblk0p3 ext4 49G 6.5G 40G 14% /
tmpfs tmpfs 3.6G 0 3.6G 0% /dev/shm
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 3.6G 0 3.6G 0% /sys/fs/cgroup
/dev/mmcblk0p2 ext4 976M 101M 809M 12% /boot
/dev/mmcblk0p1 vfat 511M 33M 479M 7% /boot/efi
/dev/loop0 squashfs 55M 55M 0 100% /snap/core18/1705
/dev/loop1 squashfs 60M 60M 0 100% /snap/lxd/14709
/dev/loop4 squashfs 94M 94M 0 100% /snap/core/8935
tmpfs tmpfs 736M 12K 736M 1% /run/user/1000
/dev/loop5 squashfs 94M 94M 0 100% /snap/core/9066
/dev/loop2 squashfs 70M 70M 0 100% /snap/lxd/14890
charlesb@odyssey:~$ uname -a
Linux odyssey 5.3.0-46-generic #38-Ubuntu SMP Fri Mar 27 17:37:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
charlesb@odyssey:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=19.10
DISTRIB_CODENAME=eoan
DISTRIB_DESCRIPTION="Ubuntu 19.10"
charlesb@odyssey:~$ sudo fdisk -l
Disk /dev/mmcblk0: 58.25 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6089F095-92D8-4D30-A864-832E675BF858Device Start End Sectors Size Type
/dev/mmcblk0p1 2048 1050623 1048576 512M EFI System
/dev/mmcblk0p2 1050624 3147775 2097152 1G Linux filesystem
/dev/mmcblk0p3 3147776 108005375 104857600 50G Linux filesystem
/dev/mmcblk0p4 108005376 122140671 14135296 6.8G Linux swap
TRY READING THROUGH POSTS!
I have linux on the eMMc not the version I want however due to the kernel , UEFI or whatever. I can install Ubuntu Mint RedHat Fedora all the modern UEFI do work.
/dev/mmcblk1p1 2048 1230847 1228800 600M EFI System
/dev/mmcblk1p2 1230848 3327999 2097152 1G Linux filesystem
/dev/mmcblk1p3 3328000 122140671 118812672 56.7G Linux filesystem
Give Qubes OS a TRY! than tell me it works
I have successfully installed from a live image UEFI distro only. I did not attempt from usb to eMMc. Qubes OS seems to be a no go on the eMMc as it is not willing to run in UEFI mode and needs to be installed under bios.
Successfully installed with boot to eMMc:
Mint UEFI from live desktop
Fedora UEFI from live desktop “posting from unit at the moment”
Successfully installed with boot to sata SSD:
Qubes OS NON-UEFI from usb.
Qubes would install to eMMc but not be recognised at boot time.
a quick googling search appears to indicate that i’s because it’s based off of xen and xen is the issue.
Unfortunately my odyssey board is sitting in its flight case as my ground station computer so i don’t really want to overwrite the emmc partitions just to try qubes.
I could always install. Booting was the issue due to having an non EFI boot loader. There is a workaround for the bios EFI issues adjusting the boot loader manually but did not attempt as it would potentially cause other issues and constant hassles with system updates. Not worth it for the constant issues and time involved. It is more reasonable to pick up a different system or an nvme ssd
Successfully installed with boot to eMMc:
Mint UEFI from live desktop
Fedora UEFI from live desktop “posting from unit at the moment”
Successfully installed with boot to sata SSD:
Qubes OS NON-UEFI from usb.
With none of the above hassle.
Hey just reviving this to say I too encountered this issue - when I had Windows on the MMC I had no problem installing an OS to the M.2 SSD I attached, but as soon as I wiped the MMC partition table to start a clean slate, no matter what install process I followed, no Linux distro would install for me. Most of the time install would go successfully but would simply not show as a boot option (so no GRUB install) despite the partitioning being done correctly for UEFI with GPT+EFI FAT32 /boot/efi partition + ext4 system partition. Ubuntu boot-repair tool could not fix the issues except to say that SecureBoot (or lock?) was maybe enabled on the NVMe SSD I had in the M.2 slot. I could not find any SecureBoot option in the BIOS, which I found very unusual as every computer I’ve owned has had an option to toggle it.
Fiddling around with CSM did nothing, and really that should only be used for running ancient operating systems that don’t support UEFI, it absolutely shouldn’t be necessary for anything modern.
I finally updated the BIOS and the EC, disabled the built-in MMC, then did yet another manual repartitioning of my SSD in the M.2 slot with a GPT table and the /boot/efi part and / ext4 part, and this time I was able to install Void Linux to the SSD and boot from it with UEFI enabled. I am not really sure why this worked, since the bios and EC update alone did not fix the issue, and I tried only installing to the SSD multiple times and ways before.
I have two theories what might have been happening:
A) Not having a CMOS battery is causing some issue perhaps? The sales material says its only for the real time clock, and indeed my BIOS settings saved no problem for months without it but now seem to reset frequently/every boot. Perhaps this device actually does require the batt for CMOS and I just lucked out and had a chip that held its programming without power for a few hours longer than usual until recently no longer being able to?
B) The BIOS flash may have a quality issue and is being tempermental/corrupted subtly? Perhaps the BIOS update didn’t fix the issue - just doing a BIOS flash was the fix as it would restore a fresh copy of the BIOS data until corruption occurred again.
C) The BIOS seems to have undocumented SecureBoot functionality that is not properly implemented and definitely has no options I can find. I could be wrong but most Intel x86 microcomputers & laptops shipping with Windows DO have SecureBoot enabled by default. Usually it can simply be toggled off in the BIOS settings.
D) Maybe its just as simple as the MMC itself failing/having quality issues? Odd though because once I finally got Linux onto it the system itself has experienced zero corruption issues. Also while I was initially trying both built in and the SSD would not work.
So I am really not sure why this is happening - but I strongly think its either undocumented SecureBoot functionality or some sort of intermittent issue with the BIOS memory or MMC storage chip. The fix for me was updating the BIOS and EC, disabling MMC in BIOS and using an SSD alone in the M.2 slot. Use GParted to do the partitioning, make it a GPT partition table, create a 300MB FAT32 partition give it the flags “boot” and “esp”, create your system partition (ext4, btrfs etc), and make sure when formatting with your distro (use the partitions made with gparted do not let the installer redo them) that you give the FAT32 partition a mount point of “/boot/efi” and your system part “/”. Use the application ‘efibootmgr’ before rebooting after installing to be sure an entry was added to the boot table. If not, you need to manually install GRUB to your /boot/efi partition - google for this as it tends to be specific to what you’re trying to setup.
Last but not least if this doesn’t work - before I finally got mine working, my next step was going to be to play around with the system’s UEFI Shell. When there is no OS installed the Odyssey boots to it by default but you can access it from the F7 boot manager too. This shell should be the final place where there’s a shot at fixing this as from there you can directly manipulate the UEFI firmware config. If this doesn’t work out I’m almost certain its out of your hands and a hardware issue
@LiamSP Thanks for pointing the problem. The answer to the question is as follows:
A&B : Odyssey need a RTC battery to hold the time and BIOS setting.
C: Yes, we will release a new version added secureboot and pxe boot.
D: it’s seems the UEFI setting problem. You can refer https://help.ubuntu.com/community/UEFI#General_principles
We just release the new EC and BIOS firmware, you can update now.
Ahh ok - I didn’t immediately install the batt as I was just testing it out and didn’t care about the time yet - no trouble to install.
Thats excellent I guess boot-repair was just detecting the SecureBoot feature in the chipset but was wrong that it was enabled. Looking forward to the updates to provide control of that and really liking the Odyssey so far!
