S20 Ultra Bootloader Unlock
Casio Bauman
First I tried using the community rolling release, and then building it myself from source code. In every case, it was failing to boot; on the HDMI console it was hanging at the stage where the initrd was attempting to scan for the root partition. ("Scanning for btrfs filesystems")
Taking a closer look at the verbose output of the UART console during a boot attempt, I saw that there was an error message about the sunxi-mmc device driver experiencing a failure while it was enumerating the EMMC chip:
On a hunch, I patched the device tree to disable that interface. After compiling that change and installing a new image on a microSD card, the board booted flawlessly, and I am now in a working desktop environment.
This leads me to a question: How likely is it that there's just some damaged/defect on my particular board which makes its EMMC unusable? (In which case I might stop here, and be satisfied with the result: Because, I'm not particularly interested in working with the EMMC chip anyway.)
Or, it is possible that there's a systemic problem with the Banana Pi M2 Ultra device tree which would be equally impacting everyone's ability to boot? (In which case it might be worthwhile to dig a little deeper, try to figure out why the kernel is hanging when it attempts to enumerate the EMMC chip, and perhaps submit a patch to fix the problem.)
Follow-up: Given the fact that Linux was able to detect the presence of the eMMC chip at all, and that it was able to correctly identify the capacity, I figured that it was at least able to get rudimentary communication up and running. Since every MMC always starts up in SDR 1-bit mode by default, and then the host has the option to interrogate the chip for the possibility to negotiate a higher bus width and/or clock mode, I figured I'd try carefully re-introducing the interface with more limited capabilities.
Looking at the voltage rail fan-out in the schematic, it's pretty clear that it's physically impossible to power the eMMC's I/O bus at anything other than 3.3V, and so HS200 and HS400 are definitively off the table.
But the device tree bindings for sunxi-mmc don't seem to provide very much configuration to take away modes which I know cannot be supported. Really just the bus width. So, since it was apparent that Linux must have successfully connected to the eMMC in a 1-bit mode before, I tried re-enabling the eMMC interface, but limiting its bus width to 1 bit. At least that would eliminate the unsupportable HS200 and HS400 as possibilities; they cannot operate on a data bus narrower than 4 bits.
Ideally, I would like to try out each of these combinations in isolation so I can figure out where things are breaking. But it looks like this might be the sort of thing that I will not be able to configure using a patched dts alone - I might need to actually dig into the kernel sources themselves.
I have a suspicion that the problem with the current image is probably limited to rev 1.1 boards based on the A40i SoC - it's entirely possible that the older rev 1 boards with an R40 SoC aren't having any problems at all.
If that's the case, then the changes I have proposed should be backward compatible with both older and newer boards, however it would come at the expense of a significant eMMC slowdown for users of the older boards. I'm not sure if the project admins would be willing to accept a pull request which would involve that level of compromise.
By the same token, a PR could also convert the stock image to a 1-bit bus, and an optional dtbo could be supplied to allow people to increase the bus back to 8-bits if they know their hardware is capable of it.
Note: I linked both the dtbo binary, and the dts source code which created it. Only the dtbo file is needed for a quick test; if you wish you could compile the dts file from source code and prove that my work is reproducible.
I tried quick test with dtbo file you provided and it works. This is the first time I have this board up and running. It would be great if you changes could somehow be included in future images provided for download.
Unfortunately, on another forum some other people have reported failure when they tried using my proposed fix. So although it's working for some people, it doesn't seem to be sufficient to fix everyone's problems. I'm hesitant to proceed with a pull request armed with these mixed results.
I'm afraid I have taken it as far as I can with the equipment I have: My own hardware is now working fine, and whatever problems other people are having must be due to a different root cause. Since I am not having that problem (whatever it is), there's no way for me to even begin to try to fix it.
@Super8film do you have a USB-TTL serial cable? If so, then maybe you could hook it up (serial terminal settings for this board are 8N1-57600 bps) and try to capture a verbose log of what the bootloader and kernel init process have to say while the board is booting? That might provide some evidence that could be used to try to solve your problem too.
If it helps at all to narrow down where the issue comes from: The current (and some earlier) minimal image of armbian worked for me initally, but after installing and updating some packages (including a rebuild of initramfs), I consistently ran into the freeze at "Scanning for btrfs filesystems".
I used "R4toR6_6.9.5.bin" and "R4toR6_Prep_Addon.bin". The upgrade started with no issues although displayed an "unable to extract image" error message on the ReadyNAS console during the upgrade. This error did not seem to affect the upgrade process. The upgrade finished, I was able to log in, created admin and user accounts, set up a single 6-disk X-RAID Volume, shares, assigned permissions, and played around with various settings and services. Rebooted ReadNAS several times just to be sure. No issues.
Once I got familiar with the new OS6 interface and services, I reset the ReadyNAS to factory (OS6) defaults, then set up ReadyNAS for production use. The Volume started re-syncing, and I started a lengthy (18TB) data copy process.
At about 2TB copy mark, ReadyNAS froze. I could not "find" it using RAIDar, could not ping it. The unit was unresponsive to the Power button push. The display was frozen showing the ReadyNAS IP address. Without much thought, I powered down the unit and restarted it in a few seconds.
The bottom line: the system is stuck at ReadyNAS screen, does not boot, runs all fans in high rmps, and does not allow for me to get to the bootloader menu. The indicator (front panel) light comes on after a few seconds when you turn on the unit and stays on solid green. The system is responsive to the front (soft) Power button: it turns off the unit.
Most power supply testers do no test the supply under load and, therefore, do not provide a very comprehensive test. If you have a standard ATX12V supply, you can connect it externally as a better check of whether it's a power supply issue.
As for the memory test, yes, I recall seeing this option under the Boot Menu, but I can't get to the Boot Menu. When I press and hold the reset button and either turn the power switch on or press the front panel power button, ReadyNAS does not pass by the ReadyNAS screen (see the picture I posted). I've tried this with and without all disks installed. Same thing: can't get to the Boot Menu.
If you can't get to the boot menu, Flash corruption is a possibility. USB recovery for a legacy unit converted to OS6 requires that you create an OS4.2.x style recovery media but with the OS6 image file or that you recover to OS4.2.x (using a spare drive) and then convert again to OS6. Unfortunately, with that level of flash corruption, your VPD file may also be corrupt, which only Netgear can repair.
Of course, there are also a lot of non-repairable things it can be. The display will say "ReadyNAS" with just 5V present -- the NAS doesn't even have to try to boot. Adding a VGA cable to the internal VGA header can help in further diagnosis.
That's the location for the Pro6 and Ultra 6 Plus. It looks the same, but is in another location, on the Ultra 6. The title of the thread is confusing, because it says Ultra 6 but gives the part number for an Ultra 6 Plus.
I believe the MBR H error indicates a corrupted flash. Unfortunately, that is not something I know how to fix. But a USB recovery might work. Note you need to use the recovery setup for OS 4.2 systems.
As far as memory goes, I've been recommending that people upgrade to at least 2 GB of RAM before converting to OS-6 for quite a while now. The Ultra 6 Plus (which is what you have) can handle some 4 GB modules (so 2x4GB is the max). But compatible modules are hard to find, and generally quite expensive. So I normally recommend 2x2GB for the Ultra 6 Plus and the Pro 6.
USB recovery is not a means to upgrade, it's a means to recover -- normally to the same version OS that you've been using. I don't know where you saw any caution about downgrading from OS6 back to OS4.2.x on a legacy machine, but there is no issue doing so. Of course, just as with the upgrade, you have to factory default to re-use the drives. So, maybe something you don't want to do using your actual volume.
You have to create an OS4.2.x style USB recovery, but use an OS6 file. The one you used to originally convert would work fine. But this is something else you might want to do with a scratch drive volume, not your main one. Then you can update back to the one you are currently running before you re-install your normal drives.
Are you seeing it stop after loading initrd.gz in normal boot or support mode? Support mode on your NAS will have an OS4.2.x base, and OS4.2.x doesn't normally have any display on the console after that, so it may be normal for support mode. But another reason it can stop there is lack of proper identification that it's running on genuine Netgear hardware, which is via the VPD file on legacy machines. While that's in flash as well, USB recovery can't restore it. The mods here will usually help you, so long as you can get the unit into support mode so they can access it.
c80f0f1006