Re: Interested for GSoC 2023

[Karel Gardas]

On 2/27/23 02:16, Joel Sherrill wrote:
Another GCC related project could be Rust RTEMS Support but I don't know 
what that entails beyond turning it on and seeing what goes wrong. I 
tried to build it last year and got far enough to decide to wait before 
trying again.


Not sure how far you went. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific 
hardware/os platform. So basically you get no_std capable compiler


(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth 
sharp edges for RTEMS.


Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not 
cortex-mX).


Karel

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

RE: Interested for GSoC 2023

[Jan.Sommer]

> -Original Message-
> From: devel  On Behalf Of Karel Gardas
> Sent: Montag, 27. Februar 2023 09:16
> To: j...@rtems.org; Vihas Makwana 
> Cc: rtems-de...@rtems.org 
> Subject: Re: Interested for GSoC 2023
> 
> On 2/27/23 02:16, Joel Sherrill wrote:
> > Another GCC related project could be Rust RTEMS Support but I don't
> > know what that entails beyond turning it on and seeing what goes
> > wrong. I tried to build it last year and got far enough to decide to
> > wait before trying again.
> 
> Not sure how far you went. The process is generally:
> 
> (1) tune Rust compiler to cross-compile correctly for specific hardware/os
> platform. So basically you get no_std capable compiler
> 
> (2) review, patch and by using (1) cross-compile libc
> 
> (3) using sources from (1) and (2) build full stage (std enabled) rustc.
> 
> (4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
> sharp edges for RTEMS.
> 
> Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not cortex-
> mX).
> 

Hi Karel,

Very interesting work. I am currently trying to reach the same goal.
The steps I came up with are a bit different:
A.) Build working llvm toolchain for RTEMS (figure out all flags etc., maybe 
building RTEMS with llvm as a bonus)
B.) Build rustc with the "RTEMS-llvm" as backend
C.) Start with no_std and then inch forward to building the stdlib

I work currently on step A (see my llvm experiments in the other thread) and 
started to look at the build stages for rustc.
If you have any tips for the configuration from your step (1), it would be 
greatly appreciated.
My hope is that with the results of step A I can reuse the libc from the 
standard rtems-gcc build environment as this is provided conveniently via rsb.
I am really looking forward to seeing rust supported on RTEMS.

Best regards,

Jan

PS: Maybe it is worth starting a new thread for exchanging ideas? I don't mean 
to hijack Vihas thread.

> Karel
> 
> ___
> 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

Rust for RTEMS [was: Re: Interested for GSoC 2023]

[Karel Gardas]

adjusting subject based on Jan request. Keeping whole Rust relevant 
comments in.


On 2/27/23 11:07, jan.som...@dlr.de wrote:




-Original Message-
From: devel  On Behalf Of Karel Gardas
Sent: Montag, 27. Februar 2023 09:16
To: j...@rtems.org; Vihas Makwana 
Cc: rtems-de...@rtems.org 
Subject: Re: Interested for GSoC 2023

On 2/27/23 02:16, Joel Sherrill wrote:

Another GCC related project could be Rust RTEMS Support but I don't
know what that entails beyond turning it on and seeing what goes
wrong. I tried to build it last year and got far enough to decide to
wait before trying again.


Not sure how far you went. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific hardware/os
platform. So basically you get no_std capable compiler

(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
sharp edges for RTEMS.

Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not cortex-
mX).



Hi Karel,

Very interesting work. I am currently trying to reach the same goal.
The steps I came up with are a bit different:
A.) Build working llvm toolchain for RTEMS (figure out all flags etc., maybe 
building RTEMS with llvm as a bonus)
B.) Build rustc with the "RTEMS-llvm" as backend


Honestly I'm not so sure (A) and (B) are necessary for rustc port. Or 
perhaps I do not precisely follow what you mean, but IMHO what you need 
is to get ABI and linking with RTEMS binaries right. And this applies 
also to RTEMS being build by GCC toolchain. This is objective of my (1) 
work.



C.) Start with no_std and then inch forward to building the stdlib

