Re: [PATCH rtems-source-builder] 6: Update MicroBlaze gdb to 12.1

2023-03-09 Thread Frank Kühndel 

Hello Chris,
Hello Alex,

On 3/8/23 20:51, Chris Johns wrote:

Subject:
Re: [PATCH rtems-source-builder] 6: Update MicroBlaze gdb to 12.1
From:
Chris Johns 
Date:
3/8/23, 20:51

To:
Alex White , devel@rtems.org


What hosts have you tested building this on?

I only ask as gdb-13 is not building on FeeBSD 13.1 for me.


I tried Alex's patch on top of RSB 
bfed51462eafcb6a5102a2d6d80b233f3c6ef635 for RTEMS 6 and microblaze:


almalinux 8.7: OK   [gcc (GCC) 8.5.0]
debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
fedora 37: OK   [gcc (GCC) 12.2.1]
opensuse-leap 15.4: OK  [gcc (SUSE Linux) 12.2.1]
ubuntu 22.04: OK[gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]

With FreeBSD I cannot help, sorry. Also, the above containers use the 
latest OS versions. I did not test older ones. Moreover, Opensuse 15.4 
does not use gcc 12 by default but a much older compiler.


*Without* Alex's patch these builds fail on Ubuntu and Fedora when 
building building microblaze-rtems6-gdb-11.2-x86_64-linux-gnu-1 with the 
following error:


In file included from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/mic
roblaze.h:21,
 from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/sim
-main.h:21,
 from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/../
common/dv-cfi.c:37:
/home/minna/src/rtems-source-builder/rtems/build/microblaze-rtems6-gdb-11.2-x86_
64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/../../opcodes/microblaze-
opcm.h:45:9: error: ‘fsqrt’ redeclared as different kind of symbol
   45 |   fint, fsqrt,
  | ^
In file included from ../../gnulib/import/math.h:41,
 from 
/home/minna/src/rtems-source-builder/rtems/build/microblaz

e-rtems6-gdb-11.2-x86_64-linux-gnu-1/build/sim/../../gdb-11.2/sim/microblaze/../
common/dv-cfi.c:28:
/usr/include/bits/mathcalls-narrow.h:36:20: note: previous declaration 
of ‘fsqrt

’ with type ‘float(double)’
   36 | __MATHCALL_NARROW (__MATHCALL_NAME (sqrt), 
__MATHCALL_REDIR_NAME2 (sqrt)

, 1);
  |^~~

Greetings,
Frank



Chris

On 9/3/2023 2:14 am, Alex White wrote:

GDB 11.2 fails to compile on Ubuntu 22.04 for MicroBlaze.
---
  rtems/config/6/rtems-microblaze.bset | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index ea59313..e05fd7b 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -13,7 +13,7 @@
  
  devel/expat-2.4.8-1

  devel/gmp-6.2.1
-tools/rtems-gdb-11.2
+tools/rtems-gdb-12.1
  
  tools/rtems-xilinx-binutils-2.36

  tools/rtems-xilinx-gcc-10-newlib-head

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel



--
embedded brains GmbH
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone:  +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11
fax:+49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[lwip 1/2] Fix build for arm/tms570 BSPs

2023-03-09 Thread Sebastian Huber 
---
 defs/bsps/arm/tms570_base.json   |  6 --
 uLan/ports/driver/tms570_emac/eth_lwip.c | 15 +++
 uLan/ports/driver/tms570_emac/phy_dp83848h.c |  1 +
 uLan/ports/driver/tms570_emac/phy_dp83848h.h |  2 ++
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/defs/bsps/arm/tms570_base.json b/defs/bsps/arm/tms570_base.json
index 33cd969..050f77a 100644
--- a/defs/bsps/arm/tms570_base.json
+++ b/defs/bsps/arm/tms570_base.json
@@ -1,9 +1,11 @@
 {
"header-paths-to-import": [
"uLan/ports/driver/tms570_emac",
-   "uLan/ports/os"
+   "uLan/ports/os",
+   "cpsw/src/include"
],
"source-paths-to-import": [
-   "uLan/ports/driver/tms570_emac"
+   "uLan/ports/driver/tms570_emac",
+   "cpsw/src"
]
 }
diff --git a/uLan/ports/driver/tms570_emac/eth_lwip.c 
b/uLan/ports/driver/tms570_emac/eth_lwip.c
index 6105268..0315cdf 100644
--- a/uLan/ports/driver/tms570_emac/eth_lwip.c
+++ b/uLan/ports/driver/tms570_emac/eth_lwip.c
@@ -39,7 +39,7 @@
 #include "netif/etharp.h" /* includes - lwip/ip.h, lwip/netif.h, 
lwip/ip_addr.h, lwip/pbuf.h */
 #include "eth_lwip_default.h"
 #include "eth_lwip.h"
-#include "beaglebone.h"
+#include "tms570_netif.h"
 #include 
 
 /* The lwIP network interface structure for the Ethernet EMAC. */
@@ -72,8 +72,13 @@ eth_lwip_get_dhcp_info(void)
   }
 }
 
-int8_t
-eth_lwip_init(uint8_t *mac_addr)
+int start_networking(
+  struct netif  *net_interface,
+  ip_addr_t *ipaddr,
+  ip_addr_t *netmask,
+  ip_addr_t *gateway,
+  unsigned char *mac_addr
+)
 {
   unsigned int instance_number = 0;
   int8_t retVal = SUCCESS;
@@ -103,15 +108,17 @@ eth_lwip_init(uint8_t *mac_addr)
 #endif
 
   netif_tmp = netif_add(netif, &ip_addr, &net_mask, &gw_addr,
-NULL, ETH_LWIP_INIT_NETIF_FNC, tcpip_input);
+NULL, tms570_eth_init_netif, tcpip_input);
 
   if (netif_tmp == NULL)
 return NETIF_ADD_ERR;
 
   netif_set_default(netif);
+#if LWIP_NETIF_API
   netifapi_netif_set_up(netif);
 #if !STATIC_IP_ADDRESS
   netifapi_dhcp_start(netif);
+#endif
 #endif
 
   return retVal;
diff --git a/uLan/ports/driver/tms570_emac/phy_dp83848h.c 
b/uLan/ports/driver/tms570_emac/phy_dp83848h.c
index d20f669..dec1011 100644
--- a/uLan/ports/driver/tms570_emac/phy_dp83848h.c
+++ b/uLan/ports/driver/tms570_emac/phy_dp83848h.c
@@ -34,6 +34,7 @@
 
 #include "ti_drv_mdio.h"
 #include "phy_dp83848h.h"
+#include "mdio.h"
 
 #ifndef TRUE
 /**
diff --git a/uLan/ports/driver/tms570_emac/phy_dp83848h.h 
b/uLan/ports/driver/tms570_emac/phy_dp83848h.h
index 58d9f04..8ddb3ec 100644
--- a/uLan/ports/driver/tms570_emac/phy_dp83848h.h
+++ b/uLan/ports/driver/tms570_emac/phy_dp83848h.h
@@ -35,6 +35,8 @@
 #ifndef __DRV_PHY_H
 #define __DRV_PHY_H
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
-- 
2.35.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[lwip 2/2] Move and rename sys_arch_data_sync_barier()

2023-03-09 Thread Sebastian Huber 
This function is not present in the lwIP mainline.  Move it to the only
user and rename it to tms570__data_sync_barier().
---
 uLan/ports/driver/tms570_emac/tms570_netif.c | 16 
 uLan/ports/os/rtems/arch/sys_arch.h  |  5 -
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/uLan/ports/driver/tms570_emac/tms570_netif.c 
b/uLan/ports/driver/tms570_emac/tms570_netif.c
index 8d14687..e166869 100644
--- a/uLan/ports/driver/tms570_emac/tms570_netif.c
+++ b/uLan/ports/driver/tms570_emac/tms570_netif.c
@@ -151,6 +151,14 @@ static void tms570_eth_init_netif_fill(struct netif 
*netif);
 static void tms570_eth_init_buffer_descriptors(struct tms570_netif_state 
*nf_state);
 static void tms570_eth_init_set_pinmux();
 
+static inline void
+tms570_data_sync_barier(void)
+{
+#ifdef __arm__
+  _ARM_Data_synchronization_barrier();
+#endif
+}
+
 /* initializing functions **/
 
 
@@ -685,7 +693,7 @@ tms570_eth_send_raw(struct netif *netif, struct pbuf *pbuf)
   if (curr_bd == NULL)
 txch->inactive_tail = curr_bd;
 
-  sys_arch_data_sync_barier();
+  tms570_data_sync_barier();
 
   if (txch->active_tail == NULL) {
 txch->active_head = packet_head;
@@ -767,7 +775,7 @@ tms570_eth_process_irq_rx(void *arg)
 unsigned int processed_rx_len = 0;
 int corrupt_fl = 0;
 
-sys_arch_data_sync_barier();
+tms570_data_sync_barier();
 
 pbuf = curr_bd->pbuf;
 total_rx_len = curr_bd->flags_pktlen & 0x;
@@ -1086,7 +1094,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state 
*nf_state, int single_fl)
   rxch->inactive_head = curr_bd->next;
 
   curr_bd->next = NULL;
-  sys_arch_data_sync_barier();
+  tms570_data_sync_barier();
 
   if (rxch->active_head == NULL) {
 rxch->active_head = curr_head;
@@ -1094,7 +1102,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state 
*nf_state, int single_fl)
 tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
   } else {
 rxch->active_tail->next = curr_head;
-sys_arch_data_sync_barier();
+tms570_data_sync_barier();
 if ((rxch->active_tail->flags_pktlen & EMAC_DSC_FLAG_EOQ) != 0)
   tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
 rxch->active_tail = curr_bd;
diff --git a/uLan/ports/os/rtems/arch/sys_arch.h 
b/uLan/ports/os/rtems/arch/sys_arch.h
index 6ec578b..eb85e3b 100644
--- a/uLan/ports/os/rtems/arch/sys_arch.h
+++ b/uLan/ports/os/rtems/arch/sys_arch.h
@@ -124,11 +124,6 @@ sys_arch_unprotect(sys_prot_t pval)
 {
   rtems_interrupt_enable(pval);
 }
-
-static inline void
-sys_arch_data_sync_barier(void){
-  _ARM_Data_synchronization_barrier();
-}
 #else
 sys_prot_t sys_arch_protect();
 
-- 
2.35.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2] c-user/chains: Correct iteration example code

