After messing with eMMC partitions, PBP won't boot, even from SD card

[granstr0m]

Messing with the partition layout is a bit dangerous, because the start of the eMMC/SD card is layed out in a specific way. 

The RK3399 SoC will read it's idbloader.img from byte 32768 (from the start of the device, sector 0x40). 
After that is the u-boot at the magic offset byte 8388608 (sector 0x4000). 
That's the reason why partitions are starting rather far into the device on the stock images, to make space for the bootloader and SPL.

You can find more information about the boot process in this wiki article from Rockchip:
http://opensource.rock-chips.com/wiki_Boot_option

In short: Don't touch the first ~16-32 MiB of the device and you'll be fine. 
Otherwise, you'll need to dd the bootloader and idbloader back onto the partition after your actions: 

Code:

dd if=idbloader.img of=/dev/sdb seek=64
dd if=u-boot.itb of=/dev/sdb seek=16384

(as root, these files are probably in /boot)

Tobias

Ooops, I just did a dd if=kali-linux-2020.2.x.x.x of=/dev/mmcblk2 yesterday

Very strange that it worked on the first reboo until today when I rebooted again and it just stays with the orange led.  

So how are you supposed to flash let's say Kali to the eMMC???

dd if=kali-linux-2020.2.x.x.x of=/dev/mmcblk2 seek=32768

Would that work??? If I first manage to restore the boot and idbloader, that is!!!

[manawyrm]

Code:

dd if=kali-linux-2020.2.x.x.x of=/dev/mmcblk2

sounds very good, that's the right command.

Just make sure you've unpacked the image before doing that. (you need an .img file, not .img.xz!) 
If it's still an .xz image, run

Code:

xz -d kali-linux-2020-x-x.img.xz

to extract it. 
Don't run these commands with offsets (like seek=32768) until you know what they're for.

[granstr0m]

Code:

dd if=kali-linux-2020.2.x.x.x of=/dev/mmcblk2

sounds very good, that's the right command.

Just make sure you've unpacked the image before doing that. (you need an .img file, not .img.xz!) 
If it's still an .xz image, run

Code:

xz -d kali-linux-2020-x-x.img.xz

to extract it. 
Don't run these commands with offsets (like seek=32768) until you know what they're for.

Well, I was unpacking it on the fly via a pipe. But anyway, I got the impression that I should NOT overwrite the first 32Mb of the emmc in another thread here. But it should work just lika above then??? And it did work I could reboot once, but what the heck happened after that?? I didn't do anything to the emmc after booting inte Kali. I have booted from the SD card now and rebound the Emma but I do not want to be in this situation again in a few days after installing 100 of my favourite tools in Kali.

[granstr0m]

If you install Kali by doing:

xzcat kali-linux-2020.2-pinebook-pro.img.xz | dd of=/dev/mmcbl2 bs=1M conv=sync

When you remove the SD card and reboot everything works as expected. Kali is booting and works perfect.

Reboot one more time and BAAM you are stuck with the orange light unable to boot from either emmc or sd card.

What is happening???

I am able to resolve the not booting issue by opening the Pinebook, switching the emmc temporary off and booting from sd. This is handled in other threads on this forum.

But the question is, how are you supposed to install another distribution??? Not like above I guess cause it does not work.

[manawyrm]

Actually, the method you described sounds just right.
I guess there must be an issue with the kali-linux image then, because this method will work with Manjaro, Debian, etc.

[wdt]

seek=32768 is 16M,,, dd defaults to sectors, 512 bytes
>I should NOT overwrite the first 32Mb
First 16M, run fdisk on most distros and see 1st user partition starts 32768 (sectors)
Matchs SPI, 128Mb (bits)
idbloader at (decimal) 64 sectors, uboot at 8M, ATF/trust at 12M, user parts at 16M
You could test your assumption that kali overwrites the uboot region by
pulling the 8-12M region and comparing with what you wrote
something like bs=1M skip=8 count=4,,, same sort of idea for idbloader