Re: [PATCH] riscv: Update RISC-V BSPs

[Hesham Almatary]

On Wed, 22 Feb 2023 at 20:48, Sebastian Huber
 wrote:
>
> On 22.02.23 16:14, Hesham Almatary wrote:
> > * Remove BSPs with medany name in them (See #4775).
> > RV64 BSPs are now all medany by default.
>
> Do we still need the non-medany 64-bit multilibs in GCC? I plan to
> adjust the multilib selection a bit and also add multilibs for
> non-compact 32-bit variants.
>
I don't think we need it anymore, please feel free to adjust it.

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



-- 
Regards,
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[gcc] RTEMS: Tune multilib selection

[Sebastian Huber]

gcc/ChangeLog:

* config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs.
Add non-compact 32-bit multilibs.
---
 gcc/config/riscv/t-rtems | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/gcc/config/riscv/t-rtems b/gcc/config/riscv/t-rtems
index 41f5927fc87..19b12030895 100644
--- a/gcc/config/riscv/t-rtems
+++ b/gcc/config/riscv/t-rtems
@@ -1,8 +1,8 @@
 MULTILIB_OPTIONS   =
 MULTILIB_DIRNAMES  =
 
-MULTILIB_OPTIONS   += 
march=rv32i/march=rv32im/march=rv32imafd/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv64imafd/march=rv64imac/march=rv64imafdc
-MULTILIB_DIRNAMES  += rv32i   rv32im   rv32imafd   rv32iac 
  rv32imac   rv32imafc   rv64imafd   rv64imac   rv64imafdc
+MULTILIB_OPTIONS   += 
march=rv32i/march=rv32iac/march=rv32im/march=rv32ima/march=rv32imac/march=rv32imaf/march=rv32imafc/march=rv32imafd/march=rv32imafdc/march=rv64ima/march=rv64imac/march=rv64imafd/march=rv64imafdc
+MULTILIB_DIRNAMES  += rv32i   rv32iac   rv32im   rv32ima   
rv32imac   rv32imaf   rv32imafc   rv32imafd   rv32imafdc   
rv64ima   rv64imac   rv64imafd   rv64imafdc
 
 MULTILIB_OPTIONS   += 
mabi=ilp32/mabi=ilp32f/mabi=ilp32d/mabi=lp64/mabi=lp64d
 MULTILIB_DIRNAMES  += ilp32  ilp32f  ilp32d  lp64  lp64d
@@ -12,14 +12,15 @@ MULTILIB_DIRNAMES   += medany
 
 MULTILIB_REQUIRED  =
 MULTILIB_REQUIRED  += march=rv32i/mabi=ilp32
-MULTILIB_REQUIRED  += march=rv32im/mabi=ilp32
-MULTILIB_REQUIRED  += march=rv32imafd/mabi=ilp32d
 MULTILIB_REQUIRED  += march=rv32iac/mabi=ilp32
+MULTILIB_REQUIRED  += march=rv32im/mabi=ilp32
+MULTILIB_REQUIRED  += march=rv32ima/mabi=ilp32
 MULTILIB_REQUIRED  += march=rv32imac/mabi=ilp32
+MULTILIB_REQUIRED  += march=rv32imaf/mabi=ilp32f
 MULTILIB_REQUIRED  += march=rv32imafc/mabi=ilp32f
-MULTILIB_REQUIRED  += march=rv64imafd/mabi=lp64d
-MULTILIB_REQUIRED  += march=rv64imafd/mabi=lp64d/mcmodel=medany
-MULTILIB_REQUIRED  += march=rv64imac/mabi=lp64
+MULTILIB_REQUIRED  += march=rv32imafd/mabi=ilp32d
+MULTILIB_REQUIRED  += march=rv32imafdc/mabi=ilp32d
+MULTILIB_REQUIRED  += march=rv64ima/mabi=lp64/mcmodel=medany
 MULTILIB_REQUIRED  += march=rv64imac/mabi=lp64/mcmodel=medany
-MULTILIB_REQUIRED  += march=rv64imafdc/mabi=lp64d
+MULTILIB_REQUIRED  += march=rv64imafd/mabi=lp64d/mcmodel=medany
 MULTILIB_REQUIRED  += march=rv64imafdc/mabi=lp64d/mcmodel=medany
-- 
2.35.3

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

Re: Jetson Nano BSP

[Christian MAUDERER]

Hello,

On 2023-02-23 06:15, Joel Sherrill wrote:



On Wed, Feb 22, 2023, 9:26 PM Prakhar Agrawal 
mailto:prakhar.agrawal...@gmail.com>> wrote:


Hello,

Does the current RTEMS version support the Jetson nano board, if
not, do you think It will be a good project for gsoc2023? something
like porting RTEMS to Jetson nano or jetson AGX orin maybe?


I'm torn whether this is a good project or not. It is quite ambitious 
but it appears that a fair amount of the boards horsepower is tied to 
binary blobs which likely won't work with RTEMS.


One challenge is that much of the support will be GPL licensed which is 
unacceptable for RTEMS.


That said, it may be feasible since freebsd appears to support it now. I 
have no idea what devices work under freebsd. But if you can boot 
freebsd on it and see what works, that would be great information.


https://cgit.freebsd.org/src/commit/?id=e903478919602c90fdc202a8628b89eb7c3bc104 


The other side of this is how useful this will be either for RTEMS 
users. What would a hobbyist use it for? A production team?


Is the board too old to be worth the effort for the limited audience?



The Jetson seems to be a big familiy. The Nano is from 2019 and has some 
chip that is most likely based on a chip from 2015? The Orin Nano is 
from September 2022 with some CPU that I didn't find on a quick search.


Otherwise, I fully agree with what Joel said: Do we have some audience 
for it? They are not really cheap so hobby use is unlikely.


I haven't found any source where I could buy small numbers of blank 
chips. In my experience, that often means that the manufacturer targets 
products where they sell big numbers of chips (at least 6 digit 
numbers). For these it's usually cheaper if the manufacturer just 
assigns a field application engineer to you instead of writing good 
documentation. If the Jetson falls into that category, it's not an easy 
project.



Honestly I'd rather see a new BSP for a decent RISC-V board.



Decent and not too expensive RISC-V would be interesting, but I haven't 
found too much of these yet. Only expensive stuff like the Renesas 
RZ/Five evaluation board or ones that are not yet easily available like 
the Pine Ox64 that I mentioned in other GSoC discussions already. If you 
find a nice cheap RISC-V board, it would be a great project. Other 
commonly available and well documented non-RISC-V boards or simulator 
targets can be interesting projects too.


Best regards

Christian




Looking forward to your response.


I'm also curious to hear what others think.

--joel


Best Regards
Prakhar

___
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


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.maude...@embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 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: Jetson Nano BSP

[Prakhar Agrawal]

I completely agree with all your points, but my rationale for introducing
the jetson nano or jetson AGX orin was because of their GPU power.

In the case of large hobby projects or maybe the initial days of a
startup(seed ones), a real-time system that can work with boards having
good GPU can do wonders.
For example, for an autonomous vehicle L2, L3 autonomy can be achieved
using a 60W Jetson AGX orin, hence if RTEMS support is added to the board,
it might help create an awesome system to handle all the critical time
constraints necessary for the vehicle and give it the ability to coordinate
a large number of concurrent activities.

One other use case I can think of is an autonomous space shuttle, which can
use AI to detect debris and space junk around it and steer itself through
them or maybe an AI-powered drone etc.

> Honestly I'd rather see a new BSP for a decent RISC-V board.

I was reading about RISC-V and their comparison with ARM SBC and in one
blog I read this - "ARM processors have benefited from a lot more research,
funding, and development than RISC-V. This means that it can be argued that
RISC-V is being left behind"

Looking forward to your opinions.

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

Re: Jetson Nano BSP

[Karel Gardas]

Hi Prakhar,

On 2/23/23 20:23, Prakhar Agrawal wrote:
I completely agree with all your points, but my rationale for 
introducing the jetson nano or jetson AGX orin was because of their GPU 
power.


it's really nice what Nvidia achieved here, right? Unfortunately this 
GPU potential is fully locked up by binary driver NVidia provides only 
for selected number of platforms --- if not just for the only one: 
Linux. So very questionable how you would unlock that on RTEMS during 
the limited time of GSoC. Just see what Nouveau folks are doing: 
https://nouveau.freedesktop.org/ -- for years and they just barely got 
to 3D acceleration. Just clone their git repo, see number of patches, 
lines of code provided and number of people involved and I think you 
will get an idea how mamooth task this is...




In the case of large hobby projects or maybe the initial days of a 
startup(seed ones), a real-time system that can work with boards having 
good GPU can do wonders.
For example, for an autonomous vehicle L2, L3 autonomy can be achieved 
using a 60W Jetson AGX orin, hence if RTEMS support is added to the 
board, it might help create an awesome system to handle all the critical 
time constraints necessary for the vehicle and give it the ability to 
coordinate a large number of concurrent activities.


If you are interested in machine vision based on AI and robotics, why 
not to look around for more open-source friendly solution? Recently just 
found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that 
powerful like NVidia, but NXP is historically more friendly to 3rd party 
OSes. Not sure about NPU, have not had a time to investigate that yet, 
but perhaps you do?


Also, with i.MX 8M Plus you still do have a chance to use AI Vision in 
non-real time manner running on top of Linux and run RTEMS real-time 
tasks on built in Cortex-M7 -- I mean if you decide that this particular 
BSP may be your GSoC. :-)