2023-03-09 Thread Kinsey Moore 
On Thu, Mar 9, 2023 at 1:01 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 09.03.23 03:33, Kinsey Moore wrote:
> > Casting the node returned by rtems_chain_head is incorrect. That node is
> > owned by the control structure and use of it post-cast could cause
> > memory corruption.
> > ---
> >   c-user/chains.rst | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/c-user/chains.rst b/c-user/chains.rst
> > index f518ef4..2044966 100644
> > --- a/c-user/chains.rst
> > +++ b/c-user/chains.rst
> > @@ -193,10 +193,14 @@ placed on another chain:
> >   rtems_chain_initialize_empty (out);
> >
> >   node = rtems_chain_head (chain);
> > +
> > +/* The node returned by rtems_chain_head() is owned by the
> chain */
> > +node = rtems_chain_next(node);
>
> You can simply use rtems_chain_first() instead of this head/next
> combination.
>
Thanks, I'll make that improvement before committing!

Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] bsps/stm32h7: fix propagation of configured HSE freq. value into the code

2023-03-09 Thread Karel Gardas 
Sponsored-By:   Precidata
---
 .../arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c | 4 
 .../stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c   | 4 
 .../stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c  | 6 ++
 .../stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c   | 4 
 .../arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c | 4 
 5 files changed, 22 insertions(+)

diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
index a8a9ff0b4b..2d53f114c1 100644
--- a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
@@ -49,6 +49,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
index a8a9ff0b4b..2d53f114c1 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
@@ -49,6 +49,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
index 2dc9542597..269288d2c0 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
@@ -91,7 +91,13 @@
 
 #include "stm32h7xx.h"
 #include 
+#ifdef __rtems__
+#include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
 
+#endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
 #endif /* HSE_VALUE */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
index 1260694d8b..59e66e133e 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
@@ -93,6 +93,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
index db11aa19b1..52e8eaafc4 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
@@ -48,6 +48,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2400) /*!< Value of the External 
oscillator in Hz */
-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

2023-03-09 Thread Kinsey Moore 
Normally with rtems-lwip I would complain that this doesn't follow the
convention of using #ifdef __rtems__ to modify files from upstream sources
(each root directory except rtemslwip has an upstream source), but the uLan
authors have given permission to fully integrate this code into the
rtemslwip directory where possible (the TI code will go into its own
directory). This patch looks good.

On Thu, Mar 9, 2023 at 6:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> This function is not present in the lwIP mainline.  Move it to the only
> user and rename it to tms570__data_sync_barier().
> ---
>  uLan/ports/driver/tms570_emac/tms570_netif.c | 16 
>  uLan/ports/os/rtems/arch/sys_arch.h  |  5 -
>  2 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/uLan/ports/driver/tms570_emac/tms570_netif.c
> b/uLan/ports/driver/tms570_emac/tms570_netif.c
> index 8d14687..e166869 100644
> --- a/uLan/ports/driver/tms570_emac/tms570_netif.c
> +++ b/uLan/ports/driver/tms570_emac/tms570_netif.c
> @@ -151,6 +151,14 @@ static void tms570_eth_init_netif_fill(struct netif
> *netif);
>  static void tms570_eth_init_buffer_descriptors(struct tms570_netif_state
> *nf_state);
>  static void tms570_eth_init_set_pinmux();
>
> +static inline void
> +tms570_data_sync_barier(void)
> +{
> +#ifdef __arm__
> +  _ARM_Data_synchronization_barrier();
> +#endif
> +}
> +
>  /* initializing functions
> **/
>
>
> @@ -685,7 +693,7 @@ tms570_eth_send_raw(struct netif *netif, struct pbuf
> *pbuf)
>if (curr_bd == NULL)
>  txch->inactive_tail = curr_bd;
>
> -  sys_arch_data_sync_barier();
> +  tms570_data_sync_barier();
>
>if (txch->active_tail == NULL) {
>  txch->active_head = packet_head;
> @@ -767,7 +775,7 @@ tms570_eth_process_irq_rx(void *arg)
>  unsigned int processed_rx_len = 0;
>  int corrupt_fl = 0;
>
> -sys_arch_data_sync_barier();
> +tms570_data_sync_barier();
>
>  pbuf = curr_bd->pbuf;
>  total_rx_len = curr_bd->flags_pktlen & 0x;
> @@ -1086,7 +1094,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state
> *nf_state, int single_fl)
>rxch->inactive_head = curr_bd->next;
>
>curr_bd->next = NULL;
> -  sys_arch_data_sync_barier();
> +  tms570_data_sync_barier();
>
>if (rxch->active_head == NULL) {
>  rxch->active_head = curr_head;
> @@ -1094,7 +1102,7 @@ tms570_eth_rx_pbuf_refill(struct tms570_netif_state
> *nf_state, int single_fl)
>  tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
>} else {
>  rxch->active_tail->next = curr_head;
> -sys_arch_data_sync_barier();
> +tms570_data_sync_barier();
>  if ((rxch->active_tail->flags_pktlen & EMAC_DSC_FLAG_EOQ) != 0)
>tms570_eth_hw_set_RX_HDP(nf_state, rxch->active_head);
>  rxch->active_tail = curr_bd;
> diff --git a/uLan/ports/os/rtems/arch/sys_arch.h
> b/uLan/ports/os/rtems/arch/sys_arch.h
> index 6ec578b..eb85e3b 100644
> --- a/uLan/ports/os/rtems/arch/sys_arch.h
> +++ b/uLan/ports/os/rtems/arch/sys_arch.h
> @@ -124,11 +124,6 @@ sys_arch_unprotect(sys_prot_t pval)
>  {
>rtems_interrupt_enable(pval);
>  }
> -
> -static inline void
> -sys_arch_data_sync_barier(void){
> -  _ARM_Data_synchronization_barrier();
> -}
>  #else
>  sys_prot_t sys_arch_protect();
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

2023-03-09 Thread Sebastian Huber 

On 09.03.23 14:46, Kinsey Moore wrote:
Normally with rtems-lwip I would complain that this doesn't follow the 
convention of using #ifdef __rtems__ to modify files from upstream 
sources (each root directory except rtemslwip has an upstream source), 
but the uLan authors have given permission to fully integrate this code 
into the rtemslwip directory where possible (the TI code will go into 
its own directory). This patch looks good.


Ok, does this mean this driver as an active upstream?

I still have some issues with this driver since the MDIO interfaces seem 
to be duplicated.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [lwip 1/2] Fix build for arm/tms570 BSPs

2023-03-09 Thread Kinsey Moore 
The changes to TI sources for dp83848h should use the #ifdef __rtems__
convention since they will not be fully integrated into the rtemslwip
directory.

Kinsey

On Thu, Mar 9, 2023 at 6:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  defs/bsps/arm/tms570_base.json   |  6 --
>  uLan/ports/driver/tms570_emac/eth_lwip.c | 15 +++
>  uLan/ports/driver/tms570_emac/phy_dp83848h.c |  1 +
>  uLan/ports/driver/tms570_emac/phy_dp83848h.h |  2 ++
>  4 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/defs/bsps/arm/tms570_base.json
> b/defs/bsps/arm/tms570_base.json
> index 33cd969..050f77a 100644
> --- a/defs/bsps/arm/tms570_base.json
> +++ b/defs/bsps/arm/tms570_base.json
> @@ -1,9 +1,11 @@
>  {
> "header-paths-to-import": [
> "uLan/ports/driver/tms570_emac",
> -   "uLan/ports/os"
> +   "uLan/ports/os",
> +   "cpsw/src/include"
> ],
> "source-paths-to-import": [
> -   "uLan/ports/driver/tms570_emac"
> +   "uLan/ports/driver/tms570_emac",
> +   "cpsw/src"
> ]
>  }
> diff --git a/uLan/ports/driver/tms570_emac/eth_lwip.c
> b/uLan/ports/driver/tms570_emac/eth_lwip.c
> index 6105268..0315cdf 100644
> --- a/uLan/ports/driver/tms570_emac/eth_lwip.c
> +++ b/uLan/ports/driver/tms570_emac/eth_lwip.c
> @@ -39,7 +39,7 @@
>  #include "netif/etharp.h" /* includes - lwip/ip.h, lwip/netif.h,
> lwip/ip_addr.h, lwip/pbuf.h */
>  #include "eth_lwip_default.h"
>  #include "eth_lwip.h"
> -#include "beaglebone.h"
> +#include "tms570_netif.h"
>  #include 
>
>  /* The lwIP network interface structure for the Ethernet EMAC. */
> @@ -72,8 +72,13 @@ eth_lwip_get_dhcp_info(void)
>}
>  }
>
> -int8_t
> -eth_lwip_init(uint8_t *mac_addr)
> +int start_networking(
> +  struct netif  *net_interface,
> +  ip_addr_t *ipaddr,
> +  ip_addr_t *netmask,
> +  ip_addr_t *gateway,
> +  unsigned char *mac_addr
> +)
>  {
>unsigned int instance_number = 0;
>int8_t retVal = SUCCESS;
> @@ -103,15 +108,17 @@ eth_lwip_init(uint8_t *mac_addr)
>  #endif
>
>netif_tmp = netif_add(netif, &ip_addr, &net_mask, &gw_addr,
> -NULL, ETH_LWIP_INIT_NETIF_FNC, tcpip_input);
> +NULL, tms570_eth_init_netif, tcpip_input);
>
>if (netif_tmp == NULL)
>  return NETIF_ADD_ERR;
>
>netif_set_default(netif);
> +#if LWIP_NETIF_API
>netifapi_netif_set_up(netif);
>  #if !STATIC_IP_ADDRESS
>netifapi_dhcp_start(netif);
> +#endif
>  #endif
>
>return retVal;
> diff --git a/uLan/ports/driver/tms570_emac/phy_dp83848h.c
> b/uLan/ports/driver/tms570_emac/phy_dp83848h.c
> index d20f669..dec1011 100644
> --- a/uLan/ports/driver/tms570_emac/phy_dp83848h.c
> +++ b/uLan/ports/driver/tms570_emac/phy_dp83848h.c
> @@ -34,6 +34,7 @@
>
>  #include "ti_drv_mdio.h"
>  #include "phy_dp83848h.h"
> +#include "mdio.h"
>
>  #ifndef TRUE
>  /**
> diff --git a/uLan/ports/driver/tms570_emac/phy_dp83848h.h
> b/uLan/ports/driver/tms570_emac/phy_dp83848h.h
> index 58d9f04..8ddb3ec 100644
> --- a/uLan/ports/driver/tms570_emac/phy_dp83848h.h
> +++ b/uLan/ports/driver/tms570_emac/phy_dp83848h.h
> @@ -35,6 +35,8 @@
>  #ifndef __DRV_PHY_H
>  #define __DRV_PHY_H
>
> +#include 
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add Formal Verification chapter v3

2023-03-09 Thread andrew.butterfi...@scss.tcd.ie 
ping


From: devel  on behalf of 
"andrew.butterfi...@scss.tcd.ie" 
Date: Friday 10 February 2023 at 16:10
To: "rtems-de...@rtems.org" 
Subject: eng: Add Formal Verification chapter v3

Dear RTEMS Developers,
Here is a 3rd version of the proposed Formal Verification chapter
 to be added to the Software Engineering Manual.

The patch-set is attached here, as I cannot use git-mail.

Best Regards,
  Andrew


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [lwip 2/2] Move and rename sys_arch_data_sync_barier()

2023-03-09 Thread Kinsey Moore 
On Thu, Mar 9, 2023 at 7:48 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 09.03.23 14:46, Kinsey Moore wrote:
> > Normally with rtems-lwip I would complain that this doesn't follow the
> > convention of using #ifdef __rtems__ to modify files from upstream
> > sources (each root directory except rtemslwip has an upstream source),
> > but the uLan authors have given permission to fully integrate this code
> > into the rtemslwip directory where possible (the TI code will go into
> > its own directory). This patch looks good.
>
> Ok, does this mean this driver as an active upstream?
>

The non-TI portions of the uLan upstream are not active and will be
integrated sometime soon. The person doing the integrating needs to
evaluate the source of the TI portions and we can see how active it is. As
of now, I don't know how active the TI portions are.

>
> I still have some issues with this driver since the MDIO interfaces seem
> to be duplicated.
>


Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add Formal Verification chapter v3

2023-03-09 Thread Gedare Bloom 
Hi Andrew,

In this case, since the patches are attachments, would you happen to
have a hosted git (github?) repo that I could examine to facilitate a
review. I can only review inline patches efficiently by email.

Gedare

On Thu, Mar 9, 2023 at 6:52 AM andrew.butterfi...@scss.tcd.ie
 wrote:
>
> ping
>
>
>
>
>
> From: devel  on behalf of 
> "andrew.butterfi...@scss.tcd.ie" 
> Date: Friday 10 February 2023 at 16:10
> To: "rtems-de...@rtems.org" 
> Subject: eng: Add Formal Verification chapter v3
>
>
>
> Dear RTEMS Developers,
>
> Here is a 3rd version of the proposed Formal Verification chapter
>
>  to be added to the Software Engineering Manual.
>
>
>
> The patch-set is attached here, as I cannot use git-mail.
>
>
>
> Best Regards,
>
>   Andrew
>
>
>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs v2] c-user/chains: Correct iteration example code

2023-03-09 Thread Chris Johns 
On 10/3/2023 10:12 pm, Kinsey Moore wrote:
> On Thu, Mar 9, 2023 at 1:01 AM Sebastian Huber
>  >
> wrote:
> On 09.03.23 03:33, Kinsey Moore wrote:
> > Casting the node returned by rtems_chain_head is incorrect. That node is
> > owned by the control structure and use of it post-cast could cause
> > memory corruption.
> > ---
> >   c-user/chains.rst | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/c-user/chains.rst b/c-user/chains.rst
> > index f518ef4..2044966 100644
> > --- a/c-user/chains.rst
> > +++ b/c-user/chains.rst
> > @@ -193,10 +193,14 @@ placed on another chain:
> >           rtems_chain_initialize_empty (out);
> >   
> >           node = rtems_chain_head (chain);
> > +
> > +        /* The node returned by rtems_chain_head() is owned by the 
> chain */
> > +        node = rtems_chain_next(node);
> 
> You can simply use rtems_chain_first() instead of this head/next
> combination.
> 
> Thanks, I'll make that improvement before committing!

