Manjaro RockPro64 image don't boot

ARM Technical Assistance
,
1

Hi,
I have Pine64 RockPro64 board. From the beginning, it causes me terrible problems. I have already tried Debian which crashed during installation and ARMbian which had various strange problems, for example still all programs was getting SIGSEGV, and not only the big (an probably buggy) ones like Java, but even apt crashed with the “Segmentation Fault” message. I have tried everything (including other governors and changing SD card). It didn’t help.

So I decided to install Manjaro as it is de facto the default OS for Pinebook Pro which have the same CPU as RockPro64. I have saved the Manjaro image to the SD card and inserted it into RockPro64 SD card slot. When I started RockPro64, the red and white lights lighted up first, then only the white light. And nothing showed on the screen. For comparison, when I boot the ARMbian image, first the red and white lights light up, and then the white light start flashing (half a second is on and half is off). I don’t know if this image is with u-boot, but before that I uploaded u-boot from ayufan image to SPI, so now I’m even able to boot images without u-boot.

So what’s going on?

2

It sounds like a u-boot issue.

The images we have, do use u-boot.

What does UART tell you when you try booting Manjaro?
We can’t really start diagnosing without this.

3 
It sounds like a u-boot issue.

It is u-boot issue. ROOTFS is ok (I’ve tested it via systemd-nspawn).

What does UART tell you when you try booting Manjaro?

I never got to work serial console. Debugging embedded, headless linux is like magic to me.

Despite the fact that your image wasn’t booting on my RockPro64 I got Manjaro to work on my machine with this tutorial - https:/2names1scott.com/docs/rockpro64boot.html (It was hard BTW). I’ve just skipped point “Installing the rootfs” and instead of doing this I copied rootfs from your image. So there is nothing with my board. Rather, your image is broken. I don’t know why it works for some folks, however, you may want to fix it, so method from tutorial I mentioned worked for me.

I still have this “SIGSEGV” issues, however. I mean: All my programs all the time are crashing with SIGSEGV. It’s completely random. Big programs like java crash almost every time but pacman crashed too while installing vim… so these are some random applications.

4

Sure, but we can’t fix it, unless we know what to fix. And this requires UARt output.

I have heard that uboot 2020.07 and 2020.10 has been troublesome for some rk3399 based devices making them only boot sometimes, but I haven’t had any issues in my tests.

Here’s the gitlab issue for reference:

5

OK, so to gather this output I need to buy special device, like CH340G console. Yes? I saw different posts. I saw this - https:/forum.pine64.org/showthread.php?tid=6387 but I also saw method to connect to this board via normal USB cable.

6

I just uploaded 20.12.1 images for the RockPro64, which should have this issue fixed. Please test it and report back.

7

No. It’s not working… Maybe I’ll manage to gather this UART output in the next few days.

8

I have tested 20.12.1 plasma image on a rockpro64 board booting from an sd card without issue.

On this board the boot order is: SPI flash, emmc, sdcard. If you still have ayufan’s image on the SPI flash, it will be going through that boot sequence before it ever sees the sdcard image. To test if this is the problem, ground pin 28 (spi_clk) during the first 2 seconds of the power on then release it. If this gets manjaro to boot, you need to clear your spi flash. See references below to get you on your way if this is the problem.

https://wiki.pine64.org/wiki/ROCKPro64#Disable_SPI_.28while_booting.29


1 Like
9 
To test if this is the problem, ground pin 28 (spi_clk) during the first 2 seconds of the power on then release it.

It worked for me! I will clear SPI flash and tell you if it works. Why this image don’t work with u-boot flashed to SPI while other OS’s work?

10

OK. Now I know that SPI is causing the problem but I’m not able to erase it. Any /dev/mtd0 access attempt ends with kernel panic, but u-boot is flashed on /dev/mtd0 partition…

/proc/mtd file:

dev:        size    erasesize    name
mtd0:  ..........   .............      "loader"
mtd1:    ......           .....         "env"
mtd2:    ....            .....          "vendor"

I was following this guide - linux-build/flash-spi.md at master · ayufan-rock64/linux-build · GitHub

How can I erase this SPI flash?

11

It does. But it depends on what U-boot is used.
If you have an older (2015’ish) u-boot on SPI, like the BSP uboot. It might not see the bootscript we are using. We are using mainline uboot and mainline kernel.

12

I managed to erase my SPI with lastest ayufan image. Now your image manages to boot. However, I still have this SIGSEGV issues.

13

Anyway, this problem is solved. I will create new topic for my second problem.

14