[PATCH]: 1182addaa8 tcl/target: Add helpers for booting Xilinx ZynqMP from JTAG

2024-02-06 Thread gerrit
This is an automated email from Gerrit.

"Name of user not set " just uploaded a new patch set 
to Gerrit, which you can find at https://review.openocd.org/c/openocd/+/8133

-- gerrit

commit 1182addaa8e1c81bdd8f04cb26a3462d344bf5c5
Author: Sean Anderson 
Date:   Tue Feb 6 18:49:59 2024 -0500

tcl/target: Add helpers for booting Xilinx ZynqMP from JTAG

Add some helpers for booting ZynqMPs over JTAG. Normally, the CSU ROM
will load boot.bin from the boot medium. However, when booting from JTAG
we have to do this ourselves. There are generally two parts to this.
First, we need to load the PMU firmware. Xilinx's tools do this by
attaching to the PMU (a Microblaze CPU) over JTAG. However, the TAP is
undocumented and we don't have any microblaze support in-tree. So
instead we do it the same way FSBL does it:

- We ask the PMU to halt
- We load the firmware into the PMU RAM
- We ask the PMU to resume

The second thing we need to do is start one of the APU cores. When an
APU is released from reset, it starts executing at the value of its
RVBARADDR. While we could load the APU firmware over the AXI target,
it is faster to load it over the APU target. To do this, we put the APU
into an infinite loop before halting it. As an aside, I chose to use the
"APU" terminology as opposed to "core" to make it clear that these
commands operate on the A53 cores and not the R5F cores.

Typical usage of these commands could look something like

targets uscale.axi
boot_pmu /path/to/pmu-firmware.bin
boot_apu /path/to/u-boot-spl.bin

But of course there is always the option to call lower-level commands
individually if your boot process is more unusual.

Signed-off-by: Sean Anderson 
Change-Id: I816940c2022ccca0fabb489aa75d682edd0f6138

diff --git a/tcl/target/xilinx_zynqmp.cfg b/tcl/target/xilinx_zynqmp.cfg
index 9734a18376..434843e601 100644
--- a/tcl/target/xilinx_zynqmp.cfg
+++ b/tcl/target/xilinx_zynqmp.cfg
@@ -104,3 +104,137 @@ proc core_up { args } {
 $_TARGETNAME.$core arp_examine
 }
 }
