Re: [Bugfix rtems-lwip 4/4] Fix crash due to link_detect_thread
Is it ok to implement it using a single ifdef __rtems__ else ? The driver
is already a ifdef - hell and it will become even less readable when I add
even more of them.
Kinsey Moore schrieb am Mo., 1. Apr. 2024, 16:39:
> The intent of this patch is fine, but changes should be purely additive
> and properly wrapped in the __rtems__ check. The addition of thread startup
> at the end should also be wrapped in !NO_SYS.
>
> Kinsey
>
> On Sun, Mar 31, 2024 at 5:49 PM Bernd Moessner
> wrote:
>
>> Within xemac_add, the link_detect_thread is set up before the ethernet
>> interface is configured and all data structures have been set up
>> correctly.
>> The steps within xemac_add are basically:
>> 1) Set up link_detect_thread
>> 2) Initialize the interface
>> 3) Set up the link speed / start autonegotiation
>> 4) When autonegotiate has completed, set up the data structures
>>
>> The issue is here that, for example if no cable is connected, the
>> autonegotiate sequence will suspend the calling task. As soon as
>> this happens, the link_detect_thread gets into running state and
>> dereferences the data structures that havent been set up. Unfortunatelly,
>> it isnt as easy as checking the pointer to the relevant data structure
>> for being NULL within the link_detect_thread. Not going into details,
>> the pointer (netif->state) isnt NULL in this moment of time, but it
>> has to point to something completely different.
>>
>> It seems to me that the easiest solution to this problem is to reorder
>> the sequence within xemac_add. Initialize the interface and set up the
>> data structures, then create the link_detect_thread which requires all of
>> this. After applying this patch, the sequence becomes:
>>
>> 1) Initialize the interface
>> 2) Set up the link speed / start autonegotiation
>> 3) When autonegotiate has completed, set up the data structures
>> 4) Set up link_detect_thread
>> ---
>> .../src/contrib/ports/xilinx/netif/xadapter.c | 32 ++-
>> 1 file changed, 24 insertions(+), 8 deletions(-)
>>
>> diff --git
>> a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
>> b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
>> index 93ff148..79a10c1 100644
>> ---
>> a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
>> +++
>> b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
>> @@ -126,8 +126,9 @@ xemac_add(struct netif *netif,
>> UINTPTR mac_baseaddr)
>> {
>> int i;
>> + struct netif * ret = NULL;
>>
>> -#if !NO_SYS
>> +#if !NO_SYS && !defined(__rtems__)
>> /* Start thread to detect link periodically for Hot Plug
>> autodetect */
>> sys_thread_new("link_detect_thread", link_detect_thread, netif,
>> THREAD_STACKSIZE, tskIDLE_PRIORITY);
>> @@ -142,7 +143,7 @@ xemac_add(struct netif *netif,
>> switch (find_mac_type(mac_baseaddr)) {
>> case xemac_type_xps_emaclite:
>> #ifdef XLWIP_CONFIG_INCLUDE_EMACLITE
>> - return netif_add(netif, ipaddr, netmask,
>> gw,
>> + ret = netif_add(netif, ipaddr, netmask,
>> gw,
>> (void*)mac_baseaddr,
>> xemacliteif_init,
>> #if NO_SYS
>> @@ -151,12 +152,14 @@ xemac_add(struct netif *netif,
>> tcpip_input
>> #endif
>> );
>> + break;
>> #else
>> - return NULL;
>> + ret = NULL;
>> + break;
>> #endif
>> case xemac_type_axi_ethernet:
>> #ifdef XLWIP_CONFIG_INCLUDE_AXI_ETHERNET
>> - return netif_add(netif, ipaddr, netmask,
>> gw,
>> + ret = netif_add(netif, ipaddr, netmask,
>> gw,
>> (void*)mac_baseaddr,
>> xaxiemacif_init,
>> #if NO_SYS
>> @@ -165,16 +168,18 @@ xemac_add(struct netif *netif,
>> tcpip_input
>> #endif
>> );
>> + break;
>> #else
>> -
[Bugfix rtems-lwip 4/4] Fix crash due to link_detect_thread
Within xemac_add, the link_detect_thread is set up before the ethernet
interface is configured and all data structures have been set up correctly.
The steps within xemac_add are basically:
1) Set up link_detect_thread
2) Initialize the interface
3) Set up the link speed / start autonegotiation
4) When autonegotiate has completed, set up the data structures
The issue is here that, for example if no cable is connected, the
autonegotiate sequence will suspend the calling task. As soon as
this happens, the link_detect_thread gets into running state and
dereferences the data structures that havent been set up. Unfortunatelly,
it isnt as easy as checking the pointer to the relevant data structure
for being NULL within the link_detect_thread. Not going into details,
the pointer (netif->state) isnt NULL in this moment of time, but it
has to point to something completely different.
It seems to me that the easiest solution to this problem is to reorder
the sequence within xemac_add. Initialize the interface and set up the
data structures, then create the link_detect_thread which requires all of
this. After applying this patch, the sequence becomes:
1) Initialize the interface
2) Set up the link speed / start autonegotiation
3) When autonegotiate has completed, set up the data structures
4) Set up link_detect_thread
---
.../src/contrib/ports/xilinx/netif/xadapter.c | 32 ++-
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git
a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
index 93ff148..79a10c1 100644
---
a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
+++
b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
@@ -126,8 +126,9 @@ xemac_add(struct netif *netif,
UINTPTR mac_baseaddr)
{
int i;
+ struct netif * ret = NULL;
-#if !NO_SYS
+#if !NO_SYS && !defined(__rtems__)
/* Start thread to detect link periodically for Hot Plug autodetect */
sys_thread_new("link_detect_thread", link_detect_thread, netif,
THREAD_STACKSIZE, tskIDLE_PRIORITY);
@@ -142,7 +143,7 @@ xemac_add(struct netif *netif,
switch (find_mac_type(mac_baseaddr)) {
case xemac_type_xps_emaclite:
#ifdef XLWIP_CONFIG_INCLUDE_EMACLITE
- return netif_add(netif, ipaddr, netmask, gw,
+ ret = netif_add(netif, ipaddr, netmask, gw,
(void*)mac_baseaddr,
xemacliteif_init,
#if NO_SYS
@@ -151,12 +152,14 @@ xemac_add(struct netif *netif,
tcpip_input
#endif
);
+ break;
#else
- return NULL;
+ ret = NULL;
+ break;
#endif
case xemac_type_axi_ethernet:
#ifdef XLWIP_CONFIG_INCLUDE_AXI_ETHERNET
- return netif_add(netif, ipaddr, netmask, gw,
+ ret = netif_add(netif, ipaddr, netmask, gw,
(void*)mac_baseaddr,
xaxiemacif_init,
#if NO_SYS
@@ -165,16 +168,18 @@ xemac_add(struct netif *netif,
tcpip_input
#endif
);
+ break;
#else
- return NULL;
+ ret = NULL;
+ break;
#endif
#if defined (__arm__) || defined (__aarch64__)
case xemac_type_emacps:
#ifdef XLWIP_CONFIG_INCLUDE_GEM
#ifndef __rtems__
- return netif_add(netif, ipaddr, netmask, gw,
+ ret = netif_add(netif, ipaddr, netmask, gw,
#else /* __rtems__ */
- return netif_add( netif,
+ ret = netif_add( netif,
(const ip4_addr_t *) ipaddr,
(const ip4_addr_t *) netmask,
(const ip4_addr_t *) gw,
@@ -188,7 +193,10 @@ xemac_add(struct netif *netif,
#endif
);
+ break;
#endif
+ ret = NULL;
+ break;
#endif
default:
#ifndef __rtems__
@@ -199,8 +207,16 @@ xemac_add(struct netif *netif,
mac_baseaddr);
xil_printf("\r\n");
#endif
- return NULL;
+
[Bugfix rtems-lwip 3/4] Correct the task prio of link_detect_thread
On my side, the link_detect_thread never gets to running state. I assume that the issues with the FreeRTOS tick rate and delay definitions have never been observed as the associated thread was never running / no one requied it to run. Previously, the link_detect_thread was set to RTEMS_MAXIMUM_PRIORITY (255). As far as I understand the docs, this should have worked out (why didnt it?). Using sched_get_priority_max (returns 254), the thread becomes active. --- rtemslwip/xilinx/xlwipopts.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rtemslwip/xilinx/xlwipopts.h b/rtemslwip/xilinx/xlwipopts.h index 8befd67..0f4316f 100644 --- a/rtemslwip/xilinx/xlwipopts.h +++ b/rtemslwip/xilinx/xlwipopts.h @@ -27,8 +27,10 @@ #ifndef __XLWIPOPTS_H__ #define __XLWIPOPTS_H__ +#include + /* These macros allow RTEMS to pretend to be FreeRTOS for Xilinx drivers */ -#define tskIDLE_PRIORITY RTEMS_MAXIMUM_PRIORITY +#define tskIDLE_PRIORITY sched_get_priority_max(SCHED_RR) #define portTICK_RATE_MS (1000 / rtems_clock_get_ticks_per_second()) #define vTaskDelay(x) rtems_task_wake_after(x) -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[Bugfix rtems-lwip 2/4] Fix definition of vTaskDelay(x)
FreeRTOS's vTaskDelay(x) is the FreeRTOS equivalent to rtems_task_wake_after(x), it suspends a task for x Ticks. The previously used sys_arch_delay(x) would add x/10 before passing it to rtems_task_wake_after. Due to the fact that portTICK_RATE_MS was set to wrong value the previous impl always called with rtems_task_wake_after(1). --- rtemslwip/xilinx/xlwipopts.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtemslwip/xilinx/xlwipopts.h b/rtemslwip/xilinx/xlwipopts.h index 23b942f..8befd67 100644 --- a/rtemslwip/xilinx/xlwipopts.h +++ b/rtemslwip/xilinx/xlwipopts.h @@ -30,6 +30,6 @@ /* These macros allow RTEMS to pretend to be FreeRTOS for Xilinx drivers */ #define tskIDLE_PRIORITY RTEMS_MAXIMUM_PRIORITY #define portTICK_RATE_MS (1000 / rtems_clock_get_ticks_per_second()) -#define vTaskDelay(x) sys_arch_delay(x) +#define vTaskDelay(x) rtems_task_wake_after(x) #endif /* __XLWIPOPTS_H__ */ -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[Bugfix rtems-lwip 1/4] Fix definition of portTICK_RATE_MS
The FreeRTOS define portTICK_RATE_MS must represent the time in ms between two system ticks. --- rtemslwip/xilinx/xlwipopts.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtemslwip/xilinx/xlwipopts.h b/rtemslwip/xilinx/xlwipopts.h index d915c3c..23b942f 100644 --- a/rtemslwip/xilinx/xlwipopts.h +++ b/rtemslwip/xilinx/xlwipopts.h @@ -29,7 +29,7 @@ /* These macros allow RTEMS to pretend to be FreeRTOS for Xilinx drivers */ #define tskIDLE_PRIORITY RTEMS_MAXIMUM_PRIORITY -#define portTICK_RATE_MS (rtems_clock_get_ticks_per_second() * 1000) +#define portTICK_RATE_MS (1000 / rtems_clock_get_ticks_per_second()) #define vTaskDelay(x) sys_arch_delay(x) #endif /* __XLWIPOPTS_H__ */ -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[Bugfix rtems-lwip 0/4] XILINX Link detect issues
I had to recognize that cable plug / unplug events are not detected. This is due to the fact that the link detect thread is created, but never gets to running state due to a too high priority (255, but it seems it should be 254). In addition to that, there are some FreeRTOS defines that have not been set up correctly. Even if the link detect thread would become running - it would wake up too often (every tick, instead of every second). Bernd Moessner (4): Fix definition of portTICK_RATE_MS Fix definition of vTaskDelay(x) Correct the task prio of link_detect_thread Fix crash due to link_detect_thread .../src/contrib/ports/xilinx/netif/xadapter.c | 32 ++- rtemslwip/xilinx/xlwipopts.h | 8 +++-- 2 files changed, 29 insertions(+), 11 deletions(-) -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Xilinx header files installed by BSP
On 25.03.2024 13:26, Sebastian Huber wrote: Hello, the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from Xilinx. They also install some header files from Xilinx in the top-level include directory of the BSP, for example: sleep.h xbasic_types.h xil_assert.h xil_cache.h xil_exception.h xil_io.h xil_mem.h xil_printf.h xil_smc.h xil_types.h xparameters.h xpseudo_asm_gcc.h xpseudo_asm.h xreg_cortexa53.h xstatus.h This can lead to conflicts if I would like to build software from https://github.com/Xilinx/embeddedsw because now some header files are duplicated and available through different include paths. Why do we install these header files? I think they should be only used internally to build the BSP provided drivers. The RTEMS drivers should expose their interfaces not through the Xilinx header files. Any objections to remove the installation of the Xilinx header files? Dear Sebastian, Zynq 7000 is not using them. Rtems-lwip requires some of the headers. I provided a patch which added "objxilinxsupport.yml" to the Zynq 7000 configurations. After a discussion on Discord my patch was rolled back (which I think was a good decision). Chris and Kinsey, please correct me if I misunderstood something, but as far as I understood it the headers will be removed from the kernel. Afaik, there are some drivers for the ZU require them. Thus, it will require some time / planning to overwork the drivers and move the required headers to rtems-lwip. Long story short, Chris and Kinsey should be able to give some more detailed information on the strategy and timeline. Regards ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Latest toolchain throws error when including newlib's regex.h
On 20.01.2024 16:49, Sebastian Huber wrote:
On 19.01.24 21:31, Bernd Moessner wrote:
Dear all,
I'm currently encountering an issue with the latest RTEMS toolchain
(GCC 13) while attempting to build GoogleTest.
Simple example, test.cpp with the following content:
#include
#include
compiled with
~/quick-start/install/tools/toolchain-arm/bin/arm-rtems6-g++ test.cpp
gives me:
In file included from test.cpp:2:
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:45:
error: expected primary-expression before '__restrict'
99 | size_t, regmatch_t [__restrict], int);
| ^~
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:45:
error: expected ']' before '__restrict'
99 | size_t, regmatch_t [__restrict], int);
| ^~
| ]
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:45:
error: expected ')' before '__restrict'
99 | size_t, regmatch_t [__restrict], int);
| ^~
| )
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:98:16:
note: to match this '('
98 | int regexec(const regex_t *__restrict, const char
*__restrict,
| ^
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:55:
error: expected initializer before ']' token
99 | size_t, regmatch_t [__restrict], int);
Is rejecting " [__restrict] " a bug in GCC, or should the signature
of newlib`s /newlib/libc/include/regex.h be changed from
int regexec(const regex_t *__restrict, const char *__restrict,
size_t, regmatch_t [__restrict], int);
to
int regexec(const regex_t *__restrict, const char *__restrict,
size_t, regmatch_t __restrict *, int);
? I would appreciate any insights or guidance you could provide on
this matter.
I would look at the pre-processed file (for example using
-save-temps=obj). Then I would send a patch fixing the issue to the
Newlib mailing list.
Thank you!
I found a bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97477
regarding this issue. Wondering why I havent seen the error earlier.
Besides, it should be regmatch_t * __restrict.
Regards Bernd
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Latest toolchain throws error when including newlib's regex.h
Dear all,
I'm currently encountering an issue with the latest RTEMS toolchain (GCC
13) while attempting to build GoogleTest.
Simple example, test.cpp with the following content:
#include
#include
compiled with
~/quick-start/install/tools/toolchain-arm/bin/arm-rtems6-g++ test.cpp
gives me:
In file included from test.cpp:2:
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:45:
error: expected primary-expression before '__restrict'
99 | size_t, regmatch_t [__restrict], int);
| ^~
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:45:
error: expected ']' before '__restrict'
99 | size_t, regmatch_t [__restrict], int);
| ^~
| ]
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:45:
error: expected ')' before '__restrict'
99 | size_t, regmatch_t [__restrict], int);
| ^~
| )
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:98:16:
note: to match this '('
98 | int regexec(const regex_t *__restrict, const char *__restrict,
| ^
/home/blofeld/quick-start/install/tools/toolchain-arm/arm-rtems6/include/regex.h:99:55:
error: expected initializer before ']' token
99 | size_t, regmatch_t [__restrict], int);
Is rejecting " [__restrict] " a bug in GCC, or should the signature of
newlib`s /newlib/libc/include/regex.h be changed from
int regexec(const regex_t *__restrict, const char *__restrict,
size_t, regmatch_t [__restrict], int);
to
int regexec(const regex_t *__restrict, const char *__restrict,
size_t, regmatch_t __restrict *, int);
? I would appreciate any insights or guidance you could provide on this
matter.
Regards
Bernd
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] Include support files also for Zynq7000
On 05.01.2024 18:54, Kinsey Moore wrote: I assume this is to support the Zynq7000 under rtems-lwip since it would need those installed headers. This looks good to me. Kinsey On Sat, Dec 23, 2023 at 7:00 AM wrote: From: Bernd Moessner --- spec/build/bsps/arm/xilinx-zynq/grp.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/spec/build/bsps/arm/xilinx-zynq/grp.yml b/spec/build/bsps/arm/xilinx-zynq/grp.yml index eeffea0..afa1e44 100644 --- a/spec/build/bsps/arm/xilinx-zynq/grp.yml +++ b/spec/build/bsps/arm/xilinx-zynq/grp.yml @@ -18,6 +18,8 @@ links: uid: abi - role: build-dependency uid: obj +- role: build-dependency + uid: ../../objxilinxsupport - role: build-dependency uid: objsmp - role: build-dependency -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel Your assumption is correct Bernd ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip - v1 02/11] FIX: add library search path to allow lwip being installed aside the RTEMS installation
On 04.01.2024 23:26, Kinsey Moore wrote:
On Thu, Jan 4, 2024 at 4:03 PM Bernd Moessner
wrote:
On 04.01.2024 22:33, Kinsey Moore wrote:
> This looks like it should be fine for now to enable installing into
> somewhere that isn't the installed BSP directory. Longer term,
> rtems-lwip should probably support similar options to rtems-libbsd
> such that the RTEMS path can be passed on the configure line using
> --rtems=.
>
> Kinsey
>
>
> On Thu, Jan 4, 2024 at 12:55 PM wrote:
>
> From: Bernd Moessner
>
> ---
> lwip.py | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/lwip.py b/lwip.py
> index bd743a1..65f1ead 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -137,9 +137,10 @@ def build(bld):
> includes=' '.join(test_app_incl))
>
> lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
> - bld.read_stlib('telnetd', paths=[lib_path])
> - bld.read_stlib('rtemstest', paths=[lib_path])
> - bld.read_stlib('ftpd', paths=[lib_path])
> + rtems_lib_path = os.path.join(bld.env.RTEMS_PATH,
arch_lib_path)
> + bld.read_stlib('telnetd', paths=[lib_path, rtems_lib_path])
> + bld.read_stlib('rtemstest', paths=[lib_path,
rtems_lib_path])
> + bld.read_stlib('ftpd', paths=[lib_path, rtems_lib_path])
>
> bld.program(features='c',
> target='telnetd01.exe',
> --
> 2.34.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
Hmm --rtems= works on my side now. I use
./waf configure --prefix=${RTEMS_LWIP_INSTALL_DIR}
--rtems=${RTEMS_OS_INSTALL_DIR}
--rtems-tools=${RTEMS_TOOLCHAIN_INSTALL_DIR}
--rtems-bsps=${RTEMS_BSP_ARCH}/${RTEMS_BSP_NAME}
to build the project.
Ah, sounds like this patch can be dropped, then. Being able to set the
RTEMS path is part of the generic rtems_waf functionality.
Kinsey
The RTEMS_PATH was set up, but without the patch stated above it wasnt
showing on the linker comand line as library search dir. You are
absolutely right that my patch is only a temporary solution. I think we
should not have to set up the RTEMS_PATH in the way shown above for
every executable. I have simply to less knowledge of waf and scripts
around to provide a better and more general solution. I just wanted to
let you know that the configure line is okay - the "real fix" must be
somewhere deeper down.
Markus
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip - v1 06/11] FIX: printf format spec compiler warning due to uintptr having 64bits on 64bit machines
On 04.01.2024 23:22, Kinsey Moore wrote:
Comments inline.
On Thu, Jan 4, 2024 at 12:54 PM wrote:
From: Bernd Moessner
---
.../lwip211/src/contrib/ports/xilinx/netif/xadapter.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
index 9594ff5..98e7a8e 100644
---
a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
+++
b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c
@@ -184,8 +184,9 @@ xemac_add(struct netif *netif,
#endif
#endif
default:
- xil_printf("unable to determine
type of EMAC with baseaddress 0x%08x\r\n",
+ xil_printf("unable to determine
type of EMAC with baseaddress %" PRIXPTR,
mac_baseaddr);
+ xil_printf("\r\b");
The second line has a \b instead of a \n.
Beyond that typo, changes in third-party sources in rtems-lwIP are
treated just like they are in rtems-libbsd. Changes are additive only
and gated by __rtems__. So if you wanted to change line A to line B,
you'd have this construct:
#ifdef __rtems__
line B
#else
line A
#endif
Okay, if fixed it in a later patch. I`ll merge the patches and add the
gates. I guess there are some other places where I ll have to add the
gates. I have reported one of the issues already to xilinx. I`ll report
all of them to Xilinx and until they've patched their sources we need to
stick to the gates.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems6 - v1 07/16] Flashdev: Refactor write_block_size and add function to dergister flashdev
On 04.01.2024 20:05, Kinsey Moore wrote:
A few comments inline.
On Thu, Jan 4, 2024 at 12:35 PM wrote:
From: Bernd Moessner
---
cpukit/dev/flash/flashdev.c | 71 --
cpukit/include/dev/flash/flashdev.h | 22 +-
cpukit/libmisc/shell/main_flashdev.c | 26 +--
testsuites/libtests/flashdev01/init.c | 204
--
.../libtests/flashdev01/test_flashdev.c | 54 +++--
.../libtests/flashdev01/test_flashdev.h | 4 +-
6 files changed, 264 insertions(+), 117 deletions(-)
diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
index 0020e8d2c1..f50d2235a1 100644
--- a/cpukit/dev/flash/flashdev.c
+++ b/cpukit/dev/flash/flashdev.c
@@ -124,7 +124,7 @@ static int rtems_flashdev_ioctl_get_page_count(
void *arg
);
-static int rtems_flashdev_ioctl_get_write_block_size(
+static int rtems_flashdev_ioctl_get_min_write_size(
I'm not sure I agree with this renaming. As I understood it, it is
actually the write block size which implies all writes must be a
multiple of the write block size versus minimum write size implying
that writes must only be larger than (or equal to) the provided size.
The NOR chips that support ECC when writing in 16-byte chunks would
disable ECC for partial writes of a 16-byte block performed primarily
on adjacent blocks. I should probably check that there is a write
alignment guarantee in flashdev.
No matter on what we agree we, we should document our expectation how a
flash memory is organized.
The memory organization on page 12 in
https://www.macronix.com/Lists/Datasheet/Attachments/8745/MX25L51245G,%203V,%20512Mb,%20v1.7.pdf
is, from my point of view, the most traditional view on a flash. Perhaps
it is problem of me, but when someone speaks of "block" wrt. to flash
memories I immediately assume it is a multiple of sections.
However, I know flashes like the S25FL512S which has the ECC feature
you've mentioned. This special device has "16 Byte Programming Blocks"
with an ECC feature. However, does this lead "min_write_block_size" or
"min_ecc_block_size"? There are other reasons than ECC for which a
driver might want to report back min write size and aligned writes.
Calling it simply "min_write_size" gives us both, it does not get
confused with a block size and it can report back a size / alignment
information. Perhaps, we could add an IOCTL to allow / forbid aligned
writes.
rtems_flashdev *flash,
void *arg
);
@@ -146,8 +146,7 @@ static int rtems_flashdev_get_abs_addr(
static int rtems_flashdev_update_and_return(
rtems_libio_t *iop,
int status,
- size_t count,
- off_t new_offset
+ size_t count
);
static uint32_t rtems_flashdev_find_unallocated_region(
@@ -225,13 +224,20 @@ static const
rtems_filesystem_file_handlers_r rtems_flashdev_handler = {
.poll_h = rtems_filesystem_default_poll,
.readv_h = rtems_filesystem_default_readv,
.writev_h = rtems_filesystem_default_writev };
-
+/*
static const IMFS_node_control
rtems_flashdev_node_control = IMFS_GENERIC_INITIALIZER(
_flashdev_handler,
IMFS_node_initialize_generic,
rtems_flashdev_node_destroy
);
+*/
The above definition should be removed instead of commented out.
I`ll keep Aarons implementation.
+static const IMFS_node_control rtems_flashdev_node_control = {
+ .handlers = _flashdev_handler,
+ .node_initialize = IMFS_node_initialize_generic,
+ .node_remove = IMFS_node_remove_default,
+ .node_destroy = rtems_flashdev_node_destroy
+};
static void rtems_flashdev_node_destroy(
IMFS_jnode_t *node
@@ -321,7 +327,7 @@ static int rtems_flashdev_read_write(
int status;
if ( read_buff == NULL && write_buff == NULL ) {
- return 0;
+ return EINVAL;
}
/* Get flash address */
@@ -335,12 +341,35 @@ static int rtems_flashdev_read_write(
if ( read_buff != NULL ) {
status = ( *flash->read )( flash, addr, count, read_buff );
} else if ( write_buff != NULL ) {
+ size_t min_write_size = 0;
+ status = (flash)->get_min_write_size(flash, _write_size);
+
+ if ( status < 0 ) {
+ return status;
+ }
+
+ if (0 == min_write_size )
+ {
+ rtems_set_errno_and_return_minus_one( EIO );
+ }
+ else
+ {
+ if (count % min_write_size)
+ {
+ rtems_set_errno_and_return_minus_one( EINVAL );
+ }
+ if (addr % min_write_size)
+ {
+ rtems_set_errno_and_return_minus_one( EFAULT );
+ }
+ }
+
status = ( *flash->write )( flash, addr, count, write_buff );
}
Re: [PATCH rtems-lwip - v1 04/11] FIX: warning variable might be used without initialization
On 04.01.2024 22:41, Kinsey Moore wrote:
This is technically a false warning since rtems_interrupt_disable is a
macro that expands to _ISR_Local_disable that expands to
_CPU_ISR_Disable which assigns it a value, but it doesn't hurt
anything, so it's OK to commit.
Kinsey
On Thu, Jan 4, 2024 at 12:54 PM wrote:
From: Bernd Moessner
---
rtemslwip/common/sys_arch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rtemslwip/common/sys_arch.c b/rtemslwip/common/sys_arch.c
index 2651c9c..b97404c 100644
--- a/rtemslwip/common/sys_arch.c
+++ b/rtemslwip/common/sys_arch.c
@@ -372,7 +372,7 @@ sys_request_irq(unsigned int irqnum,
sys_irq_handler_t handler,
sys_prot_t
sys_arch_protect()
{
- sys_prot_t pval;
+ sys_prot_t pval = 0;
#if RTEMS_SMP
rtems_recursive_mutex_lock( _arch_lock );
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Yes, I saw that it doesnt hurt. I get similar warnings from the RTEMS
Kernel. However, I will have to "fix" this warnings as I am required to
enable -Werror.
Bernd
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip - v1 02/11] FIX: add library search path to allow lwip being installed aside the RTEMS installation
On 04.01.2024 22:33, Kinsey Moore wrote:
This looks like it should be fine for now to enable installing into
somewhere that isn't the installed BSP directory. Longer term,
rtems-lwip should probably support similar options to rtems-libbsd
such that the RTEMS path can be passed on the configure line using
--rtems=.
Kinsey
On Thu, Jan 4, 2024 at 12:55 PM wrote:
From: Bernd Moessner
---
lwip.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lwip.py b/lwip.py
index bd743a1..65f1ead 100644
--- a/lwip.py
+++ b/lwip.py
@@ -137,9 +137,10 @@ def build(bld):
includes=' '.join(test_app_incl))
lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
- bld.read_stlib('telnetd', paths=[lib_path])
- bld.read_stlib('rtemstest', paths=[lib_path])
- bld.read_stlib('ftpd', paths=[lib_path])
+ rtems_lib_path = os.path.join(bld.env.RTEMS_PATH, arch_lib_path)
+ bld.read_stlib('telnetd', paths=[lib_path, rtems_lib_path])
+ bld.read_stlib('rtemstest', paths=[lib_path, rtems_lib_path])
+ bld.read_stlib('ftpd', paths=[lib_path, rtems_lib_path])
bld.program(features='c',
target='telnetd01.exe',
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hmm --rtems= works on my side now. I use
./waf configure --prefix=${RTEMS_LWIP_INSTALL_DIR}
--rtems=${RTEMS_OS_INSTALL_DIR}
--rtems-tools=${RTEMS_TOOLCHAIN_INSTALL_DIR}
--rtems-bsps=${RTEMS_BSP_ARCH}/${RTEMS_BSP_NAME}
to build the project.
Bernd
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems6 - v1 06/16] Flashdev: Make mutex name more generic
On 04.01.2024 19:55, Kinsey Moore wrote:
On Thu, Jan 4, 2024 at 12:35 PM wrote:
From: Bernd Moessner
---
cpukit/dev/flash/flashdev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
index 8bd3d11246..0020e8d2c1 100644
--- a/cpukit/dev/flash/flashdev.c
+++ b/cpukit/dev/flash/flashdev.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
#include
#include
@@ -490,7 +491,9 @@ static int rtems_flashdev_do_init(
void ( *destroy )( rtems_flashdev *flash )
)
{
- rtems_recursive_mutex_init( >mutex, "RTEMS_FLASHDEV
Flash" );
+ char mtx_name[19];
+ sprintf(mtx_name, "FDEV_MTX_%08x", (unsigned int) flash);
+ rtems_recursive_mutex_init( >mutex, (const char*)
_name );
None of the other uses of mutexes in cpukit differentiate between
various instantiations and the information you've added here is
already available if you know the mutex address and know that it's a
flash mutex.
Is there a reason this needs to differentiate between the various
instances where others don't?
Kinsey
I already know that i will require two instances of flashedev.
I had two thoughts on my mind:
a) I was worried that creating two mutex with the same name could cause
problems
b) Not sure if that already exists for RTEMS but I had those debug views
in mind where you can immediately see all kernel objects (tasks, mutex,
etc.).
Therefore, I thought about a way to make the mutex name unique.
Note: You've hit the weak spot and I've changed the implementation in a
later patch. Perhaps, I have completely misunderstood the docs:
https://docs.rtems.org/branches/master/c-user/self_contained_objects.html
The|name|must be persistent throughout the life-time of the mutex.
A|name|of|NULL|is valid. The mutex is unlocked after initialization.
Things worked out on my side, but I the "persistent" made me a worry
about the fact that mtx_name goes out scope. Therefore, I've added the
required buffer to the flashdev struct to store the name there.
I am open for all solutions: keeping Aarons implementation, passing NULL
as name, better ideas to create unique names.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems6 - v1 00/16] Overwork flashdev - V1
On 04.01.2024 20:40, Kinsey Moore wrote: On Thu, Jan 4, 2024 at 12:34 PM wrote: From: Bernd Moessner Dear all, as outlined in https://devel.rtems.org/ticket/4981 I`d like to overwork the flashdev API. The provided patch series should at least serve as a fundament for the discussion. It includes more, but h: 1) Bugfixes 1.1) missing c++ include guards 1.2) missing default cases 1.3) There are some false positive test cases. Ie. they fail, are expected to fail, but fail for a different reason. The test cases are not taking into account that fputs works on buffered IO per default. The region mechanism is there to protect reads / writes to an area outside the currently active region. This part works fine, but due to buffering newlib tries to read even more bytes than the user requested - which in turn triggers the region mechanism and causes the read to fail. In addtion to that, theres a bug in the _update_and_return function due to which a wrong address (the absolute address and not the relative address of the region) is returned to newlib. 2) Refactoring / Style Changes: 2.1) Not sure if there are naming conventions for IOCTL defines and functions, but I think it makes sense if an IOCTL is used to "get" a value, that "get" is reflected by the macro and function names. 2.2) Flashdev used the term "regions", but from my point of view "partions" fits better 2.3) I'd like to call the minimum write block size simply minimum write size. The point is that the term block is already predefined for flash devices (Bytes => Pages => Sectors => Block => Die => Chip). We should should also make sure that the writes are aligned to the min write size and are carried out with this size. I've added alignment checks, but the user must set the buffering size for newlib using setvbuf. 3) API Extension 3.1) The API is missing a function to get the erase size. Partions / Regions need to be aligned to the erase size of the flash memory. 3.2) The region / partition mechnism works differently now. There are IOCTL the create, delete, activate, deactivate partitions, and one to get idx of the currently active partion. I think the internal implementation becomes much simpler if we reduce the number of allowed partitions from 32 to 16. The patch set addresses all issues I have found. I have updated and extended the test cases. I must admit that I am a bit insecure wrt. to the RTEMS style guide - I`d be very happy if one could have a close look at that. Aaron Nyholm has added the flashdev API last year. The changes within this patch set are too large to contribute without his agreement Thanks for all the work that went into this! I see that there are 2 versions of this patch set on the list. It seems that one doesn't have a version identifier and one has a v1 identifier. Either would be fine, but I wouldn't recommend using both as it can get confusing as to which is the latest version of the patch set. Hopefully, I've chosen the correct set to review (16 patches). Unfortunately, it was made harder to distinguish because the mail server was down for a few days and they both got delivered within a few tens of minutes of each other. Kinsey Thanks a lot for going through all the commits and commenting on them! Yes, you've chosen the correct patch set. I`ll work in your comments and resubmit the patch set after we've clarified if it is "min_write_size", "min_write_block_size" or something entirely new ;). Therefore, the patch set will become smaller as two patches fix bugs I've introduced. Do I resubmit it using "[PATCH rtems6 - v1 00/16] Overwork flashdev - V1" or as V2? Bernd ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems6 - v1 05/16] FIX: Add missing default case
Dear Kinsey,
sry for the stupid question. What is the correct way to reference the issue
[#4981 <https://devel.rtems.org/ticket/4981> rtems6 - v1 05/16] FIX: Add
missing default case
or
[PATCH rtems6 - v1 05/16] #4981 <https://devel.rtems.org/ticket/4981>
FIX: Add missing default case
?
On 04.01.2024 19:48, Kinsey Moore wrote:
All of the patches here need an issue reference. Beyond that, this
patch is good to go in. I'm still reviewing the remainder of the set
and I'll leave the renaming discussion to Aaron.
Kinsey
On Thu, Jan 4, 2024 at 12:35 PM wrote:
From: Bernd Moessner
---
cpukit/dev/flash/flashdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cpukit/dev/flash/flashdev.c b/cpukit/dev/flash/flashdev.c
index 27edead968..8bd3d11246 100644
--- a/cpukit/dev/flash/flashdev.c
+++ b/cpukit/dev/flash/flashdev.c
@@ -390,6 +390,8 @@ static int rtems_flashdev_ioctl(
case RTEMS_FLASHDEV_IOCTL_GET_WRITE_BLOCK_SIZE:
err = rtems_flashdev_ioctl_get_write_block_size( flash, arg );
break;
+ default:
+ err = EINVAL;
}
rtems_flashdev_release( flash );
--
2.34.1
___
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: [rtems-lwip] Switch submodule protocol to https to allow use in restricted network environments
Sry, the patch contains a wrong url. Will provide an updated version next week. schrieb am Sa., 23. Dez. 2023, 09:36: > From: Bernd Moessner > > --- > .gitmodules | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/.gitmodules b/.gitmodules > index 4ea46da..e772af8 100644 > --- a/.gitmodules > +++ b/.gitmodules > @@ -1,6 +1,6 @@ > [submodule "lwip-upstream"] > path = lwip-upstream > - url = git://git.savannah.gnu.org/lwip.git > + url = https://git.savannah.gnu.org/cgit/lwip.git > [submodule "rtems_waf"] > path = rtems_waf > - url = git://git.rtems.org/rtems_waf.git > + url = https://git.rtems.org/rtems_waf > -- > 2.34.1 > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v3 rtems master 3/3] ZYNQ7000: Add support PYNQ, PicoZed, MicroZed, ZYBO and ZYBO Z7
This patch adds basic support for the following boards: xilinx_zynq_pynq - PYNQ Z1 / Z2 xilinx_zynq_microzed - MicroZed 7010 / 7020 xilinx_zynq_picozed - PicoZed 7010 / 7015 / 7020 / 7030 xilinx_zynq_zybo - ZYBO xilinx_zynq_zybo_z7 - ZYBO Z7-10 / Z7-20 N.b. Arty Z7-20 is basically a PYNQ Z1 - different board color and updated Eth PHY. --- .../xilinx_zynq_microzed-testsuite.tcfg | 7 +++ .../config/xilinx_zynq_microzed.cfg | 1 + .../config/xilinx_zynq_picozed-testsuite.tcfg | 7 +++ .../config/xilinx_zynq_picozed.cfg| 1 + .../config/xilinx_zynq_pynq-testsuite.tcfg| 7 +++ .../xilinx-zynq/config/xilinx_zynq_pynq.cfg | 1 + .../config/xilinx_zynq_zybo-testsuite.tcfg| 7 +++ .../xilinx-zynq/config/xilinx_zynq_zybo.cfg | 1 + .../config/xilinx_zynq_zybo_z7-testsuite.tcfg | 7 +++ .../config/xilinx_zynq_zybo_z7.cfg| 1 + .../bsps/arm/xilinx-zynq/bspmicrozed.yml | 19 +++ .../build/bsps/arm/xilinx-zynq/bsppicozed.yml | 19 +++ spec/build/bsps/arm/xilinx-zynq/bsppynq.yml | 19 +++ spec/build/bsps/arm/xilinx-zynq/bspzybo.yml | 19 +++ spec/build/bsps/arm/xilinx-zynq/bspzyboz7.yml | 19 +++ .../bsps/arm/xilinx-zynq/opta9periphclk.yml | 12 ++-- .../bsps/arm/xilinx-zynq/optclkcpu1x.yml | 5 + .../build/bsps/arm/xilinx-zynq/optclkuart.yml | 5 + spec/build/bsps/arm/xilinx-zynq/optramlen.yml | 9 - spec/build/bsps/optconminor.yml | 3 +++ spec/build/cpukit/optsmp.yml | 6 ++ 21 files changed, 172 insertions(+), 3 deletions(-) create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed-testsuite.tcfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed.cfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed-testsuite.tcfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed.cfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq-testsuite.tcfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq.cfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_zybo-testsuite.tcfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_zybo.cfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_zybo_z7-testsuite.tcfg create mode 100755 bsps/arm/xilinx-zynq/config/xilinx_zynq_zybo_z7.cfg create mode 100644 spec/build/bsps/arm/xilinx-zynq/bspmicrozed.yml create mode 100644 spec/build/bsps/arm/xilinx-zynq/bsppicozed.yml create mode 100644 spec/build/bsps/arm/xilinx-zynq/bsppynq.yml create mode 100644 spec/build/bsps/arm/xilinx-zynq/bspzybo.yml create mode 100644 spec/build/bsps/arm/xilinx-zynq/bspzyboz7.yml diff --git a/bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed-testsuite.tcfg b/bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed-testsuite.tcfg new file mode 100755 index 00..ba80faab99 --- /dev/null +++ b/bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed-testsuite.tcfg @@ -0,0 +1,7 @@ +# +# Xilinx Zedboard RTEMS Test Database. +# +# Format is one line per test that is _NOT_ built. +# + +include: xilinx_zynq-testsuite.tcfg diff --git a/bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed.cfg b/bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed.cfg new file mode 100755 index 00..2de871d46e --- /dev/null +++ b/bsps/arm/xilinx-zynq/config/xilinx_zynq_microzed.cfg @@ -0,0 +1 @@ +include $(RTEMS_ROOT)/make/custom/xilinx_zynq.inc diff --git a/bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed-testsuite.tcfg b/bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed-testsuite.tcfg new file mode 100755 index 00..ba80faab99 --- /dev/null +++ b/bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed-testsuite.tcfg @@ -0,0 +1,7 @@ +# +# Xilinx Zedboard RTEMS Test Database. +# +# Format is one line per test that is _NOT_ built. +# + +include: xilinx_zynq-testsuite.tcfg diff --git a/bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed.cfg b/bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed.cfg new file mode 100755 index 00..2de871d46e --- /dev/null +++ b/bsps/arm/xilinx-zynq/config/xilinx_zynq_picozed.cfg @@ -0,0 +1 @@ +include $(RTEMS_ROOT)/make/custom/xilinx_zynq.inc diff --git a/bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq-testsuite.tcfg b/bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq-testsuite.tcfg new file mode 100755 index 00..ba80faab99 --- /dev/null +++ b/bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq-testsuite.tcfg @@ -0,0 +1,7 @@ +# +# Xilinx Zedboard RTEMS Test Database. +# +# Format is one line per test that is _NOT_ built. +# + +include: xilinx_zynq-testsuite.tcfg diff --git a/bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq.cfg b/bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq.cfg new file mode 100755 index 00..2de871d46e --- /dev/null +++ b/bsps/arm/xilinx-zynq/config/xilinx_zynq_pynq.cfg @@ -0,0 +1 @@ +include $(RTEMS_ROOT)/make/custom/xilinx_zynq.inc diff --git
[PATCH v3 rtems master 2/3] Fix zedboard clock settings
From: Bernd Moessner --- spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml b/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml index fdee4c0568..ad34974665 100644 --- a/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml +++ b/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml @@ -9,9 +9,8 @@ default: - enabled-by: - arm/xilinx_zynq_zc702 - arm/xilinx_zynq_zc706 + - arm/xilinx_zynq_zedboard value: 3 -- enabled-by: arm/xilinx_zynq_zedboard - value: 7 - enabled-by: true value: 1 description: | -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH v3 rtems master 1/3] Fix add missing clock settings for zc706
From: Bernd Moessner --- spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml b/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml index 7233f73d5a..fdee4c0568 100644 --- a/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml +++ b/spec/build/bsps/arm/xilinx-zynq/opta9periphclk.yml @@ -6,7 +6,9 @@ build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH & Co. KG default: -- enabled-by: arm/xilinx_zynq_zc702 +- enabled-by: + - arm/xilinx_zynq_zc702 + - arm/xilinx_zynq_zc706 value: 3 - enabled-by: arm/xilinx_zynq_zedboard value: 7 -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
