I have not tried this on the BPI-R2 but it should work.
As the SATA SSD will not seem to boot from uBoot I have used a modified ‘/etc/fstab’ to support select directories
proc /proc proc defaults 0 0
/dev/mmcblk0p1 /boot/ vfat defaults 0 2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
/dev/sda2 /sda2 ext4 defaults,rw 0 0
/sda2/bin /bin/ none defaults,bind 0 0
/sda2/sbin /sbin/ none defaults,bind 0 0
/sda2/tmp /tmp/ none defaults,bind 0 0
#/sda2/usr /usr/ none defaults,bind 0 0
/sda2/var /var/ none defaults,bind 0 0
/dev/sda3 none swap sw 0 0
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
It did not seem to work for /usr as /usr/dpkg/lock seemed to fail for some reason so thats commented out. But you should be able to add /home as well. Just partition /dev/sd2 as ext4 and copy the directories from sdcard to the SSD. and partition /dev/sda3 as swap, and run ‘mkswap /dev/sda3’, ‘onswap /dev/sda3’.
I’m looking into this myself at the moment, probably just needs a driver compiling into the kernel etc - whatever is needed to access the disk at that stage. There’s grub-uboot and such things - perhaps some form of initrd for modules.
I’m also looking into kexec based loaders, I should probably confirm that kexec works first
I have successfully got a root FS on a SATA drive, OK it still does the initial boot and loads the kernel image from MMC/eMMC - but that’s fine - useful even. All you have to do is compile AHCI/SATA into the kernel, by default the support is set to compile as modules which aren’t accessible when needed given they need themselves to load themselves (catch 22) - nothing like an initrd that I can see - I don’t know uboot very well but perhaps it has the facility - there’s also grub-uboot which sounds interesting and there’s always kexec for booting different systems - I’ll report back if I can get it to work.
But yes - setup SATA/AHCI to build into the kernel, install that kernel, setup a partition etc, copy over the root filesystem :
cp -ax / /my_new_root
then adjust the uEnv.txt :
root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
to something like :
root=/dev/sda1 rootfstype=ext4 rootwait
(although I think you can use root=PARTUUID=xxx there)
And it’ll boot if you’ve got it all correct - I assume it would be possible to have uboot load the kernel/boot specifics from the hard drive as well but I think this is a better solution for now anyway - easily swap in and out new kernels on different SDs etc - plus you’d want official, tested support for booting purely off a SATA device unless you don’t care about the data that’s on it - all that bootblock stuff - don’t want to accidentally overwrite your partition tables and what not
@JohnnyWednesday So you are you still booting off of SDCard for boot partition for uEnv.txt and zLinux ? I am not sure if thats anything different against what I have done already in the head post in this thread !
It’s quite different - you’ve remapped individual directories which can problematic as you discovered, plus it requires you to have a working system on a memory card to load the modules and what not before you ‘overlay’ your locations on top of the file system (not mapping lib hmm?)
Compiling the SATA drivers into the kernel allows for a a native root file system - a configuration that’s abstracted away from the initial booting process - clean - nothing has to change.
All that’s loaded from MMC is das u-boot and the kernel.
@JohnnyWednesday Thanks I see know so the same thing will work for SDCard rather than eMMC till I have got confidence in what I am doing to get a distro together and also not to brick a board
Circumstances beyond my control have left me with my R2 board and my phone as my only computing devices for a few weeks - so I’m not doing anything that could brick the board for a while
Yuss with an SD card and a SATA drive you can have a SATA root file system without touching the eMMC if you so desire - it’s very useful for me given I’m doing everything on the R2 - I can easily try out a new kernel - just tag on your own version number when building the kernel so the modules can live in different directory, then copy the new uImage to an alternate SD - swap over and boot - if it doesn’t work? pop the old one in and the old kernel will load the old modules
So only a single environment to maintain for testing and develoment but being able to safely make big changes or roll back - it’s very convenient right now!
If you need any info to save you googling etc then please let me know