+
+proc BIT {n} {
+   return [expr {1 << $n}]
+}
+
+set IPI_BASE   0xff30
+set IPI_PMU_0_TRIG [expr {$IPI_BASE + 0x3}]
+set IPI_PMU_0_IER  [expr {$IPI_BASE + 0x30018}]
+set IPI_PMU_0  [BIT 16]
+
+set CRF_APB_BASE   0xfd1a
+set CRF_APB_RST_FPD_APU[expr {$CRF_APB_BASE + 0x104}]
+set CRF_APB_RST_FPD_APU_ACPU0_PWRON_RESET  [BIT 10]
+set CRF_APB_RST_FPD_APU_L2_RESET   [BIT  8]
+set CRF_APB_RST_FPD_APU_ACPU0_RESET[BIT  0]
+
+set APU_BASE   0xfd5c
+set APU_RVBARADDR_BASE [expr {$APU_BASE + 0x40}]
+
+set PMU_BASE   0xffd8
+set PMU_GLOBAL $PMU_BASE
+set PMU_GLOBAL_MB_SLEEP[BIT 16]
+set PMU_GLOBAL_FW_IS_PRESENT   [BIT  4]
+set PMU_GLOBAL_DONT_SLEEP  [BIT  0]
+
+set PMU_RAM_BASE   0xffdc
+
+set OCM_RAM_BASE   0xfffc
+
+rename BIT {}
+
+add_help_text halt_pmu "Halt the PMU in preparation for loading new firmware.\
+   This should be matched with a call to resume_pmu."
+proc halt_pmu {} {
+   set axi $::_CHIPNAME.axi
+   set val [$axi read_memory $::IPI_PMU_0_IER 32 1]
+   $axi write_memory $::IPI_PMU_0_IER 32 [expr {$val | $::IPI_PMU_0}]
+
+   set val [$axi read_memory $::IPI_PMU_0_TRIG 32 1]
+   $axi write_memory $::IPI_PMU_0_TRIG 32 [expr {$val | $::IPI_PMU_0}]
+
+   set start [ms]
+   while {!([$axi read_memory $::PMU_GLOBAL 32 1] & 
$::PMU_GLOBAL_MB_SLEEP)} {
+   if {[ms] - $start > 1000} {
+   error "Timed out waiting for PMU to halt"
+   }
+   }
+}
+
+add_help_text resume_pmu "Resume the PMU after loading new firmware. This\
+   should be matched with a call to halt_pmu."
+proc resume_pmu {} {
+   set axi $::_CHIPNAME.axi
+   set val [$axi read_memory $::PMU_GLOBAL 32 1]
+   $axi write_memory $::PMU_GLOBAL 32 [expr {$val | 
$::PMU_GLOBAL_DONT_SLEEP}]
+
+   set start [ms]
+   while {!([$axi read_memory $::PMU_GLOBAL 32 1] & 
$::PMU_GLOBAL_FW_IS_PRESENT)} {
+   if {[ms] - $start > 5000} {
+   error "Timed out waiting for PMU firmware"
+   }
+   }
+}
+
+add_usage_text release_apu {apu}
+add_help_text release_apu "Release an APU from reset. It will start executing\
+   at RVBARADDR. You probably want resume_apu or start_apu instead."
+proc release_apu {apu} {
+   set axi $::_CHIPNAME.axi
+   set val [$axi read_memory $::CRF_APB_RST_FPD_APU 32 1]
+   set mask [expr {
+   (($::CRF_APB_RST_FPD_APU_ACPU0_PWRON_RESET | \
+ $::CRF_APB_RST_FPD_APU_ACPU0_RESET) << $apu) | \
+   

[openocd:tickets] #421 OpenOCD v12 - STLink-v3Minie & STM32 f334 Not Working

2024-02-06 Thread Collin Kreutzer
Im running into this exact problem too but have noticed this only happens for 
"larger" programs. A simple "Blink an LED" program flashes just fine. 
Activating more and more perihperals via CubeMX - which consequently includes 
the appropriate HAL drivers - causes the flashing to stop working. I can 
reproduce this perfectly by enabling and disabling a single peripheral (I2C in 
my example), rebuilding and flashing. With I2C enabled, i observe the exact 
behavior described above. With it disabled, the program flashes just fine. I 
dont know if its allowed to attache .elf files here. If so, i would gladly 
provide a working and non-working .elf.


---

**[tickets:#421] OpenOCD v12 - STLink-v3Minie & STM32 f334 Not Working**

**Status:** new
**Milestone:** 0.10.0
**Labels:** bug v12.0 
**Created:** Tue Jan 30, 2024 12:46 AM UTC by Taylor Lineman
**Last Updated:** Sat Feb 03, 2024 03:52 PM UTC
**Owner:** nobody


Hi all! I am a member of the RIT EVT Team and we often use OpenOCD to debug our 
boards. These boards use a range of STM32 chips, specifically the f334, f302, 
and f446.  We have been struggling recently with OpenOCD on the f334 chips that 
some of our boards use. We assumed this was a board issue so tested with 
STM32CubeProgrammer, which worked flawlessly. However that program does not 
allow for debugging and we have already built OpenOCD into our workflow, so we 
wanted to get it working.

## Issue
The issue that we are seeing is that OpenOCD v12.0 fails with an STLinkv3 Minie 
on only f334 boards. We have tested on an STM32 Nucleo as well as a custom 
board to verify if there is a difference, and there is not. The following chart 
shows our findings:

| Open OCD Version | STLink Version| Board   | STM Name  | Open 
OCD|
|--|---|-|---|-|
| 0.12.0   | STLink v3 - Mini  | IMU v1  | STM32 F334 C8 U6  | Not 
Working |
| 0.12.0   | STLink v3 - Mini  | HUDL v1.2   | STM32 F302 R8 T6  | 
Working |
|  |   | |   |  
   |
| 0.12.0   | Nucleo STlLink v3 | Nucleo F302 | STM32 F302 R8 AU1 | 
Working |
| 0.12.0   | Nucleo STlLink v3 | Nucleo F334 | STM32 F334 R8 | Not 
Working |
| 0.12.0   | Nucleo STlLink v3 | Nucleo F446 | STM32 F446 RE | 
Working |
|  |   | |   |  
   |
| 0.11.0   | STLink v3 - Mini  | IMU v1  | STM32 F334 C8 U6  | Not 
Working |
| 0.11.0   | STLink v3 - Mini  | HUDL v1.2   | STM32 F302 R8 T6  | Not 
Working |
|  |   | |   |  
   |
| 0.11.0   | Nucleo STlLink v3 | Nucleo F302 | STM32 F302 R8 AU1 | 
Working |
| 0.11.0   | Nucleo STlLink v3 | Nucleo F334 | STM32 F334 R8 | 
Working |
| 0.11.0   | Nucleo STlLink v3 | Nucleo F446 | STM32 F446 RE | 
Working |

As the chart shows, STM32 F334 support was working in OpenOCD v11.0, however 
after updating to OpenOCD v12.0 we see it beging failing on Nucleo F334. The 
above information was all tested and verified multiple times to ensure we got 
our data correct.

-
If the maintainers beelive we need to provide more information please let us 
know! We will gladly help out in any way we can!




---

Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/openocd/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.

[openocd:tickets] #423 Update for JEP106BI

2024-02-06 Thread Antonio Borneo
- **status**: new --> closed
- **assigned_to**: Antonio Borneo
- **Resolution**:  --> https://review.openocd.org/8132



---

**[tickets:#423] Update for JEP106BI**

**Status:** closed
**Milestone:** 0.11.0
**Created:** Tue Feb 06, 2024 07:05 PM UTC by Véronique Allard
**Last Updated:** Tue Feb 06, 2024 09:26 PM UTC
**Owner:** Antonio Borneo


JEP106BI has been published. Would it be possible to update the list of JTAG 
manufacturers accordingly?
https://www.jedec.org/standards-documents/docs/jep-106ab


---

Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/openocd/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.

[openocd:tickets] #423 Update for JEP106BI

2024-02-06 Thread Antonio Borneo
Thanks for the alert.
https://review.openocd.org/c/openocd/+/8132



---

**[tickets:#423] Update for JEP106BI**

**Status:** new
**Milestone:** 0.11.0
**Created:** Tue Feb 06, 2024 07:05 PM UTC by Véronique Allard
**Last Updated:** Tue Feb 06, 2024 07:05 PM UTC
**Owner:** nobody


JEP106BI has been published. Would it be possible to update the list of JTAG 
manufacturers accordingly?
https://www.jedec.org/standards-documents/docs/jep-106ab


---

Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/openocd/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.

[PATCH]: f655343430 jep106: update to revision JEP106BI January 2024

2024-02-06 Thread gerrit
This is an automated email from Gerrit.

"Antonio Borneo " just uploaded a new patch set to 
Gerrit, which you can find at https://review.openocd.org/c/openocd/+/8132

-- gerrit

commit f655343430a0e343d5c93c92ed04f0a1c9e81edb
Author: Antonio Borneo 
Date:   Tue Feb 6 22:20:06 2024 +0100

jep106: update to revision JEP106BI January 2024

The original documents from Jedec since JEP106BG, do not report
the entry for "21  NXP (Philips)", replaced by "c".
It's clearly a typo.

Keep the line from JEP106BF.01 for "NXP (Philips)".

Change-Id: I293173c4527c2eabebdc33a94cd23d3a557a4618
Signed-off-by: Antonio Borneo 

diff --git a/src/helper/jep106.inc b/src/helper/jep106.inc
index bcf354c916..958dc4ea4d 100644
--- a/src/helper/jep106.inc
+++ b/src/helper/jep106.inc
@@ -2,13 +2,13 @@
 
 /*
  * The manufacturer's standard identification code list appears in JEP106.
- * Copyright (c) 2023 JEDEC. All rights reserved.
+ * Copyright (c) 2024 JEDEC. All rights reserved.
  *
  * JEP106 is regularly updated. For the current manufacturer's standard
  * identification code list, please visit the JEDEC website at www.jedec.org .
  */
 
-/* This file is aligned to revision JEP106BH September 2023. */
+/* This file is aligned to revision JEP106BI January 2024. */
 
 /* "NXP (Philips)" is reported below, while missing since JEP106BG */
 
@@ -1621,7 +1621,7 @@
 [12][0x5f - 1] = "Sitrus Technology",
 [12][0x60 - 1] = "AnHui Conner Storage Co Ltd",
 [12][0x61 - 1] = "Rochester Electronics",
-[12][0x62 - 1] = "Wuxi Petabyte Technologies Co Ltd",
+[12][0x62 - 1] = "Wuxi Smart Memories Technologies Co",
 [12][0x63 - 1] = "Star Memory",
 [12][0x64 - 1] = "Agile Memory Technology Co Ltd",
 [12][0x65 - 1] = "MEJEC",
@@ -1864,7 +1864,7 @@
 [14][0x56 - 1] = "Exacta Technologies Ltd",
 [14][0x57 - 1] = "Synology",
 [14][0x58 - 1] = "Trium Elektronik Bilgi Islem San Ve Dis",
-[14][0x59 - 1] = "Shenzhen Hippstor Technology Co Ltd",
+[14][0x59 - 1] = "Wuxi HippStor Technology Co Ltd",
 [14][0x5a - 1] = "SSCT",
 [14][0x5b - 1] = "Sichuan Heentai Semiconductor Co Ltd",
 [14][0x5c - 1] = "Zhejiang University",
@@ -1888,4 +1888,54 @@
 [14][0x6e - 1] = "Chemgdu EG Technology Co Ltd",
 [14][0x6f - 1] = "AGI Technology",
 [14][0x70 - 1] = "Syntiant",
+[14][0x71 - 1] = "AOC",
+[14][0x72 - 1] = "GamePP",
+[14][0x73 - 1] = "Yibai Electronic Technologies",
+[14][0x74 - 1] = "Hangzhou Rencheng Trading Co Ltd",
+[14][0x75 - 1] = "HOGE Technology Co Ltd",
+[14][0x76 - 1] = "United Micro Technology (Shenzhen) Co",
+[14][0x77 - 1] = "Fabric of Truth Inc",
+[14][0x78 - 1] = "Epitech",
+[14][0x79 - 1] = "Elitestek",
+[14][0x7a - 1] = "Cornelis Networks Inc",
+[14][0x7b - 1] = "WingSemi Technologies Co Ltd",
+[14][0x7c - 1] = "ForwardEdge ASIC",
+[14][0x7d - 1] = "Beijing Future Imprint Technology Co Ltd",
+[14][0x7e - 1] = "Fine Made Microelectronics Group Co Ltd",
+[15][0x01 - 1] = "Changxin Memory Technology (Shanghai)",
+[15][0x02 - 1] = "Synconv",
+[15][0x03 - 1] = "MULTIUNIT",
+[15][0x04 - 1] = "Zero ASIC Corporation",
+[15][0x05 - 1] = "NTT Innovative Devices Corporation",
+[15][0x06 - 1] = "Xbstor",
+[15][0x07 - 1] = "Shenzhen South Electron Co Ltd",
+[15][0x08 - 1] = "Iontra Inc",
+[15][0x09 - 1] = "SIEFFI Inc",
+[15][0x0a - 1] = "HK Winston Electronics Co Limited",
+[15][0x0b - 1] = "Anhui SunChip Semiconductor Technology",
+[15][0x0c - 1] = "HaiLa Technologies Inc",
+[15][0x0d - 1] = "AUTOTALKS",
+[15][0x0e - 1] = "Shenzhen Ranshuo Technology Co Limited",
+[15][0x0f - 1] = "ScaleFlux",
+[15][0x10 - 1] = "XC Memory",
+[15][0x11 - 1] = "Guangzhou Beimu Technology Co., Ltd",
+[15][0x12 - 1] = "Rays Semiconductor Nanjing Co Ltd",
+[15][0x13 - 1] = "Milli-Centi Intelligence Technology Jiangsu",
+[15][0x14 - 1] = "Zilia Technologioes",
+[15][0x15 - 1] = "Incore Semiconductors",
+[15][0x16 - 1] = "Kinetic Technologies",
+[15][0x17 - 1] = "Nanjing Houmo Technology Co Ltd",
+[15][0x18 - 1] = "Suzhou Yige Technology Co Ltd",
+[15][0x19 - 1] = "Shenzhen Techwinsemi Technology Co Ltd",
+[15][0x1a - 1] = "Pure Array Technology (Shanghai) Co. Ltd",
+[15][0x1b - 1] = "Shenzhen Techwinsemi Technology Udstore",
+[15][0x1c - 1] = "RISE MODE",
+[15][0x1d - 1] = "NEWREESTAR",
+[15][0x1e - 1] = "Hangzhou Hualan Microeletronique Co Ltd",
+[15][0x1f - 1] = "Senscomm Semiconductor Co Ltd",
+[15][0x20 - 1] = "Holt Integrated Circuits",
+[15][0x21 - 1] = "Tenstorrent Inc",
+[15][0x22 - 1] = "SkyeChip",
+[15][0x23 - 1] = "Guangzhou Kaishile Trading Co Ltd",
+[15][0x24 - 1] = "Jing Pai Digital Technology (Shenzhen) Co",
 /* EOF */

-- 



[openocd:tickets] #423 Update for JEP106BI

2024-02-06 Thread Véronique Allard



---

**[tickets:#423] Update for JEP106BI**

**Status:** new
**Milestone:** 0.11.0
**Created:** Tue Feb 06, 2024 07:05 PM UTC by Véronique Allard
**Last Updated:** Tue Feb 06, 2024 07:05 PM UTC
**Owner:** nobody


JEP106BI has been published. Would it be possible to update the list of JTAG 
manufacturers accordingly?
https://www.jedec.org/standards-documents/docs/jep-106ab


---

Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/openocd/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.

[PATCH]: a8063107c5 src/target/riscv: add cpuinfo command

2024-02-06 Thread gerrit
This is an automated email from Gerrit.

"Alan-19950616 " just uploaded a new patch set to 
Gerrit, which you can find at https://review.openocd.org/c/openocd/+/8131

-- gerrit

commit a8063107c5a8b3f6a6650c5c9c7d92e83aeaa3a2
Author: wangyanwen 
Date:   Wed Jan 24 14:56:01 2024 +0800

src/target/riscv: add cpuinfo command

Add nuclei command group
Add nuclei cpuinfo command

Change-Id: Ie2b1ac1c11ae275e6e27cb960ca95ec393a17e5b
Signed-off-by: wangyanwen 

diff --git a/src/target/riscv/riscv.c b/src/target/riscv/riscv.c
index d895ca3726..435ad770b8 100644
--- a/src/target/riscv/riscv.c
+++ b/src/target/riscv/riscv.c
@@ -2861,6 +2861,279 @@ COMMAND_HANDLER(handle_info)
return 0;
 }
 
+#define KB(1024)
+#define MB(KB * 1024)
+#define GB(MB * 1024)
+#define EXTENSION_NUM (26)
+#define POWER_FOR_TWO(n)  (1 << (n))
+#define EXTRACT_FIELD(val, which) (((val) & (which)) / ((which) & ~((which) - 
1)))
+#define print_size(bytes) do {\
+   if ((bytes) / GB) {\
+   command_print_sameline(CMD, " %dGB", (int)((bytes) / GB));\
+   } else if ((bytes) / MB) {\
+   command_print_sameline(CMD, " %dMB", (int)((bytes) / MB));\
+   } else if ((bytes) / KB) {\
+   command_print_sameline(CMD, " %dKB", (int)((bytes) / KB));\
+   } else {\
+   command_print_sameline(CMD, " %dByte", (int)(bytes));\
+   } \
+} while (0)
+#define show_cache_info(set, way, lsize) do {\
+   print_size((set) * (way) * (lsize));\
+   command_print_sameline(CMD, "(set=%d,", (int)(set));\
+   command_print_sameline(CMD, "way=%d,", (int)(way));\
+   command_print(CMD, "lsize=%d)", (int)(lsize));\
+} while (0)
+
+COMMAND_HANDLER(handle_nuclei_cpuinfo)
+{
+   riscv_reg_t csr_mcfg = 0;
+   riscv_reg_t csr_micfg = 0;
+   riscv_reg_t csr_mdcfg = 0;
+   riscv_reg_t iregion_base = 0;
+   riscv_reg_t csr_marchid = 0;
+   riscv_reg_t csr_mimpid = 0;
+   riscv_reg_t csr_misa = 0;
+   riscv_reg_t csr_mirgb = 0;
+   riscv_reg_t csr_mfiocfg = 0;
+   riscv_reg_t csr_mppicfg = 0;
+   riscv_reg_t csr_mtlbcfg = 0;
+
+   struct target *target = get_current_target(CMD_CTX);
+
+   command_print(CMD, "Supported configuration information");
+
+   /* ID and version */
+   riscv_get_register(target, _marchid, CSR_MARCHID + GDB_REGNO_CSR0);
+   riscv_get_register(target, _mimpid, CSR_MIMPID + GDB_REGNO_CSR0);
+   command_print(CMD, " MARCHID: %lx", csr_marchid);
+   command_print(CMD, "  MIMPID: %lx", csr_mimpid);
+
+   /* ISA */
+   riscv_get_register(target, _misa, CSR_MISA + GDB_REGNO_CSR0);
+   command_print_sameline(CMD, " ISA:");
+   if (riscv_xlen(target) == 32)
+   command_print_sameline(CMD, " RV32");
+   else
+   command_print_sameline(CMD, " RV64");
+   for (int i = 0; i < EXTENSION_NUM; i++) {
+   if (csr_misa & BIT(i)) {
+   if ('X' == ('A' + i))
+   command_print_sameline(CMD, " Zc XLCZ");
+   else
+   command_print_sameline(CMD, " %c", 'A' + i);
+   }
+   }
+   command_print(CMD, " ");
+
+   /* Support */
+   riscv_get_register(target, _mcfg, CSR_MCFG_INFO + GDB_REGNO_CSR0);
+   command_print_sameline(CMD, "MCFG:");
+   if (csr_mcfg & BIT(0))
+   command_print_sameline(CMD, " TEE");
+   if (csr_mcfg & BIT(1))
+   command_print_sameline(CMD, " ECC");
+   if (csr_mcfg & BIT(2))
+   command_print_sameline(CMD, " ECLIC");
+   if (csr_mcfg & BIT(3))
+   command_print_sameline(CMD, " PLIC");
+   if (csr_mcfg & BIT(4))
+   command_print_sameline(CMD, " FIO");
+   if (csr_mcfg & BIT(5))
+   command_print_sameline(CMD, " PPI");
+   if (csr_mcfg & BIT(6))
+   command_print_sameline(CMD, " NICE");
+   if (csr_mcfg & BIT(7))
+   command_print_sameline(CMD, " ILM");
+   if (csr_mcfg & BIT(8))
+   command_print_sameline(CMD, " DLM");
+   if (csr_mcfg & BIT(9))
+   command_print_sameline(CMD, " ICACHE");
+   if (csr_mcfg & BIT(10))
+   command_print_sameline(CMD, " DCACHE");
+   if (csr_mcfg & BIT(11))
+   command_print_sameline(CMD, " SMP");
+   if (csr_mcfg & BIT(12))
+   command_print_sameline(CMD, " DSP-N1");
+   if (csr_mcfg & BIT(13))
+   command_print_sameline(CMD, " DSP-N2");
+   if (csr_mcfg & BIT(14))
+   command_print_sameline(CMD, " DSP-N3");
+   if (csr_mcfg & BIT(15))
+   command_print_sameline(CMD, " Zc-xlcz");
+   if (csr_mcfg & BIT(16))
+   command_print_sameline(CMD, " IREGION");
+   if