target-utils: added 10 ms delay at the end of abb_power_off() The deosmification of the ABB access code (replacement of osmo_delay_ms() bogus delays with correctly-timed ones, which are significantly shorter) had one annoying side effect: when executing the poweroff command from any of the programs, one last '=' prompt character was being sent (and received by the x86 host) as the Calypso board powers off. With delays being shorter now, the abb_power_off() function was returning and the standalone program's main loop was printing its prompt before the Iota chip fully executed the switch-off sequence! I thought about inserting an endless tight loop at the end of the abb_power_off() function, but the implemented solution of a 10 ms delay is a little nicer IMO because if the DEVOFF operation doesn't happen for some reason in a manual hacking scenario, there won't be an artificial blocker in the form of a tight loop keeping us from further poking around.

# This phone has 3 memory chip selects:
#
# nCS0: flash chip select 1
# nCS1: RAM chip select
# nCS3: flash chip select 2
#
# All 3 chip select lines go to the same physical IC, a RAM/flash MCP.
# We set WS=4 for all 3 here, copying what OsmocomBB does.  The access
# time listed in the datasheet is 70 ns for both RAM and flash, and per
# my math setting WS=3 *might* work, but it could be marginal, so let's
# play it safe for now.

w16 fffffb00 00A4
w16 fffffb02 00A4
w16 fffffb06 00A4

# We also need to switch the CS4/ADD22 pin from its default function
# of CS4 to the needed ADD22.

w16 fffef006 0008

# With this phone all Calypso serial access always goes through the
# CP2102 usb2serial IC inside the phone itself, which is programmed
# to support the high non-standard baud rates.  So we can safely
# switch to 812500 baud unconditionally.

baud 812500