Boot process

[bero]

Hi,
I'm trying to port OpenMandriva to the PineBook Pro (not that there's anything wrong with the preloaded Manjaro - that one works pretty well too!)

Is there any documentation on the device's boot process?

So far I've gathered:
The most interesting kernel is this one: https://gitlab.manjaro.org/tsys/linux-pinebook-pro
U-boot is probably the generic rk3399 version(?)

I couldn't find anything on what to put where on the SD card for a successful SD boot (other than looking at existing OS images to see where they put stuff), or how to install a new u-boot (and particularly testing it without bricking the device), etc.
Is any such information available?

[Arwen]

As long as you test with the SD card, their is no chance of bricking.
Even if you make a mistake with the eMMC that prevents booting to either the eMMC or SD card, their are recovery techniques available.
Just stay away from programing the SPI with U-Boot, these boot problems are harder to recover from.

Here are some hints on where U-Boot lives;

https://wiki.pine64.org/index.php?title=...le_Storage
https://wiki.pine64.org/index.php?title=...root_drive
https://wiki.pine64.org/index.php?title=...ash_device

We really need a Wiki section on booting in general, & U-Boot in specific, with;

• Description
  
• General maintenance
  
• Development
  

Edit: I started a Wiki page on the boot loader for the Pinebook Pro, (and indirectly the ROCKPro64);
https://wiki.pine64.org/index.php?title=...t_sequence
It's only started, so give it time to get fleshed out / more details.

[Syonyk]

Is there a trick to logging into the wiki?  I thought it was just the forum username/password, but that doesn't work.

As I understand the boot process, per some conversations on IRC and experimenting:

The mask ROM code runs first.  This searches for a uboot binary in SPI, on eMMC, and finally on the SD card.  It will execute the first one it finds - which is why if you screw up the eMMC, the SD card doesn't work.

The uboot path then loads the remaining bits as needed, and will look for a kernel to boot - in a configurable, and perhaps different, order.  Typically these search for the SD card first, but it's not guaranteed.

The safe way to mess around is to have nothing on the eMMC (either wipe the first... oh, 16MB ought to do it, or just remove/disable it), and do all your work on the SD card.  At this point, you can't screw up anything you can't fix trivially in an external machine.  You'll probably want to enable the UART while you're inside and build an adapter for boot messages.

[bero]

Edit: I started a Wiki page on the boot loader for the Pinebook Pro, (and indirectly the ROCKPro64);
https://wiki.pine64.org/index.php?title=...t_sequence

