I am trying to reload my old TK1, I go through all the steps and nvflash does seem to flash the board, but we don’t come back to life.
when I check the network, the TK1 has acquired an address but is asking for a file called C0A8021A.img via from my network.
and there we seem to have stopped.
I am working with R21.7.0 or trying to.
Clearly, I have done something very wrong 50th times in a row, does any happen to know what it is.
Nick
It sounds like boot is falling back to attempting network boot. This would happen if eMMC were unreadable and no USB or SATA media were found. I don’t know what that file is, but there are some possibilities which can be caused by the flash host. Can you describe the host closer? From the exact location where you ran the flash, what do you get from “df -H -T .” (the “.” is important)?
Examples are live DVD distributions might not use ext4 file systems…this can cause a non-ext4 partition and U-Boot needs this. Another example is that a few Linux distributions (not many) enable 64-bit ext4 extensions, and although Linux works great with those U-Boot cannot. These would result in an inability read the rootfs partition despite good hardware and a seemingly successful flash, followed by falling back to other boot sources and eventually attempting a network boot.
I managed to trace the problem to a host version issue, running Ubuntu 18, flashing consistently failed, however, everything works with 16. From what I can glean it was a looper issue. using the same host machine, reloading R16 and the flashing worked, then doing an upgrade to Ubuntu 18, and the exact same procedure failed, rinse and repeat. The upshot is I am up and running, thank you for the responses.
I did notice that flash.sh does not like spaces in its absolute path name,
Older but no wiser.
Nick
Yes, the space in path is one of flash.sh’s weaknesses. There have also been reports of non-English character sets being an issue in the path to where JetPack runs.