Jetson Nano BSP

Fri Feb 24 09:09:33 UTC 2023

On 2023-02-24 03:52, Alan Cudmore wrote:
> Hi all,
> 
> On Thu, Feb 23, 2023 at 4:00 PM Karel Gardas <karel at functional.vision> 
> 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/ <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 <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.
> 

Systems where a Linux (or other desktop-like OS) runs on one core and 
RTEMS on another would be interesting for other cases too. For example 
for an industrial system where you can have a complex GUI and a real 
time part. We had some systems where we thought about implementing 
something like that.

> 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://www.kickstarter.com/projects/starfive/visionfive-2>
> https://wiki.pine64.org/wiki/Ox64 <https://wiki.pine64.org/wiki/Ox64>
> 
> For ARM based AI systems, what about the Beaglebone AI?
> https://beagleboard.org/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://github.com/sipeed/TinyMaix>
> https://www.tensorflow.org/lite <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 at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
>     <http://lists.rtems.org/mailman/listinfo/devel>
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.mauderer at 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/