Mass programming usage?

[mypiandrew]

Hi

I'm brain storming a few ideas on how to create a mass programming method to write out the flash on multiple CMs at a time.

So far I've been using a Linux PC with rpi boot and a series of bash scripts to parition, format and untar the two partitions, this makes the whole process a lot quicker than using winimage/dd to write the whole 4Gbyte flash.

I'm wondering if there's a way to gang up multiple CMs and have rpi-boot listen on a specific USB bus/port id, couple this with a few udev rules and that would make a half-decent programming station.

So would it be possible to create a version of this that only responds/listens to a specific USB instance?

For the purposes of the enquiry let's assume a Linux only environment if that makes it easier.

[ghollingworth]

Ah, I've just got someone to develop something for this, basically it's a simple build that contacts a local http server and downloads a script to execute. You can then program the emmc from this using nfs or something...

Just off on holiday for a week, remind me next week and I'll open it for you

Gordon

On Sat, 26 Aug 2017, 11:54 mypiandrew notifications@github.com wrote:

Hi

I'm brain storming a few ideas on how to create a mass programming method to write out the flash on multiple CMs at a time.

So far I've been using a Linux PC with rpi boot and a series of bash scripts to parition, format and untar the two partitions, this makes the whole process a lot quicker than using winimage/dd to write the whole 4Gbyte flash.

I'm wondering if there's a way to gang up multiple CMs and have rpi-boot listen on a specific USB bus/port id, couple this with a few udev rules and that would make a half-decent programming station.

So would it be possible to create a version of this that only responds/listens to a specific USB instance?

For the purposes of the enquiry let's assume a Linux only environment if that makes it easier.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/usbboot/issues/21, or mute the thread https://github.com/notifications/unsubscribe-auth/AB9CHPWJizdFXf8XGH3h_icZzJWcWrdlks5sb_l_gaJpZM4PDcfY .

--

Director of Software Engineering, Raspberry Pi (Trading) Limited t: +44 (0) 1223 322633 m: +44 (0) 7450 946289 e: gordon@raspberrypi.org w: www.raspberrypi.org

[mypiandrew]

Sounds swish! :)

Will give you a poke around the 4th if I don't hear back

Thanks for your quick reply

[mypiandrew]

Hi Gordon

Hope you had a good break, have you had a chance to look at this at all?

Thanks

Andrew.

[ghollingworth]

Great,

Recently made this public on the Raspberry Pi github organisation:

https://github.com/raspberrypi/scriptexecutor

Following the instructions at https://github.com/raspberrypi/scriptexecutor/wiki/Building-and-customizing

Gordon

[mypiandrew]

Hi Gordon

Thanks for the code base, that looks awesome!

I think I've solved the problem for my application by hacking in some extra checks into your standard rpiboot code, here's the mod to your program I did to check it was possible.

https://gist.github.com/mypiandrew/05e986be2d77d70b6def1498a98e6ba3

I think that if I have multiple instances of this running, each looking at a different port, they can't clash -- can you confirm my thinking here?

[ghollingworth]

Can you put it in as a pull request and I'll have a look at the changes, I think I'd prefer a slightly different method for setting it up but I'm not against adding the functionality

[FiesoDuck]

Hi! Any update on this?

[pelwell]

We never received a Pull Request with @mypiandrew's changes.

[mypiandrew]

Hi

Sorry, I'm not very well versed in git so the pastebin style upload was the best I could do

Sent from my iPhone

On 27 Mar 2018, at 11:27, Phil Elwell notifications@github.com wrote:

We never received a Pull Request with @mypiandrew's changes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pelwell]

It's usually trivially easy:

1. Go to the usbboot source here: https://github.com/raspberrypi/usbboot/blob/master/main.c
2. Click the pencil to write to edit the file - GitHub will create you a fork of the repo.
3. Paste your updated content into the editor.
4. Preview the differences, looking for bogus whitespace changes etc.
5. Add a commit message, then click the button to create a fork and a pull request.

However your change is against an older version of the file, so I had to manually merge the changes (something git would have done automatically).

The result is in https://github.com/raspberrypi/usbboot/commit/fb86716935f2e820333b037a2ff93a338ad9b695 - it was meant to be a PR but I managed to merge it directly to master. Just cast your eyes over it to make sure it is what you intended.

[burtyb]

Wouldn't it be better to specify the USB path "1-1.1.2" rather than a port number 0-6?

Anything with multiple hubs is potentially going to cause problems for example if you're using the Pi3b+ (looking at it with the NIC on the left) both the top left and bottom right USB ports are portNo=2 (bottom left/top right are both portNo=3).

[mypiandrew]

@pelwell Looks good to me!

[lurch]

I managed to merge it directly to master.

Does that mean this issue can be closed now?

[timg236]

Closing because we now have the CM4 provisioning system https://github.com/raspberrypi/cmprovision and the embedded Raspberry Pi Imager.

Since bootcode4.bin supports boot.img ramdisks it's also fairly straightforward to create an initframfs that does a HTTP download of your chosen image.