After running the 'olinuxino-sd-to-sata' script, how to set /dev/sda1 as root?

Started by Nate, March 11, 2022, 11:56:28 PM

Previous topic - Next topic

Nate

I have a MICRO with an SSD attached via the SATA port.  A forum search revealed the presence of the 'olinuxino-sd-to-sata' script in the Olinex images.  I've installed the minimal Bullseye image to a micro-SD card and it boots and runs as expected.

I ran the 'olinuxino-sd-to-sata' script and my disk was repartitioned (hooray for backups!) and the system copied over.  However, apparently no modification was done to uboot as the root system is still shown as /dev/mmcblk0p1 after restarting the system instead of /dev/sda1 which is my goal.

I am much more familiar with twisting Grub into working on Debian systems or the Raspberry Pi way of booting its installations.  My MICRO lacks NAND and apparently lacks SPI. My understanding is that I need to have the micro-SD to boot, or can it boot from the SD port as well?  I ask because I have some 2GB SD cards that would be good for just having uboot on it with the rest of the system on the SATA (a 32GB micro_SD is kind of a waste for 1MB of code).

Thanks for any pointers to documents that I've missed.

LubOlimex

Technical support and documentation manager at Olimex

Nate

My understanding is that these boards require the micro-SD card to boot, so I had it in place to boot.  I recall that I had modified /boot/boot.scr to set the root parameter to /dev/sda1 but it still set the rootfs to /dev/mmcblk0p1.

Right now I am trying ALARM (Arch Linux ARM) and modifying /boot/boot.scr on the micro-SD card to set root to /dev/sda1 does work and it's mounted as the rootfs.

As the MICRO also has a full size SD card slot, I thought I could use it for the boot loader but it doesn't seem to work.  Is this the case or does my MICRO have an issue?  It is several years old.

LubOlimex

I don't think the big SD card slot is suitable for boot by default. Only the micro one. So when testing the boot process use a micro SD card.

Are you sure the board has no SPI flash? The SPI flash makes the boot from SATA easier.
Technical support and documentation manager at Olimex

Nate

For some reason I thought it lacked SPI but I see no mention of that in this capture from the serial port a few days ago:


U-Boot SPL 2021.04+olimex-1-20211223.094223 (Dec 23 2021 - 09:43:25 +0000)
DRAM: 1024 MiB
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
Loading configuration from EEPROM: OK
Verifying data: OK
Trying to boot from MMC1


U-Boot 2021.04+olimex-1-20211223.094223 (Dec 23 2021 - 09:43:25 +0000) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
ID:    A20-OLinuXino-MICRO Rev.J
SN:    0000000B
MAC:   FF:FF:FF:FF:FF:FF
I2C:   ready
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0, mmc@1c12000: 1
Loading Environment from EXT4... *** Warning - bad CRC, using default environment

Loading Environment from FAT... ** No device specified **
HDMI connected: Setting up a 1280x1024 dvi console (overscan 0x0)
In:    serial
Out:   vga
Err:   vga
Allwinner mUSB OTG (Peripheral)
Net:   eth0: ethernet@1c50000, eth1: usb_ether
starting USB...
Bus usb@1c14000: USB EHCI 1.00
Bus usb@1c14400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
Bus usb@1c1c400: USB OHCI 1.0
scanning bus usb@1c14000 for devices... 1 USB Device(s) found
scanning bus usb@1c14400 for devices... 2 USB Device(s) found
scanning bus usb@1c1c000 for devices... 1 USB Device(s) found
scanning bus usb@1c1c400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2274 bytes read in 2 ms (1.1 MiB/s)
## Executing script at 43100000
U-boot loaded from eMMC or secondary SD
Boot script loaded from mmc
Checking for /uEnv.txt...
Checking for /boot/uEnv.txt...
1214 bytes read in 2 ms (592.8 KiB/s)
Loaded environment from /boot/uEnv.txt
Loading FIT image...
16177155 bytes read in 888 ms (17.4 MiB/s)
## Loading kernel from FIT Image at 58000000 ...
   Using 'config-4614' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel 5.10.60-olimex
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x580000d0
     Data Size:    6518984 Bytes = 6.2 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x40080000
     Entry Point:  0x40080000
     Hash algo:    crc32
     Hash value:   c12c1fa2
     Hash algo:    sha1
     Hash value:   772e08be6d8dc234916f0aa43c10a4dc2226bcc4
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading ramdisk from FIT Image at 58000000 ...
   Using 'config-4614' configuration
   Trying 'ramdisk-1' ramdisk subimage
     Description:  Ramdisk for kernel 5.10.60-olimex
     Type:         RAMDisk Image
     Compression:  Unknown Compression
     Data Start:   0x58637acc
     Data Size:    9203413 Bytes = 8.8 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x4fe00000
     Entry Point:  0x4fe00000
     Hash algo:    crc32
     Hash value:   308da24a
     Hash algo:    sha1
     Hash value:   369c9570d838425d1b940e46b9e6a55f3104662a
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Loading ramdisk from 0x58637acc to 0x4fe00000
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its file!
## Loading fdt from FIT Image at 58000000 ...
   Using 'config-4614' configuration
   Trying 'fdt-5' fdt subimage
     Description:  unavailable
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x58f292ac
     Data Size:    44072 Bytes = 43 KiB
     Architecture: ARM
     Load Address: 0x4fa00000
     Hash algo:    crc32
     Hash value:   ecbeaa74
     Hash algo:    sha1
     Hash value:   1218be0048cf5ecbd1d971734b10decfda734c86
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Loading fdt from 0x58f292ac to 0x4fa00000
   Booting using the fdt blob at 0x4fa00000
EHCI failed to shut down host controller.
   Loading Kernel Image
   Loading Ramdisk to 49739000, end 49fffed5 ... OK
   Loading Device Tree to 4972b000, end 49738c27 ... OK
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/spi1-spidev.dtbo'...
408 bytes read in 6 ms (66.4 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/spi2-spidev.dtbo'...
408 bytes read in 6 ms (66.4 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-i2c2.dtbo'...
726 bytes read in 6 ms (118.2 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi0.dtbo'...
1001 bytes read in 6 ms (162.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi1.dtbo'...
1005 bytes read in 6 ms (163.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi2.dtbo'...
1005 bytes read in 7 ms (139.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart3.dtbo'...
863 bytes read in 7 ms (120.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart4.dtbo'...
867 bytes read in 6 ms (140.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart5.dtbo'...
867 bytes read in 7 ms (120.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart6.dtbo'...
867 bytes read in 6 ms (140.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-uart7.dtbo'...
867 bytes read in 6 ms (140.6 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-spi0.dtbo'...
1001 bytes read in 6 ms (162.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/sun7i-a20-can.dtbo'...
732 bytes read in 6 ms (119.1 KiB/s)
Applying overlay: '/usr/lib/olinuxino-overlays/sun7i-a20/micro-lcd-olinuxino.dtbo'...
2225 bytes read in 5 ms (434.6 KiB/s)

Starting kernel ...

I am presently checking out Arch Linux ARM (ALARM) on it and it is working well and was trivial to get /dev/sda1 set as the rootfs by editing the /boot/boot.scr on the micro-SD card.  Only thing is that once the kernel starts it blanks the HDMI screen so it seems to lack the frame buffer console.

My primary use for this computer is to process the data from my weather station.  I was running plain Debian Buster on it and last week decided to upgrade it to Bullseye.  Afterward the system would freeze hard within a couple of minutes.  I moved the processing to another system temporarily and am examining available options for the MICRO.  ALARM is attractive to me for various reasons but if I can't get the console issue sorted (I have a question posted to their forum) then I'll probably come back to the Olimex image as my secondary use for this computer is a picture slide show using the frame buffer image viewer.