No boot after Manjaro flash

[PBcurry]

Hi,

I have a serious trouble with my Pinebook pro. There is no boot possible even on SD card.


Initial state : Pinebook pro boot well on emmc with Manjaro  (there were conflicts for updates in this older version of Manjaro, that’s why I wanted a new installation )

1) I boot on SD card with a Manjaro.
2) I update manjaro-flash on the SD card and run it.
3) I put a USB key that contains the image  Manjaro-ARM-kde-plasma-pbpro-22.08.img.xz
4) I tell arm-flash the location of the image and click on install. It runs and indicates a progress of the installation on the emmc (several gigabytes).
5) I turn off the machine and remove the SDCard.
6) I turn on the Pinebook pro, and absolutely nothing is happening, no LED lights up, everything stays off.

So I decided to remove the emmc memory and boot on the previous SDCard.
I did several tests by pressing the power button for a long time or not.
I also pressed the reset button on the motherboard.

The computer seems dead because there is not even a light that turns on (I specify that it is plugged into an electrical outlet).
Can a reinstall be forced with UART mode and serial cable for example?

Thank you if you have an idea.

[thebladerunner]

I'm having the same problem. After a week of trying everything else I finally opened the case and got out my serial to USB adapter. My machine has a borked SPI that I don't think I caused. After receiving my PBP I followed the instructions and went through the update process. The first reboot my machine refused to restart. I now have a flashing amber light and my machine is in a repeating loop due to the SPI being messed up.

I have also followed the instructions for SPI zero'ing and cannot get my machine to go into MASKMODE so I can do that.

I must say I am pretty frustrated.  As a hobby I have been working on hardware and software for a long time. All things considered I am probably the main type of customer for Pine products.  I have thousands of dollars worth of equipment for building equipment, repairing, etc.

Hopefully someone will have more useful input for both of us.

[wdt]

I am not at all sure why people feel a compulsion to write the SPI when the
uboot software is somewhat immature
Next to the reset button, very close, is a "short the clock - SPI" button
With no clock, it cannot be read (the SPI)
It seeems that sometimes this button is "flakey", give it a "wiggle" as you push it
OR
Find the schematic for the SPI, find which is clock lead, short it to ground
For about 5 sec at start of boot,,, there MUST be a uboot on emmc or SD (and a OS somewhere)
Then install mtd-utils and zero out the SPI
For TV boxes, with soldered emmc, shorting the clock is a common operation (clock for emmc),,,
for those brave enough to "hack" said TV box, because the image is sometimes wrong
There is info in wiki, for rkdevelop ALL media must be removed, maybe that's what you are doing wrong

[thebladerunner]

I don’t know why people try to reflash the SPI memory either. I did not intentionally do that. The update to Manjaro seemed to be the source of my problem. 

There are some differences in your proposed method. I’ll try that later today and see if I can resurrect this PBP.

[wdt]

I don’t know why people try to reflash the SPI memory either. I did not intentionally do that. The update to Manjaro seemed to be the source of my problem. 

There are some differences in your proposed method. I’ll try that later today and see if I can resurrect this PBP.

