rtems-libbsd Build Error

[Joel Sherrill]

Hi

I am trying to build rtems-libbsd for xilinx_zynq_a9_qemu using
tools and RTEMS built from their master branches. Both the
master and 5-freebsd-12 branch fail to build with this error:

In file included from ../../rtemsbsd/rtems/rtems-kernel-thread.c:56:0:
/home/joel/rtems-class/tools/5/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/score/objectimpl.h:
In function '_Objects_Free':
/home/joel/rtems-class/tools/5/bsp-install/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/score/objectimpl.h:937:17:
error: 'Objects_Information {aka struct Objects_Information}' has no member
named '_bsd_free'
   ( *information->free )( information, the_object );

I think the solution is that the structure member free needs to be renamed.

61357479 (Sebastian Huber 2019-12-16 14:50:59 +0100 213)   void ( *free )(
Objects_Information *, Objects_Control * );

FWIW I was looking at the MISRA C/C++ rules earlier this week and this is a
violation of one of them. You should not have variables, methods, structure
members, etc that use the same name as standard library entiries.

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: I2C adaption layer driver for libbsd (was: Re: rtems-libbsd build error)

[Christian Mauderer]

Am 22.04.19 um 20:57 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Sun, Apr 21, 2019 at 12:08 AM Christian Mauderer  > wrote:
> 
> Am 18.04.19 um 21:11 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Thu, Apr 18, 2019 at 12:39 AM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     First: Please note that I changed the toppic. The old one just
> didn't
> >     represent the content any more.
> >
> >     Am 17.04.19 um 20:40 schrieb Vijay Kumar Banerjee:
> >     [...]
> >     >     >     >
> >     >     >     >     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 

Re: I2C adaption layer driver for libbsd (was: Re: rtems-libbsd build error)

[Vijay Kumar Banerjee]

On Sun, Apr 21, 2019 at 12:08 AM Christian Mauderer 
wrote:

> Am 18.04.19 um 21:11 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Thu, Apr 18, 2019 at 12:39 AM Christian Mauderer  > > wrote:
> >
> > First: Please note that I changed the toppic. The old one just didn't
> > represent the content any more.
> >
> > Am 17.04.19 um 20:40 schrieb Vijay Kumar Banerjee:
> > [...]
> > > > >
> > > > > 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 

Re: I2C adaption layer driver for libbsd (was: Re: rtems-libbsd build error)

[Vijay Kumar Banerjee]

On Thu, Apr 18, 2019 at 12:39 AM Christian Mauderer 
wrote:

> First: Please note that I changed the toppic. The old one just didn't
> represent the content any more.
>
> Am 17.04.19 um 20:40 schrieb Vijay Kumar Banerjee:
> [...]
> > > >
> > > > 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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=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[] = {
> > > 

Re: I2C adaption layer driver for libbsd (was: Re: rtems-libbsd build error)

[Christian Mauderer]

First: Please note that I changed the toppic. The old one just didn't
represent the content any more.

Am 17.04.19 um 20:40 schrieb Vijay Kumar Banerjee:
[...]
> >     >
> >     >     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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=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),
> 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Tue, Apr 16, 2019 at 4:24 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 16.04.19 um 11:28 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Fri, Apr 12, 2019 at 9:16 PM Christian Mauderer  > > wrote:
> >
> > Am 12.04.19 um 16:26 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > > On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer
> > >  > 
> > >  > >> 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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=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
> >   

Re: rtems-libbsd build error

[Christian Mauderer]

Am 16.04.19 um 11:28 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Fri, Apr 12, 2019 at 9:16 PM Christian Mauderer  > wrote:
> 
> Am 12.04.19 um 16:26 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer
> >  
> >  >> 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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=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 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Fri, Apr 12, 2019 at 9:16 PM Christian Mauderer 
wrote:

> Am 12.04.19 um 16:26 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer
> >  > > 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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=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.
>
> This gave a good idea of the objective. :)

I had a look at the  bbb-i2c.c code and how it's registering
and setting up the i2c_bus struct with the transfer, set and destroy
fucntions.
I have a question from the fundamentals, the only function
of bbb-i2c.c
 that
is 'accessible' with the header file is am335x_i2c_bus_register which
basically sets the i2c_bus struct
and calls the i2c_bus_register function 

Re: rtems-libbsd build error

[Christian Mauderer]

Am 12.04.19 um 16:26 schrieb Vijay Kumar Banerjee:
> 
> 
> On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer
>  > 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=0=0=FreeBSD+12.0-RELEASE+and+Ports=default=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  
> > >> wrote:
> >
> >     On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote:
> >     > On Sun, Apr 7, 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Wed, Apr 10, 2019 at 12:50 PM Christian Mauderer <
christian.maude...@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?

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?

Can we not totally use the iicbus in the freebsd source?

> >
> > Thanks
> >
> > On Tue, Apr 9, 2019 at 5:28 AM Chris Johns  > > wrote:
> >
> > On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote:
> > > On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer
> > mailto:l...@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
> > mailto:l...@c-mauderer.de>
> > > >
> > > > 
> >  > > > Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> > > > > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer
> > > > mailto:l...@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 

Re: rtems-libbsd build error

[Christian Mauderer]

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".

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.

> 
> 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.

> 
> Thanks
> 
> On Tue, Apr 9, 2019 at 5:28 AM Chris Johns  > wrote:
> 
> On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote:
> > On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer
> mailto:l...@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
> mailto:l...@c-mauderer.de>
> >     >
> >     > 
>  >     >     Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> >     >     > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer
> >     >     mailto:l...@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.maude...@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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[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

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? :)

Thanks

On Tue, Apr 9, 2019 at 5:28 AM Chris Johns  wrote:

> On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote:
> > On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer  > > wrote:
> > Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee:
> > > On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer <
> l...@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
> > > mailto:l...@c-mauderer.de>
> > >
> > > > 
> >  > > > 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Chris Johns]

On 8/4/19 12:30 am, Vijay Kumar Banerjee wrote:
> On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer  > wrote:
> Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee:
> > On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer  
> > >> wrote:
> >     Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> >     > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>  >     >     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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 07.04.19 um 16:30 schrieb Vijay Kumar Banerjee:
> 
> 
> On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer  > wrote:
> 
> Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer
> mailto:l...@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
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>  >     >
> >     >     Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> >     >     > Hi, 
> >     >     >
> >     >     > I had a look at the files related to HDMI drivers, to
> figure out
> >     >     separate 
> >     >     > compilable parts that can be imported together and
> ported to
> >     RTEMS.
> >     >     > I figured that the import can be done in two parts,
> one for
> >     am335x_lcd
> >     >     > and one for the tda19988 framer. I have also opened a new
> >     branch for
> >     >     > am335x_lcd and have done a clean import and some basic
> first
> >     part of
> >     >     > the porting.
> >     >     >
> >     >     > https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> >     >     >
> >     >     > I had a look at the CONTRIBUTING guide and have also
> >     generated the
> >     >     > rtems-bsd-kernel-namespace.h ( not yet pushed to the
> remote) 
> >     >     >
> >     >     > Does it look good to you? 
> >     >     > What is the next set of things to do to port it to RTEMS?
> >     >
> >     >     Hello Vijay,
> >     >
> >     >     does everything compile and link correctly? If yes: does the
> >     software
> >     >     run on the target and is the hardware detected during
> boot without
> >     >     throwing an exception somewhere?
> >     >
> >     > I have checked that everything compiles and links properly with
> >     the commits.
> >     > But Unfortunately, I don't have an lcd display module right
> now. I
> >     only
> >     > have a
> >     > standard monitor that works with hdmi cable ( checked it to be
> >     working with 
> >     > FreeBSD image). To work with the HDMI port, I think we'll
> need the
> >     > tda driver
> >     > imported as well. 
> >     > Is it alright if I create another set of commits to import the
> >     > tda driver as well, and
> >     > then try to run it in the target with HDMI?
> >     >  
> >
> >     You want to test more than I intended. My main concern was
> whether the
> >     BSP still runs without throwing an exception.
> >
> > Okay, I'll test this.
> > Is running the hello world application through gdbserver, enough
> to check 
> > that it works without exception? 
> > Is there a way to run multiple exes? If I'm asking something that
> can be
> > found
> > in the docs, a link would help. I couldn't find at first search. :)
> 
> 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?
> 
> so far I know, RTEMS Tester is only for core tests. I'll ask in the
> devel if there's
> some way to run libbsd test with the tester. 
> 
> My approach would be to run one of the tests that do something more like
> the media01 from libbsd  (you boot into a shell in that test) and take a
> look whether there are some boot messages regarding the driver. Most
> libbsd drivers tend to tell you that they found their device.
> 
> I have tried running media01.exe and it seems to run fine and I see this
> nice
> line during cpu starting 
> fb0:  mem 0x4830e000-0x4830efff irq 36 on simplebus0 
> 

Sounds good.