https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS


Honestly I'd rather see a new BSP for a decent RISC-V board.


I was reading about RISC-V and their comparison with ARM SBC and in one 
blog I read this - "ARM processors have benefited from a lot more 
research, funding, and development than RISC-V. This means that it can 
be argued that RISC-V is being left behind"


Do not worry about it. RISC-V is here and will stay. A lot was already 
invested into it and much more will still be...


Karel

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

Re: Jetson Nano BSP

[Alan Cudmore]

Hi all,

On Thu, Feb 23, 2023 at 4:00 PM Karel Gardas 
wrote:

>
> Hi Prakhar,
>
> On 2/23/23 20:23, Prakhar Agrawal wrote:
> > I completely agree with all your points, but my rationale for
> > introducing the jetson nano or jetson AGX orin was because of their GPU
> > power.
>
> it's really nice what Nvidia achieved here, right? Unfortunately this
> GPU potential is fully locked up by binary driver NVidia provides only
> for selected number of platforms --- if not just for the only one:
> Linux. So very questionable how you would unlock that on RTEMS during
> the limited time of GSoC. Just see what Nouveau folks are doing:
> https://nouveau.freedesktop.org/ -- for years and they just barely got
> to 3D acceleration. Just clone their git repo, see number of patches,
> lines of code provided and number of people involved and I think you
> will get an idea how mamooth task this is...
>
> >
> > In the case of large hobby projects or maybe the initial days of a
> > startup(seed ones), a real-time system that can work with boards having
> > good GPU can do wonders.
> > For example, for an autonomous vehicle L2, L3 autonomy can be achieved
> > using a 60W Jetson AGX orin, hence if RTEMS support is added to the
> > board, it might help create an awesome system to handle all the critical
> > time constraints necessary for the vehicle and give it the ability to
> > coordinate a large number of concurrent activities.
>
> If you are interested in machine vision based on AI and robotics, why
> not to look around for more open-source friendly solution? Recently just
> found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that
> powerful like NVidia, but NXP is historically more friendly to 3rd party
> OSes. Not sure about NPU, have not had a time to investigate that yet,
> but perhaps you do?
>
> Also, with i.MX 8M Plus you still do have a chance to use AI Vision in
> non-real time manner running on top of Linux and run RTEMS real-time
> tasks on built in Cortex-M7 -- I mean if you decide that this particular
> BSP may be your GSoC. :-)
>
>
> https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS
>
> >> Honestly I'd rather see a new BSP for a decent RISC-V board.
> >
> > I was reading about RISC-V and their comparison with ARM SBC and in one
> > blog I read this - "ARM processors have benefited from a lot more
> > research, funding, and development than RISC-V. This means that it can
> > be argued that RISC-V is being left behind"
>
> Do not worry about it. RISC-V is here and will stay. A lot was already
> invested into it and much more will still be...
>
> I'm working on submitting a RISC-V BSP variant for the Kendryte K210 CPU.
It's low cost and has a 1TOPS NPU. I don't think the NPU needs a binary
driver, and it typically is used with FreeRTOS or bare metal.
But I do like the idea of a dual CPU system where a linux/AI processor can
work with a RTOS based MCU for real time tasks.

Supply chain issues aside, I also am interested in the Pine64 0x64 and its
multiple RISC-V CPUs. I also have been watching the VisionFive 2, which has
a quad-core RISC-V CPU. The VisionFive 2 Linux support is still maturing,
but it does have OpenSBI U-boot, so it might be possible to load RTEMS
images over TFTP.
https://www.kickstarter.com/projects/starfive/visionfive-2
https://wiki.pine64.org/wiki/Ox64

For ARM based AI systems, what about the Beaglebone AI?
https://beagleboard.org/AI

But, maybe a GSOC sized project related to AI would be to integrate a
library such as tensorflow lite or TinyMAIX:
https://github.com/sipeed/TinyMaix
https://www.tensorflow.org/lite

They might work with the well supported RTEMS boards like the Beaglebone
black.

Regards,
Alan


> 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

Re: [gcc] RTEMS: Tune multilib selection

[Sebastian Huber]

On 23.02.23 19:38, Palmer Dabbelt wrote:
On Thu, 23 Feb 2023 03:48:26 PST (-0800), 
sebastian.hu...@embedded-brains.de wrote:

gcc/ChangeLog:

* config/riscv/t-rtems: Keep only -mcmodel=medany 64-bit multilibs.
Add non-compact 32-bit multilibs.
---
 gcc/config/riscv/t-rtems | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/gcc/config/riscv/t-rtems b/gcc/config/riscv/t-rtems