I suspect that you are chasing a red herring (that is, SPI is blank)
My guess is that the manjaro update has a new kernel, and ALSO a new dtb
And that, I suspect is the problem
You said you have serial connection?
Does it display the start of uboot?
If so, remove ALL media, do you get the same thing?
If yes, then uboot is on SPI,,,,, if no, then problem is on emmc
And, for that matter, only mrfixit actually writes the uboot to the 1st 16M (in an update)
(nearly ALL images have the 1st 16M populated, as part of the image)
manjaro just dumps idbloader and uboot.itb into /boot,
you are supposed to do the actual dd write yourself, manually
ALSO (emmc in usb carrier),,, ls -l boot/dtbs/rockchip/*pinebook-pro*
If there is an older, try a rename (current -> *.bad,,, older -> current)

[thebladerunner]

I don’t know why people try to reflash the SPI memory either. I did not intentionally do that. The update to Manjaro seemed to be the source of my problem. 

There are some differences in your proposed method. I’ll try that later today and see if I can resurrect this PBP.

I suspect that you are chasing a red herring (that is, SPI is blank)
My guess is that the manjaro update has a new kernel, and ALSO a new dtb
And that, I suspect is the problem
You said you have serial connection?
Does it display the start of uboot?
If so, remove ALL media, do you get the same thing?
If yes, then uboot is on SPI,,,,, if no, then problem is on emmc
And, for that matter, only mrfixit actually writes the uboot to the 1st 16M (in an update)
(nearly ALL images have the 1st 16M populated, as part of the image)
manjaro just dumps idbloader and uboot.itb into /boot,
you are supposed to do the actual dd write yourself, manually
ALSO (emmc in usb carrier),,, ls -l boot/dtbs/rockchip/*pinebook-pro*
If there is an older, try a rename (current -> *.bad,,, older -> current)

The EMMC module is physically removed as well as the switch turned off. There is no SD card or USB installed.

Below is what I'm getting from the serial connection. It repeats continuously. Also, I've tried every version I have found of entering the Maskrom mode and cannot get there.

U-Boot SPL board init

U-Boot SPL 2017.09-rockchip-ayufan-1065-g95f6152134 (Apr 06 2020 - 08:11:31)
booted from SPI flash
Trying to boot from SPI
"Synchronous Abort" handler, esr 0x02000000
ELR:    10000
LR:      18d8
x 0: 0000000000400000 x 1: 0000000000000000
x 2: 0000000000010000 x 3: 0000000000400180
x 4: 0000000000000000 x 5: 0000000000000000
x 6: 0000000000000030 x 7: 0000000000400188
x 8: 00000000000003ec x 9: 0000000000000000
x10: 00000000005ffc0c x11: 00000000001ffac0
x12: 00000000000003b5 x13: 00000000000003a8
x14: 00000000005ffc5c x15: 00000000001ffac0
x16: 0000000000000000 x17: 0000000000000000
x18: 00000000005ffea0 x19: 000000000000f1c8
x20: 000000000000f1b0 x21: 0000000000000000
x22: 00000000005ffe70 x23: 00000000005ffe58
x24: 000000000000ccac x25: 000000000000cc94
x26: 000000000000f000 x27: 00000000deadbeef
x28: 0000000000000490 x29: 00000000005ffde0

Resetting CPU ...

DDR Version 1.19 20190305
In
soft reset
SRX
channel 0
CS = 0
MR0=0xB9
MR4=0x3
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 1
CS = 0
MR0=0xB9
MR4=0x3
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 0 training pass!
channel 1 training pass!
change freq to 400MHz 0,1
channel 0
CS = 0
MR0=0xB9
MR4=0x3
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 1
CS = 0
MR0=0xB9
MR4=0x3
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 0 training pass!
channel 1 training pass!
change freq to 800MHz 1,0
Channel 0: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
OUT

[wdt]

OK, you are right, somehow the SPI has an auyfan SPI uboot on it
the SPI chip is labeled (on mb) U18
notch
1....8
2....7
3---6
4...5
4 = gnd,, 8 = 3V,,, 6=clock,,, you could verify with DVM
next to reset button is "recovery" button, this is supposed to short clock to ground
you could also verify this with DVM
So, with a for sure bootable SD in, hold recovery button 5+ sec during startup
then install mtd-utils,,,, mtd_debug info /dev/mtd0 ; mtd_debug erase /dev/mtd0 0 16777216
if the button is flakey (known problem), wiggle as you push, or else use fine pointed tweezers to short 6->4
if the points are sharp, less chance of tweezer slipping
All this from before starup ,, for 5 seconds

[PBcurry]

Thanks for your help.
I tried the boot with the recovery button and a good SD-Card (boot ok with it some days ago) but nothing appends (no LED).
I have not the USB-Serial cable yet, but is there a method to completely reinitialise the PB pro with it ?

[wdt]

There are uboot commands, the syntax is a bit odd,
and documentation is quite hard to find
I know I spent most of a day trying to find useful uboot info, didn't find
The recovery button is known to be flakey
In this situation, I would try to short SPI clock (to ground)
The power flows thru a 10K resistor so it is very small power
A wire with a good alligator clip on one end (grd), soldered to a SHARP pin for the clock leg
U18 is quite close to recovery and reset button, I think the closest chip (it will be labeled)
It may have a dot rather than notch, at #1 pin
OR rkdevelop
with all media removed, a usb male to male, rkdevelop on some linux box or laptop
But I don't know those commands either, it's pretty esoteric
The usb on pbp goes to gadget mode, I think you write a 16M /dev/zero file to SPI
-----
2 or 3 people, perhaps 1.5 years ago had this same problem, for them it also was a bit painful
IIRR one did the short, another did the rkdevlop
you could search the archives
------
and here is info on rkdevelop
https://forum.pine64.org/showthread.php?...p#pid59503

[bburdette]

similar problem here. I wanted to get /dev/md0 so I could put the newer bootloader on that nixos requires. attempted to boot off the latest manjaro from SD and now I get no power LED, no nothing.