I work currently on step A (see my llvm experiments in the other thread) and 
started to look at the build stages for rustc.
If you have any tips for the configuration from your step (1), it would be 
greatly appreciated.
My hope is that with the results of step A I can reuse the libc from the 
standard rtems-gcc build environment as this is provided conveniently via rsb.


Not sure if I did not confused you with my (2) libc remark. I of course 
mean Rust's libc (that means rust code) to be build on top of 
RTEMS/Newlib/libbsd combination. It'll be interesting project especially 
if the requirement later would be to support both binary targets: e.g. 
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for 
full-blown configuration. Anyway, for now, I would start with libbsd as 
this should make project proceeding faster IMHO.



I am really looking forward to seeing rust supported on RTEMS.


Me too!

Karel

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

Re: Rust for RTEMS [was: Re: Interested for GSoC 2023]

[Joel Sherrill]

On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas 
wrote:

>
> adjusting subject based on Jan request. Keeping whole Rust relevant
> comments in.
>
> On 2/27/23 11:07, jan.som...@dlr.de wrote:
> >
> >
> >> -Original Message-
> >> From: devel  On Behalf Of Karel Gardas
> >> Sent: Montag, 27. Februar 2023 09:16
> >> To: j...@rtems.org; Vihas Makwana 
> >> Cc: rtems-de...@rtems.org 
> >> Subject: Re: Interested for GSoC 2023
> >>
> >> On 2/27/23 02:16, Joel Sherrill wrote:
> >>> Another GCC related project could be Rust RTEMS Support but I don't
> >>> know what that entails beyond turning it on and seeing what goes
> >>> wrong. I tried to build it last year and got far enough to decide to
> >>> wait before trying again.
> >>
> >> Not sure how far you went. The process is generally:
> >>
> >> (1) tune Rust compiler to cross-compile correctly for specific
> hardware/os
> >> platform. So basically you get no_std capable compiler
>

You should be able to compile gcc rust NOW to target CPU-rtems. I would
expect minor tweaking of configuration both in configure scripting and
likely
in the Rust run-time libraries. For example, with the Standard C++ Library
there are configuration settings for *-rtems which pick the threading and
synchronization model. Rust's run-time adapter with GCC should be similar.


> >>
> >> (2) review, patch and by using (1) cross-compile libc
>

Not a huge deal since you can add Rust to a standard gcc build
by adding rust to the "--enable-languages" argument on configure.

It is basically a standard cross gcc-rtems build with rust added to
the languages.



> >>
> >> (3) using sources from (1) and (2) build full stage (std enabled) rustc.



> >>
> >> (4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
> >> sharp edges for RTEMS.
>

Yep. May also uncover some small alligators in the standard Rust code which
is too Linux centric.


> >>
> >> Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not
> cortex-
> >> mX).
>

Is it using the "one tree" build and build the C library at the same time?

I attached my scripts to do this. Be warned they are what is jokingly
referred
to as "j scripts" which means they are helpers for me but not necessarily
for external human consumption. :)

Generally you will have to tweak them at the top for install point,
binutils and
gcc source tree name, etc. I generally:

+ clone binutils-gdb, newlib, and gcc
+ sym link newlib/newlib and newlib/libgloss into gcc's tree
+ run contrib/download_prerequesites in the top of gcc's source tree

j-bin gets you an install of binutils and gdb
j-gcc layers on gcc

You likely want to make sure the script --disable-multilib to speed up
the builds and work with an architecture/BSP where the default
multilib works together. sparc and aarch64 meet that rule. Building
the multlibs is time consuming and counterproductive when just
working through basic breakages.


> >>
> >
> > Hi Karel,
> >
> > Very interesting work. I am currently trying to reach the same goal.
> > The steps I came up with are a bit different:
> > A.) Build working llvm toolchain for RTEMS (figure out all flags etc.,
> maybe building RTEMS with llvm as a bonus)
> > B.) Build rustc with the "RTEMS-llvm" as backend
>
> Honestly I'm not so sure (A) and (B) are necessary for rustc port. Or
> perhaps I do not precisely follow what you mean, but IMHO what you need
> is to get ABI and linking with RTEMS binaries right. And this applies
> also to RTEMS being build by GCC toolchain. This is objective of my (1)
> work.
>
> > C.) Start with no_std and then inch forward to building the stdlib
> >
> > I work currently on step A (see my llvm experiments in the other thread)
> and started to look at the build stages for rustc.
> > If you have any tips for the configuration from your step (1), it would
> be greatly appreciated.
> > My hope is that with the results of step A I can reuse the libc from the
> standard rtems-gcc build environment as this is provided conveniently via
> rsb.
>
> Not sure if I did not confused you with my (2) libc remark. I of course
> mean Rust's libc (that means rust code) to be build on top of
> RTEMS/Newlib/libbsd combination. It'll be interesting project especially
> if the requirement later would be to support both binary targets: e.g.
> RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for
> full-blown configuration. Anyway, for now, I would start with libbsd as
> this should make project proceeding faster IMHO.
>