Hi,
thanks! This is already very useful. Where does idbloader come from? (I presume I could just copy it off EMMC and into the SD card, but that's not really the idea...)

Same for TrustedFirmware-A: Is it this? https://github.com/ARM-software/arm-trusted-firmware

Or do I need to find a fork that supports the right SoC?

Also, if in the first step I decide not to mess with the bootloader, what files on the SD card does the preloaded bootloader try to use?

[Arwen]

Hi,
thanks! This is already very useful. Where does idbloader come from? (I presume I could just copy it off EMMC and into the SD card, but that's not really the idea...)

Same for TrustedFirmware-A: Is it this? https://github.com/ARM-software/arm-trusted-firmware

Or do I need to find a fork that supports the right SoC?

Also, if in the first step I decide not to mess with the bootloader, what files on the SD card does the preloaded bootloader try to use?

The idbloader comes from building U-Boot. I don't know for certain what it is, but I think it's the initialization code for the SoC.

The TrustedFirmware-A can come from multiple places. It appears to be the run code for the management processors. Meaning after boot, what the management processors actually do. Again I am not certain.

Anyway, their are multiple places to start with U-Boot. Eventually I'd like that Wiki page to describe how to build mainline U-Boot, with USB & NVMe support. As well as how to use Grub, with video & keyboard support, as a target. Make it work a bit like x86/x64 PCs.

@Syonyk - After they changed the Wiki to the new cluster server, I was forced to change my password on the Wiki. But not on the Forum site. So I am guessing something is broke between them. Simply report it.

[matosys]

Hi,
thanks! This is already very useful. Where does idbloader come from? (I presume I could just copy it off EMMC and into the SD card, but that's not really the idea...)

Same for TrustedFirmware-A: Is it this? https://github.com/ARM-software/arm-trusted-firmware

Or do I need to find a fork that supports the right SoC?

Also, if in the first step I decide not to mess with the bootloader, what files on the SD card does the preloaded bootloader try to use?

The idbloader comes from building U-Boot. I don't know for certain what it is, but I think it's the initialization code for the SoC.

The TrustedFirmware-A can come from multiple places. It appears to be the run code for the management processors. Meaning after boot, what the management processors actually do. Again I am not certain.

Anyway, their are multiple places to start with U-Boot. Eventually I'd like that Wiki page to describe how to build mainline U-Boot, with USB & NVMe support. As well as how to use Grub, with video & keyboard support, as a target. Make it work a bit like x86/x64 PCs.

@Syonyk - After they changed the Wiki to the new cluster server, I was forced to change my password on the Wiki. But not on the Forum site. So I am guessing something is broke between them. Simply report it.

idbloader is a sort-of boot loader for u-boot. it doesn't really do much else.

The SoC gets initialized by the boot rom and once it's initialized, whatever is located at block 64 starts to run by convention. that's why we dd idbloader with a seek=64 command. since we got no complex file system, it's formated in a FAT format. that limits the available addressable space which is the reason we have a bootloader for our bootloader/firmware (the u-boot binary). usb/nvme/video/keyboard/pxe/... and the u-boot shell is implemented inside the u-boot binary and the rest of the hardware gets initialized. then the kernel is loaded into memory and control over hardware is turned over to the kernel/init.

[65a]

Mainline arm trusted firmware works. It may have a suspend issue, but I'm also running a custom kernel, so I'm not certain. I found this useful: https://eno.space/blog/2020/01/pbp-uboot

[CLC]

I would like to completely clean my eMMC to start all over again with dd the boot files, but how should I partition the eMMC before that? Do I make a single ext4 partition or do I need a fat 16?
I have been reading a lot about booting the PBP but did not find any reference to the partitioning, perhaps it is so obvious that nobody mentions that, sorry for my ignorance.

[wdt]

>sorry for my ignorance.... It is not at all clear what all happens
Most images have the first 16M within, written to raw device (no p1 or p2)
http://opensource.rock-chips.com/wiki_Boot_option
note,, 0x40 = 64 sectors ,, 0x4000(sectors) = 8MB ,, 0x6000(sectors) = 12MB
user partitions start at 32768 sectors ,, 16MB , but not manjaro
Is it room for a future efi system partition (ESP)??

[CLC]

I would like to completely clean my eMMC to start all over again with dd the boot files, but how should I partition the eMMC before that? Do I make a single ext4 partition or do I need a fat 16?
I have been reading a lot about booting the PBP but did not find any reference to the partitioning, perhaps it is so obvious that nobody mentions that, sorry for my ignorance.

This is my lsblk:
[carlos@pinebook ~]$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0          7:0    0  85.8M  1 loop /var/lib/snapd/snap/core/9670
loop1          7:1    0 107.2M  1 loop /var/lib/snapd/snap/opencpn/257
mmcblk2      179:0    0  58.2G  0 disk
├─mmcblk2p1  179:1    0  3.9M  0 part
├─mmcblk2p2  179:2    0    64K  0 part
├─mmcblk2p3  179:3    0    4M  0 part
├─mmcblk2p4  179:4    0    4M  0 part
├─mmcblk2p5  179:5    0    4M  0 part
└─mmcblk2p6  179:6    0  112M  0 part
mmcblk2boot0 179:32  0    4M  1 disk
mmcblk2boot1 179:64  0    4M  1 disk
mmcblk1      179:96  0  29.7G  0 disk
├─mmcblk1p1  179:97  0 213.6M  0 part /boot
└─mmcblk1p2  179:98  0  29.5G  0 part /
zram0        252:0    0  5.5G  0 disk [SWAP]
nvme0n1      259:0    0 465.8G  0 disk
├─nvme0n1p1  259:1    0 227.3G  0 part
└─nvme0n1p2  259:2    0 238.5G  0 part
[carlos@pinebook ~]$

I want to install Manjaro on nvmep2 with boot from eMMC, no is working with SD card and the Manjaro image I want to transfer to the nvme
Thanks for any help!

---

>sorry for my ignorance.... It is not at all clear what all happens
Most images have the first 16M within, written to raw device (no p1 or p2)
http://opensource.rock-chips.com/wiki_Boot_option
note,, 0x40 = 64 sectors ,, 0x4000(sectors) = 8MB ,, 0x6000(sectors) = 12MB
user partitions start at 32768 sectors ,, 16MB  , but not manjaro
Is it room for a future efi system partition (ESP)??

Hi wdt,
Thanks for your reply. Unfortunately, it is very interesting, but your link is far beyond my background knowledge.
If I understand, you mean that if I reproduce the content of my SD card in the eMMC it would work, as all needed is there?
It make sense since with eMMC disabled I can boot from SD. So I could sync some how SD to eMMC (after erasing eMMC content) and it should work.
That will be simple, once I study sync commands and options.
(The SD card has Manjaro installed and working)