<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 24, 2023 at 4:09 AM Christian MAUDERER <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-02-24 03:52, Alan Cudmore wrote:<br>
> Hi all,<br>
> <br>
> On Thu, Feb 23, 2023 at 4:00 PM Karel Gardas <karel@functional.vision> <br>
> wrote:<br>
> <br>
> <br>
> Hi Prakhar,<br>
> <br>
> On 2/23/23 20:23, Prakhar Agrawal wrote:<br>
> > I completely agree with all your points, but my rationale for<br>
> > introducing the jetson nano or jetson AGX orin was because of<br>
> their GPU<br>
> > power.<br>
> <br>
> it's really nice what Nvidia achieved here, right? Unfortunately this<br>
> GPU potential is fully locked up by binary driver NVidia provides only<br>
> for selected number of platforms --- if not just for the only one:<br>
> Linux. So very questionable how you would unlock that on RTEMS during<br>
> the limited time of GSoC. Just see what Nouveau folks are doing:<br>
> <a href="https://nouveau.freedesktop.org/" rel="noreferrer" target="_blank">https://nouveau.freedesktop.org/</a> <<a href="https://nouveau.freedesktop.org/" rel="noreferrer" target="_blank">https://nouveau.freedesktop.org/</a>><br>
> -- for years and they just barely got<br>
> to 3D acceleration. Just clone their git repo, see number of patches,<br>
> lines of code provided and number of people involved and I think you<br>
> will get an idea how mamooth task this is...<br>
> <br>
> ><br>
> > In the case of large hobby projects or maybe the initial days of a<br>
> > startup(seed ones), a real-time system that can work with boards<br>
> having<br>
> > good GPU can do wonders.<br>
> > For example, for an autonomous vehicle L2, L3 autonomy can be<br>
> achieved<br>
> > using a 60W Jetson AGX orin, hence if RTEMS support is added to the<br>
> > board, it might help create an awesome system to handle all the<br>
> critical<br>
> > time constraints necessary for the vehicle and give it the<br>
> ability to<br>
> > coordinate a large number of concurrent activities.<br>
> <br>
> If you are interested in machine vision based on AI and robotics, why<br>
> not to look around for more open-source friendly solution? Recently<br>
> just<br>
> found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that<br>
> powerful like NVidia, but NXP is historically more friendly to 3rd<br>
> party<br>
> OSes. Not sure about NPU, have not had a time to investigate that yet,<br>
> but perhaps you do?<br>
> <br>
> Also, with i.MX 8M Plus you still do have a chance to use AI Vision in<br>
> non-real time manner running on top of Linux and run RTEMS real-time<br>
> tasks on built in Cortex-M7 -- I mean if you decide that this<br>
> particular<br>
> BSP may be your GSoC. :-)<br>
> <br>
> <a href="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" rel="noreferrer" target="_blank">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</a> <<a href="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" rel="noreferrer" target="_blank">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</a>><br>
> <br>
> >> Honestly I'd rather see a new BSP for a decent RISC-V board.<br>
> ><br>
> > I was reading about RISC-V and their comparison with ARM SBC and<br>
> in one<br>
> > blog I read this - "ARM processors have benefited from a lot more<br>
> > research, funding, and development than RISC-V. This means that<br>
> it can<br>
> > be argued that RISC-V is being left behind"<br>
> <br>
> Do not worry about it. RISC-V is here and will stay. A lot was already<br>
> invested into it and much more will still be...<br>
> <br>
> I'm working on submitting a RISC-V BSP variant for the Kendryte K210 <br>
> CPU. It's low cost and has a 1TOPS NPU. I don't think the NPU needs a <br>
> binary driver, and it typically is used with FreeRTOS or bare metal.<br>
> But I do like the idea of a dual CPU system where a linux/AI processor <br>
> can work with a RTOS based MCU for real time tasks.<br>
> <br>
<br>
Systems where a Linux (or other desktop-like OS) runs on one core and <br>
RTEMS on another would be interesting for other cases too. For example <br>
for an industrial system where you can have a complex GUI and a real <br>
time part. We had some systems where we thought about implementing <br>
something like that.<br>
<br></blockquote><div><br></div><div>It looks like the TI TDA4VM on the Beaglebone AI-64 has a dual core A72, a number of DSPs, and 3 dual R5 processors. I'm not sure how open it is, but Ti provides SDKs that include RTOS and bare metal examples for the DSPs and R5s. The Beagle AI-64 is around $200USD. It looks like the SoC is targeted for automotive applications.</div><div><a href="https://www.ti.com/product/TDA4VM">https://www.ti.com/product/TDA4VM</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Supply chain issues aside, I also am interested in the Pine64 0x64 and <br>
> its multiple RISC-V CPUs. I also have been watching the VisionFive 2, <br>
> which has a quad-core RISC-V CPU. The VisionFive 2 Linux support is <br>
> still maturing, but it does have OpenSBI U-boot, so it might be possible <br>
> to load RTEMS images over TFTP.<br>
> <a href="https://www.kickstarter.com/projects/starfive/visionfive-2" rel="noreferrer" target="_blank">https://www.kickstarter.com/projects/starfive/visionfive-2</a> <br>
> <<a href="https://www.kickstarter.com/projects/starfive/visionfive-2" rel="noreferrer" target="_blank">https://www.kickstarter.com/projects/starfive/visionfive-2</a>><br>
> <a href="https://wiki.pine64.org/wiki/Ox64" rel="noreferrer" target="_blank">https://wiki.pine64.org/wiki/Ox64</a> <<a href="https://wiki.pine64.org/wiki/Ox64" rel="noreferrer" target="_blank">https://wiki.pine64.org/wiki/Ox64</a>><br>
> <br>
> For ARM based AI systems, what about the Beaglebone AI?<br>
> <a href="https://beagleboard.org/AI" rel="noreferrer" target="_blank">https://beagleboard.org/AI</a> <<a href="https://beagleboard.org/AI" rel="noreferrer" target="_blank">https://beagleboard.org/AI</a>><br>
> <br>
> But, maybe a GSOC sized project related to AI would be to integrate a <br>
> library such as tensorflow lite or TinyMAIX:<br>
> <a href="https://github.com/sipeed/TinyMaix" rel="noreferrer" target="_blank">https://github.com/sipeed/TinyMaix</a> <<a href="https://github.com/sipeed/TinyMaix" rel="noreferrer" target="_blank">https://github.com/sipeed/TinyMaix</a>><br>
> <a href="https://www.tensorflow.org/lite" rel="noreferrer" target="_blank">https://www.tensorflow.org/lite</a> <<a href="https://www.tensorflow.org/lite" rel="noreferrer" target="_blank">https://www.tensorflow.org/lite</a>><br>
> <br>
> They might work with the well supported RTEMS boards like the Beaglebone <br>
> black.<br>
> <br>
> Regards,<br>
> Alan<br>
> <br>
> Karel<br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a>><br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian MAUDERER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 18<br>
mobile: +49-176-152 206 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
</blockquote></div></div>