You shouldn't need RTEMS or libbsd built until you link real executables
you want to run. All needed POSIX headers are present from newlib.

I was test building rust just like C, C++, and Ada. Build the toolchain and
then build RTEMS.

>
> > I am really looking forward to seeing rust supported on RTEMS.
>
> Me too!
>
> Karel
>
>


j-bin
Description: Binary data


j-gcc
Description: Binary data
___
devel mailing list
devel@rtems.org
http://list

Re: Rust for RTEMS [was: Re: Interested for GSoC 2023]

[Karel Gardas]

On 2/27/23 15:44, Joel Sherrill wrote:



On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas  
wrote:



adjusting subject based on Jan request. Keeping whole Rust relevant
comments in.

On 2/27/23 11:07, jan.som...@dlr.de  wrote:
 >
 >
 >> -Original Message-
 >> From: devel mailto:devel-boun...@rtems.org>> On Behalf Of Karel Gardas
 >> Sent: Montag, 27. Februar 2023 09:16
 >> To: j...@rtems.org ; Vihas Makwana
mailto:makvi...@gmail.com>>
 >> Cc: rtems-de...@rtems.org 
mailto:devel@rtems.org>>
 >> Subject: Re: Interested for GSoC 2023
 >>
 >> On 2/27/23 02:16, Joel Sherrill wrote:
 >>> Another GCC related project could be Rust RTEMS Support but I don't
 >>> know what that entails beyond turning it on and seeing what goes
 >>> wrong. I tried to build it last year and got far enough to
decide to
 >>> wait before trying again.
 >>
 >> Not sure how far you went. The process is generally:
 >>
 >> (1) tune Rust compiler to cross-compile correctly for specific
hardware/os
 >> platform. So basically you get no_std capable compiler


You should be able to compile gcc rust NOW to target CPU-rtems. I would
expect minor tweaking of configuration both in configure scripting and 
likely

in the Rust run-time libraries. For example, with the Standard C++ Library
there are configuration settings for *-rtems which pick the threading and
synchronization model. Rust's run-time adapter with GCC should be similar.


There is a slight misunderstanding going here. I'm not talking about 
gccrs rust frond-end project which got merged into GCC to become part of 
GCC 13 in autumn last year to be released this spring probably. I'm 
talking and AFAIK Jan too about real Rust as distributed/provided by 
https://www.rust-lang.org/.


The messages from gccrs project are kind of mixed and clearly warns that 
even with GCC 13, the front-end would be good just for GCC rust ongoing 
development and not yet for let say Rust code in Linux kernel. I write 
that not to play that attempt down, in fact gccrs people work is 
outstanding, I write that just to remark that it may take some time 
before it's ready for general "consumption".


Hence, when investigating Rust for RTEMS, I went to rust-lang.org and 
investigated that because after all, this is still reference Rust 
implementation...



Not sure if I did not confused you with my (2) libc remark. I of course
mean Rust's libc (that means rust code) to be build on top of
RTEMS/Newlib/libbsd combination. It'll be interesting project
especially
if the requirement later would be to support both binary targets: e.g.
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for
full-blown configuration. Anyway, for now, I would start with libbsd as
this should make project proceeding faster IMHO.


You shouldn't need RTEMS or libbsd built until you link real executables
you want to run. All needed POSIX headers are present from newlib.


But I'm at the stage I'd like to link my Rust hello world with RTEMS 
BSP, that's what someone expects at the end anyway. :-)



I was test building rust just like C, C++, and Ada. Build the toolchain and
then build RTEMS.


So you liked rust + RTEMS well? Cool!

Karel

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

[PATCH] bsps/riscv: Clear interrupt complete before disable

[Padmarao Begari]

The interrupt complete should clear with the interrupt
number before disabling the interrupt in the PLIC to
get the next interrupt.
---
 bsps/riscv/riscv/irq/irq.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/bsps/riscv/riscv/irq/irq.c b/bsps/riscv/riscv/irq/irq.c
index e8d297052b..8e72bd8da5 100644
--- a/bsps/riscv/riscv/irq/irq.c
+++ b/bsps/riscv/riscv/irq/irq.c
@@ -585,6 +585,8 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
 
 #ifdef RTEMS_SMP
 if (enable != NULL) {
+  cpu = _Per_CPU_Get_by_index(_CPU_SMP_Get_current_processor());
+  cpu->cpu_per_cpu.plic_hart_regs->claim_complete = interrupt_index
   enable[group] &= ~bit;
 } else {
   uint32_t cpu_max;
@@ -595,6 +597,7 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
   for (cpu_index = 0; cpu_index < cpu_max; ++cpu_index) {
 cpu = _Per_CPU_Get_by_index(cpu_index);
 enable = cpu->cpu_per_cpu.plic_m_ie;
+cpu->cpu_per_cpu.plic_hart_regs->claim_complete = interrupt_index
 
 if (enable != NULL) {
   enable[group] &= ~bit;
@@ -603,6 +606,7 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
 }
 #else
 cpu = _Per_CPU_Get_by_index(0);
+cpu->cpu_per_cpu.plic_hart_regs->claim_complete = interrupt_index
 cpu->cpu_per_cpu.plic_m_ie[group] &= ~bit;
 #endif
 
-- 
2.25.1

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

Re: RFC #4666 TFTP: Implement block and window size options

[Frank Kühndel]

Hello Joel,

there is nothing which remains to be done. Hence, I closed this ticket. 
Thanks for remaining us and please excuse our sluggish response.


Greetings
Frank

On 2/22/23 21:12, Joel Sherrill wrote:

Hi Sebastian,

This ticket has a number of commits logged against it. What remains or can
it be closed?

https://devel.rtems.org/ticket/4666

If it can't be closed, an update on what needs to be done should be added
and maybe the milestone bumped.

Thanks.

--joel


--
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

Re: [PATCH] bsps/aarch64: Disable interrupts during MMU remap

[Gedare Bloom]

seems ok to me

On Fri, Feb 24, 2023 at 3:27 PM Kinsey Moore  wrote:
>
> Interrupts must be disabled during MMU remapping since the majority of
> RTEMS including interrupts expects normal memory mapping semantics such
> as unaligned accesses.
> ---
>  bsps/aarch64/shared/mmu/vmsav8-64.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/bsps/aarch64/shared/mmu/vmsav8-64.c 
> b/bsps/aarch64/shared/mmu/vmsav8-64.c
> index 190a05f7d5..270b9319ad 100644
> --- a/bsps/aarch64/shared/mmu/vmsav8-64.c
> +++ b/bsps/aarch64/shared/mmu/vmsav8-64.c
> @@ -47,12 +47,16 @@ rtems_status_code aarch64_mmu_map(
>  )
>  {
>rtems_status_code sc;
> +  ISR_Levellevel;
>uint64_t max_mappable = 1LLU << aarch64_mmu_get_cpu_pa_bits();
>
>if ( addr >= max_mappable || (addr + size) > max_mappable ) {
>  return RTEMS_INVALID_ADDRESS;
>}
>
> +  /* Disable interrupts so they don't run while the MMU is disabled */
> +  _ISR_Local_disable( level );
> +
>aarch64_mmu_disable();
>sc = aarch64_mmu_map_block(
>  (uint64_t *) bsp_translation_table_base,
> @@ -70,5 +74,7 @@ rtems_status_code aarch64_mmu_map(
>_AARCH64_Instruction_synchronization_barrier();
>aarch64_mmu_enable();
>
> +  _ISR_Local_enable( level );
> +
>return sc;
>  }
> --
> 2.30.2
>
> ___
> 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