index 41f5927fc87..19b12030895 100644
--- a/gcc/config/riscv/t-rtems
+++ b/gcc/config/riscv/t-rtems
@@ -1,8 +1,8 @@
 MULTILIB_OPTIONS    =
 MULTILIB_DIRNAMES    =

-MULTILIB_OPTIONS    += 
march=rv32i/march=rv32im/march=rv32imafd/march=rv32iac/march=rv32imac/march=rv32imafc/march=rv64imafd/march=rv64imac/march=rv64imafdc
-MULTILIB_DIRNAMES    += rv32i   rv32im   rv32imafd 
rv32iac   rv32imac   rv32imafc   rv64imafd rv64imac   
rv64imafdc
+MULTILIB_OPTIONS    += 
march=rv32i/march=rv32iac/march=rv32im/march=rv32ima/march=rv32imac/march=rv32imaf/march=rv32imafc/march=rv32imafd/march=rv32imafdc/march=rv64ima/march=rv64imac/march=rv64imafd/march=rv64imafdc
+MULTILIB_DIRNAMES    += rv32i   rv32iac   rv32im 
rv32ima   rv32imac   rv32imaf   rv32imafc rv32imafd   
rv32imafdc   rv64ima   rv64imac rv64imafd   rv64imafdc


 MULTILIB_OPTIONS    += 
mabi=ilp32/mabi=ilp32f/mabi=ilp32d/mabi=lp64/mabi=lp64d
 MULTILIB_DIRNAMES    += ilp32  ilp32f  ilp32d  lp64  
lp64d

@@ -12,14 +12,15 @@ MULTILIB_DIRNAMES    += medany

 MULTILIB_REQUIRED    =
 MULTILIB_REQUIRED    += march=rv32i/mabi=ilp32
-MULTILIB_REQUIRED    += march=rv32im/mabi=ilp32
-MULTILIB_REQUIRED    += march=rv32imafd/mabi=ilp32d
 MULTILIB_REQUIRED    += march=rv32iac/mabi=ilp32
+MULTILIB_REQUIRED    += march=rv32im/mabi=ilp32
+MULTILIB_REQUIRED    += march=rv32ima/mabi=ilp32
 MULTILIB_REQUIRED    += march=rv32imac/mabi=ilp32
+MULTILIB_REQUIRED    += march=rv32imaf/mabi=ilp32f
 MULTILIB_REQUIRED    += march=rv32imafc/mabi=ilp32f
-MULTILIB_REQUIRED    += march=rv64imafd/mabi=lp64d
-MULTILIB_REQUIRED    += march=rv64imafd/mabi=lp64d/mcmodel=medany
-MULTILIB_REQUIRED    += march=rv64imac/mabi=lp64
+MULTILIB_REQUIRED    += march=rv32imafd/mabi=ilp32d
+MULTILIB_REQUIRED    += march=rv32imafdc/mabi=ilp32d
+MULTILIB_REQUIRED    += march=rv64ima/mabi=lp64/mcmodel=medany
 MULTILIB_REQUIRED    += march=rv64imac/mabi=lp64/mcmodel=medany
-MULTILIB_REQUIRED    += march=rv64imafdc/mabi=lp64d
+MULTILIB_REQUIRED    += march=rv64imafd/mabi=lp64d/mcmodel=medany
 MULTILIB_REQUIRED    += march=rv64imafdc/mabi=lp64d/mcmodel=medany


Reviewed-by: Palmer Dabbelt 

IMO it's fine to remove multilibs from the default set.  It could be 
seen as breaking users, but IIRC last time we talked about something 
like this it was OK as otherwise we're going to end up with a huge set 
of multilibs for defunct ISAs.  This one is also extra safe, since 
moving to medany shouldn't break any users (aside from maybe a slight 
performance issue).


Thanks for the review. Which performance issue may show up here?


Are you aiming for GCC-13 with this?  I wouldn't be opposed to that: 
there's some risk of breaking users this late in the process, but my 
guess is that most of them aren't looking until release anyway.  Still 
better to hold off, but if there's something in RTEMS land that benefits 
from this being early then I think it's fine.


RTEMS has its own release cycle, so I would back port this change to all 
GCC branches which may be used with RTEMS 6 and this is GCC 10 or later.


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