Partial boot after installing Manjaro on emmc

[regivanx]

I use the pinebook pro from an SDcard.

I wanted to install an operating system on emmc via manjaro-arm-installer.

After installation, after rebooting without SDcard, I saw the U-boot welcome screen, which I had never seen before.

I get to the login screen, it shows wrong time, and a few seconds later the screen freezes and the computer shuts down.

I must then press the power button for 20 seconds, then press the power button again to restart it.

When the usual SD card is inserted, uboot results in a minimal prompt, without booting the OS.

USB stick doesn't work neither.

Perhaps the installation on emmc went wrong, and it no longer wants to boot from the SD card normally?

NOTA: SD card is OK, I don't erase it during the installation.

[regivanx]

After booting from the SD card, linux is apparently no longer able to detect it:



Note that the sd card is encrypted by cryptsetup.

With an unencrypted sd card, linux does not give access to the emergency shell.

From the emergency shell, it is possible to mount a usb key in /new_root and start an operating system in very degraded mode:

• already, during the emergency shell, linux only detects the usb key if it is plugged in on the left.
  
• the computer goes to sleep several times during startup.
  
• no network interface wlan0.
  
• only detects the usb key on the left, the one that contains the operating system. The usb on the right does not work, neither for a usb key nor for a mouse.
  
• does not detect the sd card.
  

[wdt]

Again, you have been 'bite' by the defective manjaro uboot
on usb stick,, cd; mkdir and cd (something with uboot in name)
to emmc,, cp 1st 16M (of emmc->usb stick),,,, copy emmc mbr
write /dev/zero to emmc (bs=1M count=16) ,,,restore mbr
Then only uboot is on SD, any uboot on usb stick is irrelevant , it will not be found
Find another WORKING uboot, apply to emmc

[regivanx]

Thank you very much for your answer.

Can you check if I understood your answer correctly before entering this shell code?

Code:

$ sudo -s
# cd ~
# mkdir uboot
# cd uboot
# dd if=/dev/mmcblk2 of=uboot_backup.img bs=1M count=16
# dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=16

After this last operation, the first 16 MB of mmcblk2 will be overwritten, and uboot with it.

Can you check the above code carefully? As I use dd, I would like not to trigger a disaster.

[wdt]

Mostly,, lsblk to be sure of number,,, mmcblkX (emmc is device with boot[1,2] sections on it)
Also, before zeroing save mbr (or take note of sector numbers)
(you can run fdisk on an image, for various reasons)
dd if=/dev/mmcblk2 of=emmc.mbr count=1 (obviously in dir where save is wanted)
Then, after zero restore mbr,,, dd if=emmc.mbr of=/dev/mmcblk2
(or run fdisk, plugging in noted sector numbers)
If you don't have a mbr you can't access emmc (except as a 'raw' device)
(well, you can do a manual mount with -o loop,offset=<BYTES> or ((512*SECTORS)) ...)

[regivanx]

Thank you for your reply.

I also asked the question on the Manjaro forum. Strit, the project lead on the manjaro arm project, replied:

We have had some reports that newer uboot packages does not work correctly. We are looking into it.

In the meantime, I'd recommend you try tow-boot:

https://wiki.manjaro.org/index.php/Manja...ptional.29

https://forum.manjaro.org/t/partial-boot...mmc/132931

Therefore, it was not the installation of a new system on the emmc that broke u-boot, but the update. Therefore, the u-boot on the SD card is also broken, and won't boot my computer any further, because I did the update on the sd card before rebooting.

A solution could be to install another linux distribution on a second sd card, in order to preserve the data on the first sd card and have a working u-boot on the second sd card, fix the problem on the emmc by starting the system from the second sd card, then patch the u-boot of the first sd card from the patched system on the emmc.

Indeed, it is not only a question of overwriting the defective version of u-boot of the emmc and the sd card, but also of finding a working boot loader and installing it without the risk of bricking the pinebook pro and the sd cards.

---

Do you have a link to the documentation about the boot system of the pinebook pro? I don't know this subject well, and I would like to understand the solution before applying it.

[wdt]

If you have a usb dongle for SD cards...?
You can pull parts off an image... as so..
zcat someimage.xz |dd of=1st-16.img bs=1M count=16
check mbr on SD card and 1st-16.img, the SD card may have been altered by expandfs
Most xterms can have tabs, so you can have 2 instances of fdisk open, each in own tab
(you alter partition table by deleting and then making a partition. this ONLY alters part table)
Manjaro does not automatically update uboot, the update dumps the files in /boot,,,
then you do a dd operation.. So you don't have to 'pin' uboot version
There is not that much info about uboot that is usefull, much is old and obsolete,
much is confusing
Uboot is ONLY a loader, so there are 2 boots, uboot 1st, then the OS
the cpu has very little ram and a fixed search order for idbloader, which enumerates and activates mb ram
Then uboot can load and always? alter search order, searchs for config file (boot.scr, extlinux.conf, aarch64.efi)
uboot has a rather limited internel dtb, which is how it knows where everything is located

[regivanx]

On the U-Boot splash screen it says:

Loading environment from SPIFlash...

I deduce that U-Boot is loaded from the SPIFlash memory, and not from the emmc.

On the pinebook pro wiki it says:

The Pinebook Pro comes with a 128Mbit, (16MByte), flash device suitable for initial boot target, to store the bootloader. The SoC used on the Pinebook Pro boots from this SPI flash device first, before eMMC or SD card. At present, April 19, 2020, the Pinebook Pros ship without anything programmed in the SPI flash device. So the SoC moves on to the next potential boot device, the eMMC. ARM/ARM64 computers do not have a standardized BIOS, yet.

[...]

Even if you need to recover from a defective bootloader written to the SPI flash, you can simply short pin 6 of the SPI flash to GND and boot. This will render the SoC bootrom unable to read from the SPI flash and have it fall back to reading the bootloader from other boot media like the eMMC or Micro SD card.

The procedures described above are a lot less risky than attaching an external SPI flasher and do not require any additional hardware. At present, April 19th, 2020, there is no good bootloader image to flash into the SPI flash device. This is expected to change, as there are people working on issue.

https://wiki.pine64.org/wiki/Pinebook_Pr...ash_device

I deduce that:

• manjaro-arm-installer presumably installed U-Boot on SPIFlash when installing Manjaro on the emmc.
  
• This version of U-Boot is unsuitable for SPIFlash.
  
• I can disable the SPIFlash to try to start U-Boot on the emmc or on the SD card (hardware deactivation).
  

On the wiki it is also written:

Zeroing out the SPI
In case, you wrote something bad to your SPI, it's helpful to wipe away that data with zeros. To do that, you follow the same steps above to enter maskrom mode and then write a binary file that consists of all zeros.

1. Create the binary file dd if=/dev/zero of=zero.bin bs=1M count=16
   
2. Flash the flash helper db file: rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin. If successful, the output should read Downloading bootloader succeeded.
   
3. Flash the new SPI binary: rkdeveloptool wl 0 zero.bin. If successful, the output should read: Write LBA from file (100%).
   
4. Test the installation: rkdeveloptool td. If successful, output should read Reset Device OK.
   
5. Run rkdeveloptool rd to reboot your Pinebook Pro.
   

https://wiki.pine64.org/index.php/Pinebo...ut_the_SPI

It is therefore possible to deactivate SPIFlash by overwriting the memory (software deactivation)

However, it is necessary to check on U-Boot is installed on the emmc or SD card, before overwriting the SPIFlash memory, otherwise the Pinebook pro will not restart.

For this I can, "short pin 6 of the SPI flash to GND and boot" and see if the pinebook pro reboots.

Do you think this is the right solution?

[KC9UDX]

Yes that sounds to me like exactly the right thing to do. Get a working U-boot, and then zero out the SPI ROM.

[wdt]

>>
I deduce that:

manjaro-arm-installer presumably installed U-Boot on SPIFlash when installing Manjaro on the emmc.
This version of U-Boot is unsuitable for SPIFlash.
I can disable the SPIFlash to try to start U-Boot on the emmc or on the SD card (hardware deactivation).
>>
1) possible but unlikely
2) code is same, but locations different (idbloader@0, uboot@6M), also idbloader
has some extra blank sectors inserted in it
3) the recovery button is also supposed to short SPI, this is NOT 100% reliable

To put the rk3399 into otg mode there must be no media
rkdevelop will work, it is a bit 'fiddly'
since you said you have a usb stick boot, try to install mtd-utils,
then ,,, flash_erase /dev/mtd0 0 0
OR mtd_debug erase /dev/mtd0 0 16777216
both programs in mtd-utils
It is unlikely that the manjaro update wrote to the nand