EmbedCoreTech - Contribution Direction for RTEMS using i.MX6Q

Russell Haley russ.haley at gmail.com
Fri Mar 30 05:55:27 UTC 2018


On Wed, Mar 28, 2018 at 11:30 PM, JunBeom Kim (EmbedCoreTech) <
jbkim at e-coretech.kr> wrote:

> Dear Sir,
>
> I am JunBeom Kim of EmbedCoreTech in South Korea.
>
> My company was established in end of 2017 year after spin-off of Coressent
> Korea.
>
> Our company business is almost same from Coressent Korea.
> 1) Embedded S/W consulting
> 2) Commercial Software distributor
>
> I have worked with Korean medical company regarding RTEMS/Qt for
> i.MX6Q(single core only) since 2015 year.
> Because my project with Korean customer will be done soon, I can start to
> discuss with RTEMS user regarding RTEMS for i.MX6Q
>
> My internal project goal is below;
>
> 1. Board : NXP i.MX6Q SDP
>
> https://www.nxp.com/support/developer-resources/hardware-
> development-tools/s
> abre-development-system/sabre-platform-for-smart-devices-
> based-on-the-i.mx-6
> -series:RDIMX6SABREPLAT
>
> I will purchase this board soon.
>
Hi, I'm keen to see RTEMS ported to IMX6. I have the an older model of the
following board:

https://www.solid-run.com/nxp-family/hummingboard/

I have the "Pro" board and the Dual core (Full) SOM that has a SDIO WiFi
chip (!). Would processor and other setup be handled in one BSP that could
be extended for SolidRun?  The FreeBSD tree uses the GNU FDT files (I
forget where, it's a little hard to find). From what I understand the
Single and Dual "lite" share similarities and the Dual Core (full) and Quad
Core use the same configuration. I know this from building uboot in FreeBSD
but the finer details are beyond me.


> 2. S/W booting sequence change from boot by BootROM's first loader to
> second
> loader of u-boot.
>
> Current RTEMS version is booted from Boot ROM directly. RTEMS booting speed
> is faster than u-boot.
> I think that correct direction is to use RTEMS boot by second
> loader(u-boot)
>
> 3. Multi-core Support
>
> I am working this internally for supporting SMP for i.MX6Q. there is RTEMS
> booting stop problem.
> I would like to discuss with RTEMS users for booting stabilization for SMP
> feature.
>
> 4. Driver framework change from Platform SDK to FreeBSD libbsd.
>
> Because Platform SDK(Bear metal device driver framework) is not supported
> by
> NXP any more, there is risk for using this continuously. I think that best
> way is driver migration from Platform SDK to FreeBSD's i.MX6 BSP port.
> Because I already ported libbsd's network stack by Sebastian Huber's i.MX7D
> port contribution help, I can port network stack on i.MX6Q SDP board by
> myself.
> Especially, I would like to add USB host stack.
>
Please also consider sata support.

>
> 5. i.MX6Q OpenGL ES port.
>
> I already discussed with NXP Europe R&D by help of NXP Korea in 2015 year.
> I re-started with NXP Korea regarding i.MX6Q Vivante OpenGL ES software
> license.
> Even though there is software license fee(high cost) for OpenGL ES, I
> decided to purchase OpenGL ES software from NXP. I am gathering budget for
> this.
> Also, I should discuss with NXP regarding OpenGL ES driver library
> distribution permission.
> I didn't decide OpenGL ES RTEMS version's business model until now.
> First of all, I will make OpenGL ES software evaluation version. Evaluation
> version have full-feature for OpenGL ES 2.0, but, there is periodic company
> logo view whenever OpenGL ES application is run on target.
>

The state of HDMI on IMX6 for FreeBSD may be suspect. I've been building
for the platform off-and-on for a few years and the support is spotty. Some
builds work, some builds don't and nobody notices for long periods of time.
That's just my experience - which is now quite dated - so it could be very
incorrect.

Good Luck!
Russ

>
> 6. Qt 5.10 Integration on top of RTEMS with OpenGL ES.
>
> It is my final goal.
>
> RTEMS users can consider two application development(RTEMS application with
> OpenGL ES only, Qt application with RTEMS/OpenGL ES).
>
> On referencing, I already ported Qt 4.8.5 version without OpenGL ES.
> But, there was several issues(CPU high-load by non-accelerated graphics,
> limitation of using another Qt module as like QML, Qt Quick for 3D).
>
> Because I have modified Qt framework for RTEMS, I can not distribute to any
> customers my modified Qt framework.
> Also, customer should purchase Qt commercial license before receiving my
> modified Qt framework.
> And then, after customer complete to make product using RTEMS/Qt, customer
> should pay to Qt royalty.
>
> I can not handle about Qt license policy.
>
> If you have any questions, please feel free to contact me.
>
> Best Regards,
> JunBeom Kim
> ~~~~~~~~~~~~~~~~~~~~~~
> President / EmbedCoreTech
> Phone: +82-31-396-5584
> Fax: +82-504-065-5720
> Mobile:+82-10-6425-5720
> Email: jbkim at e-coretech.kr
> Web: www.e-coretech.kr
> ~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180329/7d7a8dbf/attachment.html>


More information about the users mailing list