EmbedCoreTech - Contribution Direction for RTEMS using i.MX6Q

Fri Mar 30 14:47:42 UTC 2018

On Thu, Mar 29, 2018 at 11:24 PM, JunBeom Kim (EmbedCoreTech) <
jbkim at e-coretech.kr> wrote:

> 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.
>
I have just noted there is a 30 pin LVDS output on my carrier board and I
have an panel from an old Digi  IMX53 quickstart kit that I could try (not
sure the pin count on the panel yet).

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

I'm not sure what you mean by FreeBSD not having SATA support. The IMX6
AHCI driver was fixed last summer and I have access on my board to a 30 GB
SSD. However my image is well over a year old.

>
> 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.
>
Thank you, I hope to be at the point of testing some BSPs in the coming
months.

Sincerely,
Russ

>
>
> Best Regards,
>
> JunBeom
>
>
>
> *From:* Russell Haley <russ.haley at gmail.com>
> *Sent:* Friday, March 30, 2018 2:55 PM
> *To:* JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr>
> *Cc:* users <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> 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 <+82%2031-396-5584>
> Fax: +82-504-065-5720
> Mobile:+82-10-6425-5720 <+82%2010-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/20180330/80dde25c/attachment-0002.html>