Pinebook Pro doesn't boot most of the time unless connected via USB-serial!

[wdt]

Not so much info on MODERN uboots, often you see pages dated <2010
I would do a whole distro, in case your systemd setup wrong(or dtb), then try
dd-ing its 1st 16M to a save, then to your minimal card (save/restore mbr)
(I'll explain more, it is really easy to, from beginning(of media), copy or write to media,
here 16M, mbr will be overwritten, so save original as 1st step, restore as last step,,,
more simple, just bs=1M count=16 ,, (as well as if=,of=) ,, no seek, no skip)
If you do mrfixit (my recomendation), go to his git for most up to date, then update it,,mrfixit_update.sh)
Yes indeed, you can mix and match, as long is hardware is same, for that matter,
when you boot SD, it will be using uboot from emmc, not the one on the SD, so may well be mixed
A little more,, bootrom search order is SPI, emmc, SD. usb for rkdeveloptool.
1st uboot found (really idbloader) is loaded, all other uboots ignored

uboot has its own search order (strings uboot|grep _target), looking for extlinux/boot.scr
uboots search will nearly always be different, an example (samueldr)
boot_targets=mmc1 usb0 nvme0 mmc0 pxe dhcp sf0 ,,,, mmc1 is SD, mmc enumerated in order found

[nib0]

Thank you very much for the info @wdt!

I found out that there exists an alternative manjaro uboot package named uboot-pinebookpro-bsp which packages mrfixits version of uboot, so I followed your suggestion and installed it.

Code:

sudo pacman -S uboot-pinebookpro-bsp

I then followed the instructions to dd the 3 files to the eMMC and now everything works! Even rebooting is problem free now.

So @poVoq , if you're running manjaro, maybe switching to this uboot version could be the solution for you too.


One last question, what are the mmcblk2boot0 and mmcblk2boot1 devices for?

[moonwalkers]

Perhaps an off-topic, feel free to throw rocks at ignore me if it is...

Do I understand correctly that PBP SoC completely ignores the eMMC Boot Area Partitions like boot0 and boot1 (show up as, e.g., /dev/mmcblk2boot0 and are NOT visible in, say, GParted)? That is, it ONLY looks at fixed offsets on eMMC User Data Area (shows up as, e.g., /dev/mmcblk2 and IS visible in GParted)? Or at least that's the intention? Because if PBP doesn't completely ignore boot area partitions that might explain some of the booting weirdness some people experience while manipulating only the user data area. That also could be a way to avoid having a gazillion of partitions in the user data area on eMMC if one could write all the necessary U-boot data into the boot area partitions boot0 and boot1.

[poVoq]

@nib0 yes switching to uboot-pinebookpro-bsp seems to have solved the issue. It actually got much worse the week before after a Manjaro update, so mainline uboot definitly seems to have issue right now. I was happy to finally get it to boot after 20 tries or so to do the bsp switch. Since then every boot has been a success.

[wdt]

>One last question, what are the mmcblk2boot0 and mmcblk2boot1 devices for?
I think, don't know for sure, remnants of android,
you will notice that they do not show up in fdisk/cfdisk/gdisk,,
so they are NOT in partition table
They can safely be ignored,, except they are always on emmc, never on SD
so gives a clue which blk dev is which
The bootrom expects idbloader and uboot to be specific places, cares nothing about partitions
It is a raw read,, 0x8000,, 0x800 000 (Bytes) If idbloader signature is not there, on to next
in understandable,, 64 sectors, 8M,, if there is a trust, 12M
(and it is different on SPI, 0x0 and 0x600 000 I think, not at all sure)

[moonwalkers]

boot0 and boot1 (as well as rpmb) are not Android remnants, they are part of eMMC hardware partitions, defined in the standard. eMMC is divided into four areas, Boot Area Partitions (boot0 and boot1), Replay Protected Memory Block (rpmb), General Purpose Partitions, and finally User Data Area. That user data area is what is visible in fdisk and whatnot, the base /dev/mmcblk2 or whatever, GPP are generally unused, and boot area partitions are visible as /dev/mmcblk2boot0 and /dev/mmcblk2boot1. RPMB is used for some security stuff, boot would typically be used for bootloader/firmware, hence my question earlier whether PBP's SoC can make use of Boot Area Partitions at all, because if it can - kumbaya!

[wdt]

OK , a separate section of emmc?
Anyway, linux seems like it cannot touch it
Since my emmc is blank in uboot area, i just tried some tests
It won't mount, no fs,,, OK lets try that
mkdosfs /dev/mmcblk2boot0,,, attribute "partition" not found,, failed
mke2fs .....,,,,,,Operation not permitted while setting up superblock
I didn't try a dd write, thought it might be pressing my luck
In dmesg talks about F2FS-fs not found, 4 lines
--edit--
a little more digging,, boot0 and boot are disks!! Not very big tho. 3 for the price of 1
Since the bootrom is looking for idbloader at 0X8000 in its search path, if boot0 or boot1 is in the search path, it would work.
but where would uboot go?