> >
> >     For testing the whole system together another set of patches
> importing
> >     the tda driver is OK.
> >
> >     >
> >     >     From a quick look at the patches I would move the generated
> >     files (in
> >     >     rtemsbsd directory) to the port commit so that the import
> >     commit really
> >     >     only contains unchanged imported files. But that is a matter
> >     of opinion.
> >     >
> >     > Understood. I'll move them to the port commit.  
> >     >
> >     >     Best regards
> >     >
> >     >     Christian
> >     >
> >
> 

-- 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Sun, Apr 7, 2019 at 6:24 PM Christian Mauderer 
wrote:

> Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer  > > wrote:
> >
> > Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > >
> > > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > > Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> > > > Hi,
> > > >
> > > > I had a look at the files related to HDMI drivers, to figure
> out
> > > separate
> > > > compilable parts that can be imported together and ported to
> > RTEMS.
> > > > I figured that the import can be done in two parts, one for
> > am335x_lcd
> > > > and one for the tda19988 framer. I have also opened a new
> > branch for
> > > > am335x_lcd and have done a clean import and some basic first
> > part of
> > > > the porting.
> > > >
> > > > https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> > > >
> > > > I had a look at the CONTRIBUTING guide and have also
> > generated the
> > > > rtems-bsd-kernel-namespace.h ( not yet pushed to the remote)
> > > >
> > > > Does it look good to you?
> > > > What is the next set of things to do to port it to RTEMS?
> > >
> > > Hello Vijay,
> > >
> > > does everything compile and link correctly? If yes: does the
> > software
> > > run on the target and is the hardware detected during boot
> without
> > > throwing an exception somewhere?
> > >
> > > I have checked that everything compiles and links properly with
> > the commits.
> > > But Unfortunately, I don't have an lcd display module right now. I
> > only
> > > have a
> > > standard monitor that works with hdmi cable ( checked it to be
> > working with
> > > FreeBSD image). To work with the HDMI port, I think we'll need the
> > > tda driver
> > > imported as well.
> > > Is it alright if I create another set of commits to import the
> > > tda driver as well, and
> > > then try to run it in the target with HDMI?
> > >
> >
> > You want to test more than I intended. My main concern was whether
> the
> > BSP still runs without throwing an exception.
> >
> > Okay, I'll test this.
> > Is running the hello world application through gdbserver, enough to
> check
> > that it works without exception?
> > Is there a way to run multiple exes? If I'm asking something that can be
> > found
> > in the docs, a link would help. I couldn't find at first search. :)
>
> 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?
>
> so far I know, RTEMS Tester is only for core tests. I'll ask in the devel
if there's
some way to run libbsd test with the tester.

> My approach would be to run one of the tests that do something more like
> the media01 from libbsd  (you boot into a shell in that test) and take a
> look whether there are some boot messages regarding the driver. Most
> libbsd drivers tend to tell you that they found their device.
>
> I have tried running media01.exe and it seems to run fine and I see this
nice
line during cpu starting
fb0:  mem 0x4830e000-0x4830efff irq 36 on simplebus0

> >
> > For testing the whole system together another set of patches
> importing
> > the tda driver is OK.
> >
> > >
> > > From a quick look at the patches I would move the generated
> > files (in
> > > rtemsbsd directory) to the port commit so that the import
> > commit really
> > > only contains unchanged imported files. But that is a matter
> > of opinion.
> > >
> > > Understood. I'll move them to the port commit.
> > >
> > > Best regards
> > >
> > > Christian
> > >
> >
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 07.04.19 um 14:50 schrieb Vijay Kumar Banerjee:
> 
> 
> On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer  > wrote:
> 
> Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> >     > Hi, 
> >     >
> >     > I had a look at the files related to HDMI drivers, to figure out
> >     separate 
> >     > compilable parts that can be imported together and ported to
> RTEMS.
> >     > I figured that the import can be done in two parts, one for
> am335x_lcd
> >     > and one for the tda19988 framer. I have also opened a new
> branch for
> >     > am335x_lcd and have done a clean import and some basic first
> part of
> >     > the porting.
> >     >
> >     > https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> >     >
> >     > I had a look at the CONTRIBUTING guide and have also
> generated the
> >     > rtems-bsd-kernel-namespace.h ( not yet pushed to the remote) 
> >     >
> >     > Does it look good to you? 
> >     > What is the next set of things to do to port it to RTEMS?
> >
> >     Hello Vijay,
> >
> >     does everything compile and link correctly? If yes: does the
> software
> >     run on the target and is the hardware detected during boot without
> >     throwing an exception somewhere?
> >
> > I have checked that everything compiles and links properly with
> the commits.
> > But Unfortunately, I don't have an lcd display module right now. I
> only
> > have a
> > standard monitor that works with hdmi cable ( checked it to be
> working with 
> > FreeBSD image). To work with the HDMI port, I think we'll need the
> > tda driver
> > imported as well. 
> > Is it alright if I create another set of commits to import the
> > tda driver as well, and
> > then try to run it in the target with HDMI?
> >  
> 
> You want to test more than I intended. My main concern was whether the
> BSP still runs without throwing an exception.
> 
> Okay, I'll test this.
> Is running the hello world application through gdbserver, enough to check 
> that it works without exception? 
> Is there a way to run multiple exes? If I'm asking something that can be
> found
> in the docs, a link would help. I couldn't find at first search. :)

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?

My approach would be to run one of the tests that do something more like
the media01 from libbsd  (you boot into a shell in that test) and take a
look whether there are some boot messages regarding the driver. Most
libbsd drivers tend to tell you that they found their device.

> 
> For testing the whole system together another set of patches importing
> the tda driver is OK.
> 
> >
> >     From a quick look at the patches I would move the generated
> files (in
> >     rtemsbsd directory) to the port commit so that the import
> commit really
> >     only contains unchanged imported files. But that is a matter
> of opinion.
> >
> > Understood. I'll move them to the port commit.  
> >
> >     Best regards
> >
> >     Christian
> >
> 

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Sun, Apr 7, 2019 at 6:08 PM Christian Mauderer 
wrote:

> Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer  > > wrote:
> >
> > Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> > > Hi,
> > >
> > > I had a look at the files related to HDMI drivers, to figure out
> > separate
> > > compilable parts that can be imported together and ported to RTEMS.
> > > I figured that the import can be done in two parts, one for
> am335x_lcd
> > > and one for the tda19988 framer. I have also opened a new branch
> for
> > > am335x_lcd and have done a clean import and some basic first part
> of
> > > the porting.
> > >
> > > https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> > >
> > > I had a look at the CONTRIBUTING guide and have also generated the
> > > rtems-bsd-kernel-namespace.h ( not yet pushed to the remote)
> > >
> > > Does it look good to you?
> > > What is the next set of things to do to port it to RTEMS?
> >
> > Hello Vijay,
> >
> > does everything compile and link correctly? If yes: does the software
> > run on the target and is the hardware detected during boot without
> > throwing an exception somewhere?
> >
> > I have checked that everything compiles and links properly with the
> commits.
> > But Unfortunately, I don't have an lcd display module right now. I only
> > have a
> > standard monitor that works with hdmi cable ( checked it to be working
> with
> > FreeBSD image). To work with the HDMI port, I think we'll need the
> > tda driver
> > imported as well.
> > Is it alright if I create another set of commits to import the
> > tda driver as well, and
> > then try to run it in the target with HDMI?
> >
>
> You want to test more than I intended. My main concern was whether the
> BSP still runs without throwing an exception.
>
> Okay, I'll test this.
Is running the hello world application through gdbserver, enough to check
that it works without exception?
Is there a way to run multiple exes? If I'm asking something that can be
found
in the docs, a link would help. I couldn't find at first search. :)

> For testing the whole system together another set of patches importing
> the tda driver is OK.
>
> >
> > From a quick look at the patches I would move the generated files (in
> > rtemsbsd directory) to the port commit so that the import commit
> really
> > only contains unchanged imported files. But that is a matter of
> opinion.
> >
> > Understood. I'll move them to the port commit.
> >
> > Best regards
> >
> > Christian
> >
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 07.04.19 um 14:35 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer  > wrote:
> 
> Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> > Hi, 
> >
> > I had a look at the files related to HDMI drivers, to figure out
> separate 
> > compilable parts that can be imported together and ported to RTEMS.
> > I figured that the import can be done in two parts, one for am335x_lcd
> > and one for the tda19988 framer. I have also opened a new branch for
> > am335x_lcd and have done a clean import and some basic first part of
> > the porting.
> >
> > https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> >
> > I had a look at the CONTRIBUTING guide and have also generated the
> > rtems-bsd-kernel-namespace.h ( not yet pushed to the remote) 
> >
> > Does it look good to you? 
> > What is the next set of things to do to port it to RTEMS?
> 
> Hello Vijay,
> 
> does everything compile and link correctly? If yes: does the software
> run on the target and is the hardware detected during boot without
> throwing an exception somewhere?
> 
> I have checked that everything compiles and links properly with the commits.
> But Unfortunately, I don't have an lcd display module right now. I only
> have a
> standard monitor that works with hdmi cable ( checked it to be working with 
> FreeBSD image). To work with the HDMI port, I think we'll need the
> tda driver
> imported as well. 
> Is it alright if I create another set of commits to import the
> tda driver as well, and
> then try to run it in the target with HDMI?
>  

