Re: rtems-6.1-rc2 on Mac OSX Sonoma 14.4 (Apple M2) failed -> fixed
On 12/3/2024 8:06 pm, Heinz Junkes wrote: > Hello Chris, > > thanks for your mail. I have now installed the python as you described. Great. > The source-builder process runs quite well. > > Unfortunately, the gcc-13.2.0-newlib for powerpc cannot be built: I updated to the latest RSB with the newlib FS_SIZE 256 patch that Joel pushed today and 6/rtems-powerpc built without error on an M2 MacBook. I have Sonoma 14.2.1 and the latest Xcode. No brew of MacPorts. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] rtems-score-thread.ini: Remove _Thread_Close so trace examples link
Thanks. All pushed now. On Thu, Mar 14, 2024 at 6:46 PM Chris Johns wrote: > OK > > Thanks > Chris > > On 12/3/2024 1:06 am, Joel Sherrill wrote: > > _Thread_Close no longer exists. There are multiple exapmles which > > show tracing in rtems-examples which fail to link due to this. > > --- > > linkers/rtems-score-thread.ini | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/linkers/rtems-score-thread.ini > b/linkers/rtems-score-thread.ini > > index 974bcfd..a759f72 100644 > > --- a/linkers/rtems-score-thread.ini > > +++ b/linkers/rtems-score-thread.ini > > @@ -5,7 +5,7 @@ > > trace = _Thread_Handler_initialization, _Thread_Create_idle, > _Thread_Start_multitasking > > trace = _Stack_Allocate, _Stack_Free, _Thread_Start > > trace = _Thread_Yield, _Thread_Set_life_protection > > -trace = _Thread_Kill_zombies, _Thread_Close > > +trace = _Thread_Kill_zombies > > trace = _Thread_Clear_state, _Thread_Set_state, _Thread_Load_environment > > trace = _Thread_Handler > > trace = _Thread_Get > > @@ -19,7 +19,7 @@ trace = _Stack_Allocate, _Thread_Start > > trace = _Thread_Restart, _Thread_Handler > > > > [rtems-score-thread-destroy] > > -trace = _Thread_Kill_zombies, _Thread_Close > > +trace = _Thread_Kill_zombies > > > > [rtems-score-thread-activity] > > trace = _Thread_Yield, _Thread_Set_life_protection > > @@ -38,7 +38,6 @@ _Thread_Start = Status_Control, Thread_Control*, const > Thread_Entry_information* > > _Thread_Yield = void, Thread_Control* > > _Thread_Set_life_protection = Thread_Life_state, Thread_Life_state > > _Thread_Kill_zombies = void, void > > -_Thread_Close = void, Thread_Control*, Thread_Control*, > Thread_Close_context* > > _Thread_Clear_state = States_Control, Thread_Control*, States_Control > > _Thread_Set_state = States_Control, Thread_Control*, States_Control > > _Thread_Load_environment = void, Thread_Control* > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS GitLab
Hi RTEMS Community I would like to announce that RTEMS will be moving to GitLib in the coming month or so. We do not have any exact dates yet and we will let you know when we do. The change is large and complex because we are integrating an active open source project made up of various pieces into a single platform. 1. A number of services we currently run will be locked to prevent further modification but will remain available while we move, for example our current Trac web site. 2. All repo default branches will be moved to `main` as part of the move. You will need to migrate any repos you have to use `main` and we will provide instructions when the time comes. 3. Accounts you may have will not be migrated. If you have a Trac account you will need to create a new account on GitLab. Accounts will be protected by 2FA. 4. The initial roll out is to provide repo access with Merge Requests. Once live there will be no need to send patches to mailing lists for review and integration. 5. We will provide more detail closer to the roll out of the projects in GitLab and the approval process we will initially adopt. GitLab will be set up with an initial set of roles and positions assigned to people. This is an initial starting point and we are open to adding people who can help with the administrative tasks we have. 6. Moving the tickets from Trac to GitLab is complicated and involved and will require at least three weeks which means we will need to take Trac off line to do this. This means automatic updating via git commits will not be migrated and will require manual updates once GitLab is available. We need the Trac tickets in GitLab to be able to set up GitLab and migrate them to a suitable workflow. 7. Some mailings for administrative purposes will be removed. I would like to thank those who have worked over the last 12 months to bring this effort to life. This includes the people who were approached to sponsor the work, RTEMS GitLab team and Amar for his efforts making this happen. It is a complex task to secure the systems we run. Regards Chris RTEMS GitLab Team - Amar, Chris, Gedare, Joel, Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-source-builder 1/2] rtems-tools-6.cfg: Bump hash to account for 5 months of changes
OK
Thanks
Chris
On 14/3/2024 7:00 am, Joel Sherrill wrote:
> In particular, the BSP set definitions for rtems-bsp-builder were
> out of sync with RTEMS and caused unnecessary failures reported to
> the build@ mailing list.
> ---
> rtems/config/tools/rtems-tools-6.cfg | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
> index 7ef2052..8abfeea 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %define rtems_tools_ext xz
> %else
> - %define rtems_tools_version f408c0f8d935d53c232c67bed39e4018fd8d7a2a
> + %define rtems_tools_version 12971a8
> %define rtems_tools_ext bz2
> %endif
>
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
> %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
> xZIWwcW4y9wOsIY+8XWDAxKk51TwKFHeOw39SS6zxrgE0LOFxfpy/SQeidCRvOUieQPbEmZRUdLyFW1UDEHh3w==
> +
> SrjY0gweRgWHmqBYj0wFnu1LFkaeNeS05SD1dKVzz2kvs3UCZ6AM8DrLbVe0q4H14DZwmrE3mMgbutsVev0Oxg==
>
> #
> # Optionally enable/disable building the RTEMS Tools via the command line.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] rtems-score-thread.ini: Remove _Thread_Close so trace examples link
OK Thanks Chris On 12/3/2024 1:06 am, Joel Sherrill wrote: > _Thread_Close no longer exists. There are multiple exapmles which > show tracing in rtems-examples which fail to link due to this. > --- > linkers/rtems-score-thread.ini | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/linkers/rtems-score-thread.ini b/linkers/rtems-score-thread.ini > index 974bcfd..a759f72 100644 > --- a/linkers/rtems-score-thread.ini > +++ b/linkers/rtems-score-thread.ini > @@ -5,7 +5,7 @@ > trace = _Thread_Handler_initialization, _Thread_Create_idle, > _Thread_Start_multitasking > trace = _Stack_Allocate, _Stack_Free, _Thread_Start > trace = _Thread_Yield, _Thread_Set_life_protection > -trace = _Thread_Kill_zombies, _Thread_Close > +trace = _Thread_Kill_zombies > trace = _Thread_Clear_state, _Thread_Set_state, _Thread_Load_environment > trace = _Thread_Handler > trace = _Thread_Get > @@ -19,7 +19,7 @@ trace = _Stack_Allocate, _Thread_Start > trace = _Thread_Restart, _Thread_Handler > > [rtems-score-thread-destroy] > -trace = _Thread_Kill_zombies, _Thread_Close > +trace = _Thread_Kill_zombies > > [rtems-score-thread-activity] > trace = _Thread_Yield, _Thread_Set_life_protection > @@ -38,7 +38,6 @@ _Thread_Start = Status_Control, Thread_Control*, const > Thread_Entry_information* > _Thread_Yield = void, Thread_Control* > _Thread_Set_life_protection = Thread_Life_state, Thread_Life_state > _Thread_Kill_zombies = void, void > -_Thread_Close = void, Thread_Control*, Thread_Control*, Thread_Close_context* > _Thread_Clear_state = States_Control, Thread_Control*, States_Control > _Thread_Set_state = States_Control, Thread_Control*, States_Control > _Thread_Load_environment = void, Thread_Control* ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] modified code for hello world exercise
---
testsuites/samples/hello/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 83f6342ab3..cee3c67d0c 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,7 @@ static rtems_task Init(
{
rtems_print_printer_fprintf_putc(_test_printer);
TEST_BEGIN();
- printf( "Hello World\n" );
+ printf( "Hello World, i modified this line of code\n" );
TEST_END();
rtems_test_exit( 0 );
}
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Trying to run freebsd on qemu
Try at FreeBSD.org. On Mar 14, 2024, at 10:18 AM, ashish wrote: I am trying to run freebsd aarch64 12.x on qemu to know whether freebsd supports usb or not. and Error i am getting is this ```qemu-system-aarch64: device requires 67108864 bytes, block backend provides 2097152 bytes``` does anyone tried running freebsd aarch 12 or freebsd arm 12 on qemu ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] improved error checking in ticks per timeslice
It should be in the repo now. On Thu, Mar 14, 2024 at 12:50 PM zack leung wrote: > Did you check in the code? > > Il mar 12 mar 2024, 21:55 Kinsey Moore ha > scritto: > >> Sorry, I missed this in the deluge of emails. Looks good to me. >> >> Kinsey >> >> On Tue, Mar 12, 2024 at 8:17 PM zack leung >> wrote: >> >>> ping >>> >>> On Fri, 8 Mar 2024 at 22:03, wrote: >>> From: Zack leung --- cpukit/doxygen/appl-config.h | 3 +-- cpukit/include/rtems/confdefs/clock.h | 4 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h index bd7cde628f..f843ebbd39 100644 --- a/cpukit/doxygen/appl-config.h +++ b/cpukit/doxygen/appl-config.h @@ -3312,8 +3312,7 @@ * @parblock * The following constraints apply to this configuration option: * - * * The value of the configuration option shall be greater than or equal to - * zero. + * * The value of the configuration option shall be greater than zero. * * * The value of the configuration option shall be less than or equal to >>> * href="https://en.cppreference.com/w/c/types/integer ">UINT32_MAX. diff --git a/cpukit/include/rtems/confdefs/clock.h b/cpukit/include/rtems/confdefs/clock.h index 26519cc70b..bb6c7e0b68 100644 --- a/cpukit/include/rtems/confdefs/clock.h +++ b/cpukit/include/rtems/confdefs/clock.h @@ -70,6 +70,10 @@ #warning "The clock ticks per second is not an integer" #endif +#if defined(CONFIGURE_TICKS_PER_TIMESLICE) && CONFIGURE_TICKS_PER_TIMESLICE <= 0 + #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero" +#endif + #if CONFIGURE_MICROSECONDS_PER_TICK <= 0 #error "CONFIGURE_MICROSECONDS_PER_TICK must be positive" #endif -- 2.43.0 ___ >>> 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] improved error checking in ticks per timeslice
Did you check in the code? Il mar 12 mar 2024, 21:55 Kinsey Moore ha scritto: > Sorry, I missed this in the deluge of emails. Looks good to me. > > Kinsey > > On Tue, Mar 12, 2024 at 8:17 PM zack leung > wrote: > >> ping >> >> On Fri, 8 Mar 2024 at 22:03, wrote: >> >>> From: Zack leung >>> >>> --- >>> cpukit/doxygen/appl-config.h | 3 +-- >>> cpukit/include/rtems/confdefs/clock.h | 4 >>> 2 files changed, 5 insertions(+), 2 deletions(-) >>> >>> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h >>> index bd7cde628f..f843ebbd39 100644 >>> --- a/cpukit/doxygen/appl-config.h >>> +++ b/cpukit/doxygen/appl-config.h >>> @@ -3312,8 +3312,7 @@ >>> * @parblock >>> * The following constraints apply to this configuration option: >>> * >>> - * * The value of the configuration option shall be greater than or >>> equal to >>> - * zero. >>> + * * The value of the configuration option shall be greater than zero. >>> * >>> * * The value of the configuration option shall be less than or equal >>> to >> * href="https://en.cppreference.com/w/c/types/integer >>> ">UINT32_MAX. >>> diff --git a/cpukit/include/rtems/confdefs/clock.h >>> b/cpukit/include/rtems/confdefs/clock.h >>> index 26519cc70b..bb6c7e0b68 100644 >>> --- a/cpukit/include/rtems/confdefs/clock.h >>> +++ b/cpukit/include/rtems/confdefs/clock.h >>> @@ -70,6 +70,10 @@ >>>#warning "The clock ticks per second is not an integer" >>> #endif >>> >>> +#if defined(CONFIGURE_TICKS_PER_TIMESLICE) && >>> CONFIGURE_TICKS_PER_TIMESLICE <= 0 >>> + #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero" >>> +#endif >>> + >>> #if CONFIGURE_MICROSECONDS_PER_TICK <= 0 >>>#error "CONFIGURE_MICROSECONDS_PER_TICK must be positive" >>> #endif >>> -- >>> 2.43.0 >>> >>> ___ >> 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
[RFC] Adding RISC-V Vector support to RTEMS
Hello RTEMS experts, We're in the process of implementing support for RTEMS on a new RISC-V platform. Among other things, our processor core supports the RISC-V Vector ISA (RVV), with its 32 vector registers which in our case are 512 bits (VLEN) deep. RVV is used by applications to accelerate a variety of code/algorithms utilizing either the auto-vectorizer in GCC/Clang, or through C intrinsics or direct assembly coding. My query here is regarding context saving, and options for optimization. Before I get to that, here's a few points of background. #1. Use of RVV by the compiler (GCC/Clang) is dictated by the ISA string provided, e.g -march=rv64imadcv, where v is for vector. The compiler preprocessor symbol "__riscv_vector" can then be used for conditionally compiled code, similar to what is done for floating point. #2. Enablement of RVV can be controlled via a machine status CSR. This allows one to disable RVV entirely (triggering an exception if RVV instructions are executed), but also allows one to track the dirty/clean state of the vector register file. (https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#vector-context-status-in-mstatus). So, one can conditionally save/restore the registers, although the 2KB of stack space (32 x (512b / 8)) would need to be allocated. #3. The C ABI specifies that vector registers are Caller saved. So, any system call (or any function call for that matter) does not need to preserve these registers. A relatively straightforward approach is to say that RTEMS + Application is built with vectors enabled (i.e -march=rv64imadcv). One does not need to save/restore the vector registers within Context_Control because of #3, however, because we are now building RTEMS with V enabled, we need to add this save/restore to the CPU_Interrupt_frame and incur that cost on all interrupts and stack space for all tasks. (A small secondary effect is that CPU_INTERRUPT_FRAME_SIZE is now larger than the immediate addressing range). Is there an alternative to consider? Might one build RTEMS itself without V, leaving that only for Applications/Tasks, perhaps adding a Task attribute, and thereby taking the vector save/restore penalty only when switching into or out of a vector enabled task? (Perhaps similar to HW floating point from the past). One would then use an RTEMS config flag to enable vector support, although qualified in runtime by validating the existence of the vector ISA (misa CSR).Or maybe that direction would require too many changes? e.g I see that "is_fp" is used more specifically, rather than the more general rtems_attribute in Thread_Control and in the arguments to _Context_Initialize(). Anyways, I'm happy to hear any thoughts on this subject. Note that I'm new to RTEMS, so may not have some past context. Thank you, Ken ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Trying to run freebsd on qemu
I am trying to run freebsd aarch64 12.x on qemu to know whether freebsd supports usb or not. following https://gist.github.com/ctsrc/a1f57933a2cde9abc0f07be12889f97f and getting error when running with qemu command i am using to build is qemu-system-aarch64 \ -M virt \ -smp 4 \ -m 4096 \ -drive file=pflash0.img,format=raw,if=pflash,readonly=on \ -drive file=pflash1.img,format=raw,if=pflash \ -device virtio-gpu-pci \ -display default,show-cursor=on \ -device qemu-xhci \ -device usb-kbd \ -device usb-tablet \ -device intel-hda \ -device hda-duplex \ -drive file=FreeBSD-12.1-RELEASE-arm64-aarch64.raw,format=raw,if=virtio,cache=writethrough \ -nographic \ -serial mon:stdio and Error i am getting is this ```qemu-system-aarch64: device requires 67108864 bytes, block backend provides 2097152 bytes``` does anyone tried running freebsd aarch 12 or freebsd arm 12 on qemu ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
