Is is possible to run vim3 off of an external ssd drive? (u-boot mainline is not working)

@hyphop,

"its very easy to fix ! plz wait i will try solve it "

How is the easy fix coming along?

Hi @biohumans,

Can you try to explain me what are you trying to achieve? As I see you have marked the above post as the solution which is just a workaround.

Maybe I can try and help you.

From all of the above points what I understand is you want to get the device to boot from sd card while it load the rootfs from the external ssd connected over usb.

To achieve this we need to understand what is in the emmc and sd card. Please share which os do you plan to use from emmc and usb external drive.

Thanks.

still try to solve it :wink:

@Spikerguy

Thanks for the reply, at this point maybe I’m asking for something that is not possible with Vim3 in general (at least not simply)? The following I’ve been able to achieve with other SBC’s products in a very straightforward manner (very clear documented steps):

  1. Current State: booting off of the Bootable SD-Card image plugged into Vim3 (e.g. Manjaro-ARM-xfce-vim3-20.04.img.xz) containing the BOOT FS and ROOT FS

  2. Wanted State: Booting the entire os image (e.g. Manjaro-ARM-xfce-vim3-20.04.img.xz BOOT FS and ROOT FS) or at the very least the ROOT FS partition off of a external SSD drive connected to Vim3.

I’m not sure how else to communicate this more clearly. I simply want to boot my Vim3 with Manjaro-ARM-xfce-vim3-20.04.img.xz entirely off of a external USB attached ssd harddrive Samsung 970 ev0 plus 250 gb drive.

The documentation https://docs.khadas.com/vim3/BootFromExtMedia.html, is not very clear to me at all and also seems slightly out of date, and not very reliable:

for example:

This step:
Edit FDT in /extlinux/extlinux.conf and dtb_name= in uEnv.ini with the correct dtb filename.

the path /extlinux/ does not exist in Manjaro-ARM-xfce-vim3-20.04.img.xz

Hi Spikerguy,

Currently what I’m using to achieve my goal is:

emmc: default os that came vim3 -> Android OS

Sd card: Use VIM3_Ubuntu-server-bionic_Linux-5.5-rc2_arm64_SD-USB_V0.8.2-20200103 or Use
Manjaro-ARM-xfce-vim3-20.04.img.xz (Currently trying Manjaro) Use sd card as BootFS

SSD external usb 3.0 drive: Samsung 970 ev0 plus 250 gb Use VIM3_Ubuntu-server-bionic_Linux-5.5-rc2_arm64_SD-USB_V0.8.2-20200103 or Use Manjaro-ARM-xfce-vim3-20.04.img.xz for ROOTFS.

Also tried to follow the instructions in the khadas docs, I installed U-boot mainline in emmc via etcher also used Uboot.bin.sd.bin in Sd-card and burned the entire os .img.gz Boot FS and Root FS in the SSD, still no reliable bootup success.

Afaik the mainline uboot does not have the ability to boot from usb yet.

The approach you’re using is fine as this is the only workaround I recommend normal users so they don’t brick the device and then have to flash android back.

I was testing something similar of your requirement but my testing ended with my vim3 not being able to flash the android back again.

From my understanding you will always need to have uboot on emmc with bootfs always on emmc and rootfs can be on usb but for this you can only achieve it using the android uboot and not mainline uboot.

If you want then you can try this approach.

  • Install latest android on emmc.
  • Flash latest Manjaro img on emmc - Wait till I get you updated boot-vim3 package which will contain the install script for emmc. Using this your whole Manjaro os will run off emmc.
  • if you want to use it like this and make usb as data storage then its upto you OR
  • comment out the commands in the install script to ignore creating and copying root partition content while you make use of the root partition off usb ssd.

I won’t claim this to be an easy task but its not complicated as well.

Ill try to get you the updated install script.

1 Like

@Spikerguy,

Thank you,

I’m willing to try anything at this point. I have hundreds of gigabytes that my vim3’s are unable to properly use at this point. Really appreciate the updated install script when you send it out.

Mainline u-boot has supported USB booting for aeons.

@chewitt
Do you mean vanilla mainline uboot or patched mainline uboot?

mainline u-boot does not need patching to run on any VIM device, all are supported since 2020.04

1 Like

mainline u-boot does not need patching to run on any VIM device, all are supported since 2020.04

its not almost true :wink: only vim1 and vim2 support usbstorage
vim3 and vim3l need special patch !

@hyphop,

Any chance you can actually point me to where this legacy uboot is? Download url, carrier pigeon? Because you keep saying things mysteriously, but you don’t actually give any details.

we can share new mainline uboot with full support for every khadas board very soon ( 1 or 2 days ) - and every can get it from fenix or download directly from our server

1 Like

This is good news, finally we can use mainline uboot on vim devices and use easy emmc installer instead of confusing complex boot scripts.

Looking forward for the mainline u-boot @hyphop
Thanks.

It’s already possible to use mainline u-boot with simple (extlinux) boot on all VIM boards and it’s likely that EFI works too. I’m just wondering what hacks @hyphop will add before calling it mainline? - I hope he realises that upstream code + vendor hacks is “vendor hacked u-boot” and not “mainline u-boot” as the sole source for mainline u-boot is the denx repo. If Khadas wants to provide its customers witth mainline u-boot (and everyone with any kind of desktop or industrial use-case will want this) they need to invest some time and effort in upstreaming any required changes to the kernel and u-boot. Both have well documented and simple rule based submission processes that are not hard to learn.

1 Like

look like u never seriously use mainline uboot for khadas boards

its not hacks - just fix bugs etc… and finish not complited and missed code

  • usbstorage VIM3x
  • hdmi VIM3x
  • spifc
  • mcu kbi

I don’t do extensive u-boot testing because the existing level of upstream support is enough for my needs with LE. I look forward to seeing your bug fix submissions to respective mailing lists - and I’m always happy to help test and validate proposed changes.

If you are so “mainline” orientated then why is there double LE images for i.MX6 based devices (Udoo, Cubox). Mainline u-boot supports single u-boot for both dual and quad SoC based devices.

Maybe you don’t understand mainline u-boot good enough?

LibreElec wants us all to have cake tomorrow over that bright blue horizon.

Shoog

@newmonkey maybe you don’t know how the LE build-system works? because a cursory look at iMX6 shows we cross-compile a single iMX6 codebase then iterate this into a number of device-specific images where the only variance is u-boot. In the case of Udoo (and Cubox-i) we are using a common defconfig for both dual/quad variants, but cutting a device specific image (an extra 60 seconds build time) means users don’t have to fiddle with setting which device-tree to use. iMX6 support is nothing to do with me, but to me it looks like the maintainer knows how to use mainline u-boot.

Why am I applying some pressure to @hyphop and others on the Khadas staff? … because I see their complaints about how the upstream kernel, u-boot, etc. doesn’t support their products right. And at the same time I haven’t seen a single submission to a publiic mailing list from them with fixes. LE simply wants vendors like Khadas to take some responsibility for their products.