I finally received my Turing Pi 2 yesterday, and the BMC was running fine along with a CM4 node. However, today it wouldn't boot. I used the BMC UART to get a serial console, which shows lots of error messages, culminating in a message stating that it's unable to mount root fs on unknown block. Note that I haven't tried to change or update the BMC firmware. Is my Turing Pi 2 somehow defective and should I do an RMA?

Go here https://github.com/wenyi0421/turing-pi/releases/tag/v1.0.0 and flash an SD card with the recovery image then reflash your BMC this way

Thanks @DhanOS! Those instructions assume that I can just run the Phoenix Suit tool, but I don't have a Windows machine. I've tried running it under Wine, but it fails. I'm now in the process of trying it out under Virtualbox. I'll keep you posted... 😅

You might have a success with VMWare Player (free). This usually works best and is mentioned as a software to let people flash Jetson modules when they're not on ubuntu 🙂

I've finally managed to get my hands on a Windows machine, but unfortunately I haven't managed to get Phoenixsuit to work yet. Here are the steps I followed: 1. I downloaded Phoenixsuit v.1.10 from androidmtk.com. 2. I downloaded

turingpi_recovery-sdcard.zip

, unzipped the file and used

dd

to copy the

img

onto an SD card. This SD card was inserted in the slot on the back of the Turing Pi. 3. I also downloaded the latest version of the Turing Pi firmware (

turingpi-1.0.1.img

) for later usage (step 8). 4. I connected the Turing Pi's Micro USB OTG to the PC running Windows. 5. I started Phoenixsuit by running the

PhoenixSuit.exe

. 6. I turned on the Turing Pi. 7. After a while, the "No device connected" message changed to "Device connected". 8. In the "Firmware" tab I selected the firmware file previously downloaded (

turingpi-1.0.1.img

) and said "Yes" do the dialog box asking for confirmation. 9. After just a couple of seconds, the "Device connected" changes to " Device not connected"! ☹️

Can I send you v1.15 that I know should work?

Sure, thanks!

If this situation will continue with 1.15, I'll try to find out what might be a cause but it's weekend so this will take probably up to even like Monday

I appreciate the help, but I don't understand how a different version will make any difference. I mean, the process fails immediately when I try to upload a new firmware.

The difference is 1.10 might not "know" about T113-S3 maybe

Ah, you mean version 1.15 of Phoenixsuit!

Yes

(I thought you were talking about a newer version of the firmware...)

Ah, no, this would not help in this case 🙂

Which version of Windows should I berunning, btw? I am trying with Windows 10 (the one I managed to get a hold of), but I suspect it may not be compatible. When I tell Windows Device Manager to install the drivers in the

Usbdriver

directory, it does complain that the drivers are not compatible with this version of Windows...

I believe it should work under Windows 10

the PhoenixSuit 1.10 is capable of flashing the T113-S3 on the TPI2.

I did briefly try LiveSuit, but also gave up upon running into problems and noticing the project hasn't seen any love for many many years.

I'am not a Windows user either... I run PhoenixSuit.exe directly. I had the Device Manager open for manually installing drivers for unrecognized devices. A driver for the "Android config ffs gadget" was not needed, but for the devices that appeared later. I installed the AW_driver from the drivers sub directory, assuming that you have the same dubios ZIP from somewhere, which I scanned for Malware first ;). The drivers are not signed, Windows might complain but at least runs. I run it an VM and hat du add some rules to VirtualBox for the USB Device passtrough.

Seems like the same problem I ran into and haven’t solved yet. Restarting windows to allow unsigned drivers was the only way I could get pheonixtools to start, but was never able to boot from the recovery image on the Sd card so it was a moot point

The point is not booting the recovery image from SD card. But flashing the Image to the whole flash, including partitions and other data relevant for boot.

I could be wrong but I presumed you need a software layer to expose the nand for flashing via the usb interface, since the image on the nand is obviously crashing the recovery image was necessary. So yes the point is booting an image that has the capability of exposing the nand for flashing.

I'm happy to report that I finally got it to work! I ended up doing a clean installation of Windows 11 running natively. I had tried running Windows 11 under Virtualbox and using the USB passthrough trick, but the because the device changes its identification when the flashing begins, the connection was always dropped.

That’s great news. Can you confirm you used the recovery image and PheonixTools 1.10?

I used the recovery image and PhoenixSuit 1.15 (thanks @DhanOS!). I should note that even under Windows 11 running natively it was failing at first. I explicitly uninstalled the built-in Windows drivers and told Windows to install the ones under the

Usbdriver

folder. However, I'm not sure if this was really necessary or just coincidental... 🙃

if you have an serial console cable attached you can put the BMC into a state to flash via livesuit without a booted image. You need: * to interrupt the uboot boot process * run

efex

on the Uboot console

Yes, I figured it ought to be possible to tweak Virtualbox's USB passthrough rules, but that option was not immediately obvious in the settings, and since I had an extra hard drive lying around I figured I could also just install Windows natively... 😅

what is the keyboard sequence to interrupt uboot? Neither ESC nor ^C appear to work

Just out of curiosity: you haven't never flashed an .img before? It had the same issue, but have noted the observation that I could not enter UBoot's console. It worked after I flashed my own image. If thats the case I have no clue 🤷

I had initially updated to 1.0.1 via OTA which worked for a couple days before the crashes started.

I suspect there isn't one - but I hope I'm wrong about that. I work around it by just reflashing an envimage that removes the

run boot_normal

which gets me a U-Boot prompt on every boot, then reflash the envimage back when I don't need U-Boot anymore.

Okay that supports my observation, maybe the uboot or the uboot env from the flashed versions are different from what has been shipped for some/all? models? A dump of an untinkered uboot+env might bring light into this? But unfortunatly that might help others later if documented.