BMC kernel panics on boot: Unable to mount root fs...
# │forum
d
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?
d
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
Let's see if this works
Do you have a log you can share?
d
Thanks @DhanOS (Daniel Kukiela)! 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... 😅
d
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 🙂
d
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"! ☹️
Anyway, I'm at a loss about how to proceed. I should mention that the BMC instructions mention that the drivers present in the
Usbdrivers
folder should also be installed. However, this folder does not exist in the version of Phoenixsuit I downloaded. Also, there are a bunch of other executables in the Phoenixsuit directory which don't seem to do anything.
d
Can I send you v1.15 that I know should work?
I'll DM you it
d
Sure, thanks!
d
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
d
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.
d
The difference is 1.10 might not "know" about T113-S3 maybe
Also, I've seen more weirdness with different stuff from China
d
Ah, you mean version 1.15 of Phoenixsuit!
d
Yes
Sorry if I was not clear
d
(I thought you were talking about a newer version of the firmware...)
d
Ah, no, this would not help in this case 🙂
Different cable, as you mentioned in #754950670175436848 is also a good idea as well as trying to use different USB port. If you happen to have USB 2.0 port on the machine, try to use it instead too
One more thing - can you attach the UART cable and monitor the flashing process? I believe you might find something there too when it disconnects.
d
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...
All of this would be so much easier if Allwinner had tools for Linux... 😫
d
I believe it should work under Windows 10
I'm not sure why the drivers might cause this issue
j
the PhoenixSuit 1.10 is capable of flashing the T113-S3 on the TPI2.
Maybe I missed it, are you running that Windows installation nativly or in an VM?
If running in eg. an VirtualBox VM, dedicated automated USB rules for that VM might be needed. Windows 10 worked fine for me.
There exists LiveSuit, unfortunatly I did not got LiveSuit 1.10 running under linux. The DKMS modules awusb/awdev builds after some adaptions to newer kernels, but it does not load 😦
d
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 running Windows 10 natively, but this is a borrowed computer and I'm not sure how trustworthy the installation is. 😅
@j0jux Did you just run the
PhoenixSuit.exe
executable or did you run one of the many executables in the
Phoenixsuit
folder before hand? The instructions mention something about installing USB drivers, but I don't know what exactly they mean by that (I am not a Windows user).
j
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.
k
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
j
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.
k
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.
d
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.
k
That’s great news. Can you confirm you used the recovery image and PheonixTools 1.10?
d
I used the recovery image and PhoenixSuit 1.15 (thanks @DhanOS (Daniel Kukiela)!). 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... 🙃
j
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
Note: the USB passthroug rules can be tweaked, because the usb device id, changes but not the vendor id. So a adaption of the correspondig rule is enough to get the process running on a Windows VM running in VirtualBox
d
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... 😅
k
what is the keyboard sequence to interrupt uboot? Neither ESC nor ^C appear to work
j
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 🤷
k
I had initially updated to 1.0.1 via OTA which worked for a couple days before the crashes started.
c
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.
j
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.
2 Views