)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"a3bff11df7439124c3e1951aafed79ef79351b55","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6aec2574_baca1219","updated":"2023-01-15 14:00:35.000000000","message":"I have no problem merging this, as is, just please cleanup the commit message.\n\nFor the evolution of reset stuff, I would like to start rationalizing in every target\u0027s file:\n- handle HW reset srst; that is reworking struct target_type::{,de}assert_reset to have only one reset pulse;\n- move in struct target_type::soft_reset_halt for targets that today implement SW reset inside target_type::{,de}assert_reset;\n- introduce a DAP flag for chips that implement standard DBGPWRUPREQ, like rp2040;\n- introduce an helper for chips that implement proprietary system reset through some internal register;\n- introduce a target helper for chips that implement proprietary core reset through some internal register;\n- any other method?\nThen as following step, having commands \"$target_name reset [run|halt|init]\" to reset a single core and \"reset [run|halt|init]\" to reset all the chips on the adapter.\nEventually a \"$soc_name/$tap_name reset [run|halt|init]\" for soc that beside srst can be reset independently from the other soc on the adapter.\n\nThen rethinking the reset framework rework on top of this split.","commit_id":"ab819678a52594ae3492748d54bfd2ac1b410287"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"219111e50a59b69545affcd277de5eaa7a1fd450","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"dae34967_9189906a","updated":"2023-01-16 20:40:03.000000000","message":"Oops, not finished yet.","commit_id":"ab819678a52594ae3492748d54bfd2ac1b410287"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"724373ec47c0f821aa9722f5e1fc2cbfbae35bd4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b4b4eeca_e7c6f9bf","in_reply_to":"6aec2574_baca1219","updated":"2023-01-17 06:18:08.000000000","message":"\u003e - any other method?\n - a dedicated AP (MDM AP of Kinetis)\nAnd two hard-to-implement methods of reset halt:\n - write to a register in very short time window after reset (PSoC acquire)\n - the target sense SWCLK level at SRST deassert (Atmel/Microchip SAMD, SAME5)\n\n\u003e Then as following step, having commands \"$target_name reset [run|halt|init]\" to reset a single core and \"reset [run|halt|init]\" to reset all the chips on the adapter.\n\u003e Eventually a \"$soc_name/$tap_name reset [run|halt|init]\" for soc that beside srst can be reset independently from the other soc on the adapter.\n\nSounds reasonable.\nThinking about $soc_name: it should be generalised to a group of targets.\nOpenOCD already use something similar for SMP. It will be handy for defining work areas as well.","commit_id":"ab819678a52594ae3492748d54bfd2ac1b410287"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"6845b0295868c1187eadcc9898fe8082a7bd40ac","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b54192f7_6984cfc8","in_reply_to":"dae34967_9189906a","updated":"2023-01-19 18:03:00.000000000","message":"I examined the possibility of rescue by Tcl proc.\nNot possible as explained in the commit message.","commit_id":"ab819678a52594ae3492748d54bfd2ac1b410287"}]}