You want to test more than I intended. My main concern was whether the
BSP still runs without throwing an exception.

For testing the whole system together another set of patches importing
the tda driver is OK.

> 
> From a quick look at the patches I would move the generated files (in
> rtemsbsd directory) to the port commit so that the import commit really
> only contains unchanged imported files. But that is a matter of opinion.
> 
> Understood. I'll move them to the port commit.  
> 
> Best regards
> 
> Christian
> 

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Sun, Apr 7, 2019 at 5:37 PM Christian Mauderer 
wrote:

> Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> > Hi,
> >
> > I had a look at the files related to HDMI drivers, to figure out
> separate
> > compilable parts that can be imported together and ported to RTEMS.
> > I figured that the import can be done in two parts, one for am335x_lcd
> > and one for the tda19988 framer. I have also opened a new branch for
> > am335x_lcd and have done a clean import and some basic first part of
> > the porting.
> >
> > https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> >
> > I had a look at the CONTRIBUTING guide and have also generated the
> > rtems-bsd-kernel-namespace.h ( not yet pushed to the remote)
> >
> > Does it look good to you?
> > What is the next set of things to do to port it to RTEMS?
>
> Hello Vijay,
>
> does everything compile and link correctly? If yes: does the software
> run on the target and is the hardware detected during boot without
> throwing an exception somewhere?
>
> I have checked that everything compiles and links properly with the
commits.
But Unfortunately, I don't have an lcd display module right now. I only
have a
standard monitor that works with hdmi cable ( checked it to be working with
FreeBSD image). To work with the HDMI port, I think we'll need the
tda driver
imported as well.
Is it alright if I create another set of commits to import the tda driver
as well, and
then try to run it in the target with HDMI?


> From a quick look at the patches I would move the generated files (in
> rtemsbsd directory) to the port commit so that the import commit really
> only contains unchanged imported files. But that is a matter of opinion.
>
> Understood. I'll move them to the port commit.

> Best regards
>
> Christian
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 07.04.19 um 13:08 schrieb Vijay Kumar Banerjee:
> Hi, 
> 
> I had a look at the files related to HDMI drivers, to figure out separate 
> compilable parts that can be imported together and ported to RTEMS.
> I figured that the import can be done in two parts, one for am335x_lcd
> and one for the tda19988 framer. I have also opened a new branch for
> am335x_lcd and have done a clean import and some basic first part of
> the porting.
> 
> https://github.com/thelunatic/rtems-libbsd/tree/am335x_lcd
> 
> I had a look at the CONTRIBUTING guide and have also generated the
> rtems-bsd-kernel-namespace.h ( not yet pushed to the remote) 
> 
> Does it look good to you? 
> What is the next set of things to do to port it to RTEMS?

Hello Vijay,

does everything compile and link correctly? If yes: does the software
run on the target and is the hardware detected during boot without
throwing an exception somewhere?

From a quick look at the patches I would move the generated files (in
rtemsbsd directory) to the port commit so that the import commit really
only contains unchanged imported files. But that is a matter of opinion.

Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

Hi,

I had a look at the files related to HDMI drivers, to figure out separate
compilable parts that can be imported together and ported to RTEMS.
I figured that the import can be done in two parts, one for am335x_lcd
and one for the tda19988 framer. I have also opened a new branch for
am335x_lcd and have done a clean import and some basic first part of
the porting.

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

I had a look at the CONTRIBUTING guide and have also generated the
rtems-bsd-kernel-namespace.h ( not yet pushed to the remote)

Does it look good to you?
What is the next set of things to do to port it to RTEMS?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

Doing a make for all, I'm getting this not found error ...

make: freebsd-org/contrib/libpcap/gen_version_header.sh: Command not found
make: *** [Makefile.todo:277: freebsd/contrib/libpcap/pcap_version.h] Error
127
.

But it successefully builds the .m files into .c and .h files (I haven't
edited the Makefile yet).
after the make, if I try to ./waf it, it gives this error ...
==
In file included from ../../rtemsbsd/include/machine/bus.h:781:0,
 from ../../rtemsbsd/include/machine/_bus.h:1,
 from ../../freebsd/sys/sys/bus.h:35,
 from ../../rtemsbsd/local/usb_if.c:17:
../../rtemsbsd/include/machine/bus_dma.h:44:2: error: #error "the header
file  must be included first"
 #error "the header file  must be
included first"
  ^
../../rtemsbsd/local/usb_if.c:18:10: fatal error: usb_if.h: No such file or
directory
 #include "usb_if.h"
  ^~
compilation terminated.

==
it seems like it's not changing it to #include .
Is it supposed
to be done manually by opening each file or am I missing a script?

On Mon, Apr 1, 2019 at 7:32 PM Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:
>
> [...] (I removed some of the discussion to make it more readable)
>
> >
> > If you use the fb and framebuffer headers from RTEMS, you will get an
> > RTEMS interface. The RTEMS based console code will work fine. But it
> > might would be the solution where more work is necessary to port
> other
> > applications or libraries. It seems that we have some libs already
> (like
> > nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would
> be OK
> > with that.
> >
> > The other alternative would be to use the FreeBSD code that does the
> > same. I'm not sure whether they call it framebuffer or something
> else.
> > But I would expect that there is something similar. In that case it
> > might would be simpler to port graphics libraries that already work
> on
> > FreeBSD.
> >
> > Both ways could be nice. I'm really not sure which one I would
> prefer.
> > The first one is better integrated into the existing RTEMS ecosystem.
> > The second one promises a wider world. So either take the one that
> > interests you more or just use the one that looks simpler ;-)
> >
> > I will take the 2nd path and use the codes from freebsd fb. In the
> > forked branch
> > I have imported them along with the iic souce files just to make sure
> > that it builds.
> > I have also added the driver references in the nexus-device.h
> > I have a few questions/doubts before moving on to creating a fresh
> > branch to import
> > the file cleanly so that porting work can be started.
> >
> > There are a lot of files that are imported and out of them some were .m
> > files that
> > I built manually with the awk scripts and imported using the libbsd.py .
> > It seems like those
> > will need a cleanup and will need to be added to the Makefile.todo (?)
>
> Most likely Makefile.todo is currently the right place. Also in long
> term it should move to waf. But that's out of the scope of your project.
>
> >
> > Will the whole thing be one big patch? or will it be done in chunks of
> > the subdirectory
> > like videomode headers and souce imported in one patch, fb in another ?
>
> I think I already have made a note at your proposal: I would suggest to
> split it up in smaller functional blocks. That even allows to merge
> small parts during the GSoC instead of having one big block at the end.
> But please note that all parts should be useful and every commit in
> libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
> `git bisect` won't work.
>
> So if you have functional groups: Split it up. If a big block is
> necessary because the small parts can't work on their own: Keep it in
> one import + one port commit.
>
> >
> [...]
>
>
>
> --
> 
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@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.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:

[...] (I removed some of the discussion to make it more readable)

> 
> If you use the fb and framebuffer headers from RTEMS, you will get an
> RTEMS interface. The RTEMS based console code will work fine. But it
> might would be the solution where more work is necessary to port other
> applications or libraries. It seems that we have some libs already (like
> nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would be OK
> with that.
> 
> The other alternative would be to use the FreeBSD code that does the
> same. I'm not sure whether they call it framebuffer or something else.
> But I would expect that there is something similar. In that case it
> might would be simpler to port graphics libraries that already work on
> FreeBSD.
> 
> Both ways could be nice. I'm really not sure which one I would prefer.
> The first one is better integrated into the existing RTEMS ecosystem.
> The second one promises a wider world. So either take the one that
> interests you more or just use the one that looks simpler ;-)
> 
> I will take the 2nd path and use the codes from freebsd fb. In the
> forked branch 
> I have imported them along with the iic souce files just to make sure
> that it builds.
> I have also added the driver references in the nexus-device.h 
> I have a few questions/doubts before moving on to creating a fresh
> branch to import
> the file cleanly so that porting work can be started.
> 
> There are a lot of files that are imported and out of them some were .m
> files that 
> I built manually with the awk scripts and imported using the libbsd.py .
> It seems like those 
> will need a cleanup and will need to be added to the Makefile.todo (?) 

Most likely Makefile.todo is currently the right place. Also in long
term it should move to waf. But that's out of the scope of your project.

> 
> Will the whole thing be one big patch? or will it be done in chunks of
> the subdirectory
> like videomode headers and souce imported in one patch, fb in another ?

I think I already have made a note at your proposal: I would suggest to
split it up in smaller functional blocks. That even allows to merge
small parts during the GSoC instead of having one big block at the end.
But please note that all parts should be useful and every commit in
libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
`git bisect` won't work.

So if you have functional groups: Split it up. If a big block is
necessary because the small parts can't work on their own: Keep it in
one import + one port commit.

> 
[...]



