CM3 Udev rule

[bioe007]

My CM3-based device is going into production now and I'm working on a gang-programming setup.

The hardware is dead simple, 3 "TARGET" CMIO boards and 1 "Host" CM3/CMIO board with raspbian-lite (stretch) on it. The "target" cmio are left powered off until loaded with CM3, then turned on.

I'm using a UDEV rule on the "host" CM3/CMIO to automatically put the CM3 into block-device mode.

Code: Select all

ACTION=="add", ATTR{idVendor}=="0a5c", ATTR{product}=="BCM2710 Boot", RUN+="/usr/local/bin/rpiboot"

Generally, I'm having good success with this approach, but:

1. It's really slow for rpiboot to work through the udev rule. It can take minutes for all three CM3 to show up as block devices.
2. Sometimes it seems like a CM3 (or two) just refuses to enter block device mode. The only solution being power it down/up and try again.
3. Watch (htop, udavdm monitor) I can *see* the rule working but also multiple instances of rpiboot are running. My impression of rpiboot is it doesn't really handle that well.

I'd rather be passing/grabbing the device directly to rpiboot so each instance can 'know' which CM3 it should be talking to. This seems like it would be more deterministic.

Does anyone know if there is an rpiboot option to pass it a device path (as a string or something) ?

[gsh]

Can you not use the -l command line option to make rpiboot sit in a loop continuously booting attached devices?

It did work the last time I tested it (but that may well have been over a year ago now)

Gordon

[bioe007]

Yes, I can do that, but it is less deterministic and actually seems to work worse for detecting all the CM3.

[bioe007]

What would be ideal (I haven't looked at adding this yet) is if the rpiboot executable could use the device path from the udev environment.