Running two RTEMS instances on two RISC-V harts
hello, world\n
we’re currently in the design phase for a rocketchip RISC-V project with two
harts.
Think a common HW platform where each hart drives a separate telescope unit.
The C code for each telescope is basically identical with the exception of
memory mapped registers and interrupts.
Our idea is to compile the C code twice and link with different linkerscripts,
separating the images in RAM
via different MEMORY { RAM: ORIGIN = 0x } declarations. A bootloader
loads the images
to different addresses and branches depending on mhartid, starting two separate
RTEMS applications, each
of which runs 10 tasks. There’s no communication between the RTEMS instances.
Are we attempting something crazy (too complex) and we should instead look into
?
If not, is there a simple way to compile an app twice for different RAM: ORIGIN
values?
I tried using a Linkerscript with -Wl,-T,Linkerscript with a different MEMORY
but this draws a warning such as
warning: redeclaration of memory region `RAM'
and uses the value in the BSPs linkcmds file. It looks like the last
declaration wins and the linkcmds is
always read after linker scripts specified by my -Wl command line option.
Jens Schweikhardt
TL4 LCT Software Development
Phone:
Mail:
+49 7191 930-2849
jens.schweikha...@tesat.de
[logo][tw]
This electronic message may contain highly confidential or privileged
information from Tesat-Spacecom GmbH & Co. KG. Any of the information is only
intended for the recipient and the use by any other party is not authorized. If
you are not the intended recipient, be aware, that any disclosure, copying,
distribution or use of the contents of this message is prohibited. If you have
received this message by error please notify us immediately by telephone (+49
7191 930-2849) or by e-mail (jens.schweikha...@tesat.de). Thank you.
Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid
[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
RE: Running two RTEMS instances on two RISC-V harts
Hi Jens,
Is there a real need to have the telescope driver twice in memory?
Would it be enough to implement the driver as “object oriented” in C?
Then you would just need to create a context struct during initialization based
on the hartid with the correct interrupt assignment and base address of the
memory mapped registers.
At least that is a common pattern in the driver implementations of RTEMS.
Best regards,
Jan
PS: It is probably a good idea to remove the disclaimer in your email footer
before posting to a public mailinglist.
From: users On Behalf Of Schweikhardt, Jens
(TSPCE6-TL5)
Sent: Montag, 24. Oktober 2022 13:53
To: 'users@rtems.org'
Subject: Running two RTEMS instances on two RISC-V harts
hello, world\n
we’re currently in the design phase for a rocketchip RISC-V project with two
harts.
Think a common HW platform where each hart drives a separate telescope unit.
The C code for each telescope is basically identical with the exception of
memory mapped registers and interrupts.
Our idea is to compile the C code twice and link with different linkerscripts,
separating the images in RAM
via different MEMORY { RAM: ORIGIN = 0x } declarations. A bootloader
loads the images
to different addresses and branches depending on mhartid, starting two separate
RTEMS applications, each
of which runs 10 tasks. There’s no communication between the RTEMS instances.
Are we attempting something crazy (too complex) and we should instead look into
?
If not, is there a simple way to compile an app twice for different RAM: ORIGIN
values?
I tried using a Linkerscript with -Wl,-T,Linkerscript with a different MEMORY
but this draws a warning such as
warning: redeclaration of memory region `RAM'
and uses the value in the BSPs linkcmds file. It looks like the last
declaration wins and the linkcmds is
always read after linker scripts specified by my -Wl command line option.
Jens Schweikhardt
TL4 LCT Software Development
Phone:
Mail:
+49 7191 930-2849
jens.schweikha...@tesat.de
[logo][tw]
This electronic message may contain highly confidential or privileged
information from Tesat-Spacecom GmbH & Co. KG. Any of the information is only
intended for the recipient and the use by any other party is not authorized. If
you are not the intended recipient, be aware, that any disclosure, copying,
distribution or use of the contents of this message is prohibited. If you have
received this message by error please notify us immediately by telephone (+49
7191 930-2849) or by e-mail (jens.schweikha...@tesat.de). Thank you.
Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid
[Image removed by sender. banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
AW: Running two RTEMS instances on two RISC-V harts
Hi Jan,
well, in the beginning there was a system with just one telescope. Now a second
shall be added.
Easy as 1-2-3: duplicate the software and run it on two cores. No SW changes
needed.
Developers like me are expensive J That’s how corporate thinks.
Driving a telescope involves not just a single driver, it’s a symphony of 10
tasks
juggling tele-commands and telemetry data. Turning a singleton application into
a
multi-telescope app would probably require extensive changes. There is a lot of
data
that needs to be part of that context struct you suggest. Running two
“unmodified”
RTEMS instances would make that easy: the context structs are the data segments.
(Which is why running two RTEMS instances from the /same/ address does NOT work:
they overwrite their data segment objects and trash each others stacks, etc. Can
this be avoided with linker script magic?).
About the disclaimer, I think I can get rid of the first one, the second is due
to
corporate lawyers fearing getting their pants sued off and auto-appended by the
mailhost. GRRR.
Thanks for taking the time to help me find a way how to proceed.
Jens
Von: jan.som...@dlr.de
Gesendet: Montag, 24. Oktober 2022 14:13
An: Schweikhardt, Jens (TSPCE6-TL5) ;
users@rtems.org
Betreff: RE: Running two RTEMS instances on two RISC-V harts
Externe E-Mail: Bitte Absender und Inhalt der Mail prüfen, bevor Dateianhänge
oder Links geöffnet werden!
Hi Jens,
Is there a real need to have the telescope driver twice in memory?
Would it be enough to implement the driver as “object oriented” in C?
Then you would just need to create a context struct during initialization based
on the hartid with the correct interrupt assignment and base address of the
memory mapped registers.
At least that is a common pattern in the driver implementations of RTEMS.
Best regards,
Jan
PS: It is probably a good idea to remove the disclaimer in your email footer
before posting to a public mailinglist.
From: users mailto:users-boun...@rtems.org>> On Behalf
Of Schweikhardt, Jens (TSPCE6-TL5)
Sent: Montag, 24. Oktober 2022 13:53
To: 'users@rtems.org' mailto:users@rtems.org>>
Subject: Running two RTEMS instances on two RISC-V harts
hello, world\n
we’re currently in the design phase for a rocketchip RISC-V project with two
harts.
Think a common HW platform where each hart drives a separate telescope unit.
The C code for each telescope is basically identical with the exception of
memory mapped registers and interrupts.
Our idea is to compile the C code twice and link with different linkerscripts,
separating the images in RAM
via different MEMORY { RAM: ORIGIN = 0x } declarations. A bootloader
loads the images
to different addresses and branches depending on mhartid, starting two separate
RTEMS applications, each
of which runs 10 tasks. There’s no communication between the RTEMS instances.
Are we attempting something crazy (too complex) and we should instead look into
?
If not, is there a simple way to compile an app twice for different RAM: ORIGIN
values?
I tried using a Linkerscript with -Wl,-T,Linkerscript with a different MEMORY
but this draws a warning such as
warning: redeclaration of memory region `RAM'
and uses the value in the BSPs linkcmds file. It looks like the last
declaration wins and the linkcmds is
always read after linker scripts specified by my -Wl command line option.
Tesat-Spacecom GmbH & Co. KG
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRA 270977
Persoenlich haftender Gesellschafter: Tesat-Spacecom Geschaeftsfuehrungs GmbH;
Sitz: Backnang; Registergericht: Amtsgericht Stuttgart HRB 271658;
Geschaeftsfuehrung: Thomas Reinartz, Kerstin Basche, Ralph Schmid
[banner]
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Running two RTEMS instances on two RISC-V harts
Hello Jens, in general, such a setups works. We used it some time ago on the NXP P1020 before the SMP support was available. You just have to provide two MEMORY definitions for the linker. You also have to make sure that you don't accidentally share hardware modules between the two RTEMS instances without synchronization. -- 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/ ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Running two RTEMS instances on two RISC-V harts
The leon3 BSP also supported something similar at one point. If the two applications do not need to communicate, then it should not be an issue. If the do need to communicate, then this might be a case where the original distributed multiprocessing in RTEMS makes sense. It isn't used much but is still there. Or you could just reserve some RAM for a shared communications area and manage it yourself. The key is going to be keeping the two really separate and making sure you can load two images. --joel On Mon, Oct 24, 2022 at 8:03 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Jens, > > in general, such a setups works. We used it some time ago on the NXP > P1020 before the SMP support was available. You just have to provide two > MEMORY definitions for the linker. You also have to make sure that you > don't accidentally share hardware modules between the two RTEMS > instances without synchronization. > > -- > 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/ > ___ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
