MASKROM: USB3 (type-A to type-A) needed?

[eselarm]

On my NanoPi-R6C I have been doing several U-boot updates (writes with dd to areas in 1st 32k) and so far so good. But behavior has changed w.r.t. eMMC v.s. SD-card.

I want to do some U-boot build config changes, so the risk it that something might go wrong and I would need USB MASKROM mode to do writes to eMMC I think.

The NanoPi-R6C wiki is not very clear with 'connect USB', but it turn out that  this should be a connection via type-A to type-A and it does not work in the USB2 port.

 

I have a USB2-only type-A to type-A cable and used that.

The NanoPi-R6C appears in the USB device list ('lsusb') and also the tool is seeing the device:

/tmp/upgrade_tool_v2.30_for_linux/upgrade_tool LD
Using /tmp/upgrade_tool_v2.30_for_linux/config.ini
List of rockusb connected(1)
DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=12     Mode=Maskrom    SerialNo=

However, as soon as I want to read blocks from eMMC for example or try any other commands, connection is lost.

 

Now I think that maybe for actual data transfer, USB3 wires in the cable are needed, so the question is: Will it work when I buy/use an USB3 type-A to type-A cable?

 

Edited November 14 by eselarm

[Dantes]

I think you lose the connection because the kernel is loaded. I do not use the friendly elec tools. I just boot from an OpenWRT image.

• Get a USB-A to USB-C cable
• Connect USB-A to PC
• Connect USB-C to DEBUG port
• Use screen to connect to the NanoPi: (you might need sudo)

  screen /dev/ttyUSB0 1500000

• Get OpenWRT NanoPi-r6c image and write to sdcard
• Boot from sdcard with maskrom
• then you can use scp to transfer files
• and dd to write/erase/backup

I think I did something similar here:

 

[specs]

@dantes

"You might need sudo" generally means "if you regularly use a serial console or maskrom connection you will want to configure user permissions for /dev/ttyusbX" (i.e. adding the user to the "dialout" group).

Back when modems were still frequently used adding a user to dialout might have been a serious problem.

 

I think nowadays using sudo for pretty much anything is the greater risk.

[eselarm]

@DantesWhen I still had the original 2017 U-boot on the eMMC (from the OpenWRT that came pre-installed), inserting an SD-card with some recent Armbian image booted always from the SD-card. So in serial/debug console I had full control of the eMMC (and also an NVME in the M.2 slot). So that is also how I recently wrote a new/latest 2024 U-boot from the current-branch Armbian to the eMMC with dd.

But that 2024 U-boot is more flexible and I needed quite some time to and figure out what was what (after stop autoboot prompt):

1 - SD-card with a known good simple basic Armbian Bookworm

2 - eMMC where the custom kernel did not work

3 - NVME with an EFI boot partition with grub.efi and some variant of openSUSE and some Debian flavor

After reading U-boot command docs like 'bootflow', I somehow booted from NMVE. Fine but I want also operation with no NVME in the M.2 slot inserted.

So eMMC and SD-card can be selected in U-boot but was a bit guessing as I had to rely on some addresses, so 3rd try or so I started the good simple basic Armbian Bookworm from SD-card and from there I could put a working kernel Image/uInitrd/DTB on the eMMC again.

 

But what will happen if the somehow the U-boot on eMMC is corrupt? That has not happened, but when it would, will it then always somehow re-init and try SD-card? That is my point, that is why I thought I should also get to know USB loading, like I know from Android smartphones with fastboot tool.

 

But you state: "Boot from sdcard with maskrom", that I had not thought of. Does that skip eMMC always?

 

And scp? You mean the ethernet port(s) is/are up and running then? Or something over serial cable downloading what is known from simple old processor boards?

 

[eselarm]

I have done a bit more trial-error and it turns out that the USB port where the A-A cable is inserted won't initialize/open. I can see that via strace and also upgrade_tool creates a log file in a hardcoded filefolderpath /root/upgrade_tool/log/

 

