U-Boot with direct NVMe boot support for eMMC/SPI Flash

[Wizzard]

No, the details are in the opening post of this very same thread.

Okay, so now we just have to check it we also need to wipe those boot partitions from eMMC.

[Wizzard]

I tried it but this is the output:

dd: writing to '/dev/mtd0': No space left on device
8129+0 records in
8128+0 records out
4161536 bytes (4.2 MB, 4.0 MiB) copied, 12.889 s, 323 kB/s

I see in lsblk there is no mtd0 device, just this:

mtdblock0     31:0    0     4M  0 disk
mtdblock1     31:1    0    32K  0 disk
mtdblock2     31:2    0   256K  0 disk

So I am a little afraid to reboot now

---

I tried to PM, but you have the PMs disabled, so I think I can reply here:

SPI flash is not supposed to show up in lsblk because it's not a block device.
Which Linux distribution did you use to flash the image? You should've checked the target before doing any writes.
Execute `dmesg | grep spi` and make sure spi-nor module was loaded correctly. There should be something along these lines:

Code:

spi-nor spi0.0: gd25q128 (16384 Kbytes)

Try to read the image back from /dev/mtd0 and check its contents.
If they represent the first 4 Mbytes of spiflash.bin and spi-nor was loaded properly, you can try to erase the contents by executing

Code:

flash_erase /dev/mtd0 0 0

Don't do this unless you're sure that /dev/mtd0 is indeed an SPI flash.

Thanks, but it seems it is late for me, I rebooted already and PBP does not start now. I used Ubuntu Mate distro.
I just tried cat /dev/mtd0 and the result was empty.
I also found some 16 MB device in lsblk, but as you said, it should not be SPI flash.
I know, it is just my fault, so I will try something with the SD cards now. I made those steps to clean those booting code from SD card but still does not boot. I guess I cannot just replace the SPi flash because it is a part of PCB, right?

[tgrauss]

It is possible, but you have to unsolder the NOR flash.
I did this in the past on a board to change a sound codec.
You then have to solder a new NOR flash if you want to try to flash u-boot again on it.
To unsolder such chip, the best is to use a knife first to cut the feets, then remove them with the iron.
Use a lot of flux and copper braid.
You should train yourself to solder and unsolder SMD on old broken electronics.

[bcnaz]

Just a thought :
The 'legs' look fairly long in the wiki pictures.
Would it be possible to cut the legs close to the chip itself ? and solder your new chip to the existing 'legs' ? ?
MAY be ugly, but a bit easier..? AS I said, Just a Thought or Question.

[ElektromAn]

FWIW
http://opensource.rock-chips.com/wiki_Rockusb

Maskrom mode

If there is no bootable firmware found on board, the SoC will run Rockusb driver automatically, we call it Bootrom mode or Maskrom mode.

If firmware is at somewhere of the board, in order to get into this mode, we can do something to prevent cpu read the firmware successful:

   for SD-card, unplug the SD-card;
   for eMMC, short the eMMC clock to GND;
   for NAND, short the data line or clock line;
   for SPI, short the spi signal to GND;
   By "reboot bootrom" command in U-Boot and Kernel, WIP.
   erase bootable region with non-bootable data in eMMC or other media devices

ayufan has some descrition for rock64
https://github.com/ayufan-rock64/linux-b...ash-spi.md
should be (almost ?) same with pinebookpro not tested and not wrapped my mind around this

currently reading/following/whatever the whole thread
anyway of this
u-boot supports boot script, so it's possible to check for a bootable device/partition/network

I don't know if u-boot can use/supports a watchdog as barebox does
It's a nice feature

You should check the partition size first

[Wizzard]

I solved that by flashing SPI directly from rkdeveloptool, thank to @pcm720 .

It boots after I cleaned all the boot code from my eMMC, so will try my SD cards later.

[pcm720]

I tried it but this is the output:

dd: writing to '/dev/mtd0': No space left on device
8129+0 records in
8128+0 records out
4161536 bytes (4.2 MB, 4.0 MiB) copied, 12.889 s, 323 kB/s

I see in lsblk there is no mtd0 device, just this:

mtdblock0     31:0    0     4M  0 disk
mtdblock1     31:1    0    32K  0 disk
mtdblock2     31:2    0   256K  0 disk

So I am a little afraid to reboot now

@Wizzard was able to fix incomplete SPI flash using Rockchip's rkdeveloptool.
Since the first 4 Mbytes of SPI image contain only DDR initialization and SPI bootcode, device got stuck in Loader mode.
Connecting it with USB-C cable to PC and executing the following was enough to fix it:

Code:

rkdeveloptool wl 0 /path/to/spiflash.bin

[Wizzard]

I am not sure if it is related, but I am seeing the errors like this when booting and in dmesg since yesterday:

Code:

rockchip-dmc dmc: Get wrong frequency, Request 800000000, Current 856000000

[pcm720]

I am not sure if it is related, but I am seeing the errors like this when booting and in dmesg since yesterday:

Code:

rockchip-dmc dmc: Get wrong frequency, Request 800000000, Current 856000000

rockchip-dmc is Dynamic Memory Controller driver that dynamically adjusts DRAM frequency:
http://archive.lwn.net:8080/devicetree/2...ora.com/t/
There are probably some incompatibilities between the current Trusted Firmware and kernel your distro is using: it's pretty clear that rockchip-dmc can't set the frequency it wants.
I guess you can try building your own SPI image with different ATF binary (e.g. the one used in stock U-Boot) and see if that fixes these errors.

[Wizzard]

Building is not for me, but I would like to know if I am the only one with this issue and if someone alse also tried this new SPI flash.

If it is only warning, it is not a big problem for me.