EmbedCoreTech - Contribution Direction for RTEMS using i.MX6Q

Fri Mar 30 06:30:24 UTC 2018

I received automatic notice mail regarding email size is big.

You can download this in below URL.

https://www.dropbox.com/s/p7wozdxl7o5hw1p/iMX6_Firmware_Guide.pdf?dl=0

Best Regards,

JunBeom Kim / EmbedCoreTech

From: JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr> 
Sent: Friday, March 30, 2018 3:24 PM
To: 'Russell Haley' <russ.haley at gmail.com>
Cc: 'users' <users at rtems.org>
Subject: RE: EmbedCoreTech - Contribution Direction for RTEMS using i.MX6Q

Dear Russell Haley,

Because FreeBSD is ported for i.MX6 Humming board, I will consider RTEMS for i.MX6 Humming Board, too 

But, first target board will be i.MX6 SDP board because there is LVDS panel.

Regarding display port, I ported framebuffer for both LVDS panel and HDMI with clone display mode using Platform SDK driver in project for my customer. I attached this(old document).

If I open RTEMS version for i.MX6 in the future, framebuffer will be used for both LVDS Hanstar panel 1024x768 and HDMI.

As I check from FreeBSD port for i.MX6, IPU/LDB driver is not supported.

Therefore, I will use Platform SDK’s IPU/LDB driver code until FreeBSD support IPU/LDB driver.

Regarding SATA port, I will consider Platform SDK’s SATA driver because there is not SATA for FreeBSD/i.MX6 port. On referencing, I didn’t test this SATA driver until now.

I just tested SD card and eMMC for FAT32 file system on customer design board.

Anyway, I think that my final goal with RTEMS users is to migrate driver code from FreeBSD to RTEMS because there is well-hidden bug in Platform SDK.

On referencing, If you want to receive old Platform SDK code for internal review, I can share this.

Best Regards,

JunBeom

From: Russell Haley <russ.haley at gmail.com <mailto:russ.haley at gmail.com> > 
Sent: Friday, March 30, 2018 2:55 PM
To: JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr <mailto:jbkim at e-coretech.kr> >
Cc: users <users at rtems.org <mailto:users at rtems.org> >
Subject: Re: EmbedCoreTech - Contribution Direction for RTEMS using i.MX6Q

On Wed, Mar 28, 2018 at 11:30 PM, JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr <mailto: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 <https://www.nxp.com/support/developer-resources/hardware-development-tools/sabre-development-system/sabre-platform-for-smart-devices-based-on-the-i.mx-6-series:RDIMX6SABREPLAT> 
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 <mailto:jbkim at e-coretech.kr> 
Web: www.e-coretech.kr <http://www.e-coretech.kr> 
~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
users mailing list
users at rtems.org <mailto: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/20180330/8804f4ad/attachment-0002.html>