u-Boot location on the disk

[tsago]

(I've initially intended to ask in the Linux-specific sub-forum, but I guess this is not limited to Linux only. Corrections welcome)

To be ready for un-bricking my horrible experiments that are bound to come, I'm slowly working on gathering information on how this wonderful creature boots.

Mrfixit (thanks!) clarified on IRC that the u-Boot bootloader is stored in an off-set on the eMMC, not directly accessible (~not in one of the two actual partitions, I assume).
So my questions would be:
- Where is it exactly?
- How do I find it?
- How do I recognize that I have actually found it?


I have also had a look at the ChromiumOS image, and in it, there are two interesting files in /boot: boot.scr and bootloader.bin.
(disclaimer: I'm away from the PBP and SD card, so I may be misremembering the filenames. Corrections will follow.)
When I run "file boot.scr", this is identified as an u-Boot bootloader image. The other file is simply data.
==> this brings a side-question: can the bootloader then be stored completely in the /boot partition? Or am I misunderstanding the purpose of these two files?

Upon further googling and reading, I've stumbled upon these links:
https://linux-sunxi.org/Bootable_SD_card
https://linux-sunxi.org/Mainline_U-Boot

These suggest specific places on the eMMC for the location of u-boot. I have also noticed that there are "gaps" at the beginning of the mmcblk1 disk and between the two "readable" partitions.
I've tried to copy various amounts of data from the above start locations using dd into a file and then tried to identify them with "file", but had no luck so far.

Am I looking into the wrong place?
Am I applying a completely wrong approach to find and identify u-Boot?

Ultimately, the question can be boiled down to: Once I have a u-Boot binary, where do I put it on the disk?
Apologies if these questions are too dumb, but I sort of figured this might be useful to document somewhere on the forums/wiki.

[fire219]

uBoot should be at offset 32768 (bytes) within the image.

To confirm this, I opened the .img file in 7zip (there are probably archive programs on Linux which can show the sections of a raw image too), which gets me this... From here, I extracted the individual sections and ran the "strings" command (I did it within WSL, but obviously on Linux you could just do this natively) on each one until I found something that looks like uBoot. As it turns out, RWFW.img is a match.

Offset 32768 is pretty standard for this. The earlier Rockchip-specific bootloaders reside in even lower offsets, and chainload one to another before finally starting up uBoot.

Also as a note: You may not want to rely on information from the linux-sunxi wiki when dealing with the PBP. General topics will likely be accurate, but the focus of that wiki is on Allwinner systems, which don't always operate in the same way as Rockchip.

[Arwen]

Thank you both for the information.

I have glanced at the GPT layout, and it would appear that the normal partition layout can be preserved, if we make room for the u-Boot code at the proper offset.

GPT header ends at 17407 byte offset, (LBA 33). And with the u-Boot starting at 32768, it would be trivial to make room for it. Then have all the user partitions follow after.

Is that the way the eMMC & SD card images are created?

[z4v4l]

GPT header is always at LBA 1 and spans only one sector. Partition Array on the other hand is not fixed.
I don't know how Rockchip does, but with GPT, having huge number of partitions, it would be better to rely on them instead of hadrcoded locations for uboot. except the ROM code wouldn't find uboot then. even though it's trivial to add GPT parsing for finding the needed partitions, they wouldn't want to change it.

By the way, I know, that most of available builds (armbian being an exception) keep using rockchip disk layout and the latter does use GPT scheme, Did you know, that with GPT, you cannot just use dd (alone) for putting an image onto the target medium. you need at least to have some process (installation is its proper name, ideally) in addition, that would regenerate GUIDs on every partition and disk and CRC, in both GPT zones - main and backup. this is something that I see is totally neglected now and violated (and what bugs me honestly). having the same GUIDs on entities, intended to have them unique, is a standard violation and might have unpleasant practical consequenses. GPT aware utilities might get confused and corrupt your data. and as we see, with people constantly copying from SD to eMMC, USB storage, HDD, SSD and running them both, this scenario is not something unreal.

Overall, GPT requires more careful handling during flashing, than plain copying, at the service utilities side. for example GPT mandates putting the backup GPT header at the last block of the device. apparently this means that flashing by copying would shrink the target medium to the size of the source medium. resizing here is more than writing somewhere, that this disk is 256GB instead of 8GB - you need to generate backup GPT header and Partition Array at right places, adjust fields everywhere and recalculate CRC. this should be done in a strict sequence to guarantee consistence. It has been seen on this forum not once, when people complained about their storages got irreversibly shrunk, and this was reported on many machines they tried without possibilities to fix. this might have something to do with messing up GPT. It was intended to use one, real size, - you generate GPT structures for a new device, not create them by silly copying another device as a whole and then "resizing" it. the latter might go wrong, resulting in a device lacking most of its payload space. maybe some utilities think, it's wrong to move backup GPT header. but without this, resizing is impossible - your fatty eMMC would turn into slim eMMC for everything, that takes disk size by thoroughly analyzing corresponding GPT header fields. neglecting GUID uniqness requirement could be even worse (confusing one disk with another, when writing, what else could be worse).

[Arwen]

I've started a Wiki sub-section on boot sequence details. It's early stages, so feel free to improve, correct or make polite comments, (good or bad);

Pinebook Pro Wiki - Boot sequence details

Eventually we can clearly document it, and share some of the details with the RockPro64 board's Wiki.

[tllim]

I've started a Wiki sub-section on boot sequence details. It's early stages, so feel free to improve, correct or make polite comments, (good or bad);

Pinebook Pro Wiki - Boot sequence details

Eventually we can clearly document it, and share some of the details with the RockPro64 board's Wiki.

Thanks :-)