rtems-libbsd build error
Christian Mauderer
list at c-mauderer.de
Fri Apr 12 15:46:24 UTC 2019
Am 12.04.19 um 16:26 schrieb Vijay Kumar Banerjee:
>
>
> On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> Am 09.04.19 um 18:12 schrieb Vijay Kumar Banerjee:
> > Hi,
> >
> > I have imported and ported the the drivers in 2 pairs(import and port)
> > of commits
> > for each one. Please have a look at this branch
> > https://github.com/thelunatic/rtems-libbsd/commits/tda19988
>
> One detail: You have a commit named "tda19988.c: import from FreeBSD".
> Please remove the ".c".
>
> Noted.
>
> Maybe it would be a good idea to split of the I2C part and put it in
> front of the other two parts. You can develop and test that independent
> with a test that just accesses some of the I2C devices on the board via
> the FreeBSD API and the translation driver discussed below.
>
> This is a good idea, I'll import iicbus separately and add the other
> two on top of it.
>
> >
> > I have also tried running the media01.exe and have seen it running
> fine
> > without
> > throwing any exceptions.
> >
> > I have used the fb.c and iicbus.c codes from the freebsd source. From
> > what I
> > understand, I think the next big steps would be to write an RTEMS
> > implementation layer for these portions of the code? And then a
> test in the
> > libbsd, like media01, to write to the /dev/fb0
> >
> > Can you please help me chalk out a rough outline of the next set of
> > actions? :)
>
> As far as I can tell, there are two possible I2C buses here:
>
> 1. The one between the AM335x and the TDA19988.
>
> 2. The one directly on the HDMI connector (called HDMI_DSCL and
> HDMI_DSDA). I assume that's an I2C bus too.
>
> For 1. the RTEMS driver should be used. You'll need some code that
> translates the FreeBSD API to the one used in RTEMS. Basically that will
> just be a FreeBSD-I2C-driver.
>
> For 2: If that even is an independent I2C bus, you can use the driver
> provided by FreeBSD. I don't think that it is necessary to translate to
> the RTEMS API here.
>
> I had a look at the iic and iicbus codes in freebsd and the bbb-i2c.c
> This looks very confusing to me. Are we looking for something like a
> rtems-iicbus.c in the rtemsbsd that works like a wrapper to the bbb-i2c
> code, and uses the freebsd api of DEVMETHODs?
Yes correct. Basically it would be necessary to have a I2C device driver
for FreeBSD that translates to the RTEMS API.
>
> I've not been able to figure out at one look, how to relate them and
> get a wrapper like that. Any suggestions on how to approach this?
I haven't had a look at the FreeBSD drivers yet. The first part that I
would have a look at is the description of the user facing FreeBSD API:
https://www.freebsd.org/cgi/man.cgi?query=iic&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html
Nice thing: They use a struct iic_msg that is compatible with Linux's
struct i2c_msg (according to the man page). We are Linux compatible too.
Can be a big advantage.
Then take a look at the simplest i2c driver that you can find in FreeBSD
that uses the transfer API.
freebsd-org/sys/dev/drm2/radeon/atombios_i2c.c looks good to me.
Basically you have to implement the following functions (replace
radeon_atom... by a useful prefix):
static device_method_t radeon_atom_hw_i2c_methods[] = {
DEVMETHOD(device_probe, radeon_atom_hw_i2c_probe),
DEVMETHOD(device_attach, radeon_atom_hw_i2c_attach),
DEVMETHOD(device_detach, radeon_atom_hw_i2c_detach),
DEVMETHOD(iicbus_reset, radeon_atom_hw_i2c_reset),
DEVMETHOD(iicbus_transfer, radeon_atom_hw_i2c_xfer),
DEVMETHOD_END
};
The iicbus_transfer function seems to get a struct iic_msg as a
parameter. Now that's really lucky.
With that you should be able to open the i2c device in RTEMS and just
pass the structure via the correct ioctl call to the RTEMS driver.
Basically you just have to pass the bus to use as a parameter to the
driver. Take a look at some of the other drivers in nexus-devices.h that
have for example an address as a parameter to see how you can do that.
>
> Can we not totally use the iicbus in the freebsd source?
We already have a I2C driver for that BSP in RTEMS. If you would use the
FreeBSD code, they would fight for the hardware. Of course it would be
possible to replace the RTEMS driver by a FreeBSD one. But that would
potentially break some applications. Besides that I think that a lot of
RTEMS BSPs already have an I2C driver so a generic wrapper could be
helpful for other BSPs too.
>
> >
> > Thanks
> >
> > On Tue, Apr 9, 2019 at 5:28 AM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>
> > <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
> >
> > On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote:
> > > On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer
> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>> wrote:
> > > Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee:
> > > > On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer
> > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>> wrote:
> > > > Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> > > > > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer
> > > > <list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>
> > > > > <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
> <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>
> > > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>
> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>
> <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>>>>> wrote:
> > > > > Am 07.04.19 um 13:08 schrieb Vijay Kumar
> Banerjee:
> > >
> > > I don't think that there are a lot of docs for how to test.
> > Although I'm
> > > sure that there are some scripts to run a number of libbsd
> > tests, I'm
> > > not sure where. Maybe in the RTEMS tester but I think
> that is
> > mainly for
> > > the core tests?
> >
> > The documentation for testing can be found here ...
> >
> > https://docs.rtems.org/branches/master/user/testing/index.html
> >
> > > so far I know, RTEMS Tester is only for core tests.
> >
> > The `rtems-test` command checks the for test start and end
> banners.
> > I am not
> > sure if libbsd supports the test banners. Maybe it could now with
> > Sebastian's
> > movement of the test support code into libtest.
> >
> > > I'll ask in the devel if there's some way to run libbsd test
> with
> > the tester.
> >
> > There is the `rtems-run` command which has similar args to
> > `rtems-test`. It does
> > suffer from a limitation I have not fixed which is stdin is not
> > passed through
> > to the console of the target. I also think the command has a
> timeout
> > running,
> > but I am not sure about this one.
> >
> > Chris
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> Phone: +49-89-18 94 741 - 18
> Fax: +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
More information about the devel
mailing list