(01-05-2021, 01:01 PM)jja2000 Wrote: (01-05-2021, 10:23 AM)amiraeva Wrote: (01-05-2021, 05:14 AM)jja2000 Wrote: I'm running into the same problem. How do I remove usb start from the preboot env variable? Booting timeout is on 0 so I don't have the chance to mash any keys. If I'm not mistaken, even with a timeout of 0 - there is a narrow window to stop the automatic boot process. Just had to mash keys in the UART console right as you turn your SBC on. At least that's how I was able to muck around in the uboot console. I read that you could use escape in UART yes, I was hoping that I could do it through the videoconsole too. Time to bust out the CP2102 then 
If you do have "usb start" in the preboot env variable, the USB system will be init'ed when U-Boot starts. So then after you see messages about USB starting, you can hit Ctrl-C on the USB keyboard repeatedly until you've cancelled all the attempts to boot from MMC, network and so on, and you should hopefully arrive at the U-Boot prompt, allowing keyboard interaction.
(08-02-2020, 09:00 PM)Mentaluproar Wrote: (07-26-2020, 05:20 PM)belfastraven Wrote: (07-26-2020, 05:33 AM)sigmaris Wrote: I've made another build based on 2020.07 using this branch, with a couple of additional patches:
Patch from Tian Yuanhao which allows compressed (gzip, etc) kernels to be loaded. No need to gunzip the default arm64 kernels to load them with u-boot anymore.
Patch from Jagan Teki which is supposed to enable USB-3 support on the USB-3.0 type A port. When testing this with the one USB-3 disk drive I have, it didn't seem to work, the disk drive wasn't detected in the USB-3.0 port. I'd be interested to hear if anyone else has success in using USB-3.0 devices in USB-3.0 mode with this. Note the USB Type C port is configured as OTG mode by default in the DTS, and so won't be used as a host port, so only the Type A port should be used for USB-3.0.
Build artifacts for MMC and SPI installation from this branch can be found here. This works fine for me with USB3-- I have attached the u-boot logs from booting a SANDISK extreme stick and then a Samsung portable ssd T150. I was booting from SPI . I also booted my NVME, which I removed in order to boot the other devices, since that is first in the boot order. When not booting from the USB3, the kernel recognizes the USB3 devices, just FYI. Is there anything in particular I could do to help you debug your issue? Opposite experience for me here. I did a fresh install of manjaro on a USB flash drive, ran all the updates and then installed from the link above. Sata boot still works, but this breaks USB boot. Not even USB2 boots properly now. Both stick at "Booting using fdtblob at 0x1f0000000"
Was seeing this on the screen something we could have turned on before? I prefer it to the blindly waiting for the OS to load.
Hi, could you or someone resolve this "Booting using fdtblob at 0x1f0000000" somehow?
I got the same with latest Armbian_21.02.3_Rockpro64_focal_current_5.10.21.img.xz and U-Boot 2020.10-07966-ge34a1785a0 (Nov 17 2020 - 19:32:18 +0000))
Code: U-Boot 2020.10-07966-ge34a1785a0 (Nov 17 2020 - 19:32:18 +0000)
SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
Card did not respond to voltage select!
Device 0: unknown device
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
SATA link 2 timeout.
SATA link 3 timeout.
SATA link 4 timeout.
AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode
flags: 64bit ncq stag pm led clo pmp fbss pio slum part ccc apst boh
Device 0: (0:0) Vendor: ATA Prod.: INTEL SSDSC2KW48 Rev: LSF
Type: Hard Disk
Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
Device 0: (0:0) Vendor: ATA Prod.: INTEL SSDSC2KW48 Rev: LSF
Type: Hard Disk
Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 9 ms (344.7 KiB/s)
## Executing script at 00500000
Boot script loaded from scsi 0
166 bytes read in 8 ms (19.5 KiB/s)
15335962 bytes read in 254 ms (57.6 MiB/s)
28582400 bytes read in 463 ms (58.9 MiB/s)
75809 bytes read in 19 ms (3.8 MiB/s)
2698 bytes read in 15 ms (174.8 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3de0000
## Loading init Ramdisk from Legacy Image at 06000000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 15335898 Bytes = 14.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
(03-14-2021, 03:48 AM)mdesign Wrote: Hi, could you or someone resolve this "Booting using fdtblob at 0x1f0000000" somehow?
I got the same with latest Armbian_21.02.3_Rockpro64_focal_current_5.10.21.img.xz and U-Boot 2020.10-07966-ge34a1785a0 (Nov 17 2020 - 19:32:18 +0000))
Code: U-Boot 2020.10-07966-ge34a1785a0 (Nov 17 2020 - 19:32:18 +0000)
SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 RockPro64 v2.1
DRAM: 3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: vidconsole
Err: vidconsole
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus usb@fe3a0000: USB OHCI 1.0
Bus usb@fe3c0000: USB EHCI 1.00
Bus usb@fe3e0000: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus usb@fe3a0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3c0000 for devices... 1 USB Device(s) found
scanning bus usb@fe3e0000 for devices... 2 USB Device(s) found
scanning bus dwc3 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
Card did not respond to voltage select!
Device 0: unknown device
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
SATA link 2 timeout.
SATA link 3 timeout.
SATA link 4 timeout.
AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode
flags: 64bit ncq stag pm led clo pmp fbss pio slum part ccc apst boh
Device 0: (0:0) Vendor: ATA Prod.: INTEL SSDSC2KW48 Rev: LSF
Type: Hard Disk
Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
Device 0: (0:0) Vendor: ATA Prod.: INTEL SSDSC2KW48 Rev: LSF
Type: Hard Disk
Capacity: 457862.8 MB = 447.1 GB (937703088 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 9 ms (344.7 KiB/s)
## Executing script at 00500000
Boot script loaded from scsi 0
166 bytes read in 8 ms (19.5 KiB/s)
15335962 bytes read in 254 ms (57.6 MiB/s)
28582400 bytes read in 463 ms (58.9 MiB/s)
75809 bytes read in 19 ms (3.8 MiB/s)
2698 bytes read in 15 ms (174.8 KiB/s)
Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
Moving Image from 0x2080000 to 0x2200000, end=3de0000
## Loading init Ramdisk from Legacy Image at 06000000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 15335898 Bytes = 14.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
Booting using the fdt blob at 0x1f00000
I think you're encountering the same problem, where U-Boot starting USB before boot will cause booting the kernel to hang.
I noticed that Debian has disabled starting USB in U-Boot preboot ( https://bugs.debian.org/cgi-bin/bugrepor...bug=973323), I haven't seen this problem on my RockPro64 board but enough other people have reported issues with USB that I decided to make another release, updating to be based on v2021.01, with starting USB disabled in preboot: https://github.com/sigmaris/u-boot/relea...ckpro64-ci
Try that and see if it fixes the issue (though it will sacrifice the use of USB keyboard in U-Boot).
I'm currently experiencing problems booting the latest Armbian release on my rockpro64 from eMMC.
I just hangs like you can see on the photo on the first comment in this forumthread:
https://forum.armbian.com/topic/14724-ro...-v44-does/
Would this u-boot also solve that problem? Currently booting from SDCard but would prefer eMMC of course.
(04-15-2021, 05:04 AM)MisterA Wrote: I'm currently experiencing problems booting the latest Armbian release on my rockpro64 from eMMC.
I just hangs like you can see on the photo on the first comment in this forumthread:
https://forum.armbian.com/topic/14724-ro...-v44-does/
Would this u-boot also solve that problem? Currently booting from SDCard but would prefer eMMC of course.
If you're using Armbian, probably best to stick with Armbian's U-Boot. It makes things simpler and Armbian volunteers probably don't want to support mixing other builds of U-Boot with Armbian Linux.
FWIW, if you're seeing log messages about /scripts/local-premount and so on like in the photo, that's booted up the Linux kernel and got as far as running the scripts on initramfs. So U-Boot may not be the issue here. I would suspect the scripts on initramfs are having trouble finding the root filesystem to mount it and continue booting. Look at your root= argument in the kernel command line, check it's specifying the filesystem you want, and see if you can enable more verbose logging (remove things like quiet from the kernel arguments) to get more information.
04-16-2021, 02:20 AM
(This post was last modified: 04-16-2021, 02:23 AM by LMM.)
(04-15-2021, 10:46 AM)sigmaris Wrote: (04-15-2021, 05:04 AM)MisterA Wrote: I'm currently experiencing problems booting the latest Armbian release on my rockpro64 from eMMC.
I just hangs like you can see on the photo on the first comment in this forumthread:
https://forum.armbian.com/topic/14724-ro...-v44-does/
Would this u-boot also solve that problem? Currently booting from SDCard but would prefer eMMC of course.
If you're using Armbian, probably best to stick with Armbian's U-Boot. It makes things simpler and Armbian volunteers probably don't want to support mixing other builds of U-Boot with Armbian Linux.
FWIW, if you're seeing log messages about /scripts/local-premount and so on like in the photo, that's booted up the Linux kernel and got as far as running the scripts on initramfs. So U-Boot may not be the issue here. I would suspect the scripts on initramfs are having trouble finding the root filesystem to mount it and continue booting. Look at your root= argument in the kernel command line, check it's specifying the filesystem you want, and see if you can enable more verbose logging (remove things like quiet from the kernel arguments) to get more information.
Hi,
I don't know if it is your case, it happened to me when I made an direct image of my emmc to boot from a ssd nvme : the root dev was indeed pointing on the emmc device instead on the ssd. I did not want to bother and downloaded the new image with the 5.10 kernel.
But I suppose that the good procedure would be to specify the root dev :
- get the uuid of the dev containing the root/ : "lsblk -o NAME,PATH,MOUNTPOINT,UUID "
- in the file /boot/armbianEnv.txt change UUID of the line "rootdev=UUID=" with the UUID on the root or "/" mountpoint
Hi Sigmaris,
I am trying to boot with PXE boot an Armbian image (I wrote it in a separate post).
With the ayufan u-boot and with a boot directory extracted from a not "first boot" system and I managed to login.
However, it still does not work with Sigmaris or Armbian u-boot the boot sequence seems stuck. I tried a manual u-boot sequence with UART console by following this instruction https://andreialdea.com/2019/06/12/odroi...orial-ish/ and it seems that I get further without the ftd resize (boot sequence starts).
Have you noticed the same issue ?
04-23-2021, 09:35 AM
(This post was last modified: 04-23-2021, 10:57 AM by Maxpako.)
Hi all,
I'm trying to install the bootloader to my RockPro64, but I'm facing an issue trying to flash it.
Code: U-Boot TPL 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Colpddr4_set_rate: change freq to lpddr4_set_rate: change freq to Trying to boot from BOOTROM
Ret
U-Boot SPL 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30 +0000)
Trying to boot from MMC1
NOTICE: BL31: v2.4(release):v2.4
NOTICE: BL31: Built : 13:33:26, Mar 20 2021
U-Boot 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30 +0000)
SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 Roc3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
*** Warning - spi_flash_probe_buIn: serial
Out: serial
Err: serial
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:3...
Found U-Boot script /boot.scr
967 bytes read in 4 ms (235.4 KiB/s)
## Executing script at 00500000
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Error: No SPI <<<<<<Pressed Ctrl+c>>>>>>sleep - delay execution for some time
Usage:
sleep N
- delay execution for N seconds (NSCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
Scanning disk mmc@fe310000.blk...
Disk mmc@fe310000.blk not ready
Scanning disNo valid Btrfs found
** UnrecogNo valid Btrfs found
** Unrecognized filesystem type **
Card did not respond to voltage select! : -110
Scanning disk sdhci@fe330000.blk...
Disk sdhci@fe330000.blk not ready
Found 4 ition
Device nor0 not found!
BootOrder not defined
EFI boot manager: Cannot load any image
=> sf probe
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash (error -2)
=>
First I left the board at this point for some time:
Code: ## Executing script at 00500000
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Error: No SPI
There, the white and red leds were flashing alternating (white, then red, then white, then red and so on).
Then on the serial console I press Ctrl+c, and the message continued as shown above
No matter if I try @ sigmaris or @ ayufan, the error is the same on both.
For example, using ayufan's Buster minimal, if I try to reset the SPI, it says success:
Code: root@rockpro64:/usr/local/sbin# /usr/local/sbin/rockpro64_reset_spi_flash.sh
Unbinding...
Binding...
Finished
root@rockpro64:/usr/local/sbin# /usr/local/sbin/rock64_erase_spi_flash.sh
Doing this will overwrite data stored on SPI Flash and it will require that you use eMMC or SD as your boot device.
loader partition on MTD is not found
/usr/local/sbin/rock64_erase_spi_flash.sh: line 14: return: can only `return' from a function or sourced script
root@rockpro64:/usr/local/sbin# ls -lah /dev/mt*
ls: cannot access '/dev/mt*': No such file or directory
root@rockpro64:/usr/local/sbin#
But I still can't see anything about SPI if I remove the emmc and the SD card. So I doubt it loads anything from SPI.
Any help?
04-23-2021, 12:32 PM
(This post was last modified: 04-23-2021, 12:49 PM by LMM.)
(04-23-2021, 09:35 AM)Maxpako Wrote: Hi all,
I'm trying to install the bootloader to my RockPro64, but I'm facing an issue trying to flash it.
Code: U-Boot TPL 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Colpddr4_set_rate: change freq to lpddr4_set_rate: change freq to Trying to boot from BOOTROM
Ret
U-Boot SPL 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30 +0000)
Trying to boot from MMC1
NOTICE: BL31: v2.4(release):v2.4
NOTICE: BL31: Built : 13:33:26, Mar 20 2021
U-Boot 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30 +0000)
SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 Roc3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
*** Warning - spi_flash_probe_buIn: serial
Out: serial
Err: serial
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:3...
Found U-Boot script /boot.scr
967 bytes read in 4 ms (235.4 KiB/s)
## Executing script at 00500000
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Error: No SPI <<<<<<Pressed Ctrl+c>>>>>>sleep - delay execution for some time
Usage:
sleep N
- delay execution for N seconds (NSCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
Scanning disk mmc@fe310000.blk...
Disk mmc@fe310000.blk not ready
Scanning disNo valid Btrfs found
** UnrecogNo valid Btrfs found
** Unrecognized filesystem type **
Card did not respond to voltage select! : -110
Scanning disk sdhci@fe330000.blk...
Disk sdhci@fe330000.blk not ready
Found 4 ition
Device nor0 not found!
BootOrder not defined
EFI boot manager: Cannot load any image
=> sf probe
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash (error -2)
=>
First I left the board at this point for some time:
Code: ## Executing script at 00500000
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Error: No SPI
There, the white and red leds were flashing alternating (white, then red, then white, then red and so on).
Then on the serial console I press Ctrl+c, and the message continued as shown above
No matter if I try @sigmaris or @ayufan, the error is the same on both.
For example, using ayufan's Buster minimal, if I try to reset the SPI, it says success:
Code: root@rockpro64:/usr/local/sbin# /usr/local/sbin/rockpro64_reset_spi_flash.sh
Unbinding...
Binding...
Finished
root@rockpro64:/usr/local/sbin# /usr/local/sbin/rock64_erase_spi_flash.sh
Doing this will overwrite data stored on SPI Flash and it will require that you use eMMC or SD as your boot device.
loader partition on MTD is not found
/usr/local/sbin/rock64_erase_spi_flash.sh: line 14: return: can only `return' from a function or sourced script
root@rockpro64:/usr/local/sbin# ls -lah /dev/mt*
ls: cannot access '/dev/mt*': No such file or directory
root@rockpro64:/usr/local/sbin#
Any help? Hi,
In the wiki it says "Ayufan images contain (at the moment) only one script for the SPI and the RP64, it's "rockpro64_reset_spi_flash". Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them"
So "rock64_erase_spi_flash.sh" would no work. To erase you may use the erase image. I usually have both images in two sd cards
You have to flash the u-boot image again from the sd card containing the image and strictly follow the intructions of the operations.
sigmaris : https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI
ayufan : same procedure with ayufan mainline u-boot image - wait until it blinks once per second
The error you see may be due to a bad or not appropriate boot/kernel image on the emmc.
Good luck. Do not hesitate to post more questions/details.
LMM
(04-23-2021, 12:32 PM)LMM Wrote: (04-23-2021, 09:35 AM)Maxpako Wrote: Hi all,
I'm trying to install the bootloader to my RockPro64, but I'm facing an issue trying to flash it.
Code: U-Boot TPL 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Colpddr4_set_rate: change freq to lpddr4_set_rate: change freq to Trying to boot from BOOTROM
Ret
U-Boot SPL 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30 +0000)
Trying to boot from MMC1
NOTICE: BL31: v2.4(release):v2.4
NOTICE: BL31: Built : 13:33:26, Mar 20 2021
U-Boot 2021.01-09768-gc762ab29b8 (Mar 20 2021 - 13:35:30 +0000)
SoC: Rockchip rk3399
Reset cause: POR
Model: Pine64 Roc3.9 GiB
PMIC: RK808
MMC: mmc@fe310000: 2, mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPIFlash... jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
*** Warning - spi_flash_probe_buIn: serial
Out: serial
Err: serial
Model: Pine64 RockPro64 v2.1
Net: eth0: ethernet@fe300000
Hit any key to stop autoboot: 0
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:3...
Found U-Boot script /boot.scr
967 bytes read in 4 ms (235.4 KiB/s)
## Executing script at 00500000
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Error: No SPI <<<<<<Pressed Ctrl+c>>>>>>sleep - delay execution for some time
Usage:
sleep N
- delay execution for N seconds (NSCRIPT FAILED: continuing...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Card did not respond to voltage select! : -110
Scanning disk mmc@fe310000.blk...
Disk mmc@fe310000.blk not ready
Scanning disNo valid Btrfs found
** UnrecogNo valid Btrfs found
** Unrecognized filesystem type **
Card did not respond to voltage select! : -110
Scanning disk sdhci@fe330000.blk...
Disk sdhci@fe330000.blk not ready
Found 4 ition
Device nor0 not found!
BootOrder not defined
EFI boot manager: Cannot load any image
=> sf probe
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash (error -2)
=>
First I left the board at this point for some time:
Code: ## Executing script at 00500000
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 1:0 (error -2)
Error: No SPI
There, the white and red leds were flashing alternating (white, then red, then white, then red and so on).
Then on the serial console I press Ctrl+c, and the message continued as shown above
No matter if I try @sigmaris or @ayufan, the error is the same on both.
For example, using ayufan's Buster minimal, if I try to reset the SPI, it says success:
Code: root@rockpro64:/usr/local/sbin# /usr/local/sbin/rockpro64_reset_spi_flash.sh
Unbinding...
Binding...
Finished
root@rockpro64:/usr/local/sbin# /usr/local/sbin/rock64_erase_spi_flash.sh
Doing this will overwrite data stored on SPI Flash and it will require that you use eMMC or SD as your boot device.
loader partition on MTD is not found
/usr/local/sbin/rock64_erase_spi_flash.sh: line 14: return: can only `return' from a function or sourced script
root@rockpro64:/usr/local/sbin# ls -lah /dev/mt*
ls: cannot access '/dev/mt*': No such file or directory
root@rockpro64:/usr/local/sbin#
Any help? Hi,
In the wiki it says "Ayufan images contain (at the moment) only one script for the SPI and the RP64, it's "rockpro64_reset_spi_flash". Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them"
So "rock64_erase_spi_flash.sh" would no work. To erase you may use the erase image. I usually have both images in two sd cards
You have to flash the u-boot image again from the sd card containing the image and strictly follow the intructions of the operations.
sigmaris : https://github.com/sigmaris/u-boot/wiki/...oot-to-SPI
ayufan : same procedure with ayufan mainline u-boot image - wait until it blinks once per second
The error you see may be due to a bad or not appropriate boot/kernel image on the emmc.
Good luck. Do not hesitate to post more questions/details.
LMM
Hi LMM,
Thanks for the info.
As far as I know I've used the proper images for RP64 that can be downloaded from their git repos (sigmaris and ayufan).
Unfortunately, I get the error commented (output of the serial console).
Fortunately, the ayufan scripts for RP64 doesn't work on my RP64 (and I did not tried to force them somehow). Seems I can reset the spi, but I cannot flash it with the SD image for rockpro64.
Will try again later this weekend.
Enviado desde mi NX659J mediante Tapatalk
|