Nice :)

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-source-builder] 6: Update MicroBlaze gdb to 12.1

2023-03-09 Thread Chris Johns 
On 9/3/2023 8:10 pm, Frank Kühndel wrote:
> Hello Chris,
> Hello Alex,
> 
> On 3/8/23 20:51, Chris Johns wrote:
>> Subject:
>> Re: [PATCH rtems-source-builder] 6: Update MicroBlaze gdb to 12.1
>> From:
>> Chris Johns 
>> Date:
>> 3/8/23, 20:51
>>
>> To:
>> Alex White , devel@rtems.org
>>
>>
>> What hosts have you tested building this on?
>>
>> I only ask as gdb-13 is not building on FeeBSD 13.1 for me.
> 
> I tried Alex's patch on top of RSB bfed51462eafcb6a5102a2d6d80b233f3c6ef635 
> for
> RTEMS 6 and microblaze:
> 
> almalinux 8.7: OK   [gcc (GCC) 8.5.0]
> debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
> fedora 37: OK   [gcc (GCC) 12.2.1]
> opensuse-leap 15.4: OK  [gcc (SUSE Linux) 12.2.1]
> ubuntu 22.04: OK    [gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]
> 
> With FreeBSD I cannot help, sorry. Also, the above containers use the latest 
> OS
> versions. I did not test older ones. Moreover, Opensuse 15.4 does not use gcc 
> 12
> by default but a much older compiler.

Thanks Frank, this is a great set of results.

This change is fine to push.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 0/2] bsps/riscv: Add kendrytek210 riscv BSP variant

2023-03-09 Thread Alan Cudmore 
This patch set adds the riscv/kendrytek210 BSP variant to support the
Kendryte K210 Dual Core RISC-V SoC. The BSP runs on the renode.io
 simulator, the Sipeed MAiX BiT and MAiXDuino boards, and would likely
run on other boards. RTEMS binaries can be flashed to the boards using
the kflash python utility available through the pip command. Currently
the BSP supports the console UART which is shared with the frdme310arty,
an interrupt controller, and timer. The included device tree source
just covers the minimal set of peripherals. The device tree can be
expanded as additional device support is addded.
Manufacturer, board links, and other information can be found in
ticket #4876.
Documentation that describes how to build and run the BSP on the 
boards and simulator has been prepared and will be submitted after the bsp
is merged.

Updates #4876

Alan Cudmore (2):
  spec: add riscv Kendryte K210 variant options
  bsps/riscv: add riscv/kendrytek210 BSP variant

 bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
 bsps/riscv/riscv/console/console-config.c |  10 +-
 bsps/riscv/riscv/console/fe310-uart.c |   2 +-
 bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
 bsps/riscv/riscv/include/bsp.h|   4 +
 bsps/riscv/riscv/include/bsp/k210.h   |  91 +
 .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
 bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
 bsps/riscv/riscv/start/bspstart.c |  42 +++
 spec/build/bsps/optdtb.yml|   4 +-
 spec/build/bsps/optdtbheaderpath.yml  |   2 +
 spec/build/bsps/optfdtuboot.yml   |   3 +
 spec/build/bsps/riscv/optramsize.yml  |   2 +
 spec/build/bsps/riscv/riscv/abi.yml   |   1 +
 .../bsps/riscv/riscv/bspkendrtyek210.yml  |  19 ++
 spec/build/bsps/riscv/riscv/grp.yml   |   4 +
 spec/build/bsps/riscv/riscv/obj.yml   |   1 +
 .../bsps/riscv/riscv/optkendrytek210.yml  |  18 +
 spec/build/bsps/riscv/riscv/optns16550max.yml |   4 +-
 spec/build/bsps/riscv/riscv/optsifiveuart.yml |  20 ++
 spec/build/cpukit/optsmp.yml  |   1 +
 21 files changed, 764 insertions(+), 8 deletions(-)
 create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
 create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
 create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
 create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h
 create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml

-- 
2.25.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] bsps/riscv: add riscv/kendrytek210 BSP variant

2023-03-09 Thread Alan Cudmore 
This patch set adds support for the Kendryte K210 RISC-V BSP variant.
The SoC uses existing PLIC, Timer, and console UART. It only needs
SoC specific initalization and an embedded device tree binary similar
to the polarfire SoC BSP.

Updates #4876
---
 bsps/riscv/riscv/config/kendrytek210.cfg  |   9 +
 bsps/riscv/riscv/console/console-config.c |  10 +-
 bsps/riscv/riscv/console/fe310-uart.c |   2 +-
 bsps/riscv/riscv/dts/kendryte-k210.dts| 216 
 bsps/riscv/riscv/include/bsp.h|   4 +
 bsps/riscv/riscv/include/bsp/k210.h   |  91 +
 .../riscv/include/bsp/kendryte-k210-dtb.h | 315 ++
 bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
 bsps/riscv/riscv/start/bspstart.c |  42 +++
 9 files changed, 687 insertions(+), 6 deletions(-)
 create mode 100644 bsps/riscv/riscv/config/kendrytek210.cfg
 create mode 100644 bsps/riscv/riscv/dts/kendryte-k210.dts
 create mode 100644 bsps/riscv/riscv/include/bsp/k210.h
 create mode 100644 bsps/riscv/riscv/include/bsp/kendryte-k210-dtb.h

