Re: [OpenOCD-devel] Request for license extension on your SH Quad SPI driver

2020-11-22 Thread Antonio Borneo
Resent, since the original destinatary
nobuhiro.iwamatsu...@renesas.com is rejected as unknown

Dear Nobuhiro Iwamatsu,

in April 2019, Marek, in copy, ported and submitted to the open source
project OpenOCD the driver for 'SH Quad SPI' that you have originally
developed inside the U-Boot project.
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/spi/sh_qspi.c
http://openocd.zylin.com/5143/

Marek took care to keep the original license "GPL v2.0" and mentioned
you as the original author.

The project OpenOCD is currently licensed as "GPL v2.0 or later". It
is possible it will move to a newer GPL license in the future.
Would it be possible for you to re-license your code as "GPL v2.0 or
later" inside OpenOCD?

Checking U-Boot history of the driver, between your initial submission
in U-Boot and the port to OpenOCD there have been other contributors,
but apart from yours and Marek patches the rest is extremely small and
even not relevant for the port to OpenOCD:
- ccaa9485011b ("spi: sh_qspi: Use BIT macro") Jagan Teki 
- 24b852a7a2b8 ("Move console definitions into a new console.h file")
Simon Glass 
- 83d290c56fab ("SPDX: Convert all of our single license tags to Linux
Kernel style") Tom Rini 
- e2cae5147255 ("spi: Remove unused spi_init") Jagan Teki


So only your and Marek's agreement seems enough to re-license the code
in OpenOCD.

Thanks and Best Regards,
Antonio Borneo


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] Request for license extension on your SH Quad SPI driver

2020-11-22 Thread Antonio Borneo
Dear Nobuhiro Iwamatsu,

in April 2019, Marek, in copy, ported and submitted to the open source
project OpenOCD the driver for 'SH Quad SPI' that you have originally
developed inside the U-Boot project.
https://gitlab.denx.de/u-boot/u-boot/-/blob/master/drivers/spi/sh_qspi.c
http://openocd.zylin.com/5143/

Marek took care to keep the original license "GPL v2.0" and mentioned
you as the original author.

The project OpenOCD is currently licensed as "GPL v2.0 or later". It
is possible it will move to a newer GPL license in the future.
Would it be possible for you to re-license your code as "GPL v2.0 or
later" inside OpenOCD?

Checking U-Boot history of the driver, between your initial submission
in U-Boot and the port to OpenOCD there have been other contributors,
but apart from yours and Marek patches the rest is extremely small and
even not relevant for the port to OpenOCD:
- ccaa9485011b ("spi: sh_qspi: Use BIT macro") Jagan Teki 
- 24b852a7a2b8 ("Move console definitions into a new console.h file")
Simon Glass 
- 83d290c56fab ("SPDX: Convert all of our single license tags to Linux
Kernel style") Tom Rini 
- e2cae5147255 ("spi: Remove unused spi_init") Jagan Teki


So only your and Marek's agreement seems enough to re-license the code
in OpenOCD.

Thanks and Best Regards,
Antonio Borneo


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] [PATCH]: e48ea26 mips_mips64: fix minor host endianness bug

2020-11-22 Thread gerrit
This is an automated email from Gerrit.

Antonio Borneo (borneo.anto...@gmail.com) just uploaded a new patch set to 
Gerrit, which you can find at http://openocd.zylin.com/5944

-- gerrit

commit e48ea2690627b5e824feb6a15c98ab35ff486c71
Author: Antonio Borneo 
Date:   Sun Nov 22 13:02:32 2020 +0100

mips_mips64: fix minor host endianness bug

Commit 80f1a92bd798 ("mips64: Add generic mips64 target support")
adds a log of the target's program counter in function
mips_mips64_debug_entry() by directly casting the little-endian
buffer in pc->value.
This is going to print an incorrect value on big-endian hosts.

Use the function buf_get_u64() to return the register value.

Not tested on real HW. Issue identified with GCC compiler flag
'-Wcast-align=strict' after change http://openocd.zylin.com/5937/
("target/register: use an array of uint8_t for register's value").

Change-Id: Icbda2b54a03fdec287c804e623f5db4252f9cd2a
Signed-off-by: Antonio Borneo 
Fixes: 80f1a92bd798 ("mips64: Add generic mips64 target support")

diff --git a/src/target/mips_mips64.c b/src/target/mips_mips64.c
index f941af5..0fc0897 100644
--- a/src/target/mips_mips64.c
+++ b/src/target/mips_mips64.c
@@ -62,7 +62,7 @@ static int mips_mips64_debug_entry(struct target *target)
mips_mips64_examine_debug_reason(target);
 
LOG_DEBUG("entered debug state at PC 0x%" PRIx64 ", target->state: %s",
- *(uint64_t *)pc->value, target_state_name(target));
+ buf_get_u64(pc->value, 0, 64), target_state_name(target));
 
return ERROR_OK;
 }

-- 


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] [PATCH]: a4f890b armv4_5: fix output of command 'arm reg'

2020-11-22 Thread gerrit
This is an automated email from Gerrit.

