When testing out the flashing of the beaglebones, I noticed that sometimes the flashing would fail - when taking a closer look, I could see that in the case of a failed flashing, the procedure took < 1min, and when it was successful, the internal flashing took closer to 2+ mins.
Looking at the journal logs for the testbot, I could see momentary drops of the ethernet carrier signal used to detect a power off event. For example:
Feb 22 17:04:56 a0e25d2 kernel: r8152 1-1.5:1.0 eth1: carrier off
Feb 22 17:04:59 a0e25d2 NetworkManager[1583]: <info> [1645549499.4424] device (eth1): carrier: link connected
Feb 22 17:04:59 a0e25d2 kernel: r8152 1-1.5:1.0 eth1: carrier on
This lead to false detection of the DUT powering off, and a false assumption that the internal storage was flashed. To make sure the device is actually powered off, I make sure that the device is detected as off for a period of time (20 sec) before we assume that it is internally flashed
Change-type: patch
Signed-off-by: Ryan Cooke ryan@balena.io
When testing out the flashing of the beaglebones, I noticed that sometimes the flashing would fail - when taking a closer look, I could see that in the case of a failed flashing, the procedure took < 1min, and when it was successful, the internal flashing took closer to 2+ mins.
Looking at the journal logs for the testbot, I could see momentary drops of the ethernet carrier signal used to detect a power off event. For example:
This lead to false detection of the DUT powering off, and a false assumption that the internal storage was flashed. To make sure the device is actually powered off, I make sure that the device is detected as off for a period of time (20 sec) before we assume that it is internally flashed
Change-type: patch Signed-off-by: Ryan Cooke ryan@balena.io