The screen/screen connection/ZPUI code fails, but the user doesn't know it, and ZPUI keeps running (or fails after it's stopped the serial port getty)
UART is, therefore, inaccessible - serial port getty is stopped, and serial port itself is likely opened by ZPUI
The ZeroPhone is not connected to WiFi - user can't connect it because ZPUI is not accessible, and UART is locked by ZPUI
So, the user loses access to ZeroPhone, and can't even debug what's wrong. It's even worse if the user doesn't understand where the problem is, and wastes a lot of time debugging.
I have some solutions in mind - they all involve giving access to UART by blocking/interrupting the ZPUI's "phone" app, which is the app grabbing the serial port:
Add a /boot/zpui_config.json hook that'd allow to "do_not_load" arbitrary apps, in this case, unloading the "phone" app would be useful.
1.1 Powering off the ZeroPhone (and editing the SD card externally) would be necessary
Hook a GPIO so that it allows stopping ZPUI's 'phone' app - for example, the RESET gpio is not supposed to be used as output all of the time. So, while the modem is not being RESET by an app (or other driver), it could use RESET as a GPIO, and pulling that GPIO low would signal ZPUI phone app to stop the modem and unbind the serial port.
2.1 this solution has the benefit of not having to power off the ZeroPhone for it to work
2.2 this GPIO could then be hooked to the USB-UART&charging mod board for developer usage
There's a scenario where:
So, the user loses access to ZeroPhone, and can't even debug what's wrong. It's even worse if the user doesn't understand where the problem is, and wastes a lot of time debugging.
I have some solutions in mind - they all involve giving access to UART by blocking/interrupting the ZPUI's "phone" app, which is the app grabbing the serial port: