V8.13.2 on Odroid c1 no longer sees USB drives to be mounted

ok let’s go > apt upgrade :smiley:

apt upgrade is done.
rebooted device.
failed to boot with USB drive attached.
unplugged and plugged back in, still no boot.
removed USB drive and rebooted, and got prompt
login and launch drive manager ok
attach USB drive and refresh drive manager, no USB drive found

ok so it is the latest Armbian kernel as expected…

I recall some issues with some systems where a reboot was not possible while a USB drive is attached. But not 100% which SBC it was. Ah it was the C2 Odroid C2 Does not Detect/Power USB devices · Issue #5963 · MichaIng/DietPi · GitHub

Ok asking Armbian for support would be an option but don’t tell them you are using DietPi. They are not our friends. :roll_eyes:

Can you test with an original Armbian Bullseye image on your C1/C1+ ? how does this behave?

I don’t have any armbian images but I can go get one and try it to see what happens. then at least if it is doing it I can point that out to armbian without any dietpi influence.

yes, otherwise you will receive just blame from Igor (Armbian developer)

no C1 or C1+ listed on armbian, just C2 and up. looking at the C1 wiki, i don’t see anyone with armbian except for Armbian Ubuntu Xenial Docker
so it looks like I may be out of luck

@MichaIng could you assist pls

i found an archive link but nothing is newer than 2021.
i also found this, which is greek to me but maybe you understand what he’s saying

Posted August 16, 2021 (edited)

would like to add my two cents. I have read this thread after installing Armbian 21.02.3 Focal with Linux 5.10.21-meson and running into some USB related issues - USB hard drive was not detected.

But contrary to what image description states - eMMC works. My odroid-c1 device contains root filesystem on eMMC. I have not noticed any issues related to eMMC support.

About USB issue - it turns out there is a workaround I found it on some kernel dev mailing linst - adding

usbcore.autosuspend=-1

to kernel boot arguments makes USB fully functional. At least I have not yet run into any issues.

this would fit to the solution the user describe with his C2 Odroid C2 Does not Detect/Power USB devices · Issue #5963 · MichaIng/DietPi · GitHub

extraargs=net.ifnames=0 usbcore.autosuspend=-1 in /boot/dietpiEnv.txt

ok, so i’ll boot up the C1 again, add in the argument to the dietpienv.txt file and restart and see if it makes it work.

and either i’m doing it wrong or this is not the fix.
there was no dietpiEnv.txt file so I created it. then added the line
extraargs=net.ifnames=0 usbcore.autosuspend=-1
and saved it.

no effect

let’s wait on @MichaIng he knows what the image is based on.

okie dokie. i’m easy.

thanks for the help so far.

Please add the setting to /boot/armbianEnv.txt. You have an older image which does not have our own boot config file(s) yet, but otherwise it works just the same.

We fixed it with DietPi v8.12 by running:

sed -i 's/coherent_pool=2M/coherent_pool=2M usbcore.autosuspend=-1/' /boot/boot.cmd

But I guess this has no effect for the older images since your /boot/boot.cmd does not contain coherent_pool=2M, right?

grep -q 'coherent_pool' /boot/boot.cmd

So we’d need to redo the patch for older images, to have the fix applied.

okay so work and such had gotten in the way of following up here. I just downloaded the latest C1 DietPi image (dated 2-13-23) and flashed it to two different cards, neither boot up on a C1+. i flashed one card with an older image (7.7.3) and it booted just fine. so i let it run through the automated setup and upgrade to 8.14.2.

i then tested it with a USB drive and it was not found.
I added the arnbianEnv.txt file with “extraargs=net.ifnames=0 usbcore.autosuspend=-1 in /boot/dietpiEnv.txt”

the sed and grep commands both gave errors as there is no /boot/boot.cmd file

i’ll admit, I’m lost.

i just tried to use the latest C1 image on a C1 (not plus) and same problem, no boot.
it powers on, but the heartbeat light stays solid.

i used the wayback machine and downloaded a C1 image from 11/2/22 (file date10-23-22).
flashed that and no boot same as the later version, on the C1 or the C1+.
I don’t get it. i can flash the cards with real old versions of DietPi and they boot, update and then the USB drive doesn’t work…but I can’t get a recent image to even boot.
one more try with the latest version image and i’m powering it up and walking away. i’ll check it in an hour.

after an hour…still nothing.
flashed card with dietpi backup of 8.11.2 and it boots fine, USB works fine.
once updated to 8.14.2 the USB doesn’t work again
I tried adding the string to the dietpiEnv.txt and adding the other arguments “coherent_pool=2M usbcore.autosuspend=-1” to the boot.ini (not boot.cmd) and with everything in… after a long reboot, i have access to USB drive on the C1 with 8.14.2 running. finally some headway.
so now I guess I need to make a backup of this card to flash the others with.

give time to @MichaIng to be able to have a look to your challange.

Oh, I mixed it up with Odroid C2. On Odroid C1 there never was an issue with USB drives (reported). You can remove /boot/armbianEnv.txt, /boot/dietpiEnv.txt, /boot/boot.cmd again, if existing, since the Odroid C1 bootloader uses /boot/boot.ini only.

Generally, do not create config files in /boot. If they do not exist in the first place, they are not used :wink:.

Can you try this instead:

sed -i '/^setenv bootargs/s/"$/ usbcore.autosuspend=-1"/' /boot/boot.ini

You say our latest C1 image does not boot on your C1 and C1+? Since they have no display output (right?), how do you know that? You do not have a UART adapter to check boot logs on serial console, do you?

The working image, of you are fine with potentially breaking it as well, could you try to flash the latest U-Boot binary and see whether it still boots?

source /usr/lib/u-boot/platform_install.sh
write_uboot_platform "$DIR" /dev/mmcblk0

Since the bootloader package, and after kernel upgrade as well the kernel patches are exactly the same, both images have a dedicated FAT boot partition, all needed files are in place and correctly referenced in configs, so I wonder what the difference is that it is possible that one image boots and the other not :thinking:.