-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@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.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Thu, Mar 21, 2019 at 10:21 PM Christian Mauderer 
wrote:

> Am 21.03.19 um 15:36 schrieb Vijay Kumar Banerjee:
> >
> > On Wed, 20 Mar 2019 at 01:52, Christian Mauderer  > > wrote:
> >
> > Am 19.03.19 um 20:37 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > >
> > > On Tue, 19 Mar 2019 at 02:44, Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > > Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> > > >
> > > >
> > > >
> > > > On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> > > > mailto:vijaykumar9...@gmail.com>
> > >
> > >  >   >  > > wrote:
> > > >
> > > >
> > > > Hi Christian,
> > > >
> > > > (it got sent by mistake :) )
> > > >
> > > > Thanks for telling about the script, now I have the code
> > imported and
> > > > it's building successfully.
> > > > I have forked the repo and created a branch with my commits.
> > > Please have
> > > > a look and see if
> > > > It's going in the right direction.
> > > > https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer
> > > >
> > > > I have also wrote a first draft of the proposal. Are we
> supposed
> > > to send
> > > > the draft proposals only after the the application period
> stars?
> > > or can
> > > > we just share it offlist with the mentors now?
> > > >
> > > > Thanks
> > >
> > > Hello Vijay,
> > >
> > > first regarding the proposal:
> > >
> > > @Joel: Please correct me if I'm wrong!
> > >
> > > I think it should be OK to discuss the proposal as soon as you
> > have
> > > something. I assume you already have completed the Hello world
> > and sent
> > > it to at least one of our Org Admins?
> > >
> > > I have sent pictures in the offlist thread with Joel and you,
> where we
> > > were dicussing the
> > > hardwares. I can send again in an offlist thread, along with the
> > > proposal. :)
> > >
> >
> > If Joel has them, it's OK.
> >
> > >
> > > Regarding the code:
> > >
> > > Although the commits need some polishing (see * at the end) it
> > looks
> > > like a good start that you were already able to import and
> > compile some
> > > of the necessary files.
> > >
> > > From what I've seen, you currently pulled in three parts:
> > >
> > > 1. Some part of videomode. There are some awk scripts in that
> > directory
> > > too so some generated files might need some processing.
> > >
> > > the ediddevs and modelines.c needed the scripts. I added them and
> > > imported, but
> > > there's a strange error with modelines.c
> > > (If I comment it out, it builds fine)
> > > ===
> > > ../../freebsd/sys/dev/videomode/modelines.c:13:19: error: expected
> > > declaration specifiers or '...' before string constant
> > >  __KERNEL_RCSID(0, "$NetBSD$");
> > >  ===
> > >
> >
> > Most likely it's necessary to import them sooner or later. It will be
> > necessary to take a look at the original make process in FreeBSD and
> > duplicate the steps. For other awk scripts that's done in the
> > Makefile.todo.
> >
> > >
> > > 2. The iic headers. That looks good. An RTEMS implementation
> > for the
> > > functions most likely is necessary.
> > >
> > > I have added this in the proposal.
> >
> > Great.
> >
> > >
> > > 3. The driver for the chip that converts from the LCD
> > interface to an
> > > HDMI interface. That's good and necessary too.
> > >
> > > What is missing (which is entirely OK at the current phase)
> > are the
> > > following parts:
> > >
> > > A. The LCD controller driver itself (am335x_lcd.c, ...).
> > >
> > > Added. Along with it, I had to import other fb codes that it
> > depends on.
> > > I can push it in my
> > > forked branch for you to see.
> > > Since it has already seen some trial and errors. I think it would
> be
> > > better to create a new
> > > branch after we're happy with what's imported, then we can squash
> > it all
> > > into a commit
> > > and then start the porting work to get two clean commits.
> >
> > If you haven't forgotten the files everything is OK. It's totally OK
> to
> > do some trial and error to find out what's necessary. You can do a
> clean
> > 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Wed, 20 Mar 2019 at 01:52, Christian Mauderer  wrote:

> Am 19.03.19 um 20:37 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Tue, 19 Mar 2019 at 02:44, Christian Mauderer  > > wrote:
> >
> > Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > >
> > > On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> > > mailto:vijaykumar9...@gmail.com>
> > >>
> > wrote:
> > >
> > >
> > > Hi Christian,
> > >
> > > (it got sent by mistake :) )
> > >
> > > Thanks for telling about the script, now I have the code imported
> and
> > > it's building successfully.
> > > I have forked the repo and created a branch with my commits.
> > Please have
> > > a look and see if
> > > It's going in the right direction.
> > > https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer
> > >
> > > I have also wrote a first draft of the proposal. Are we supposed
> > to send
> > > the draft proposals only after the the application period stars?
> > or can
> > > we just share it offlist with the mentors now?
> > >
> > > Thanks
> >
> > Hello Vijay,
> >
> > first regarding the proposal:
> >
> > @Joel: Please correct me if I'm wrong!
> >
> > I think it should be OK to discuss the proposal as soon as you have
> > something. I assume you already have completed the Hello world and
> sent
> > it to at least one of our Org Admins?
> >
> > I have sent pictures in the offlist thread with Joel and you, where we
> > were dicussing the
> > hardwares. I can send again in an offlist thread, along with the
> > proposal. :)
> >
>
> If Joel has them, it's OK.
>
> >
> > Regarding the code:
> >
> > Although the commits need some polishing (see * at the end) it looks
> > like a good start that you were already able to import and compile
> some
> > of the necessary files.
> >
> > From what I've seen, you currently pulled in three parts:
> >
> > 1. Some part of videomode. There are some awk scripts in that
> directory
> > too so some generated files might need some processing.
> >
> > the ediddevs and modelines.c needed the scripts. I added them and
> > imported, but
> > there's a strange error with modelines.c
> > (If I comment it out, it builds fine)
> > ===
> > ../../freebsd/sys/dev/videomode/modelines.c:13:19: error: expected
> > declaration specifiers or '...' before string constant
> >  __KERNEL_RCSID(0, "$NetBSD$");
> >  ===
> >
>
> Most likely it's necessary to import them sooner or later. It will be
> necessary to take a look at the original make process in FreeBSD and
> duplicate the steps. For other awk scripts that's done in the
> Makefile.todo.
>
> >
> > 2. The iic headers. That looks good. An RTEMS implementation for the
> > functions most likely is necessary.
> >
> > I have added this in the proposal.
>
> Great.
>
> >
> > 3. The driver for the chip that converts from the LCD interface to an
> > HDMI interface. That's good and necessary too.
> >
> > What is missing (which is entirely OK at the current phase) are the
> > following parts:
> >
> > A. The LCD controller driver itself (am335x_lcd.c, ...).
> >
> > Added. Along with it, I had to import other fb codes that it depends on.
> > I can push it in my
> > forked branch for you to see.
> > Since it has already seen some trial and errors. I think it would be
> > better to create a new
> > branch after we're happy with what's imported, then we can squash it all
> > into a commit
> > and then start the porting work to get two clean commits.
>
> If you haven't forgotten the files everything is OK. It's totally OK to
> do some trial and error to find out what's necessary. You can do a clean
> version during the work phases.
>
> >
> > B. The driver isn't referenced anywhere (normally would be done in
> > nexus-devices.h for devices that should be always there). So it isn't
> > linked into the applications yet. That's the reason that you
> currently
> > didn't get any `function not found` errors during the linking yet ;-)
> >
> >  Is there any reference that I can follow to understand how the
> > nexusmodule is working,
> > and how to add the driver to it? I had a look into the libbsd.txt
>
> I don't think that there is a real reference. libbsd is quite heavily
> lacking documentation. The nexus-devices.h is more or less the file that
> defines which drivers are linked to which BSP in the default
> configuration for each application. If you have a look at the file you
> will see (especially for BBB) a lot of lines like
>
> SYSINIT_DRIVER_REFERENCE(usbss, simplebus);
>
> or
>
> SYSINIT_MODULE_REFERENCE(wlan_ccmp);
>
> If you have a look at the corresponding sources of the drivers or
> modules, you will see matching lines like
>
> DRIVER_MODULE(usbss, simplebus, 

Re: rtems-libbsd build error

[Christian Mauderer]

Am 19.03.19 um 20:37 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Tue, 19 Mar 2019 at 02:44, Christian Mauderer  > wrote:
> 
> Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>
> >>
> wrote:
> >
> >
> >     Hi Christian,
> >
> > (it got sent by mistake :) )
> >
> > Thanks for telling about the script, now I have the code imported and
> > it's building successfully.
> > I have forked the repo and created a branch with my commits.
> Please have
> > a look and see if 
> > It's going in the right direction. 
> > https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer 
> >
> > I have also wrote a first draft of the proposal. Are we supposed
> to send
> > the draft proposals only after the the application period stars?
> or can
> > we just share it offlist with the mentors now?
> >
> > Thanks 
> 
> Hello Vijay,
> 
> first regarding the proposal:
> 
> @Joel: Please correct me if I'm wrong!
> 
> I think it should be OK to discuss the proposal as soon as you have
> something. I assume you already have completed the Hello world and sent
> it to at least one of our Org Admins?
> 
> I have sent pictures in the offlist thread with Joel and you, where we
> were dicussing the
> hardwares. I can send again in an offlist thread, along with the
> proposal. :) 
> 

