Jump to content

Rockpro64 PCIe NVME boot not working Armbian 20.11.3 Focal with Linux 5.9.14-rockchip64

Baptiste

By Baptiste
in Pine RockPro64

 Share

Recommended Posts

Baptiste

Baptiste

Posted
Posted
Armbianmonitor:
http://ix.io/2JFD

Hi everyone,

I tried the 20.11.3 version of Armbian, I have manually updated the SPI with U-boot using armbian-config (after an apt update && apt upgrade), but it doesn't start from a PCIe NVME SSD :-/

Is there something that I have missed? Any idea is more than welcome !

Here is my serial - USB console output:

  Reveal hidden contents

 

Kind regards,

Baptiste

piter75

piter75

Posted
Posted
  On 12/29/2020 at 11:17 AM, Igor said:

So far we have no plans to support RockPro64.

Expand  

Well... I apparently enabled it also for RockPro64 by accident while doing some merges between branches ;-)

I had the intention to do this at some point anyway...

 

  On 12/27/2020 at 1:24 AM, Baptiste said:

Is there something that I have missed? Any idea is more than welcome !

Expand  

Are you sure that your nvme0n1p3 partition contains all files in /boot dir?

It seems like it is not loading /boot/uInitrd, /boot/Image or /boot/dtb/rockchip/rk3399-rockpro64.dtb although /boot/boor.scr is loaded.

If you are sure you have those files (did you move your Armbian there with nand-sata-install?) maybe u-boot has issues reading from this particular drive.

I see it's ADATA SX8200 Pro and I had no confirmation that it works properly in SPI/NVMe scenario but that also means nothing - maybe no-one simply reported it yet.

belfastraven

belfastraven

Posted
Posted

@Piter75, Just FYI,  Booting  a a Samsumg pm980 nvme from spi_flash with your new 20.10 u-boot (from your   

rockchip64-u-boot-v2020.10 branch         )  works most of the time.   This is a build made from playing with the desktop stuff, hirsute with gnome...

 

  Reveal hidden contents

It normally works--every once in a while it seems to not get past  

 

 Booting using the fdt blob at 0x1f00000

 

not sure what is causing that yet,  or the constant :

 

Timeout poll on interrupt endpoint

 

I did manually clear previous spi_flash and used nand-sata-install  to install the build and new  spi flash.  

I've also noticed that when asked to update spi flash,  it seems like the script will error if it doesn't find an spi_flash,  but does not try to erase it if it has been written,  andwill fail without any error message if  a  program already exists there...

 

I apologize in advance if the spoiler is not hide-able--I can't seem to make that happen 

piter75

piter75

Posted
Posted

@belfastraven thanks for testing!

Would you be also able to test SPI/NVMe with one of the official Armbian images?

v20.11.3 already have the rkspi_loader.img bundled ;-)

 

  On 1/2/2021 at 2:38 AM, belfastraven said:

every once in a while it seems to not get past  

 

 Booting using the fdt blob at 0x1f00000

Expand  

I have noticed that one too while testing v2020.10 switch yesterday. It fails also with simple SD boot.

For me it was 3 failures with 3 tries but it was already late and I decided to look into that on one of the coming days.

 

  On 1/2/2021 at 2:38 AM, belfastraven said:

or the constant :

Timeout poll on interrupt endpoint

Expand  

I did not notice this one with my ROCK Pi 4 tests. For proper RockPro64 tests I still need to get the passthrough PCIE to m.2 card.

 

  On 1/2/2021 at 2:38 AM, belfastraven said:

I've also noticed that when asked to update spi flash,  it seems like the script will error if it doesn't find an spi_flash

Expand  

I will verify the not found spi flash scenario. Do you mean that the SPI chip was not recognised and there was no error in the nand-sata-install?

 

  On 1/2/2021 at 2:38 AM, belfastraven said:

but does not try to erase it if it has been written,  andwill fail without any error message if  a  program already exists...

Expand  

Do you mean it does not work without manual clearing the SPI before nand-sata-install?

Strange, I specifically chosen to use dd with /dev/mtdblock0 for writing so that mtd-utils dependency was not needed and verified that it clears the blocks before writing new content.

But still... this is pretty fresh so maybe I missed something.

belfastraven

belfastraven

Posted
Posted
  On 1/2/2021 at 11:15 AM, piter75 said:

@belfastraven thanks for testing!

Would you be also able to test SPI/NVMe with one of the official Armbian images?

v20.11.3 already have the rkspi_loader.img bundled ;-)

Expand  

I will test later today with an official image

  7 hours ago, piter75 said:

 

I

I will verify the not found spi flash scenario. Do you mean that the SPI chip was not recognised and there was no error in the nand-sata-install?

No I mean that you will get an error if the device doesn't have (pysically)  an API_FLASH unit,  

 

Do you mean it does not work without manual clearing the SPI before nand-sata-install?

Yes--I believe that to be the case.   You certainly know more about this than I do,  but I found that if I already had something written to SPI_FLASH  ( I was playing with sigmaris's build)  the if I used the NAND_SATA_INSTALL update the SPI_FLASH.  It would return almost immediately with no error and obviously not having written the flash....  If I cleared it first,  it did come back after a while that it had written the flash.    I can certainly try again and see what happens.  

Expand  

     

  7 hours ago, piter75 said:

Strange, I specifically chosen to use dd with /dev/mtdblock0 for writing so that mtd-utils dependency was not needed and verified that it clears the blocks before writing new content.

But still... this is pretty fresh so maybe I missed something.

Expand  

 

belfastraven

belfastraven

Posted
Posted

@piter85,  here's result of testing with official build,  which uses 20.7, u-boot, I see:

 

Bourd booted fine without all of those""Timeout poll on interrupt endpoint"  spams,  using nand-sata-install overwrote the spi_flash just fine ( as you can see :-) )     and without this error,  which I imagine would have been fixed by your most recent patch anyway?

 

Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

 

 

  Reveal hidden contents

 

piter75

piter75

Posted
Posted
  On 1/2/2021 at 8:04 PM, belfastraven said:

here's result of testing with official build,  which uses 20.7, u-boot

Expand  

Thanks for testing!

 

  On 1/2/2021 at 8:04 PM, belfastraven said:

without this error,  which I imagine would have been fixed by your most recent patch anyway?

Expand  

The boot hanging issue has a workaround now in the rockchip64-u-boot-v2020.10 branch indeed and the board boots consistently for me again.

I don't know if it also fixed those "Timeout poll on interrupt endpoint" errors - I did not observe them with v2020.10.

 

  On 1/2/2021 at 8:04 PM, belfastraven said:

Loading Environment from SPIFlash... Invalid bus 0 (err=-19)

Expand  

This is also fixed in the branch with the patch from Sigmaris.

 

I will also definitely add some polish to the nand-sata-install writing process.

1
denni_isl

denni_isl

Posted
Posted

Did do apt update; apt upgrade on rockpro64 today and it did hangs on booting kernel....

 

Did use UART serial to connect and =>ums 0 mmc 0 - and USB 3 male and USB C male to connect to the USB-C on rockpro64,  the emmc came up as a /dev/sda1 on the host computer.   Did sudo mount /dev/sda1 /mnt/sda1, cd /mnt/sda1/boot,  ls -alh and uInitrd was linked to uInitrd-5-10-12-rockchip65 but Image was wrongly linked to vlinux-4.4.213-rockchip6, then, sudo rm Image, ln -s vmlinuz-5.10.12-rockship64 and reboot and it did boot successfully after the upgrade.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept