On 25/06/2019 19:42, Gedare Bloom wrote: > On Tue, Jun 25, 2019 at 10:36 AM Vijay Kumar Banerjee > <vijaykumar9...@gmail.com> wrote: >> >> >> >> On Tue, Jun 25, 2019 at 9:32 PM Gedare Bloom <ged...@rtems.org> wrote: >>> >>> On Tue, Jun 25, 2019 at 5:34 AM Vijay Kumar Banerjee >>> <vijaykumar9...@gmail.com> wrote: >>>> >>>> Hello, >>>> >>>> The First Evaluation is going on and I here I would summarize all the >>>> progress >>>> that the project has made in the first Phase. >>>> >>>> 1. The major progress is the completion of the I2C adaptation layer in the >>>> libbsd >>>> along with the iicbus driver imports. The v4 of the driver [1] has >>>> been tested to be >>>> working with the bbb-i2c driver patch [2]. After the RTEMS driver is >>>> updated in the >>>> master, the adaptation layer will be mergeable. >>>> >>>> 2. I am getting EDID reading from the imported tda drivers. I have checked >>>> this using >>>> the ti_i2c driver but now as we have an updated version of the >>>> driver, I'll pull this all >>>> with the adaptation layer and will continue from there. >>>> >>>> 3. I found a sample app from the freebsd mailing list, that draws a basic >>>> shape on the >>>> screen. I have made it a standalone app with only single source and >>>> have tested it >>>> to be working with the FreeBSD. The only issue with the code is that >>>> it uses mmap >>>> and RTEMS doesn't use mmap so I'm rewriting the app with pread and >>>> pwrtie on >>>> to write to the /dev/fb0 directly. This app work is ongoing. >>>> >>> We have a rudimentary mmap() support available. I would expect this >>> might be important to investigate for graphics applications in general >>> might be trying to mmap() device memory. >>> >> At this moment, my objective is to just test that the fb device is working. >> For that, as I said, I'm trying to rewrite the mmap with pread instead. So >> far I couldn't get anything on screen with it though but if the writes work >> then I'm expecting to see something on the screen. >> As you have pointed out that most graphics applications will be using >> mmap(). Do you suggest trying to improve mmap() support as a part >> of this project? Is that expected to take a lot of time? >> > > I leave this decision up to you and your mentors whether (and why) to > re-prioritize any of your work. >
Vijay: If you are interested you can of course start to have a look at the mmap support right now. Just now that would be more a general improved mmap support (for any kind of file) which certainly would be a benefit for RTEMS too. But it would mean that you more or less stop with the frame buffer. I don't have a problem with it if you want to do that but I wouldn't suggest it. My suggestion would be to first continue with the frame buffer till the test application works. You already did quite a bit into that direction and it would be a pity if it couldn't be merged. If that is done you have reached a quite nice mile stone. So from there there would be two possible further directions: a) Either you can continue with the original plan to add a console (from RTEMS or from FreeBSD) and then - depending on time - some demo applications. b) Or after the framebuffer works you take a look how mmap support could look for _some_ special devices. That would make it simpler to port new graphics libraries to RTEMS (like QT - we could just use the bsdfb driver) which would be a really nice thing too. Maybe that would be even more useful then a simple console. Most embedded systems will use a serial port for the system console and will use a displays to show a GUI for a user. Like I said: You can decide which way you want and I'll support every decision. But the most useful one - and therefore the one I would suggest - would be the solution b). Oh and while writing that I noted: I'm not even sure whether libbsd device drivers fall back to the same rudimentary mmap that is used for file systems in RTEMS like I thought. Maybe you are even able to use the mmap support right now. Might could be a good idea to just try a mmap call in a simple test application (without any reading or writing to it) and try with a debugger whether you reach some driver function. Best regards Christian > >>>> Next Up: >>>> 1. merge the ported TDA driver and using it with the adaptation layer. >>>> 2. Import and port the fbd dirver to create an fb0 device. >>>> 3. complete the sample app and convert it into a libbsd sample app to test >>>> the device. >>>> >>>> Thanks, >>>> Vijay >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel