I don’t know who is currently responsible for CLI, but it would be good if the -q switch would also do away with the need for an acknowledgement for something you will know after the first time (or get reminded anyway when you forgot to do what’s needed).
Or add a switch for particularly that (e.g. like many Linux commands offer the -y switch to auto-accept the default response for user-interaction-requests).
@marekparticle, can you tag the person in charge for CLI?
1 Like
hi sidwarkd,
good to know! i guess there are dependencies. we get a little insight using “particle serial inspect”. see below the system module #2 has a depenency “Bootloader module #0 - version 400”
next virgin p1 i flash i will check not to violate depenencies!
MackMyra:updates frank$ particle serial inspect
Platform: 8 - P1
Modules
Bootloader module #0 - version 502, main location, 16384 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1512, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 207
System module #2 - version 1512, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 1512
Bootloader module #0 - version 400
User module #1 - version 6, main location, 131072 bytes max size
UUID: 0D3A802532E549FE881F39851D2220A7FD8F0F5884C306E9EBA42F16409C27FA
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 1512
User module #1 - version 4, factory location, 131072 bytes max size
UUID: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 21
okay, here is a p1 fresh from the particle factory. it has device os version 0.5.3. in this case there is no device os dependency on the bootloader (see below). but i guess if there were it would only explain to load the new bootloader first…
anyhow: i flashed this p1 device-os/system before the bootloader. also works. but have to do an extra “particle usb reset” and “stty -f /dev/cu.usbmodemxxxxxx 14400”
can anyone explain why/how/if/when bootloader after device-os flashing?
MackMyra:updates frank$ particle serial inspect
Platform: 8 - P1
Modules
Bootloader module #0 - version 7, main location, 16384 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
empty - main location, 262144 bytes max size
System module #2 - version 21, main location, 262144 bytes max size
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #1 - version 21
User module #1 - version 4, main location, 131072 bytes max size
UUID: 11B13BD023486339343808493C222BBD27753EB71D4290F352EE4D7A11AB9E82
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 21
User module #1 - version 4, factory location, 131072 bytes max size
UUID: 11B13BD023486339343808493C222BBD27753EB71D4290F352EE4D7A11AB9E82
Integrity: PASS
Address Range: PASS
Platform: PASS
Dependencies: PASS
System module #2 - version 21
We’re closed for the holiday until next week, but upon return I’m sure @m_m would happily take a look! 
it is already implemented, just not documented (as far as i can find): --yes
particle -v flash --serial p1-bootloader\@1.5.2+lto.bin --yes
so no hands:
MackMyra:updates frank$ particle -v flash --serial p1-bootloader\@1.5.2+lto.bin --yes
sending file: p1-bootloader@1.5.2+lto.bin
Flash success!
Flash success!
2 Likes
the only thing open for me is when to flash bootloader after device-os and when it is safe to do the other way (which is faster as it has less steps). anyone any insight?