I tried to flash the system.img into the NVME instead of the eMMC.
The flashing process fails because of a timeout. it says: “Waiting for target to boot-up”.
Why this is happen and how I can fix this issue?
I noticed that during the flashing process it seems like the main script calls the bootloader several times and try to recreate the system.img several times (I can see it in the log). Does it suppose to be like that?
NVME_flash.log (182.3 KB)
Are you running this on your custom board or devkit?
Does your custom board have micro usb working fine?
Initrd flash requires to use the usb device mode created by your micro usb port. If that does not work on custom board, then it won’t support.
Yes it does. I use it all the time with flash.sh
No, I think you didn’t get it.
My point is initrd flash requires micro usb port to work as device mode in kernel. Flash.sh does not care about anything happened in kernel, but initrd flash needs. The mechanism of them are different.
Initrd flash is actually booting into initrd and then flash, thus, it depends on the otg function of kernel to work first.
If you don’t know usb terms, please just ignore them.
This is just first step thing to check, not guarantee it would 100% work for a custom board afterwards.
Please check, If you boot up the OS, connect the micro usb port to you host, is your host side able to see it as 192.168.55.100? and lsusb shall see it.
Could you check them first?
If you can see them, then we need to check the xml file you wrote.
If the target is on “regular” mode , my host doesn’t list it in lsusb.
If the target is on “recovery” mode , my host does list it in lsusb.
lsusb.log (1.7 KB)
Did you ever make any patch to enable usb otg on your board?
Is that board made by you or some other board vendor?
Then please contact with the board vendor for the usb device mode functionality.
The technical term is to enable usb otg on my board?
and then I’ll see my target(in “regular” mode) listed in lsusb command on my host?
Thank you. I’ll check it and update