diff --git a/bsps/riscv/riscv/config/kendrytek210.cfg 
b/bsps/riscv/riscv/config/kendrytek210.cfg
new file mode 100644
index 00..b04e78b0e9
--- /dev/null
+++ b/bsps/riscv/riscv/config/kendrytek210.cfg
@@ -0,0 +1,9 @@
+include $(RTEMS_ROOT)/make/custom/default.cfg
+
+RTEMS_CPU = riscv
+
+CPU_CFLAGS = -march=rv64imafdc -mabi=lp64d -mcmodel=medany
+
+LDFLAGS = -Wl,--gc-sections
+
+CFLAGS_OPTIMIZE_V ?= -O2 -g -ffunction-sections -fdata-sections
diff --git a/bsps/riscv/riscv/console/console-config.c 
b/bsps/riscv/riscv/console/console-config.c
index 4916191e0b..72743fe9d5 100644
--- a/bsps/riscv/riscv/console/console-config.c
+++ b/bsps/riscv/riscv/console/console-config.c
@@ -55,7 +55,7 @@
 #include 
 #include 
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
 #include 
 static fe310_uart_context fe310_uart_instance;
 #endif
@@ -239,7 +239,7 @@ static void riscv_console_probe(void)
 }
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
 if (fdt_stringlist_contains(compat, compat_len, "sifive,uart0")) {
   fe310_uart_context *ctx;
 
@@ -255,7 +255,7 @@ static void riscv_console_probe(void)
 riscv_console.getchar = fe310_uart_read;
   }
 
-  rtems_termios_device_context_initialize(&ctx->base, "FE310UART");
+  rtems_termios_device_context_initialize(&ctx->base, "SIFIVEUART");
 }
 #endif
 