It looks like I need to buy an USB3 A-A cable if I want to know more. What for sure is not working is pressing maskrom button and hoping that the R6C boots from SD-card. When I don't press the maskrom button, so normal power on, then the "U-Boot 2024.10-armbian-2024.10-Sf919-Pbdc8-H3f52-V1bfa-Bda0a-R448a-dirty (Oct 22 2024 - 11:19:49 +0000)" also prints:

 

rockchip_dnl_key_pressed: no saradc device found

 

That is some sign to me although I vaguely know/guess that there is no DC level voltage detected indication what to do. Or more likely that the driver for SARADC is missing.

Anyway, I can stop via keypress at autoboot via serial console and then do:

=> bootflow scan
[...]
=> bootflow list
Showing all bootflows
Seq  Method       State   Uclass    Part  Name                      Filename
---  -----------  ------  --------  ----  ------------------------  ----------------
 0  efi_mgr      ready   (none)       0  <NULL>                     
 1  script       ready   mmc          1  mmc@fe2e0000.bootdev.part /boot.scr
 2  script       ready   mmc          1  mmc@fe2c0000.bootdev.part /boot/boot.scr
 3  efi          ready   nvme         1  nvme#0.blk#1.bootdev.part /EFI/BOOT/BOOTAA64.EFI
---  -----------  ------  --------  ----  ------------------------  ----------------
(4 bootflows, 4 valid)

So this is with valid IP-address, SD-card with older know to work minimal Armbian Bookworm, eMMC with 1st FAT boot, NVME with openSUSE and a handful others.

 

Number 0 is not clear to me, likely this is when there is some real UEFI somewhere in MTD or so like on x86 PCs.

From number 1 and 2 I have to guess what is SD-card and eMMC, but that is do-able.

 

I am not sure where the loaded U-boot comes from. I have to write an own/other one on eMMC I think, and just make sure I know the version already from the file written with dd, not only from the bootlog via serial console.

[specs]

Don't you have a computer with a free USB-C port?

Then you just can use a standard USB-A to USB-C cable. Most  recent laptops use USB-C for power (USB PD) which also can be used for a serial console (although for long session you might need a USB-C docking station).

 

The T6 is a little easier than the R6C, since it provides both the serial console and the maskrom connection over USB-C, meaning either a USB-A to USB-C is needed or USB-C to USB-C.

 

For EFI you could try:

https://github.com/edk2-porting/edk2-rk3588

But my guess is that it a lot of work to provide a different way of booting from u-boot. It might be a improvement, but then again it might not.

[eselarm]

Shame on me that I don't have a USB-A to USB-C cable. Only USB-C to USB-C (including powermeasuring in connector). Also have several USB3-A to microUSB3 for Samsung phone debugging (S5). Because the S5 needs USB3 for ADB, I think the same is for Rockchips which also are main business case Android I think.

 

My NanoPi-R6C is promoted to 'production' so must run 24/7 UPS connected. I am looking to buy some other Rockchip based board so I have an option to play with 2-storage device/rootfs issues. I have an RK3066 (in MK808 Android stick) but that is stuck at Debian7 more or less and 32-bit. Maskrom works as expected there with USB2-A to mini-USB2 cable. I can read/write ranges from its 8GB MTDblock, so including some Linux kernel 3.0.36.

 

The EDK2 UEFI RK3588 I know and tried, but it hides the eMMC, so only NVME is usable (with standard ARM64 UEFI kernels). Also no option if you want HW accelerated Wayland/X11/DRM/GUI. Modern U-boot can do/emulate EFI as well, so together with matching Linux kernel DTB that is a better option.

 

The U-boot in my NanoPi-R6C in eMMC is now '2024.10-armbian-2024.10-Sf919-P485c-H3f52-V1bfa-Bda0a-R448a', verified that it comes from eMMC. Which also means I don't have a method to boot from SD-card, unless a watchdog or so would try SD-card in case eMMC boot area would be corrupted with random data. All zeros in eMMC would result in boot from SD-card I think. This is something different from the 2017 U-boot from OpenWRT pre-installed. So the worry is still there that I currently don't have an un-brick method I think, so will order some cable types that are needed.