BBB Framebuffer driver : Project status

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Thu May 16 18:31:18 UTC 2019


On Wed, May 15, 2019 at 11:36 PM Christian Mauderer <list at c-mauderer.de>
wrote:

> Hello Vijay,
>
> >
> > My forked repository for the rtems-libbsd can be found here
> > https://github.com/thelunatic/rtems-libbsd
> > All my work so far is in three branches in my forked repo.
> > The am335x_lcd branch contains the commits for importing and
> > porting the am335x_lcd drivers and the tda19988 branch has all
> > the lcd and tda driver commits.
>
> We already discussed that: The basic direction is fine.
>
> >
> > The hdmi framer communicates through the i2c bus and uses the
> > iicbus driver from the freebsd source. Since RTEMS already
> > supports the i2c very nicely in the target board, we have decided
> > to write an adaptation layer of i2c driver that will use the RTEMS
> > i2c driver throught the FreeBSD API.
>
> I still think that's a good way that can be useful for other
> applications too. But let's see whether someone has more comments
> regarding that.
>
> > All the imported codes along
> > with the porting commit, which includes the adaptation layer,
>
> Please split the adaption layer into an extra commit. I think that this
> can be made ready quite soon and it can be commited to master totally
> independent of the rest of the work.
>
> > can be
> > found in the iicbus branch in the above mentioned repository. The
> > adaptation layer is currently in a basic state and it compiles without
> > any warning, to make it work with the FreeBSD API. I also wrote
> > a device tree overlay and applied it throught u-boot to get the device
> > path with the OF_getprop* calls.
> > The overlay device tree source can be found in the following gist
> > https://gist.github.com/thelunatic/70fb08700c28044b779e7649839d9015
>
> Again: Split the adaption layer into it's own commit. Please add some
> test case that used the FreeBSD i2c API (maybe some simple i2c command
> or access to some i2c EEPROM). If you are very ambitious you could try
> to port the FreeBSD i2c command:
>
> https://www.freebsd.org/cgi/man.cgi?query=i2c&sektion=8&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports
>
> From a quick glance it seems a quite simple command with only one c file
> and without any global variables. So it shouldn't be too hard to port.
>
> I have made all separate commits and also have imported the i2c command and
ported it to RTEMS. I have checked that it builds without any warning.

https://github.com/thelunatic/rtems-libbsd/tree/i2c_adaptation

I think it would need some work to make it work with the
adaptation layer and the adaptation driver hasn't been tested either.

I had an offlist discussion about it, I'm putting a summary of what
came out to be the next possible set of actions :

- the next thing will be to find out where the FreeBSD /dev/iic0
(or whatever FreeBSD names them) is created and do something similar.

- Just and in Linux, we have udev. There must be some FreeBSD user
space application that create dev entries, that might be the way to go.

- At the location where normally the udev equivalent would be notified, it
will be necessary to create a dev entry.

- (Maybe) some file handlers will be necessary for that entry.

The closest we could find at a quick qrep is at
rtemsbsd/rtems/rtems-kernel-cam.c
there is a rtems_bsd_sim_attach_worker() that creates /dev/ entries.

If someone has any better reference or any hints or ideas that we can work
on,
it will be really helpful. :)

Thank you

>
> Best regards
>
> Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190517/fdeb9c76/attachment-0002.html>


More information about the devel mailing list