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) <jb...@e-coretech.kr> Sent: Friday, March 30, 2018 3:24 PM To: 'Russell Haley' <russ.ha...@gmail.com> Cc: 'users' <users@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.ha...@gmail.com <mailto:russ.ha...@gmail.com> > Sent: Friday, March 30, 2018 2:55 PM To: JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr <mailto:jb...@e-coretech.kr> > Cc: users <users@rtems.org <mailto:users@rtems.org> > Subject: Re: EmbedCoreTech - Contribution Direction for RTEMS using i.MX6Q On Wed, Mar 28, 2018 at 11:30 PM, JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr <mailto:jb...@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: jb...@e-coretech.kr <mailto:jb...@e-coretech.kr> Web: www.e-coretech.kr <http://www.e-coretech.kr> ~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ users mailing list users@rtems.org <mailto:users@rtems.org> http://lists.rtems.org/mailman/listinfo/users
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