@@ -290,7 +290,7 @@ rtems_status_code console_initialize(
   size_t i;
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
   fe310_uart_context *ctx;
   char fe310_path[] = "/dev/ttyS0";
 #endif
@@ -326,7 +326,7 @@ rtems_status_code console_initialize(
   }
 #endif
 
-#if RISCV_ENABLE_FRDME310ARTY_SUPPORT != 0
+#if RISCV_ENABLE_SIFIVE_UART_SUPPORT != 0
   ctx = &fe310_uart_instance;
   rtems_termios_device_install(
 fe310_path,
diff --git a/bsps/riscv/riscv/console/fe310-uart.c 
b/bsps/riscv/riscv/console/fe310-uart.c
index 506521add0..ddabcff4c8 100644
--- a/bsps/riscv/riscv/console/fe310-uart.c
+++ b/bsps/riscv/riscv/console/fe310-uart.c
@@ -53,7 +53,7 @@ static void fe310_uart_write (
   fe310_uart_context * ctx = (fe310_uart_context*) base;
   size_t i;
 
-  ctx->regs->div = riscv_get_core_frequency() / 115200 - 1;
+  ctx->regs->div = (riscv_get_core_frequency() / 115200 - 1) & 0x;
   ctx->regs->txctrl |= 1;
   ctx->regs->rxctrl |= 1;
 
diff --git a/bsps/riscv/riscv/dts/kendryte-k210.dts 
b/bsps/riscv/riscv/dts/kendryte-k210.dts
new file mode 100644
index 00..379aaf01a3
--- /dev/null
+++ b/bsps/riscv/riscv/dts/kendryte-k210.dts
@@ -0,0 +1,216 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) Alan Cudmore
+ * Copyright (C) Padmarao Begari
+ * Copyright (C) 2022 Microchip Technology Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER

[PATCH 1/2] spec: add riscv Kendryte K210 variant options

2023-03-09 Thread Alan Cudmore 
This patch includes the spec/build options for the riscv kendrytek210
BSP variant. It includes options to allow the frdme310arty console
UART to be used on multiple BSPS, device tree options, memory
options, and other required options for the variant.
---
 spec/build/bsps/optdtb.yml|  4 +++-
 spec/build/bsps/optdtbheaderpath.yml  |  2 ++
 spec/build/bsps/optfdtuboot.yml   |  3 +++
 spec/build/bsps/riscv/optramsize.yml  |  2 ++
 spec/build/bsps/riscv/riscv/abi.yml   |  1 +
 .../bsps/riscv/riscv/bspkendrtyek210.yml  | 19 ++
 spec/build/bsps/riscv/riscv/grp.yml   |  4 
 spec/build/bsps/riscv/riscv/obj.yml   |  1 +
 .../bsps/riscv/riscv/optkendrytek210.yml  | 18 +
 spec/build/bsps/riscv/riscv/optns16550max.yml |  4 +++-
 spec/build/bsps/riscv/riscv/optsifiveuart.yml | 20 +++
 spec/build/cpukit/optsmp.yml  |  1 +
 12 files changed, 77 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optkendrytek210.yml
 create mode 100644 spec/build/bsps/riscv/riscv/optsifiveuart.yml

diff --git a/spec/build/bsps/optdtb.yml b/spec/build/bsps/optdtb.yml
index 78fed67866..f775dc7750 100644
--- a/spec/build/bsps/optdtb.yml
+++ b/spec/build/bsps/optdtb.yml
@@ -6,7 +6,9 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
-- enabled-by: riscv/mpfs64imafdc
+- enabled-by:
+  - riscv/mpfs64imafdc
+  - riscv/kendrytek210
   value: true
 - enabled-by: true
   value: false
diff --git a/spec/build/bsps/optdtbheaderpath.yml 
b/spec/build/bsps/optdtbheaderpath.yml
index 65573c4cb8..944c8e830e 100644
--- a/spec/build/bsps/optdtbheaderpath.yml
+++ b/spec/build/bsps/optdtbheaderpath.yml
@@ -8,6 +8,8 @@ copyrights:
 default:
 - enabled-by: riscv/mpfs64imafdc
   value: bsp/mpfs-dtb.h
+- enabled-by: riscv/kendrytek210
+  value: bsp/kendryte-k210-dtb.h
 - enabled-by: true
   value: false
 description: |
diff --git a/spec/build/bsps/optfdtuboot.yml b/spec/build/bsps/optfdtuboot.yml
index 8c53b8b799..9d91639dc6 100644
--- a/spec/build/bsps/optfdtuboot.yml
+++ b/spec/build/bsps/optfdtuboot.yml
@@ -6,6 +6,9 @@ build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
+- enabled-by:
+  - riscv/kendrytek210
+  value: false
 - enabled-by: true
   value: true
 description: |
diff --git a/spec/build/bsps/riscv/optramsize.yml 
b/spec/build/bsps/riscv/optramsize.yml
index be80c0f462..1fc407d1ea 100644
--- a/spec/build/bsps/riscv/optramsize.yml
+++ b/spec/build/bsps/riscv/optramsize.yml
@@ -15,6 +15,8 @@ default:
   value: 0x1000
 - enabled-by: riscv/griscv
   value: 0x0100
+- enabled-by: riscv/kendrytek210
+  value: 0x0060
 - enabled-by: true
   value: 0x0400
 description: ''
diff --git a/spec/build/bsps/riscv/riscv/abi.yml 
b/spec/build/bsps/riscv/riscv/abi.yml
index ab3046ee24..de23bdd795 100644
--- a/spec/build/bsps/riscv/riscv/abi.yml
+++ b/spec/build/bsps/riscv/riscv/abi.yml
@@ -10,6 +10,7 @@ default:
 - enabled-by:
   - riscv/mpfs64imafdc
   - riscv/rv64imafdc
+  - riscv/kendrytek210
   value:
   - -march=rv64imafdc
   - -mabi=lp64d
diff --git a/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml 
b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
new file mode 100644
index 00..91c601979e
--- /dev/null
+++ b/spec/build/bsps/riscv/riscv/bspkendrtyek210.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: riscv
+bsp: kendrytek210
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Alan Cudmore
+cppflags: []
+enabled-by: true
+family: riscv
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: ../../opto2
+- role: build-dependency
+  uid: grp
+source: []
+type: build
diff --git a/spec/build/bsps/riscv/riscv/grp.yml 
b/spec/build/bsps/riscv/riscv/grp.yml
index 713c15509a..a2ed4a1052 100644
--- a/spec/build/bsps/riscv/riscv/grp.yml
+++ b/spec/build/bsps/riscv/riscv/grp.yml
@@ -50,10 +50,14 @@ links:
   uid: ../../optdtbheaderpath
 - role: build-dependency
   uid: optfrdme310arty
+- role: build-dependency
+  uid: optkendrytek210
 - role: build-dependency
   uid: opthtif
 - role: build-dependency
   uid: optmpfs
+- role: build-dependency
+  uid: optsifiveuart
 - role: build-dependency
   uid: optns16550max
 - role: build-dependency
diff --git a/spec/build/bsps/riscv/riscv/obj.yml 
b/spec/build/bsps/riscv/riscv/obj.yml
index 0ddeef828b..d28945fae4 100644
--- a/spec/build/bsps/riscv/riscv/obj.yml
+++ b/spec/build/bsps/riscv/riscv/obj.yml
@@ -16,6 +16,7 @@ install:
   - bsps/riscv/riscv/include/bsp/fe310-uart.h
   - bsps/riscv/riscv/include/bsp/irq.h
   - bsps/riscv/riscv/include/bsp/riscv.h
+  - bsps/riscv/riscv/include/bsp/k210.h
 - destination: ${BSP_INCLUDEDIR}/dev/serial
   source:
   - bsps/riscv/riscv/include/dev/seri

Re: [PATCH] bsps/stm32h7: fix propagation of configured HSE freq. value into the code

2023-03-09 Thread Sebastian Huber 

On 09.03.23 14:16, Karel Gardas wrote:

Sponsored-By:   Precidata
---
  .../arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c | 4 
  .../stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c   | 4 
  .../stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c  | 6 ++
  .../stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c   | 4 
  .../arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c | 4 
  5 files changed, 22 insertions(+)


Looks good.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel