FreeCalypso > hg > freecalypso-tools
changeset 955:803e926e0699
doc/Pirelli-loadtools-entry: new article
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Wed, 07 Jun 2023 23:52:09 +0000 |
parents | 21604c3413c1 |
children | b0b6966fa62e |
files | doc/Pirelli-loadtools-entry |
diffstat | 1 files changed, 68 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/Pirelli-loadtools-entry Wed Jun 07 23:52:09 2023 +0000 @@ -0,0 +1,68 @@ +Pirelli DP-L10 phone is a quirky Calypso target in that the same hardware +interface (USB) that provides access to the one easily accessible Calypso UART +also feeds charging power to the phone. The result of this arrangement is that +whenever you connect your phone to your computer for communication, programming +or tinkering, the charging voltage is always present and the Calypso+Iota +chipset never enters switched-off state: every "soft poweroff" operation is +converted by the hardware into a deep reboot. + +You can force a "cold programming boot" cycle on your Pirelli phone by removing +the battery, connecting USB to the "debattered" phone, running fc-loadtool on +the ttyUSB device that appears, and then inserting the battery in one swift +motion - this sequence will be necessary if you brick your flash and need to +unbrick it - but of course it is hugely inconvenient for ordinary FreeCalypso +tinkering (such as running FreeCalypso VPM firmware builds via fc-xram), and +doing it too often will ruin battery spring contacts. The other alternative is +to let Pirelli's official fw boot fully (including GSM network registration) in +between cycles of fc-loadtool or fc-xram, and then do the switch-off operation +from the UI (press and hold red button on unlocked home screen) with fc-loadtool +or fc-xram running. But this option is also unattractive, as it involves +unwanted SIM bring-up and GSM network registration from Pirelli's fw. + +As of fc-host-tools-r19 we have an improved solution in the form of -Petmoff +option to fc-loadtool, fc-xram, fc-simint etc. The usage scenario is as +follows: + +* The phone needs to be in its "booted for charging only" state. With Pirelli's + official fw, this state is entered when you connect USB to a switched-off + phone, or when you execute the switch-off sequence from the UI with USB + connected. + +* In this state, you issue a command like the following: + +fc-loadtool -h pirelli -Petmoff /dev/ttyUSB0 + +or + +fc-simint -h pirelli -Petmoff /dev/ttyUSB0 + +or + +fc-xram -h pirelli -Petmoff /dev/ttyUSB0 ramimage.srec rvinterf + +etc + +This -Petmoff option (implemented as part of our generic boot control framework, +see Target-boot-control article) tells loadtools programs to send an ETM ABB +write (abbw) command to the target serial port, issuing a DEVOFF write to the +VRPCDEV register, just before going into the loop that sends beacons aiming to +interrupt the boot process at the Calypso boot ROM. This trick works because +Pirelli's official fw implements a TI-standard RVTMUX interface on the Calypso +IrDA UART behind USB, complete with ETM, and with USB applying VCHG to Iota +VRPC, the DEVOFF operation (soft poweroff) turns into a deep reboot. + +Running loadtools programs with -Petmoff against a Pirelli phone that is fully +booted, as opposed to "booted for charging only" state, is possible but not +recommended: it will forcibly kill the running firmware without any kind of +clean shutdown. Strictly speaking, this option always effects the just- +described forced firmware kill, no matter which state the official fw happens +to be in, but if the fw is in its "booted for charging only" state, then there +are no ill effects to be concerned with. + +When fc-loadtool or fc-simint/fc-simtool finishes with a clean exit, or when a +RAM-based firmware session started with fc-xram is cleanly finished with +fc-shell poweroff, the phone returns to the same "booted for charging only" +state. Therefore, multiple operations of fc-loadtool, fc-simtool or fc-xram, +each with -Petmoff option, may be performed back to back, just like how a +FreeCalypso developer using a proper FC dev board would run back-to-back +sessions starting with -Pdtr or -Prts and ending with Iota poweroff.