The difficulty is that as it stands, Panda naturally always wants to boot into the X-loader / U-Boot it finds on the SD Card.
If we teleported in a broken X-loader / U-Boot because that's what we wanted to have tested, then we kind of brick the Panda until someone comes and rewrites the SD by hand or swaps in a good card. That's not really acceptable.
One solution to this is to provide a fake SD card PCB which comes out into two SD sockets. One contains a stable reference boot image and initrd, the other contains the test image. By one out-of-band means or another, we allow the test system to select which of the SD cards is visible to the Panda after reset.
If it selects the reference SD, the initrd is loaded and the SD card switched back by timeout to the test image SD, From the initrd userland, the test environment can nuke and prepare the test image SD for the test action over the network. Since it's an initrd, the test image SD is not mounted so you have full control over it.
If it selects the test image SD, then that just boots normally, if it's workable the tests are run otherwise the test session times out and it can be rebooted into the reference SD environment again to prepare for the next test image. That's the case even if, eg, x-loader is corrupted or missing in the test SD image.
The difficulty is that as it stands, Panda naturally always wants to boot into the X-loader / U-Boot it finds on the SD Card.
If we teleported in a broken X-loader / U-Boot because that's what we wanted to have tested, then we kind of brick the Panda until someone comes and rewrites the SD by hand or swaps in a good card. That's not really acceptable.
One solution to this is to provide a fake SD card PCB which comes out into two SD sockets. One contains a stable reference boot image and initrd, the other contains the test image. By one out-of-band means or another, we allow the test system to select which of the SD cards is visible to the Panda after reset.
If it selects the reference SD, the initrd is loaded and the SD card switched back by timeout to the test image SD, From the initrd userland, the test environment can nuke and prepare the test image SD for the test action over the network. Since it's an initrd, the test image SD is not mounted so you have full control over it.
If it selects the test image SD, then that just boots normally, if it's workable the tests are run otherwise the test session times out and it can be rebooted into the reference SD environment again to prepare for the next test image. That's the case even if, eg, x-loader is corrupted or missing in the test SD image.