Antonio Borneo (borneo.anto...@gmail.com) just uploaded a new patch set to 
Gerrit, which you can find at http://openocd.zylin.com/5942

-- gerrit

commit a4f890b5c4cd2fb07a5ec423bddf8a638f36711d
Author: Antonio Borneo 
Date:   Sun Nov 22 00:33:59 2020 +0100

armv4_5: fix output of command 'arm reg'

Commit fc2abe63fd3c ("armv7m: use generic arm::core_mode") adds
two special modes for ARMv6M and ARMv7M in struct arm_mode_data[].
While these modes do not have any additional register to be dumped
by command 'arm reg', the command still prints an header for these
modes but not followed by any register.

Detect the special modes for ARMv6M and ARMv7M and skip them to
avoid printing the useless header.

Change-Id: I04145769e5742624f143c910eebf9a6f6d8e3cdc
Signed-off-by: Antonio Borneo 
Fixes: fc2abe63fd3c ("armv7m: use generic arm::core_mode")

diff --git a/src/target/armv4_5.c b/src/target/armv4_5.c
index 8ac4825..b725853 100644
--- a/src/target/armv4_5.c
+++ b/src/target/armv4_5.c
@@ -856,6 +856,9 @@ COMMAND_HANDLER(handle_armv4_5_reg_command)
char *sep = "\n";
char *shadow = "";
 
+   if (!arm_mode_data[mode].n_indices)
+   continue;
+
/* label this bank of registers (or shadows) */
switch (arm_mode_data[mode].psr) {
case ARM_MODE_SYS:

-- 


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] [PATCH]: 4f01d2b armv4_5: fix segmentation fault in command 'arm reg'

2020-11-22 Thread gerrit
This is an automated email from Gerrit.

Antonio Borneo (borneo.anto...@gmail.com) just uploaded a new patch set to 
Gerrit, which you can find at http://openocd.zylin.com/5941

-- gerrit

commit 4f01d2b11ada1d739b9f4f951fe6056d1266f7fb
Author: Antonio Borneo 
Date:   Sun Nov 22 00:15:44 2020 +0100

armv4_5: fix segmentation fault in command 'arm reg'

Commit fed713104904 ("armv4_5: support weirdo ARMv6 secure monitor
mode") introduces the secure mode 28 of ARMv6 as a synonymous of
mode 22 (MON), but does not add it in the switch/case in command
'arm reg'.
When command 'arm reg' scans the array arm_mode_data[] on targets
without secure modes, it does not detect the new secure mode as
not supported by the architecture, thus triggers a segmentation
fault when it try to read the register's value from unallocated
memory.
Issue detected with target arm926ejs.

Add the new mode in the switch/case and threat is as the mode MON.

Change-Id: I2b72cc558e097879a7ee6ea601200bfda6b60270
Signed-off-by: Antonio Borneo 
Fixes: fed713104904 ("armv4_5: support weirdo ARMv6 secure monitor mode")

diff --git a/src/target/armv4_5.c b/src/target/armv4_5.c
index 7da28e3..8ac4825 100644
--- a/src/target/armv4_5.c
+++ b/src/target/armv4_5.c
@@ -869,6 +869,7 @@ COMMAND_HANDLER(handle_armv4_5_reg_command)
continue;
/* FALLTHROUGH */
case ARM_MODE_MON:
+   case ARM_MODE_1176_MON:
if (arm->core_type != ARM_CORE_TYPE_SEC_EXT
&& arm->core_type != 
ARM_CORE_TYPE_VIRT_EXT)
continue;

-- 


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] [PATCH]: 2207f5a arm7_9_common: fix host endianness bug in arm7_9_full_context()

2020-11-22 Thread gerrit
This is an automated email from Gerrit.

Antonio Borneo (borneo.anto...@gmail.com) just uploaded a new patch set to 
Gerrit, which you can find at http://openocd.zylin.com/5943

-- gerrit

commit 2207f5af930961430dd325aab2434d2088e71ad4
Author: Antonio Borneo 
Date:   Sun Nov 22 12:29:04 2020 +0100

arm7_9_common: fix host endianness bug in arm7_9_full_context()

The original code passes to ->read_core_regs() and to
->read_xpsr() the pointer to the little-endian buffer reg.value.
This is incorrect because the two functions above require a
pointer to uint32_t, since they already run the conversion with
arm_le_to_h_u32() in the jtag callback.
This causes a mismatch on big-endian host and the registers get
read with the incorrect endianness.

Use an intermediate buffer to read the registers as uint32_t and
to track the destination reg.value pointer, then copy the value in
reg.value after the call to jtag_execute_queue().

Tested with qemu-armeb and an OpenOCD built through buildroot
configured for cortex-a7 big-endian.

Note that if jtag_execute_queue() fails, the openocd register
cache is not updated, so the already modified flags 'valid' and
'dirty' are incorrect. This part should be moved after the call to
jtag_execute_queue() too.

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

