PBP: microSD and NVMe questions

I tried Manjaro after not understanding enough about building Armbian. I am new to both. Been around Linux since 1.2.13 came out. Been around UN*X since 1984.

I have a 1TB NVMe SSD (Intel 660p ?) in the PBP (Pinebook Pro) that I eventually want to use as the device/partition that is my root filesystem. I am not in a hurry.

The biggest annoyance has been the USB/ethernet dongle that I got with my Pinebook Pro. I gather it is going into suspend mode to save energy, and never comes back. I've tried blacklisting in /etc/default/tlp, in /etc/udev/rules.d and both. I've called the product a 8152 and a 8153 (and had rules for both), and while I can get the ethernet to stay up longer, it does eventually die. Someone created a bash script to toggle some command states which I used for the most part. It makes use of the nmcli (?) command. To run the script, it never returns to a prompt. Appears to hang on the nmcli command. I've never used the nmcli command and never looked for a man page.

But for the moment, if I boot, I can use the ethernet enough to do some things like install or update software.

I can understand that not everyone like emacs, but there are times where the psychoanalyst is needed. Emacs is not perfect, I have never run across emacs doing coffee properly. :slight_smile:

No vi/vim surprised me.

I have done some package addition/update, and had the machine refuse to boot, so I started again. I have also done an update, and I am hoping things boot.

Being a dinosaur, I like to use multiple partitions to compartmentalize problems. On my NVMe, I have /, /tmp, /usr, /usr/local, /var, /var/log and /home. I've been using rsync to keep the NVMe in sync with the microSD (64GB, so lots of room for now).

This latest upgrade attempt, flashed a couple of messages about uboot, and I tracked down a log file for pacman which allowed me to see those messages again. I gather I probably don't have to copy the two uboot files to offsets in the 30 or so MB of (supposedly) unused space at the beginning of the microSD. The message to me is a little ambiguous, in that it could either be talking about the microSD device, or if "X" is allowed to be multiple characters, to the first partition of that device. Maybe nobody else gets this?

I ran gdisk -l /dev/mmc... (whatever it is for a microSD, sorry I haven't memorized it yet), and gdisk comes back and says there is a 33 block overlap between the end of the filesystem on the microSD, and the spare partition table stored at the end of the device.

I wasn't sure what the messages about uboot were, so I remounted and rsynced things, and I was going to append the partition names, devices, labels and UUIDs to etc/fstab. Just in case what needed to be done with uboot (which as mentioned above, probably doesn't) might also involve this new boot device (in the future). But, the message was just a couple of dd copies, and I never did them. But, I noticed that etc/fstab is empty.

I can see that uboot can provide the device for the root filesystem (and maybe the filesystem for the kernel, which I normally see in /boot as partition on its own). And lots of people only run single partition Linux systems. Should I fill in etc/fstab on the NVMe in preparation for booting to the NVMe in the future?

mmcblkX ,, X should really be N ,, 1 number
I am still on 19.12 idbloader and uboot, I don't think ATF changed
I have stock on emmc, manjaro on (fast) uSD. It's REALLY important
to have a fast SD, at least if you want it to work well (hard to beat samsung)
gdisk has a backup partition table + 1 sector loader at end of disk = 33sectors
So it wants the space to install
The empty fstab is a systemd thing I'm guessing, I quite despise systemd
Good thing it usually works or I'd have to do something about it

I believe the microSD is a fast SanDisk. I have 4 of them. I also have a Samsung, I believe it is fast. Most of my bigger machines are Devuan (no systemd). The other is Debian Jessie (badly in need of upgrade, no systemd).

A couple of things. I haven't tried using an SSD for root yet, so I am not certain this would work.

  1. The uboot commands flashes the uboot (bootloader) into specific sectors of your SD or eMMC device. mmcblkX is because the X can be any number, so you should check which is related to your Manjaro install. We can't know for sure. You need to check this with lsblk.

  2. The reason why fstab is empty, is because the 20.20.1 and previous images use a single partition layout and a uboot config script has the information about the root device. So what you need to do to use the SSD as root device instead of the SD/eMMC, is to edit the uboot config. If you updated to the latest packages it would be /boot/extlinux/extlinux.conf. In there you will found a section of the APPEND line with root=LABEL=ROOT. Change that to root=/dev/sdXY where sdXY is the drive and partition according to lsblk. After that you need to edit /etc/fstab (because you now have a 2 partition layout), where you add LABEL=ROOT /boot ext4 default 0 0 (I think it should be, I have only don't it with fat32 partitions).

After that is done, you should reboot and make sure it's all correct with lsblk -o NAME,LABEL,MOUNTPOINT.

I am not a hardware expert. :slight_smile:

Nominally, I am talking to myself. Trying to get details correct.

The first bootable device is SPI NOR, eMMC is second. Both are "on the motherboard" in some way. To me, the biggest reason to use SPI NOR, is to have the fastest boot times. With all my servers and desktops, if it takes 2 minutes to boot, that is fine. I'm not in a hurry. If it will be a while, there will be time for some coffee.

Writing to SPI NOR seems a little more problematic than writing to eMMC.

The experts in the Linux kernel seem to think that eMMC and microSD are sufficiently close, that they use the same base name for devices.

I haven't done a compare on the devices in question, but to run
lsblk -f /dev/mmc*
it looks like the eMMC and the microSD card are set up the same. They could be the same logically and different physically.

As MMC1 seems to be the microSD card, and MMC2 the eMMC.

The pinebook-pro uses eMMC as the second boot device, but the 1st device is typical empty (NULL). There is some version of uboot installed in the eMMC, which first looks to boot a microSD. The version of uboot in the eMMC as shipped, did not allow booting from NVMe.

It seems that the uboot that Manjaro is providing, will allow booting from NVMe. For me, I don't want to update the uboot (and uboot configuration) on the microSD card, I want to update the uboot (and configuration) in the eMMC.

And I should hope that the uboot so installed, first attempts to boot from microSD, and if not from NVMe.

My thinking is that I need some other uboot (set of data) to write to eMMC to make this work. So, I will go looking at pine64.org about this.

But in the absence of such, I should be able to boot from a microSD (with the Manjaro uboot on it) to the NVMe. I can live with having a microSD inserted all the time, but it seems to be better to not need that.

Writing to SPI NOR seems a little more problematic
Well yes, it's not a dd. Problem is, if something wrong is written boot is blocked
spi clock has to be shorted to get past it
As to nvme, it's only been a year (maybe) that in the arm branch of uboot
that pcie could be read, so still a work in progress
There was no pcie hardware attached to arm until rk3999, IIRR
AND the pcie hardware is sometimes not EXACTLY spec
So maybe better to have /boot on emmc and root fs on nvme
Lots of nvme seem to draw enough power to impact run time,
emmc seems to be ~ 1W

lsblk and blkid don't really seem to distinguish between the eMMC (which is a socketed chip?) and the microSD (which is meant to be removable). I installed lshw, and it doesn't really distinguish between them either. The hwinfo program does distinguish between them. Evenually it spits out 3 stanzas of pci.13: mmc
id 2 is identified as mmc using the mmcblk driver
id1 is identified as sd using the mmcblk driver
id 0 is identified as sdio using the(null) driver
That unambuously identifies the mmc device. Then lsblk -f could pick out the filesystem, and a person might think about editing the block device in some way.

It seems that hwinfo needs to be installed, or the library that hwinfo uses to determine things would need to be called to do this. But this might be a step to a more universal method of adjusting how the machine boots.

I normally do this sort of thing in Perl. "Real maintainers" seem to use python, or so it seems at times. Is this of interest?

Running fdisk on mmcblk1, There is a vfat partition of size 64M that starts at an offset of 16M (32768 sectors of 512 bytes). And there is an ext4 partition of almost 60G (rest of device, so to speak. Although, I still think that it should be stopping 33 or so sectors earlier.). I will guess that the 4M boot1, 4M boot2 and rpmb things; are at specific offsets inside that 16M empty space at the beginning of the eMMC device. The ext4 partition is containing the Debian/Mate desktop that ships with the Pinebook-Pro. The vfat partition contains a subdirectory (which contains an extlinux.conf file), two Image files (one is .bak) and two rk3399-pinebookpro.dtb files (one is .bak).

/extlinux/extlinux.conf contains 2 stanzas (primary and bak). The Image file in the parent directory must be a Linux kernel (file doesn't identify it as a Linux kernel), and root command line is showing the rootfs as /dev/mmcblk1p2. The two dtb files are arguments of a ftd line of the stanza.

My script, needs to be provided with a Linux kernel Image (presumably not compressed?), a copy of the rk3399-pinebookpro.dtb file for that kernel and the location of the root of the filesystem to use.

An edit of the root command line info in extlinux.conf may be necessary if the root of the filesystem is being changed.

We then need to adjust 4 files. The existing Image and rk3399-pinebookpro.dtb files need to become.bak, and the new files need to be copied in. Setting the existing file to become the new bak file(s) could be done by deleting a filename and moving the existing to .bak, or a copy could be done. If uboot knows the vfat filesystem, it is probably less potential for problems if renaming files is how one affects the change of existing to bak. A person still needs to copy the new information in.

Not being around uboot in the past, it may be there is some subtlety present. A 4M boot1, a 4M boot2 and a 16M SD (rpmb) won't fit into a 16M segment of storage.

Time to go do some more reading.

To make it simple, be completely unambiguous, I boot emmc (no SD inserted)
and label2fs / emmc-root. Almost impossible to be confused now
I have no idea where the boot0, boot1, or rpmb come from, certainly not fdisk
Anyway, the way rk3999 seems to be set up is idbloader, start sector64,,,
uboot, start 16384 (8M),,,ATF, start 12M

Forum kindly sponsored by