Temporary fix to get SATA SSD working using /etc/fstab on R2


(Aaron Gray) #1

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’.

/sda2/home	/home/		none    defaults,bind   0       0

Banana Pi BPI-M3 New Image (New EMMC) Release: Raspbian jessie 8.0 2018-5-28 V1.1
(Frank W.) #2

Why do you use a mountpoint in / for further mounts instead of using /dev/sdax and/or links/lvm


(gary) #3

May I know if the /dev/sda2 can be mounted successfully? Can you please share me your log?


(Aaron Gray) #4

I could not get uBoot to work with an Samsung EVO SSD.

The log just said “Waiting for /dev/sda2” IIRC

I was booting on an SDCard with the boot line pointing to /dev/sda2.

I am finding multiple other posts where RPI’s are booting from SATA.

Do I need to reflash my eMMc maybe ?

I will try another drive first though


(gary) #5

can you please share me whole log when the /dev/sda2 is configired as root file system?


(Aaron Gray) #6

@garywang, How do I get at the log if it will not boot ?


(Frank W.) #7

(Aaron Gray) #8

Okay will have to wait till in the week as I dont have the right hardware here to do it. But I can use the OTG with debugger or the RS232 ?


(Frank W.) #9

No,i don’t think so. Only via serial-adapter on debug-uart-pins.


(Aaron Gray) #10

Is there proper documentation on this anywhere ?

This won’t just give me what I get on startup on the monitorwill it or will it give extra information ?


(gary) #11

you can record the serial console log via secureCRT/putty or minicom.


(Johnny) #12

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 :joy:


(Frank W.) #13

Imho sata must be accessable via uboot to load kernel from it. After that Kernel needs sata-driver.


(Johnny) #14

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 :wink:


(Aaron Gray) #15

Can you do a patch and pull request against :-

https://github.com/BPI-SINOVOIP/BPI-R2-bsp

please.

@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 !


(Johnny) #16

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.


(Aaron Gray) #17

@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 :slight_smile:


(Johnny) #18

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 :slight_smile:

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 :slight_smile: