Closed sjg20 closed 2 weeks ago
To handle this in labgrid we usually solder additions to the board if the required headers are not exposed and use the IO protocol in a custom strategy to bring the board into the correct state. Labgrid supports USB relais or exported GPIOs from embedded boards such as raspberry pi's for this.
Yes I have wires soldered to the boards. I have added a RecoverProtocol which seems to work OK so will do a PR for that at some point
Wait, how does your recovery protocol decide which IO port to use for reset and which for the recovery switch? The reason we usually don't encode this into labgrid is that most of these are device specific and aren't easily generalized to other lab configurations.
The actual sequence of actions for a given board is implemented in a Strategy.
OK so here it where I perhaps need to explain my goal a little better. I want to have a lab which can automatically run U-Boot tests on any board automatically, for my lab and for other U-Boot users. I originally implemented this with labman (https://github.com/sjg20/u-boot/tree/lab6a/tools/labman , but I believe it would be better done with labgrid.
From what I can tell, a Strategy is the way to all this, so long as it has suitable parameters to use.
If there is a recovery switch available, then the strategy will use it. Otherwise it won't. This seems to work well enough for me, for now.
It is similar (in a way) to the USBBoot driver. I have added drivers for sunxi and tegra and these seem to work OK.
It is also similar to writing U-Boot to a board, which has different methods. So far my writer driver has rpi3, sunxi, rockchip, em100 and zynq.
labgrid is where all the lab info is kept so I want to avoid adding a cloud of scripts which duplicate that knowledge.
Thanks for the pointers. I was able to make this work with this in my environment:
- HIDRelayDriver:
name: reset_driver
bindings:
relay: reset
- HIDRelayDriver:
name: recovery_driver
bindings:
relay: recovery
- DigitalOutputResetDriver:
name: reset_output
bindings:
output: reset_driver
- DigitalOutputRecoveryDriver:
name: recovery_output
bindings:
output: recovery_driver
Many boards have a 'recovery' button which is used in conjunction with reset to put the board into a boot-ROM-recovery mode.
The sequence is:
This puts the board into a mode where it can be accessed over USB, to write U-Boot, etc.
What is the best way to implement this? Should it be a new 'recovery' protocol?