FreeCalypso > hg > freecalypso-tools
view loadtools/scripts/compal.init @ 497:74610c4f10f7
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.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sat, 25 May 2019 20:44:05 +0000 |
parents | ac48ed111d6a |
children | b0f9d38bfd9e |
line wrap: on
line source
# Set WS=3 for both nCS0 and nCS1. This configuration is used by all official # C11x, C139/140 and SE J100 firmwares that have been examined, i.e., by the # official firmwares for all Compal models to which this init script applies. w16 fffffb00 00A3 w16 fffffb02 00A3 # On most targets we use the alternate nCS0 mapping at 0x03000000 to access # the full flash bank even though the boot ROM is mapped at 0, overlapping # the first 8 KiB of flash. However, the Calypso chip (all versions we work # with) has a little design bug in this part of the silicon: the alternate # nCS0 mapping at 0x03000000 works only when the debug visibility bit in the # API-RHEA control register (bit 6 in the FFFF:FB0E register) is set, and # does not work otherwise. This bit is initially set as the Calypso comes # out of reset, and on most platforms we gain loadtool access via the boot ROM, # hence the problem does not occur - but on these Compal targets we gain # loadtool access either through Compal's bootloader or via tfc139, and in # both cases Compal's fw (either the full fw or the bootloader part) has # already set the register in question to the runtime operational value of # 0x2A (unchanged from TI's TCS211 reference fw), with the debug visibility # bit cleared, hence the 0x03000000 flash mapping no longer works. # # We could write into the FFFF:FB0E register here, restore the Calypso power-up # state and use the 0x03000000 mapping like on other platforms, but the problem # of the mapping not working as expected was first encountered in 2014 when we # started working on Compal targets, whereas the root cause described above was # only discovered in 2019. For now we are keeping the original workaround from # 2014: we set the FFFF:FB10 register to map the flash (not the boot ROM) # to address 0, and use that "main" mapping instead of the alternate one. w16 fffffb10 0300