If Joel has them, it's OK.

> 
> Regarding the code:
> 
> Although the commits need some polishing (see * at the end) it looks
> like a good start that you were already able to import and compile some
> of the necessary files.
> 
> From what I've seen, you currently pulled in three parts:
> 
> 1. Some part of videomode. There are some awk scripts in that directory
> too so some generated files might need some processing.
> 
> the ediddevs and modelines.c needed the scripts. I added them and
> imported, but 
> there's a strange error with modelines.c 
> (If I comment it out, it builds fine)
> ===
> ../../freebsd/sys/dev/videomode/modelines.c:13:19: error: expected
> declaration specifiers or '...' before string constant
>  __KERNEL_RCSID(0, "$NetBSD$");
>  ===
>  

Most likely it's necessary to import them sooner or later. It will be
necessary to take a look at the original make process in FreeBSD and
duplicate the steps. For other awk scripts that's done in the Makefile.todo.

> 
> 2. The iic headers. That looks good. An RTEMS implementation for the
> functions most likely is necessary.
> 
> I have added this in the proposal. 

Great.

> 
> 3. The driver for the chip that converts from the LCD interface to an
> HDMI interface. That's good and necessary too.
> 
> What is missing (which is entirely OK at the current phase) are the
> following parts:
> 
> A. The LCD controller driver itself (am335x_lcd.c, ...).
> 
> Added. Along with it, I had to import other fb codes that it depends on.
> I can push it in my
> forked branch for you to see. 
> Since it has already seen some trial and errors. I think it would be
> better to create a new 
> branch after we're happy with what's imported, then we can squash it all
> into a commit 
> and then start the porting work to get two clean commits.  

If you haven't forgotten the files everything is OK. It's totally OK to
do some trial and error to find out what's necessary. You can do a clean
version during the work phases.

> 
> B. The driver isn't referenced anywhere (normally would be done in
> nexus-devices.h for devices that should be always there). So it isn't
> linked into the applications yet. That's the reason that you currently
> didn't get any `function not found` errors during the linking yet ;-)
> 
>  Is there any reference that I can follow to understand how the
> nexusmodule is working,
> and how to add the driver to it? I had a look into the libbsd.txt

I don't think that there is a real reference. libbsd is quite heavily
lacking documentation. The nexus-devices.h is more or less the file that
defines which drivers are linked to which BSP in the default
configuration for each application. If you have a look at the file you
will see (especially for BBB) a lot of lines like

SYSINIT_DRIVER_REFERENCE(usbss, simplebus);

or

SYSINIT_MODULE_REFERENCE(wlan_ccmp);

If you have a look at the corresponding sources of the drivers or
modules, you will see matching lines like

DRIVER_MODULE(usbss, simplebus, usbss_driver, usbss_devclass, 0, 0);

and

DECLARE_MODULE(...);
/* hidden behind IEEE80211_CRYPTO_MODULE(ccmp, 1)) */

Basically for your drivers you just have to add the
SYSINIT_DRIVER_REFERENCE lines. After that the drivers should be linked
in and the probe and attach is called during 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Tue, 19 Mar 2019 at 02:44, Christian Mauderer  wrote:

> Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> >
> >
> >
> > On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> > mailto:vijaykumar9...@gmail.com>> wrote:
> >
> >
> > Hi Christian,
> >
> > (it got sent by mistake :) )
> >
> > Thanks for telling about the script, now I have the code imported and
> > it's building successfully.
> > I have forked the repo and created a branch with my commits. Please have
> > a look and see if
> > It's going in the right direction.
> > https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer
> >
> > I have also wrote a first draft of the proposal. Are we supposed to send
> > the draft proposals only after the the application period stars? or can
> > we just share it offlist with the mentors now?
> >
> > Thanks
>
> Hello Vijay,
>
> first regarding the proposal:
>
> @Joel: Please correct me if I'm wrong!
>
> I think it should be OK to discuss the proposal as soon as you have
> something. I assume you already have completed the Hello world and sent
> it to at least one of our Org Admins?
>
> I have sent pictures in the offlist thread with Joel and you, where we
were dicussing the
hardwares. I can send again in an offlist thread, along with the proposal.
:)

>
> Regarding the code:
>
> Although the commits need some polishing (see * at the end) it looks
> like a good start that you were already able to import and compile some
> of the necessary files.
>
> From what I've seen, you currently pulled in three parts:
>
> 1. Some part of videomode. There are some awk scripts in that directory
> too so some generated files might need some processing.
>
> the ediddevs and modelines.c needed the scripts. I added them and
imported, but
there's a strange error with modelines.c
(If I comment it out, it builds fine)
===
../../freebsd/sys/dev/videomode/modelines.c:13:19: error: expected
declaration specifiers or '...' before string constant
 __KERNEL_RCSID(0, "$NetBSD$");
 ===


> 2. The iic headers. That looks good. An RTEMS implementation for the
> functions most likely is necessary.
>
> I have added this in the proposal.

> 3. The driver for the chip that converts from the LCD interface to an
> HDMI interface. That's good and necessary too.
>
> What is missing (which is entirely OK at the current phase) are the
> following parts:
>
> A. The LCD controller driver itself (am335x_lcd.c, ...).
>
> Added. Along with it, I had to import other fb codes that it depends on. I
can push it in my
forked branch for you to see.
Since it has already seen some trial and errors. I think it would be better
to create a new
branch after we're happy with what's imported, then we can squash it all
into a commit
and then start the porting work to get two clean commits.

> B. The driver isn't referenced anywhere (normally would be done in
> nexus-devices.h for devices that should be always there). So it isn't
> linked into the applications yet. That's the reason that you currently
> didn't get any `function not found` errors during the linking yet ;-)
>
>  Is there any reference that I can follow to understand how the
nexusmodule is working,
and how to add the driver to it? I had a look into the libbsd.txt

> C. The framebuffer interface of FreeBSD. I haven't had a detailed look
> at that yet. But someone has to do something with the fb_getinfo
> DEVMETHOD that is defined in am335x_lcd.c. I'm also not sure whether we
> have some generic framebuffer code in RTEMS or whether we should use it
> completely from libbsd.
>
> We have the fb.h and framebuffer.h headers. The RPi seems to have
implemented those
functions using own implementation using the mailbox module.

> So most likely you will find some more problems when the real work
> starts. But it would be no fun if everything would run smoothly ;-)
>
> Best regards
>
> Christian
>
>
> (*) See hints in CONTRIBUTING.md in chapter "How to Import Code from
> FreeBSD". The final commits should be (for each sensible module) one
> import commit where unchanged files are imported and one port commit
> where the files are added to libbsd.py and necessary changes are made.
>
>
> >
> >
> > On Sun, 17 Mar 2019 at 14:30, Christian Mauderer  > > wrote:
> >
> > Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >>
> wrote:
> > >
> > > Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> > > >
> > > >
> > > > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
> > > mailto:l...@c-mauderer.de>
> > >
> > > > 
> > 

Re: rtems-libbsd build error

[Christian Mauderer]

Am 18.03.19 um 20:31 schrieb Vijay Kumar Banerjee:
> 
> 
> 
> On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee
> mailto:vijaykumar9...@gmail.com>> wrote:
> 
> 
> Hi Christian,
> 
> (it got sent by mistake :) )
> 
> Thanks for telling about the script, now I have the code imported and
> it's building successfully.
> I have forked the repo and created a branch with my commits. Please have
> a look and see if 
> It's going in the right direction. 
> https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer 
> 
> I have also wrote a first draft of the proposal. Are we supposed to send
> the draft proposals only after the the application period stars? or can
> we just share it offlist with the mentors now?
> 
> Thanks  

Hello Vijay,

first regarding the proposal:

@Joel: Please correct me if I'm wrong!

I think it should be OK to discuss the proposal as soon as you have
something. I assume you already have completed the Hello world and sent
it to at least one of our Org Admins?


Regarding the code:

Although the commits need some polishing (see * at the end) it looks
like a good start that you were already able to import and compile some
of the necessary files.

From what I've seen, you currently pulled in three parts:

1. Some part of videomode. There are some awk scripts in that directory
too so some generated files might need some processing.

2. The iic headers. That looks good. An RTEMS implementation for the
functions most likely is necessary.

3. The driver for the chip that converts from the LCD interface to an
HDMI interface. That's good and necessary too.

What is missing (which is entirely OK at the current phase) are the
following parts:

A. The LCD controller driver itself (am335x_lcd.c, ...).

B. The driver isn't referenced anywhere (normally would be done in
nexus-devices.h for devices that should be always there). So it isn't
linked into the applications yet. That's the reason that you currently
didn't get any `function not found` errors during the linking yet ;-)

C. The framebuffer interface of FreeBSD. I haven't had a detailed look
at that yet. But someone has to do something with the fb_getinfo
DEVMETHOD that is defined in am335x_lcd.c. I'm also not sure whether we
have some generic framebuffer code in RTEMS or whether we should use it
completely from libbsd.

So most likely you will find some more problems when the real work
starts. But it would be no fun if everything would run smoothly ;-)

Best regards

Christian


(*) See hints in CONTRIBUTING.md in chapter "How to Import Code from
FreeBSD". The final commits should be (for each sensible module) one
import commit where unchanged files are imported and one port commit
where the files are added to libbsd.py and necessary changes are made.


> 
> 
> On Sun, 17 Mar 2019 at 14:30, Christian Mauderer  > wrote:
> 
> Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> >     >
> >     >
> >     > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
> >     mailto:l...@c-mauderer.de>
> >
> >     > 
>  >     >
> >     >     Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> >     >     > Hello, 
> >     >     >
> >     >     > I am trying to `./waf install` the libbsd but
> getting some
> >     error,
> >     >     need help
> >     >     > with that. The commands used and the errors are
> given below ...
> >     >     >
> >     >     > configured using: `./waf configure
> >     --buildset=buildset/default.ini
> >     >     > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >     >     >
> >     >     > configure was successful.
> >     >     >
> >     >     > then : `./waf install`
> >     >     >
> >     >     > Error ...
> >     >     > 
> >     >     > Build failed
> >     >     >  -> task in 'lex__nsyy' failed with exit status 1
> (run with
> >     -v to
> >     >     > display more information)
> >     >     >  -> task in 'yacc__nsyy' failed with exit status 1
> (run with
> >     -v to
> >     >     > display more information)
> >     >     >  -> task in 'lex_pcap' failed with exit status 1
> (run with -v to
> >     >     display
> >     >     > more information)
> >     >     >  -> task in 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Tue, 19 Mar 2019 at 00:56, Vijay Kumar Banerjee 
wrote:

>
> Hi Christian,
>
> (it got sent by mistake :) )

Thanks for telling about the script, now I have the code imported and it's
building successfully.
I have forked the repo and created a branch with my commits. Please have a
look and see if
It's going in the right direction.
https://github.com/thelunatic/rtems-libbsd/tree/hdmi_framer

I have also wrote a first draft of the proposal. Are we supposed to send
the draft proposals only after the the application period stars? or can we
just share it offlist with the mentors now?

Thanks

>
> On Sun, 17 Mar 2019 at 14:30, Christian Mauderer 
> wrote:
>
>> Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
>> >
>> >
>> > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer > > > wrote:
>> >
>> > Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
>> > >
>> > >
>> > > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
>> > mailto:l...@c-mauderer.de>
>> > > >> wrote:
>> > >
>> > > Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
>> > > > Hello,
>> > > >
>> > > > I am trying to `./waf install` the libbsd but getting some
>> > error,
>> > > need help
>> > > > with that. The commands used and the errors are given below
>> ...
>> > > >
>> > > > configured using: `./waf configure
>> > --buildset=buildset/default.ini
>> > > > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
>> > > >
>> > > > configure was successful.
>> > > >
>> > > > then : `./waf install`
>> > > >
>> > > > Error ...
>> > > > 
>> > > > Build failed
>> > > >  -> task in 'lex__nsyy' failed with exit status 1 (run with
>> > -v to
>> > > > display more information)
>> > > >  -> task in 'yacc__nsyy' failed with exit status 1 (run with
>> > -v to
>> > > > display more information)
>> > > >  -> task in 'lex_pcap' failed with exit status 1 (run with
>> -v to
>> > > display
>> > > > more information)
>> > > >  -> task in 'yacc_pcap' failed with exit status 1 (run with
>> > -v to
>> > > > display more information)
>> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
>> > to display
>> > > > more information)
>> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
>> > to display
>> > > > more information)
>> > > >  -> task in 'yacc_pfctly' failed with exit status 1 (run
>> > with -v to
>> > > > display more information)
>> > > >
>> > > > 
>> > > >
>> > > > Thanks
>> > > > --vijay
>> > > >
>> > >
>> > > Hello Vijay,
>> > >
>> > > did you try to build before the install? I don't see the call.
>> > > Normally it's
>> > >
>> > >   waf configure ...
>> > >   waf
>> > >   waf install
>> > >
>> > > If you did that: It seems that some of the lex / yacc files
>> > should be
>> > > regenerated. Did you enable --enable-auto-regen somewhen
>> during an
>> > > earlier configuration run (not necessary except if you import
>> > yacc or
>> > > lex files)? Did you import some yacc or lex files?
>> > >
>> > > I had to install `byacc` package using yum in fedora, then I used
>> the
>> > > --enable-auto-regen
>> > > option, that worked.
>> > > However, it's still not building and I'm seeing a lot of
>> warnings, I
>> > > think this is because of the
>> > > files I imported from the freebsd source, maybe they depend on
>> some
>> > > other headers that
>> > > I didn't include. Any suggestion on how to debug, if this is the
>> > case?
>> > >
>> > > Best regards
>> > >
>> > > Christian
>> > >
>> >
>> >
>> > Hello Vijay,
>> >
>> > normally you shouldn't need the --enable-auto-regen option. It only
>> > changes a lot of files that you don't want to change. Especially:
>> If you
>> > use Fedora (or some other Linux) you get GPL licensed output. We
>> > normally use FreeBSD for that step and check in the generated files
>> so
>> > that no user has to use --enable-auto-regen.
>> >
>> > Regarding how to start such a port: Normally it's a good idea to get
>> > some overview over what's missing. For that you import the files
>> that
>> > you think are relevant (like you already did). Then you can build
>> with
>> > `waf -k -j1` which continues even if some files are not compilable
>> (-k
>> > is for continue, -j1 so that you receive the messages in order). You
>> > should get a lot of compiler errors during that run.
>> >
>> > Now comes the hard part: You have to 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

Hi Christian,


On Sun, 17 Mar 2019 at 14:30, Christian Mauderer  wrote:

> Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Sat, 16 Mar 2019 at 01:00, Christian Mauderer  > > wrote:
> >
> > Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> > >
> > >
> > > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
> > mailto:l...@c-mauderer.de>
> > > >> wrote:
> > >
> > > Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > > > Hello,
> > > >
> > > > I am trying to `./waf install` the libbsd but getting some
> > error,
> > > need help
> > > > with that. The commands used and the errors are given below
> ...
> > > >
> > > > configured using: `./waf configure
> > --buildset=buildset/default.ini
> > > > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> > > >
> > > > configure was successful.
> > > >
> > > > then : `./waf install`
> > > >
> > > > Error ...
> > > > 
> > > > Build failed
> > > >  -> task in 'lex__nsyy' failed with exit status 1 (run with
> > -v to
> > > > display more information)
> > > >  -> task in 'yacc__nsyy' failed with exit status 1 (run with
> > -v to
> > > > display more information)
> > > >  -> task in 'lex_pcap' failed with exit status 1 (run with
> -v to
> > > display
> > > > more information)
> > > >  -> task in 'yacc_pcap' failed with exit status 1 (run with
> > -v to
> > > > display more information)
> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
> > to display
> > > > more information)
> > > >  -> task in 'objs01' failed with exit status 1 (run with -v
> > to display
> > > > more information)
> > > >  -> task in 'yacc_pfctly' failed with exit status 1 (run
> > with -v to
> > > > display more information)
> > > >
> > > > 
> > > >
> > > > Thanks
> > > > --vijay
> > > >
> > >
> > > Hello Vijay,
> > >
> > > did you try to build before the install? I don't see the call.
> > > Normally it's
> > >
> > >   waf configure ...
> > >   waf
> > >   waf install
> > >
> > > If you did that: It seems that some of the lex / yacc files
> > should be
> > > regenerated. Did you enable --enable-auto-regen somewhen
> during an
> > > earlier configuration run (not necessary except if you import
> > yacc or
> > > lex files)? Did you import some yacc or lex files?
> > >
> > > I had to install `byacc` package using yum in fedora, then I used
> the
> > > --enable-auto-regen
> > > option, that worked.
> > > However, it's still not building and I'm seeing a lot of warnings,
> I
> > > think this is because of the
> > > files I imported from the freebsd source, maybe they depend on some
> > > other headers that
> > > I didn't include. Any suggestion on how to debug, if this is the
> > case?
> > >
> > > Best regards
> > >
> > > Christian
> > >
> >
> >
> > Hello Vijay,
> >
> > normally you shouldn't need the --enable-auto-regen option. It only
> > changes a lot of files that you don't want to change. Especially: If
> you
> > use Fedora (or some other Linux) you get GPL licensed output. We
> > normally use FreeBSD for that step and check in the generated files
> so
> > that no user has to use --enable-auto-regen.
> >
> > Regarding how to start such a port: Normally it's a good idea to get
> > some overview over what's missing. For that you import the files that
> > you think are relevant (like you already did). Then you can build
> with
> > `waf -k -j1` which continues even if some files are not compilable
> (-k
> > is for continue, -j1 so that you receive the messages in order). You
> > should get a lot of compiler errors during that run.
> >
> > Now comes the hard part: You have to analyse the errors and try to
> find
> > out what's the reason for them. If some big part is missing you most
> > likely get a lot of similar errors (like "header xy.h not found").
> Most
> > likely you can identify some groups. With that you can estimate what
> has
> > to be ported besides the files you already imported.
> >
> > Identifying these groups is a quite relevant step for planning the
> > amount of work for your GSoC proposal. If you are unsure, try to ask
> on
> > the mailing list. You can also post the build output and an
> assumption
> > what groups you estimate to get some feedback.
> >
> > Best regards
> >
> > Christian
> >
> >
> > Hi
> >
> > I figured 

Re: rtems-libbsd build error

[Christian Mauderer]

Am 16.03.19 um 23:52 schrieb Vijay Kumar Banerjee:
> 
> 
> On Sat, 16 Mar 2019 at 01:00, Christian Mauderer  > wrote:
> 
> Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer
> mailto:l...@c-mauderer.de>
> > >> wrote:
> >
> >     Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> >     > Hello, 
> >     >
> >     > I am trying to `./waf install` the libbsd but getting some
> error,
> >     need help
> >     > with that. The commands used and the errors are given below ...
> >     >
> >     > configured using: `./waf configure
> --buildset=buildset/default.ini
> >     > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >     >
> >     > configure was successful.
> >     >
> >     > then : `./waf install`
> >     >
> >     > Error ...
> >     > 
> >     > Build failed
> >     >  -> task in 'lex__nsyy' failed with exit status 1 (run with
> -v to
> >     > display more information)
> >     >  -> task in 'yacc__nsyy' failed with exit status 1 (run with
> -v to
> >     > display more information)
> >     >  -> task in 'lex_pcap' failed with exit status 1 (run with -v to
> >     display
> >     > more information)
> >     >  -> task in 'yacc_pcap' failed with exit status 1 (run with
> -v to
> >     > display more information)
> >     >  -> task in 'objs01' failed with exit status 1 (run with -v
> to display
> >     > more information)
> >     >  -> task in 'objs01' failed with exit status 1 (run with -v
> to display
> >     > more information)
> >     >  -> task in 'yacc_pfctly' failed with exit status 1 (run
> with -v to
> >     > display more information)
> >     >
> >     > 
> >     >
> >     > Thanks
> >     > --vijay
> >     >
> >
> >     Hello Vijay,
> >
> >     did you try to build before the install? I don't see the call.
> >     Normally it's
> >
> >       waf configure ...
> >       waf
> >       waf install
> >
> >     If you did that: It seems that some of the lex / yacc files
> should be
> >     regenerated. Did you enable --enable-auto-regen somewhen during an
> >     earlier configuration run (not necessary except if you import
> yacc or
> >     lex files)? Did you import some yacc or lex files?
> >
> > I had to install `byacc` package using yum in fedora, then I used the
> > --enable-auto-regen
> > option, that worked. 
> > However, it's still not building and I'm seeing a lot of warnings, I
> > think this is because of the
> > files I imported from the freebsd source, maybe they depend on some
> > other headers that 
> > I didn't include. Any suggestion on how to debug, if this is the
> case? 
> >
> >     Best regards
> >
> >     Christian
> >
> 
> 
> Hello Vijay,
> 
> normally you shouldn't need the --enable-auto-regen option. It only
> changes a lot of files that you don't want to change. Especially: If you
> use Fedora (or some other Linux) you get GPL licensed output. We
> normally use FreeBSD for that step and check in the generated files so
> that no user has to use --enable-auto-regen.
> 
> Regarding how to start such a port: Normally it's a good idea to get
> some overview over what's missing. For that you import the files that
> you think are relevant (like you already did). Then you can build with
> `waf -k -j1` which continues even if some files are not compilable (-k
> is for continue, -j1 so that you receive the messages in order). You
> should get a lot of compiler errors during that run.
> 
> Now comes the hard part: You have to analyse the errors and try to find
> out what's the reason for them. If some big part is missing you most
> likely get a lot of similar errors (like "header xy.h not found"). Most
> likely you can identify some groups. With that you can estimate what has
> to be ported besides the files you already imported.
> 
> Identifying these groups is a quite relevant step for planning the
> amount of work for your GSoC proposal. If you are unsure, try to ask on
> the mailing list. You can also post the build output and an assumption
> what groups you estimate to get some feedback.
> 
> Best regards
> 
> Christian
> 
> 
> Hi
> 
> I figured out that there were some unnecessary imports I was doing and
> also some necessary
> header files that I'm missing, after adding those most of the warnings
> vanished. The error I'm
> seeing now is due to a missing '.m' header file. The error looks like
> this ...
> =
>    ../../freebsd/sys/arm/ti/am335x/tda19988.c:56:10: fatal 

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Sat, 16 Mar 2019 at 01:00, Christian Mauderer  wrote:

> Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> >
> >
> > On Fri, 15 Mar 2019 at 21:47, Christian Mauderer  > > wrote:
> >
> > Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > > Hello,
> > >
> > > I am trying to `./waf install` the libbsd but getting some error,
> > need help
> > > with that. The commands used and the errors are given below ...
> > >
> > > configured using: `./waf configure --buildset=buildset/default.ini
> > > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> > >
> > > configure was successful.
> > >
> > > then : `./waf install`
> > >
> > > Error ...
> > > 
> > > Build failed
> > >  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> > > display more information)
> > >  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> > > display more information)
> > >  -> task in 'lex_pcap' failed with exit status 1 (run with -v to
> > display
> > > more information)
> > >  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> > > display more information)
> > >  -> task in 'objs01' failed with exit status 1 (run with -v to
> display
> > > more information)
> > >  -> task in 'objs01' failed with exit status 1 (run with -v to
> display
> > > more information)
> > >  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> > > display more information)
> > >
> > > 
> > >
> > > Thanks
> > > --vijay
> > >
> >
> > Hello Vijay,
> >
> > did you try to build before the install? I don't see the call.
> > Normally it's
> >
> >   waf configure ...
> >   waf
> >   waf install
> >
> > If you did that: It seems that some of the lex / yacc files should be
> > regenerated. Did you enable --enable-auto-regen somewhen during an
> > earlier configuration run (not necessary except if you import yacc or
> > lex files)? Did you import some yacc or lex files?
> >
> > I had to install `byacc` package using yum in fedora, then I used the
> > --enable-auto-regen
> > option, that worked.
> > However, it's still not building and I'm seeing a lot of warnings, I
> > think this is because of the
> > files I imported from the freebsd source, maybe they depend on some
> > other headers that
> > I didn't include. Any suggestion on how to debug, if this is the case?
> >
> > Best regards
> >
> > Christian
> >
>
>
> Hello Vijay,
>
> normally you shouldn't need the --enable-auto-regen option. It only
> changes a lot of files that you don't want to change. Especially: If you
> use Fedora (or some other Linux) you get GPL licensed output. We
> normally use FreeBSD for that step and check in the generated files so
> that no user has to use --enable-auto-regen.
>
> Regarding how to start such a port: Normally it's a good idea to get
> some overview over what's missing. For that you import the files that
> you think are relevant (like you already did). Then you can build with
> `waf -k -j1` which continues even if some files are not compilable (-k
> is for continue, -j1 so that you receive the messages in order). You
> should get a lot of compiler errors during that run.
>
> Now comes the hard part: You have to analyse the errors and try to find
> out what's the reason for them. If some big part is missing you most
> likely get a lot of similar errors (like "header xy.h not found"). Most
> likely you can identify some groups. With that you can estimate what has
> to be ported besides the files you already imported.
>
> Identifying these groups is a quite relevant step for planning the
> amount of work for your GSoC proposal. If you are unsure, try to ask on
> the mailing list. You can also post the build output and an assumption
> what groups you estimate to get some feedback.
>
> Best regards
>
> Christian
>

Hi

I figured out that there were some unnecessary imports I was doing and also
some necessary
header files that I'm missing, after adding those most of the warnings
vanished. The error I'm
seeing now is due to a missing '.m' header file. The error looks like this
...
=
   ../../freebsd/sys/arm/ti/am335x/tda19988.c:56:10: fatal error:
rtems/bsd/local/iicbus_if.h: No such file or directory
 #include 
=
There's an iicbus_if.m file in the freebsd source which is being included as
``#include "iicbus_if.h"``
How to work with the .m files ?

Thanks
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 15.03.19 um 19:20 schrieb Vijay Kumar Banerjee:
> 
> 
> On Fri, 15 Mar 2019 at 21:47, Christian Mauderer  > wrote:
> 
> Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > Hello, 
> >
> > I am trying to `./waf install` the libbsd but getting some error,
> need help
> > with that. The commands used and the errors are given below ...
> >
> > configured using: `./waf configure --buildset=buildset/default.ini
> > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >
> > configure was successful.
> >
> > then : `./waf install`
> >
> > Error ...
> > 
> > Build failed
> >  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'lex_pcap' failed with exit status 1 (run with -v to
> display
> > more information)
> >  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> > display more information)
> >
> > 
> >
> > Thanks
> > --vijay
> >
> 
> Hello Vijay,
> 
> did you try to build before the install? I don't see the call.
> Normally it's
> 
>   waf configure ...
>   waf
>   waf install
> 
> If you did that: It seems that some of the lex / yacc files should be
> regenerated. Did you enable --enable-auto-regen somewhen during an
> earlier configuration run (not necessary except if you import yacc or
> lex files)? Did you import some yacc or lex files?
> 
> I had to install `byacc` package using yum in fedora, then I used the
> --enable-auto-regen
> option, that worked. 
> However, it's still not building and I'm seeing a lot of warnings, I
> think this is because of the
> files I imported from the freebsd source, maybe they depend on some
> other headers that 
> I didn't include. Any suggestion on how to debug, if this is the case? 
> 
> Best regards
> 
> Christian
> 


Hello Vijay,

normally you shouldn't need the --enable-auto-regen option. It only
changes a lot of files that you don't want to change. Especially: If you
use Fedora (or some other Linux) you get GPL licensed output. We
normally use FreeBSD for that step and check in the generated files so
that no user has to use --enable-auto-regen.

Regarding how to start such a port: Normally it's a good idea to get
some overview over what's missing. For that you import the files that
you think are relevant (like you already did). Then you can build with
`waf -k -j1` which continues even if some files are not compilable (-k
is for continue, -j1 so that you receive the messages in order). You
should get a lot of compiler errors during that run.

Now comes the hard part: You have to analyse the errors and try to find
out what's the reason for them. If some big part is missing you most
likely get a lot of similar errors (like "header xy.h not found"). Most
likely you can identify some groups. With that you can estimate what has
to be ported besides the files you already imported.

Identifying these groups is a quite relevant step for planning the
amount of work for your GSoC proposal. If you are unsure, try to ask on
the mailing list. You can also post the build output and an assumption
what groups you estimate to get some feedback.

Best regards

Christian
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Vijay Kumar Banerjee]

On Fri, 15 Mar 2019 at 21:47, Christian Mauderer  wrote:

> Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> > Hello,
> >
> > I am trying to `./waf install` the libbsd but getting some error, need
> help
> > with that. The commands used and the errors are given below ...
> >
> > configured using: `./waf configure --buildset=buildset/default.ini
> > --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> >
> > configure was successful.
> >
> > then : `./waf install`
> >
> > Error ...
> > 
> > Build failed
> >  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'lex_pcap' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> > display more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'objs01' failed with exit status 1 (run with -v to display
> > more information)
> >  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> > display more information)
> >
> > 
> >
> > Thanks
> > --vijay
> >
>
> Hello Vijay,
>
> did you try to build before the install? I don't see the call. Normally
> it's
>
>   waf configure ...
>   waf
>   waf install
>
> If you did that: It seems that some of the lex / yacc files should be
> regenerated. Did you enable --enable-auto-regen somewhen during an
> earlier configuration run (not necessary except if you import yacc or
> lex files)? Did you import some yacc or lex files?
>
> I had to install `byacc` package using yum in fedora, then I used the
--enable-auto-regen
option, that worked.
However, it's still not building and I'm seeing a lot of warnings, I think
this is because of the
files I imported from the freebsd source, maybe they depend on some other
headers that
I didn't include. Any suggestion on how to debug, if this is the case?

> Best regards
>
> Christian
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error

[Christian Mauderer]

Am 15.03.19 um 15:48 schrieb Vijay Kumar Banerjee:
> Hello, 
> 
> I am trying to `./waf install` the libbsd but getting some error, need help
> with that. The commands used and the errors are given below ...
> 
> configured using: `./waf configure --buildset=buildset/default.ini
> --prefix=$HOME/development/rtems/5 --rtems-arch=arm`
> 
> configure was successful.
> 
> then : `./waf install`
> 
> Error ...
> 
> Build failed
>  -> task in 'lex__nsyy' failed with exit status 1 (run with -v to
> display more information)
>  -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to
> display more information)
>  -> task in 'lex_pcap' failed with exit status 1 (run with -v to display
> more information)
>  -> task in 'yacc_pcap' failed with exit status 1 (run with -v to
> display more information)
>  -> task in 'objs01' failed with exit status 1 (run with -v to display
> more information)
>  -> task in 'objs01' failed with exit status 1 (run with -v to display
> more information)
>  -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to
> display more information)
> 
> 
> 
> Thanks
> --vijay
> 

Hello Vijay,

did you try to build before the install? I don't see the call. Normally it's

  waf configure ...
  waf
  waf install

If you did that: It seems that some of the lex / yacc files should be
regenerated. Did you enable --enable-auto-regen somewhen during an
earlier configuration run (not necessary except if you import yacc or
lex files)? Did you import some yacc or lex files?

Best regards

Christian

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems-libbsd build error

[Vijay Kumar Banerjee]

Hello,

I am trying to `./waf install` the libbsd but getting some error, need help
with that. The commands used and the errors are given below ...

configured using: `./waf configure --buildset=buildset/default.ini
--prefix=$HOME/development/rtems/5 --rtems-arch=arm`

configure was successful.

then : `./waf install`

Error ...

Build failed
 -> task in 'lex__nsyy' failed with exit status 1 (run with -v to display
more information)
 -> task in 'yacc__nsyy' failed with exit status 1 (run with -v to display
more information)
 -> task in 'lex_pcap' failed with exit status 1 (run with -v to display
more information)
 -> task in 'yacc_pcap' failed with exit status 1 (run with -v to display
more information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more
information)
 -> task in 'objs01' failed with exit status 1 (run with -v to display more
information)
 -> task in 'yacc_pfctly' failed with exit status 1 (run with -v to display
more information)



Thanks
--vijay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error on

[Chris Johns]

On 4/5/18 1:25 am, Christian Mauderer wrote:
> Am 03.05.2018 um 16:07 schrieb jameszxj:
>> *HI,
>> I compile the current libbsd (newest github version) use
>> "--buildset=buildset/minimal.ini" ,
>>  Error occurs on building "testsuit/debugger01".
>>
>> I found that the waf_libbsd.py file lost a link lib file
>> "libdebugger.a". Would someone review and patch it.
>> *
>>
> 
> Hello,
> 
> I have already a patch up for review that addresses that issue:
> https://lists.rtems.org/pipermail/devel/2018-May/021289.html
> 
> I hope that I can commit it in the next few days.
> 

Please push.

> Just adding the libdebugger.a to all tests would work but maybe wouldn't
> be the ideal solution because we potentially link in a lot of stuff we
> don't need.

Agreed.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-libbsd build error on

[Christian Mauderer]

Am 03.05.2018 um 16:07 schrieb jameszxj:
> *HI,
> I compile the current libbsd (newest github version) use
> "--buildset=buildset/minimal.ini" ,
>  Error occurs on building "testsuit/debugger01".
> 
> I found that the waf_libbsd.py file lost a link lib file
> "libdebugger.a". Would someone review and patch it.
> *
> 

Hello,

I have already a patch up for review that addresses that issue:
https://lists.rtems.org/pipermail/devel/2018-May/021289.html

I hope that I can commit it in the next few days.

Just adding the libdebugger.a to all tests would work but maybe wouldn't
be the ideal solution because we potentially link in a lot of stuff we
don't need.

Best regards

Christian Mauderer
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rtems-libbsd build error on

[jameszxj]

HI,
I compile the current libbsd (newest github version) use 
"--buildset=buildset/minimal.ini" ,
 Error occurs on building "testsuit/debugger01".

I found that the waf_libbsd.py file lost a link lib file "libdebugger.a". Would 
someone review and patch it.

waf_libbsd.py.patch
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: LIBBSD Build Error

[Sebastian Huber]

Sorry, should be fixed now:

https://git.rtems.org/rtems-libbsd/commit/?id=9db59c71ad8bc1f1852838d147a29467a1cd6e3d

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

LIBBSD Build Error

[Kirspel, Kevin]

I have rebased my tools via RSB to the latest and have successfully compiled 
RTEMS with a custom lpc32xx BSP.  When compiling LIBBSD, I am getting the 
following error when compiling "freebsd/lib/libc/inet/nsap_addr.c "

/tmp/ccWucPca.s: Assembler messages:
/tmp/ccWucPca.s:474: Error: symbol `inet_nsap_addr' is already defined
/tmp/ccWucPca.s:476: Error: symbol `inet_nsap_ntoa' is already defined

I assume this is related to pushing network headers into newlib.  There are 
weak aliases in the file as follows:

/*
* Weak aliases for applications that use certain private entry points,
* and fail to include .
*/
#undef inet_nsap_addr
__weak_reference(__inet_nsap_addr, inet_nsap_addr);
#undef inet_nsap_ntoa
__weak_reference(__inet_nsap_ntoa, inet_nsap_ntoa);

Before digging into this, does anyone have an explanation?

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel