On Thu, Mar 29, 2018 at 11:24 PM, JunBeom Kim (EmbedCoreTech) < jb...@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.ha...@gmail.com> > *Sent:* Friday, March 30, 2018 2:55 PM > *To:* JunBeom Kim (EmbedCoreTech) <jb...@e-coretech.kr> > *Cc:* users <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> 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: jb...@e-coretech.kr > Web: www.e-coretech.kr > ~~~~~~~~~~~~~~~~~~~~~~ > > > _______________________________________________ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users > > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