diff --git a/src/target/arm7_9_common.c b/src/target/arm7_9_common.c
index d70d273..d992aa7 100644
--- a/src/target/arm7_9_common.c
+++ b/src/target/arm7_9_common.c
@@ -1391,6 +1391,11 @@ static int arm7_9_full_context(struct target *target)
int retval;
struct arm7_9_common *arm7_9 = target_to_arm7_9(target);
struct arm *arm = &arm7_9->arm;
+   struct {
+   uint32_t value;
+   void *reg_p;
+   } read_cache[6 * (16 + 1)];
+   int read_cache_idx = 0;
 
LOG_DEBUG("-");
 
@@ -1433,10 +1438,12 @@ static int arm7_9_full_context(struct target *target)
for (j = 0; j < 15; j++) {
if (!ARMV4_5_CORE_REG_MODE(arm->core_cache,
armv4_5_number_to_mode(i), 
j).valid) {
-   reg_p[j] = (uint32_t 
*)ARMV4_5_CORE_REG_MODE(
+   read_cache[read_cache_idx].reg_p = 
ARMV4_5_CORE_REG_MODE(
arm->core_cache,

armv4_5_number_to_mode(i),
j).value;
+   reg_p[j] = 
&read_cache[read_cache_idx].value;
+   read_cache_idx++;
mask |= 1 << j;
ARMV4_5_CORE_REG_MODE(arm->core_cache,
armv4_5_number_to_mode(i),
@@ -1454,9 +1461,10 @@ static int arm7_9_full_context(struct target *target)
/* check if the PSR has to be read */
if (!ARMV4_5_CORE_REG_MODE(arm->core_cache, 
armv4_5_number_to_mode(i),
16).valid) {
-   arm7_9->read_xpsr(target,
-   (uint32_t 
*)ARMV4_5_CORE_REG_MODE(arm->core_cache,
-   armv4_5_number_to_mode(i), 
16).value, 1);
+   read_cache[read_cache_idx].reg_p = 
ARMV4_5_CORE_REG_MODE(arm->core_cache,
+   armv4_5_number_to_mode(i), 16).value;
+   arm7_9->read_xpsr(target, 
&read_cache[read_cache_idx].value, 1);
+   read_cache_idx++;
ARMV4_5_CORE_REG_MODE(arm->core_cache, 
armv4_5_number_to_mode(i),
16).valid = true;
ARMV4_5_CORE_REG_MODE(arm->core_cache, 
armv4_5_number_to_mode(i),
@@ -1472,6 +1480,14 @@ static int arm7_9_full_context(struct target *target)
retval = jtag_execute_queue();
if (retval != ERROR_OK)
return retval;
+   /*
+* FIXME: regs in cache should be tagged as 'valid' only now,
+* not before the jtag_execute_queue()
+*/
+   while (read_cache_idx) {
+   read_cache_idx--;
+   buf_set_u32(read_cache[read_cache_idx].reg_p, 0, 32, 
read_cache[read_cache_idx].value);
+   }
return ERROR_OK;
 }
 

-- 


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[OpenOCD-devel] GigaDevice support

2020-11-22 Thread kristof . mulier
Hi Marc, Tomas, Karl and others,

I noticed some activity on Gerrit regarding the Risc-V based GigaDevice 
GD32VF103 microcontroller:
http://openocd.zylin.com/#/c/5839/


I just want to inform all of you that GigaDevice forked OpenOCD a couple of 
days ago:
https://github.com/GigaDevice-Semiconductor/openocd

In their fork, they're adding support for their chips. It can be a first step 
to upstream these fixes to the official OpenOCD repo. I'm in contact with some 
engineers at GigaDevice. They're very kind and helpful, so please don't 
hesitate to post questions/ideas/issues/... on their GitHub page.

Kind regards,
Kristof Mulier




- Oorspronkelijk bericht -
Van: "Marc Schink (Code Review)" 
Aan: "kristof mulier" 
Cc: "Tomas Vanek" , "Karl Palsson" 
Verzonden: Zondag 22 november 2020 11:27:58
Onderwerp: Change in openocd[master]: flash/nor: Add GigaDevice GD32VF103 driver

Marc Schink has posted comments on this change. ( http://openocd.zylin.com/5839 
)

Change subject: flash/nor: Add GigaDevice GD32VF103 driver
..


Patch Set 2:

> More than 70% of code is common for both stm32f1.c and gd32vf103.c In terms 
> of the long term maintenance the duplicated code is pain.

I know but it somehow feels wrong to use the stm32f1 driver for a different MCU 
family with different architecture. I didn't compare both drivers. Are you sure 
that we don't need some ugly hacks to make the GD32VF work with the current 
stm32f1 driver?

-- 
To view, visit http://openocd.zylin.com/5839
To unsubscribe, visit http://openocd.zylin.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ia17e1d28649def0e9164e30c2b9163cb57a97029
Gerrit-PatchSet: 2
Gerrit-Project: openocd
Gerrit-Branch: master
Gerrit-Owner: Kristof Mulier 
Gerrit-Reviewer: Karl Palsson 
Gerrit-Reviewer: Marc Schink 
Gerrit-Reviewer: Tomas Vanek 
Gerrit-Reviewer: jenkins
Gerrit-HasComments: No


___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel