Hello everyone, in the snapd team we find that, although a lot of automation is already in place and more is coming down the pipe, the validation processes are still very manual and this prevents us from getting the full benefits of the rest of practices and methodologies we are following.
One (two in fact) particular platform where we are lacking automation the most is the Pi, we have an automated test suite that can be executed without supervision on them but the provisioning is still a manual process. AFAIK, please anyone that knows more about the details correct me if I’m wrong, it is not possible/easy to automatically flash an image on a sd card, make it available to a pi board and ask it to reboot in order to use the new image. This problem affects the Pi but probably would affect other sd card based boards without PXE or additional features to facilitate the automated provision.
There have been great efforts to automate this process from @plars, the last news I got is that he managed to design a prototype board to make a sd accessible to both a host machine and a pi board, with the switch between the two controlled from the host, and that he also found a company to manufacture it, please Paul correct me if that’s not the case.
We have been talking about this on the team and we would like to experiment with that kind of prototypes on our local dev environments, the questions (to @plars and anyone else interested) are:
Paul, is it possible to get your prototype from the manufacturer you found? How could we contact them?
Are there any alternatives? I know for sure that resin.io is using something similar, and @zyga-snapd showed us a board from linaro that maybe could be used for the same purpose.
It’s something I’m actively working on. I have a prototype based on a sd switcher board that I found as an open source hardware project. I made some changes to allow us to have better connectors and things like that, and I have had varying degrees of success with it so far. It’s something we would need to make ourselves, so keeping it as simple as possible is a goal. Some of the components are a bit tricky though, and I’m currently looking at the possibility of simplifying it by making it a pi hat and driving the switching through gpio instead of with an ftdi chip over usb. I’ve looked at the linaro devices, and last I heard they had even abandoned those because they were unreliable. I haven’t heard anything about the stuff resin is doing, do you have a link?
In any case, this is something I’m actively working on now, so as soon as I have a solution, you will be the first to know.
Neat! I hadn’t seen this one, but it has a lot of similarities to the one I’m working on now. I ended up designing my own micro-sd breakout with 2x4 IDC headers on it so I don’t have to solder the individual wires like they do in this one. The 8pin idc cables are cheap and easy to source, so it seemed a really good option. The one I have uses a pair of TI SN74CBT3257 chips to multiplex the 8 pins of the micro-sd instead of a relay. The fickle part is the ftdi chip like they use here. I have capability to do smd components (hot air and reflow) at home, but the super tiny pins of that package are a frequent source of headaches and reworks. So in the interest of having something that can be quickly and reliably produced, I’m looking at reworking it as a pi hat instead (as mentioned). Thanks for pointing out this project though, it does validate some of the things I’ve done so far as being a good choice.
I did see that one, yes. It’s based on the samsung/tizen board, and is much more complex than what I was shooting for, because it includes power control which we handle a different way already, and ftdi for switching (which I was trying to get away from in favor of gpio control), and for some reason it also includes a usb hub and usb switching. I’m not sure what those are used for. The primary part I’m concerned with is multiplexing the pins from the microsd. The autohat (which does not seem to actually be a hat, though that would be neat if it was) uses a 6-bit multiplexer. The ground pin is not switched, and VDD is switched using a separate circuit. The one I’m working on uses a pair of very similar 4-bit multiplexer chips to switch all 8 pins. Both use 2x4 IDC cables, but the one I’m working on adds a small breakout board for the microsd side that also uses a 2x4 pin header, so that way I don’t need a custom cable, and can just use readily available 8-pin IDC cables. (See links below for project files and pictures)
Current status
I have the latest prototype built, which now works as a RPI hat triggered off of GPIO12 to switch between host and target for the SD. I am currently testing it by inserting a known-good microSD into the hat, and connecting one of the cables/breakouts to a USB-SD converter to my laptop. It “sees” the connection, but right now it fails to see the partitions, or filesystem and usually just gives me a lot of IO errors in dmesg. As I was doing some debugging to ensure everything was properly routed (it was), I connected a sparkfun microSD switcher (link below) to both ends, and to my surprise, it works perfectly when I have it hooked up like this! The sniffer doesn’t really do anything but allow intercepting the pins though, and it works even when I have nothing connected to the sniffer pins. So I’m reasonably confident that this can work, but clearly there are a few more issues to work through. If anyone has any ideas on this, I’d love to hear from you.
