Re: RTEMS-libbsd copyright question

[punit vara]

Hi Sichen

On Wed, Jun 21, 2017 at 11:05 AM, Sebastian Huber
 wrote:
> On 19/06/17 15:45, Sichen Zhao wrote:
>
>> Ok, so i think most of my ported file shouldn't add copyright.
>> But some file in the rtemsbsd folder , i think i modified some new
>> code.  The link is below:
>>
>> https://github.com/hahchenchen/rtems-libbsd/blob/usb2.0/rtemsbsd/include/bsp/nexus-devices.h#L49
>>
>>
>> https://github.com/hahchenchen/rtems-libbsd/blob/usb2.0/rtemsbsd/include/machine/rtems-bsd-nexus-bus.h#L260
>
>
> It would be easier to look at patches, so that you can see what is actually
> changed.
>
> In general, changes in the "freebsd" subdirectory should be as small and
> mechanical as possible. There should be simply nothing to do that deserves a
> copyright.
>
>
> --
> 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.
>
Don't add copy right as of now. You can always show off your commits
if someone ask you to show your work. Any way once it is merged with
rtems , it will be represented as green dot ;)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Fix beagle bsp irq issue

[punit vara]

Good job Sichen. Keep it up

On Sat, Jun 17, 2017 at 8:01 PM, Sichen Zhao <1473996...@qq.com> wrote:
> Enable/disable vector routines now check for a valid vector.
> Without these guards, the enable/disable vector routines
> will not work with the interrupt server.
> ---
>  c/src/lib/libbsp/arm/beagle/irq.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
> b/c/src/lib/libbsp/arm/beagle/irq.c
> index d080a5e..35750ba 100644
> --- a/c/src/lib/libbsp/arm/beagle/irq.c
> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
> @@ -98,11 +98,14 @@ static uint32_t omap_get_mir_reg(rtems_vector_number 
> vector, uint32_t *const mas
>  rtems_status_code bsp_interrupt_vector_enable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
> -  uint32_t mir_reg = omap_get_mir_reg(vector, );
>
> -  cur = mmio_read(omap_intr.base + mir_reg);
> -  mmio_write(omap_intr.base + mir_reg, cur & ~mask);
> -  flush_data_cache();
> +  if (bsp_interrupt_is_valid_vector(vector)) {
> +uint32_t mir_reg = omap_get_mir_reg(vector, );
> +
> +cur = mmio_read(omap_intr.base + mir_reg);
> +mmio_write(omap_intr.base + mir_reg, cur & ~mask);
> +flush_data_cache();
> +  }
>
>return RTEMS_SUCCESSFUL;
>  }
> @@ -110,11 +113,14 @@ rtems_status_code 
> bsp_interrupt_vector_enable(rtems_vector_number vector)
>  rtems_status_code bsp_interrupt_vector_disable(rtems_vector_number vector)
>  {
>uint32_t mask, cur;
> -  uint32_t mir_reg = omap_get_mir_reg(vector, );
>
> -  cur = mmio_read(omap_intr.base + mir_reg);
> -  mmio_write(omap_intr.base + mir_reg, cur | mask);
> -  flush_data_cache();
> +  if (bsp_interrupt_is_valid_vector(vector)) {
> +uint32_t mir_reg = omap_get_mir_reg(vector, );
> +
> +cur = mmio_read(omap_intr.base + mir_reg);
> +mmio_write(omap_intr.base + mir_reg, cur | mask);
> +flush_data_cache();
> +  }
>
>return RTEMS_SUCCESSFUL;
>  }
> --
> 2.7.4
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

rsb only download option

[punit vara]

Hi

Is there any way to download packages for rsb and then build locally
rather than downloading while installing rsb ?

If there is no option for only download , I would suggest to provide
something like download all the packages required for rsb and then
developer can install it locally. Last time when I was gsoc student it
used to take around 10-12 hours for building RSB. This idea could be
helpful to students/developers lives in cities where internet
connections are pretty low and still want to contribute to RTEMS
organization.

What do you guys think about this ?

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

Re: [PATCH] Add the i2c driver for Beaglebone Black:

[punit vara]

On Tue, May 23, 2017 at 7:13 PM, Sichen Zhao <1473996...@qq.com> wrote:
> Update ticket #2891 and my GSOC project
>
> add c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> modify c/src/lib/libbsp/arm/beagle/include/i2c.h
> modify c/src/lib/libbsp/arm/beagle/include/bbb-gpio.h
> modify c/src/lib/libcpu/arm/shared/include/am335x.h
> modify c/src/lib/libbsp/arm/beagle/Makefile.am
>
> Now can read the EEPROM by i2c, the test application link is: 
> https://github.com/hahchenchen/GSOC-test-application
> ---
>  c/src/lib/libbsp/arm/beagle/Makefile.am|   1 +
>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c  | 577 
> +
>  c/src/lib/libbsp/arm/beagle/include/bbb-gpio.h |   4 +-
>  c/src/lib/libbsp/arm/beagle/include/i2c.h  | 161 ++-
>  c/src/lib/libcpu/arm/shared/include/am335x.h   | 198 +
>  5 files changed, 921 insertions(+), 20 deletions(-)
>  create mode 100644 c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
>
> diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
> b/c/src/lib/libbsp/arm/beagle/Makefile.am
> index 8bb8478..274dc0e 100644
> --- a/c/src/lib/libbsp/arm/beagle/Makefile.am
> +++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
> @@ -115,6 +115,7 @@ libbsp_a_SOURCES += ../../shared/console.c \
>
>  # I2C
>  libbsp_a_SOURCES += misc/i2c.c
> +libbsp_a_SOURCES += i2c/bbb-i2c.c
>
>  # GPIO
>  libbsp_a_SOURCES += gpio/bbb-gpio.c
> diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
> b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> new file mode 100644
> index 000..5c8958f
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> @@ -0,0 +1,577 @@
> +/**
> + * @file
> + *
> + * @ingroup arm_beagle
> + *
> + * @brief BeagleBoard I2C bus initialization and API Support.
> + */
> +
> +/*
> + * Copyright (c) 2017 Sichen Zhao <zsc19940...@gmail.com>
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> + */
> +
> +/*
> + * Modified on Punit Vara<punitv...@gmail.com> works, currently
> + * the i2c file is working on the Beaglebone Black board(AM335x).
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +static void am335x_i2c0_pinmux(bbb_i2c_bus *bus)
> +{
> +  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
> +  (BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
> +
> +  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
> +  (BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
> +}
> +
> +static void I2C0ModuleClkConfig(void)
> +{
> +/* Configuring L3 Interface Clocks. */
> +
> +/* Writing to MODULEMODE field of CM_PER_L3_CLKCTRL register. */
> +  REG(AM335X_CM_PER_ADDR + CM_PER_L3_CLKCTRL) |=
> +  CM_PER_L3_CLKCTRL_MODULEMODE_ENABLE;
> +

I can see few Macros without AM335X_ . Change all those macros and
don't use same name because this function is similar to starterware. I
have used to just test my code last year. So change the macro names
completely and add AM335X as prefix.

Remove unnecessary lines in this code. Only write registers which are
required to enable clock.

> +/* Waiting for MODULEMODE field to reflect the written value. */
> +  while(CM_PER_L3_CLKCTRL_MODULEMODE_ENABLE !=
> +  (REG(AM335X_CM_PER_ADDR + CM_PER_L3_CLKCTRL) &
> +   CM_PER_L3_CLKCTRL_MODULEMODE));
> +
> +/* Writing to MODULEMODE field of CM_PER_L3_INSTR_CLKCTRL register. */
> +  REG(AM335X_CM_PER_ADDR + CM_PER_L3_INSTR_CLKCTRL) |=
> +  CM_PER_L3_INSTR_CLKCTRL_MODULEMODE_ENABLE;
> +
> +/* Waiting for MODULEMODE field to reflect the written value. */
> +  while(CM_PER_L3_INSTR_CLKCTRL_MODULEMODE_ENABLE !=
> +  (REG(AM335X_CM_PER_ADDR + CM_PER_L3_INSTR_CLKCTRL) &
> +   CM_PER_L3_INSTR_CLKCTRL_MODULEMODE));
> +
> +/* Writing to CLKTRCTRL field of CM_PER_L3_CLKSTCTRL register. */
> +  REG(AM335X_CM_PER_ADDR + CM_PER_L3_CLKSTCTRL) |=
> +  CM_PER_L3_CLKSTCTRL_CLKTRCTRL_SW_WKUP;
> +
> +/* Waiting for CLKTRCTRL field to reflect the written value. */
> +  while(CM_PER_L3_CLKSTCTRL_CLKTRCTRL_SW_WKUP !=
> +  (REG(AM335X_CM_PER_ADDR + CM_PER_L3_CLKSTCTRL) &
> +   CM_PER_L3_CLKSTCTRL_CLKTRCTRL));
> +
> +/* Writing to CLKTRCTRL field of CM_PER_OCPWP_L3_CLKSTCTRL register. */
> +  REG(AM335X_CM_PER_ADDR + CM_PER_OCPWP_L3_CLKSTCTRL) |=
> +  CM_PER_OCPWP_L3_CLKSTCTRL_CLKTRCTRL_SW_WKUP;
> +
> +/*Waiting for CLKTRCTRL field to reflect the written value. */
> +  while(CM_PER_OCPWP_L3_CLKSTCTRL_CLKTRCTRL_SW_WKUP !=
> +  (REG(AM335X_CM_PER_ADDR + CM_P

Keep your proposal open for suggestion

[punit vara]

Hi GSOC'17 aspirants,

Please permit other guys to provide suggestion on your proposals.

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

Can we use slack instead of IRC

[punit vara]

Hi

Can we use a slack for informing all the students general or common
things ? Its easy to add @everyone and that it every student will get
notified about specific instructions. Even weekly meetings if we can
arrange in slack it would be better than IRC. There are many benefits
of Slack over IRC(I hope you guys are aware of it) so can we have
official slack channel for RTEMS ?

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

Re: IoT Protocol in RTEMS

[punit vara]

OK.

For a time being we can create tickets for these protocol. We can
figure it out from where we can port. :)



On Tue, Mar 14, 2017 at 10:13 PM, Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Mar 14, 2017 at 12:08 PM, Joel Sherrill <j...@rtems.org> wrote:
>>
>>
>> On Tue, Mar 14, 2017 at 10:22 AM, punit vara <punitv...@gmail.com> wrote:
>>>
>>> Can I port MQTT from here ?
>>>
>>>
>>> https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/mqtt
>>>
>>> It has Apache licence. Where do I possibly need to add files ?  Any
>>> suggestion ?
>>>
>> Why would Zephyr want their code to support multiple RTOSes? Would
>> we end up with something that has long-term life as an RTEMS option?
>>
> Apache License is a bit of a pain to use if we need to modify the
> upstream source, especially if the upstream will not accept changes.
> I, like Joel, am  more concerned about the latter in case we need to
> adapt the upstream for easier porting and maintenance.
>
>>>
>>> -- PV
>>>
>>> On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill <j...@rtems.org> wrote:
>>> >
>>> >
>>> > On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom <ged...@rtems.org> wrote:
>>> >>
>>> >> On Tue, Mar 14, 2017 at 1:26 AM, punit vara <punitv...@gmail.com>
>>> >> wrote:
>>> >> > Hi
>>> >> >
>>> >> > I think RTEMS don't have any IoT protocol so I propose we should
>>> >> > implement at least two important IoT protocols
>>> >> >
>>> >> > 1. MQTT
>>> >> > (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
>>> >> > 2. CoAP  (http://coap.technology/)
>>> >> >
>>> >> Why are these 2 important?
>>> >>
>>> >> The problem to avoid is adopting a network protocol too early, because
>>> >> there is always a bunch of competing ones, and in the end only a
>>> >> handful will survive in the long term.
>>> >
>>> >
>>> > MQTT is an OASIS standard which is a good sign. It also has multiple
>>> > implementations
>>> > already with this one from the Eclipse Foundation looking very promising
>>> > and
>>> > appropriate for RTEMS.
>>> >
>>> > https://www.eclipse.org/paho/clients/c/embedded/
>>> >
>>> > CoAP also looks promising since it has an RFC. And promising
>>> > implementations
>>> > to investigate.
>>> >
>>> > http://coap.technology/impls.html
>>> >
>>> > https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?).
>>> >
>>> >>
>>> >>
>>> >> >
>>> >> > What's your opinion on this ? :)
>>> >> >
>>> >> This may be a good idea. What is the state of industry and of
>>> >> standardization in this space? Are there open-source reference
>>> >> implementations with a useful (BSD/MIT) license?
>>> >>
>>> >
>>> > I think those two are worth porting. There are already other ports to
>>> > embedded
>>> > environments so RTEMS should join the list.
>>> >
>>> > The effort would have to get the RTEMS specific configuration and
>>> > adaptation
>>> > code upstream, add RSB recipes, and examples with documentation. I would
>>> > honestly expect the ports to be easy enough where more work needs to be
>>> > identified. :)
>>> >
>>> > --joel
>>> >
>>> >>
>>> >> Gedare
>>> >>
>>> >> >
>>> >> > Regards
>>> >> > Punit Vara
>>> >
>>> >
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: IoT Protocol in RTEMS

[punit vara]

Can I port MQTT from here ?

https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/net/lib/mqtt

It has Apache licence. Where do I possibly need to add files ?  Any suggestion ?

-- PV

On Tue, Mar 14, 2017 at 7:50 PM, Joel Sherrill <j...@rtems.org> wrote:
>
>
> On Tue, Mar 14, 2017 at 8:56 AM, Gedare Bloom <ged...@rtems.org> wrote:
>>
>> On Tue, Mar 14, 2017 at 1:26 AM, punit vara <punitv...@gmail.com> wrote:
>> > Hi
>> >
>> > I think RTEMS don't have any IoT protocol so I propose we should
>> > implement at least two important IoT protocols
>> >
>> > 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
>> > 2. CoAP  (http://coap.technology/)
>> >
>> Why are these 2 important?
>>
>> The problem to avoid is adopting a network protocol too early, because
>> there is always a bunch of competing ones, and in the end only a
>> handful will survive in the long term.
>
>
> MQTT is an OASIS standard which is a good sign. It also has multiple
> implementations
> already with this one from the Eclipse Foundation looking very promising and
> appropriate for RTEMS.
>
> https://www.eclipse.org/paho/clients/c/embedded/
>
> CoAP also looks promising since it has an RFC. And promising implementations
> to investigate.
>
> http://coap.technology/impls.html
>
> https://github.com/obgm/libcoap is dual licensed as GPL and BSD (why?).
>
>>
>>
>> >
>> > What's your opinion on this ? :)
>> >
>> This may be a good idea. What is the state of industry and of
>> standardization in this space? Are there open-source reference
>> implementations with a useful (BSD/MIT) license?
>>
>
> I think those two are worth porting. There are already other ports to
> embedded
> environments so RTEMS should join the list.
>
> The effort would have to get the RTEMS specific configuration and adaptation
> code upstream, add RSB recipes, and examples with documentation. I would
> honestly expect the ports to be easy enough where more work needs to be
> identified. :)
>
> --joel
>
>>
>> Gedare
>>
>> >
>> > Regards
>> > Punit Vara
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: IoT Protocol in RTEMS

[punit vara]

On Tue, Mar 14, 2017 at 7:26 PM, Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Mar 14, 2017 at 1:26 AM, punit vara <punitv...@gmail.com> wrote:
>> Hi
>>
>> I think RTEMS don't have any IoT protocol so I propose we should
>> implement at least two important IoT protocols
>>
>> 1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
>> 2. CoAP  (http://coap.technology/)
>>
> Why are these 2 important?
These two are currently latest protocol some IoT devices use. MQTT is
specially for small footprint devices and I believe RTEMS has
potential to run on small foot print devices. Both protocol will good
addition to show RTEMS as IoT OS.

>
> The problem to avoid is adopting a network protocol too early, because
> there is always a bunch of competing ones, and in the end only a
> handful will survive in the long term.
>
>>
>> What's your opinion on this ? :)
>>
> This may be a good idea. What is the state of industry and of
> standardization in this space? Are there open-source reference
> implementations with a useful (BSD/MIT) license?
>
> Gedare
>
>>
>> Regards
>> Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

IoT Protocol in RTEMS

[punit vara]

Hi

I think RTEMS don't have any IoT protocol so I propose we should
implement at least two important IoT protocols

1. MQTT (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html)
2. CoAP  (http://coap.technology/)


What's your opinion on this ? :)


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

Re: GSoC 2017

[punit vara]

Hi

On Fri, Mar 3, 2017 at 9:45 PM, aditya upadhyay  wrote:
> Hello all,
> I am trying to implement pthread_condattr_getclock() in pthread.h in POSIX
> directory. but i am not able to understand where and which location(files
> and directories) these changes would require.As there are 3 pthread.h files
> and i think implementation of this function is done at this location
> (/home/aditya/development/rtems/4.12/sparc-rtems4.12/include/). I have used

This location is not the actual RTEMS kernel location. Whenever you
want to implement something you should add in actual source code.
Which should be look like :

https://github.com/RTEMS/rtems

Here Posix directory is

/rtems/cpukit/posix/src

@Gedare Correct me if I am wrong ? I think we guys add POSIX function
in this directory only right ?

> FREEBSD and NETBSD as a reference.Would you please help me so that i can
> proceed.
>
> Regards,
> Aditya
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding GSOC 2017

[punit vara]

Hi,

Good to know that you are interested to contribute RTEMS. Welcome to
community. It is always nice to put devel@rtems.org in CC so that more
people can help along with me. :)

Have you gone through this ?

https://devel.rtems.org/wiki/Developer/Projects/Open/POSIXCompliance

Joel has nicely explained everything there.

Before applying to GSOC, I suggest build RTEMS hello word  in host Linux system.

Regards
PV

On Thu, Feb 23, 2017 at 9:26 PM, aditya upadhyay  wrote:
> Hello Punit,
> I am new in RTEMS and want to apply in GSOC 2017 for Posix compliance. For
> Posix compliance,would you please point me to the docs as a reference so
> that i can proceed.Any help will be greatly appriciable.
>
>
>
>
> Regards,
> Aditya
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Interested to mentor RTEMS GSOC 2017

[punit vara]

Hi

I have got a great exprience from RTEMS community last year during
GSOC'16. I would like to help other guys for GSOC 2017. Has RTEMS
applied for GSOC 2017 ?

Happy to mentor future GSOC guys :)

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

Re: Using helper functions

[punit vara]

If you are trying to build my gpio sample then its just for arm
architecture and specifically for beagle bone black. Sparc is
completely different architecture so sample won't build in it.

On Tue, Feb 7, 2017 at 7:12 PM, Tanu Hari Dixit  wrote:
> Hello Punit,
>
> Thank you for the explanation. I did as you suggested.  I copied the gpio
> folder to testsuites/samples/ and edited configure.ac, ran bootstrap,
> configure and make for the new build. It ran fine (without errors). However,
> I could see all executables except for one in
> /home/thd/development/rtems/src/builds/erc32_gpio/sparc-rtems4.12/c/erc32/testsuites/samples/gpio
> for the gpio application. I am unable to figure out what might be the fault.
> The bootstrap and configure are as below. The make output is attached.
> Something strange that I observed in the make output is, that unlike other
> subdirectories in samples, there never appears a line like:
> make[6]: Entering directory
> `/home/thd/development/rtems/src/builds/erc32_gpio/sparc-rtems4.12/c/erc32/testsuites/samples/gpio'
> Also the gpio folder in
> home/thd/development/rtems/src/builds/erc32_gpio/sparc-rtems4.12/c/erc32/testsuites/samples/gpio
> just has Makefile in it.
> I (just experimenting) ran the Makefile and I got the following output:
>
> thd@thd-Inspiron-5537:~/development/rtems/src/builds/erc32_gpio/sparc-rtems4.12/c/erc32/testsuites/samples/gpio$
> make
> sparc-rtems4.12-gcc -B../../../../../erc32/lib/ -specs bsp_specs -qrtems
> -DHAVE_CONFIG_H -I.
> -I../../../../../../../../rtems/c/src/../../testsuites/samples/gpio -I..
> -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall
> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
> -Wnested-externs -MT init.o -MD -MP -MF .deps/init.Tpo -c -o init.o
> ../../../../../../../../rtems/c/src/../../testsuites/samples/gpio/init.c
> ../../../../../../../../rtems/c/src/../../testsuites/samples/gpio/init.c:6:70:
> fatal error: bsp/beagleboneblack.h: No such file or directory
>  #include  /* Calls the BBB specific library */
>   ^
> compilation terminated.
> make: *** [init.o] Error 1
>
> Maybe that is the error I am facing. I don't know how to rectify it. I
> searched for similar errors but found no luck. Can you please help me with
> this?
> Also, now I am able to understand more and have a feeling that I'll soon
> have a working application that is made by me. Thank you.
>
> Regards,
> Tanu Hari Dixit.
>
>
> OUTPUT: ./bootstrap
>
> ./cpukit
> ./c
> ./c/src/ada-tests
> ./c/src
> ./c/src/make
> ./c/src/lib/libbsp/bfin/bf537Stamp
> ./c/src/lib/libbsp/bfin/eZKit533
> ./c/src/lib/libbsp/bfin
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/bfin/TLL6527M
> ./c/src/lib/libbsp/mips/malta
> ./c/src/lib/libbsp/mips/jmr3904
> ./c/src/lib/libbsp/mips/csb350
> ./c/src/lib/libbsp/mips/rbtx4925
> ./c/src/lib/libbsp/mips
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/mips/rbtx4938
> ./c/src/lib/libbsp/mips/hurricane
> ./c/src/lib/libbsp/epiphany
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/epiphany/epiphany_sim
> ./c/src/lib/libbsp/sparc/leon2
> ./c/src/lib/libbsp/sparc
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/sparc/erc32
> ./c/src/lib/libbsp/sparc/leon3
> ./c/src/lib/libbsp/no_cpu
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/no_cpu/no_bsp
> ./c/src/lib/libbsp/sh/shsim
> ./c/src/lib/libbsp/sh/gensh2
> ./c/src/lib/libbsp/sh/gensh4
> ./c/src/lib/libbsp/sh
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/sh/gensh1
> ./c/src/lib/libbsp/moxie
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/moxie/moxiesim
> ./c/src/lib/libbsp/m32c/m32cbsp
> ./c/src/lib/libbsp/m32c
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/nios2
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/nios2/nios2_iss
> ./c/src/lib/libbsp/arm/altera-cyclone-v
> ./c/src/lib/libbsp/arm/raspberrypi
> ./c/src/lib/libbsp/arm/beagle
> ./c/src/lib/libbsp/arm/edb7312
> ./c/src/lib/libbsp/arm/gumstix
> ./c/src/lib/libbsp/arm/stm32f4
> ./c/src/lib/libbsp/arm/csb337
> ./c/src/lib/libbsp/arm/lpc176x
> ./c/src/lib/libbsp/arm/tms570
> ./c/src/lib/libbsp/arm/xilinx-zynq
> ./c/src/lib/libbsp/arm/csb336
> ./c/src/lib/libbsp/arm
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/arm/lm3s69xx
> ./c/src/lib/libbsp/arm/smdk2410
> ./c/src/lib/libbsp/arm/gdbarmsim
> ./c/src/lib/libbsp/arm/lpc32xx
> ./c/src/lib/libbsp/arm/rtl22xx
> ./c/src/lib/libbsp/arm/lpc24xx
> ./c/src/lib/libbsp/arm/realview-pbx-a9
> ./c/src/lib/libbsp/arm/atsam
> ./c/src/lib/libbsp/v850
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/v850/gdbv850sim
> ./c/src/lib/libbsp/sparc64
> acinclude.m4 is unchanged
> ./c/src/lib/libbsp/sparc64/niagara
> ./c/src/lib/libbsp/sparc64/usiii
> ./c/src/lib/libbsp/m68k/av5282
> ./c/src/lib/libbsp/m68k/genmcf548x
> ./c/src/lib/libbsp/m68k/uC5282
> ./c/src/lib/libbsp/m68k/mvme147s
> ./c/src/lib/libbsp/m68k/mcf5329
> ./c/src/lib/libbsp/m68k/mvme147
> 

Re: Using helper functions

[punit vara]

On Mon, Feb 6, 2017 at 8:31 PM, Tanu Hari Dixit <tokencol...@gmail.com> wrote:
> Hello Punit, Gedare,

> I cloned the repo you linked to in your previous mail. However, I am unable
> to figure out how to run the application. I have kept it outside the rtems
> tree. I know how executables for tests are made i.e. by the configure script
> at the top. But I don't know how I will be able to run an application
> outside of testsuites. For example, my question is rtems_gsoc16/gpio has no
> configure.ac file.

You don't have to create separate configure.ac. In case of
rtems_gsoc16/gpio copy gpio directory under samples. To execute that
testcase you need to add one line

gpio/Makefile

in configure.ac at testsuits/samples/configure.ac

Then do bootstrap

$ ./bootstrap; ./bootstrap -p

I hope you know where to do it.

> What example did you take to learn how to make an application (and run it)?

I wasn't able to find any app at that time so I have figured out own
my own and created this simple app to test GPIO. Carefully follow my
testcase I think you will understand once you compile.

> On Thu, Feb 2, 2017 at 11:16 PM, Gedare Bloom <ged...@rtems.org> wrote:
>>
>> see rtems.git/testsuites/fstests for examples of some filesystem usage.
>>
>> On Thu, Feb 2, 2017 at 12:03 PM, punit vara <punitv...@gmail.com> wrote:
>> > Hi
>> >
>> > Which file system API you are talking about ? Can you please send me
>> > the file location ?
>> >
>> > I have used some of GPIO APIs for BBB board. Have a look at this example
>> >
>> > https://github.com/punitvara/rtems_gsoc16/blob/master/gpio/init.c
>> >
>> > Similarly you can create application for any APIs.
>> >
>> > P.S. Always add devel mailing list as CC so that other person also can
>> > help you :)
>> >
>> > Thanks
>> > PV
>> >
>> > On Wed, Feb 1, 2017 at 11:25 PM, Tanu Hari Dixit <tokencol...@gmail.com>
>> > wrote:
>> >> Hello Punit,
>> >> I have been reading the docs as you suggested. But I want to execute
>> >> the various directives and helper functions and test for myself in an
>> >> isolated example. For example I want to test the various API functions
>> >> available for the filesystem (In memory Filesystem) in RTEMS. How do I
>> >> go about doing that?
>> >> Thanks,
>> >> Tanu Hari Dixit.
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using helper functions

[punit vara]

Hi

Which file system API you are talking about ? Can you please send me
the file location ?

I have used some of GPIO APIs for BBB board. Have a look at this example

https://github.com/punitvara/rtems_gsoc16/blob/master/gpio/init.c

Similarly you can create application for any APIs.

P.S. Always add devel mailing list as CC so that other person also can
help you :)

Thanks
PV

On Wed, Feb 1, 2017 at 11:25 PM, Tanu Hari Dixit  wrote:
> Hello Punit,
> I have been reading the docs as you suggested. But I want to execute
> the various directives and helper functions and test for myself in an
> isolated example. For example I want to test the various API functions
> available for the filesystem (In memory Filesystem) in RTEMS. How do I
> go about doing that?
> Thanks,
> Tanu Hari Dixit.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help with RTEMS

[punit vara]

Hi Tanu,


https://github.com/RTEMS/rtems

You can follow any of following open ideas to get contribute :

https://devel.rtems.org/wiki/Developer/OpenProjects





On Tue, Dec 13, 2016 at 11:40 AM, Tanu Hari Dixit  wrote:
> Hey Punit,
>
> I am Tanu, here. I am an undergraduate student from IIT BHU studying
> electronics engineering. I wanted to contribute to RTEMS, and in a useful
> way so that the devs consider me for GSoC '17. I wanted to know how did you
> fill the gaps when you started with RTOS. I've not even done my bachelor
> yet, am I too early to start with any real time implementation of an OS? I'm

There is always something we can contribute to open source project.

> facing trouble while finding exe files in the prefix and have mailed on the
> users list. (I did that yesterday). Can you please help me with it?
> I have included the mail I sent on the users list:

Its better you ask question on dev list rather than user list.

>
> Hello Devs!
>
> I followed the instructions given in the Getting started guide
> (https://devel.rtems.org/wiki/GSoC/GettingStarted) and
> (https://devel.rtems.org/wiki/TBR/UserManual/Quick_Start). The latter
> says that when I bootstrap and then make and make install, I should
> find sample executables in a path similar to:
>
> "/home2/work/joel/rtems-4.11-work/build/build-sparc-sis-rtems/
> sparc-rtems4.11/c/sis/testsuites/samples/ticker/ticker.exe"
>
That's Joel's directory structure. But I would say you must have
created directory named b-sis right ?

You can see .exe file in path something like

b-sis/sparc-rtems4.12/c/../testsuites/samples/hello

> I am unable to find exe files in my working directory (not even in the
> prefix).
> My tree is the following:
> /development/rtems/src/b-sis
> ./
> |-- sparc-rtems4.12
> |   `-- c
> |-- testsuites
> |   `-- tools
> |   `-- generic
> `-- tools
> |-- build
> `-- cpu
> `-- generic
> and sparc-rtems4.12/c/ has 3 files config.log,  config.status,  Makefile
> and the directory testsuites(shown in the above tree) has no samples.
> There are samples in the rtems source directory, though
> (/development/rtems/src/rtems/testsuites/samples/ticker) but I'm
> clueless as to how to specify to test those samples. The configure
> command :
>
> /rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=sis \
>   --enable-tests=samples --prefix=${HOME}/install_path
>
> specifies to enable tests on "samples" which I'm unable to find. How
> do I successfully run a test? Is there a mistake I did while building
> RTEMS or the RSB? Kindly help me figure this out.
>
> Thank you so much!
> Tanu Hari Dixit,
> Senior Undergraduate,
> Department of Electronics Engineering,
> IIT BHU.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: I2C Driver testcase

[punit vara]

Thanks I am currently refering this one only :)



On Mon, Aug 1, 2016 at 10:14 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
> A good test device for an I2C bus driver is an EEPROM. See also
>
> https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01/init.c#n414
>
>
> On 30/07/16 22:53, punit vara wrote:
>>
>> Hi Sebastian !
>>
>> You have suggested me following i2c drivers which follows /dev/i2c
>> framwork :
>>
>>
>> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/i2c/atsam_i2c_bus.c
>>
>> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/xilinx-zynq/i2c/cadence-i2c.c
>>
>> Can you please provide link to the test case application code for any
>> of above driver ?
>>
>> Thanks,
>> Punit Vara
>
>
> --
> 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

I2C Driver testcase

[punit vara]

Hi Sebastian !

You have suggested me following i2c drivers which follows /dev/i2c framwork :

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/i2c/atsam_i2c_bus.c
https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/xilinx-zynq/i2c/cadence-i2c.c

Can you please provide link to the test case application code for any
of above driver ?

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

[PATCH] doc: source-builder.txt: Update installtion for ubuntu packages

[Punit Vara]

This patch fixes the most common python missing error for RTEMS
tool chain build and RSB built is tested for ubuntu 16.04.1 LTS
---
 doc/source-builder.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/source-builder.txt b/doc/source-builder.txt
index 43bcf77..8b0cd89 100644
--- a/doc/source-builder.txt
+++ b/doc/source-builder.txt
@@ -3098,11 +3098,12 @@ home directory as recommended and end up on the SD card.
 Ubuntu
 ^^
 
-The latest testing was with Ubuntu 13.10 64bit. This section also includes 
Xubuntu. A
+The latest testing was with Ubuntu 16.04.1 LTS 64bit. This section also 
includes Xubuntu. A
 minimal installation was used and the following packages installed.
 
 -
-$ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev
+$ sudo apt-get build-dep binutils gcc g++ gdb unzip git
+$ sudo apt-get install python2.7-dev
 -
 
 FreeBSD
-- 
2.7.4

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

Re: Python missing error Solved

[punit vara]

yeah sorry for typo. Sending patch soon :)

On Thu, Jul 28, 2016 at 11:54 PM, Gedare Bloom <ged...@rtems.org> wrote:
> On Thu, Jul 28, 2016 at 12:36 PM, punit vara <punitv...@gmail.com> wrote:
>> I have seen many newbie stucking on python missing error.  Today I
>> have freshly installed UBUNTU 16.04 and stuck to python missing error.
>> and solved that issue.
>>
>> https://docs.rtems.org/rsb/#_ubuntu
>>
>> $ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev
>>
>> This guide should be updated as follow to solve python missing error :
>>
>> $ sudo apt-get build-dep binutils gcc g++ gdb unzip git
>>
>> $ sudo apt-get install pytohn2.7-dev
>>
> You could send a patch for
> https://git.rtems.org/rtems-source-builder/tree/doc/source-builder.txt
>
> I think you mis-spelt python in the second line though.
>
>> Hope this will helpful to future newbies :)
>>
>> Thanks,
>> Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Python missing error Solved

[punit vara]

I have seen many newbie stucking on python missing error.  Today I
have freshly installed UBUNTU 16.04 and stuck to python missing error.
and solved that issue.

https://docs.rtems.org/rsb/#_ubuntu

$ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev

This guide should be updated as follow to solve python missing error :

$ sudo apt-get build-dep binutils gcc g++ gdb unzip git

$ sudo apt-get install pytohn2.7-dev

Hope this will helpful to future newbies :)

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

Re: I2C testcase linking error

[punit vara]

Thanks a lot. :) I2C framework uses IMFS that why I think this solution
worked.

On Sun, Jul 24, 2016 at 11:52 PM, Ben Gras <b...@shrike-systems.com> wrote:

> All,
>
> Aha, I see the problem indeed.
> From the output I conclude default-configuration.o is providing symbols
> that conflict with your configuration symbols. This suggests
> default-configuration.o is pulled in to satisfy some configuration
> requirement. This suggests we should put more info in init.c.
>
> I found a small change from your init.c that seems to "fix" this problem:
> -#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
> +#define CONFIGURE_FILESYSTEM_IMFS
>
> I guess DEVFS is too limited to support the I2C subsystem but I didn't go
> so deep as to find out what the ins and outs are once I saw this does link
> :-)
>
>
> On 24-07-16 09:06, punit vara wrote:
>
> https://github.com/punitvara/rtems/tree/new
>
> You can reproduce linking error from this  new branch.
>
> On Sat, Jul 23, 2016 at 11:57 PM, Ben Gras <b...@shrike-systems.com>
> wrote:
>
>> All,
>>
>>
>> I tried to reproduce this. The I2C branch of your repo doesn't build
>> because of struct i2c not being defined. So I #if 0'd out all the
>> function bodies in i2c.c, and then everything builds, without linker
>> errors.
>>
>> What is your state now? Are you blocked on this (or anything else)
>> still? If so, can you help me reproduce, e.g. by creating a branch that
>> definitely exhibits the problem?
>>
>> I did build from scratch, if you have linking problems it may be an idea
>> to rm -rf the beagle build dir and reconfigure and rebuild, in case
>> there is a library hanging around with an extra object file it isn't
>> supposed to have that the buildsystem isn't updating.
>>
>> Cheers,
>>
>> Ben
>>
>>
>> On 22-07-16 14:26, punit vara wrote:
>> >
>> /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23:
>> > multiple definition of
>> > `_Linker_set__Sysinit__RTEMS_tasks_Initialize_user_tasks_body'
>>
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: I2C testcase linking error

[punit vara]

https://github.com/punitvara/rtems/tree/new

You can reproduce linking error from this  new branch.

On Sat, Jul 23, 2016 at 11:57 PM, Ben Gras <b...@shrike-systems.com> wrote:

> All,
>
>
> I tried to reproduce this. The I2C branch of your repo doesn't build
> because of struct i2c not being defined. So I #if 0'd out all the
> function bodies in i2c.c, and then everything builds, without linker
> errors.
>
> What is your state now? Are you blocked on this (or anything else)
> still? If so, can you help me reproduce, e.g. by creating a branch that
> definitely exhibits the problem?
>
> I did build from scratch, if you have linking problems it may be an idea
> to rm -rf the beagle build dir and reconfigure and rebuild, in case
> there is a library hanging around with an extra object file it isn't
> supposed to have that the buildsystem isn't updating.
>
> Cheers,
>
> Ben
>
>
> On 22-07-16 14:26, punit vara wrote:
> >
> /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23:
> > multiple definition of
> > `_Linker_set__Sysinit__RTEMS_tasks_Initialize_user_tasks_body'
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

I2C testcase linking error

[punit vara]

 of `rtems_filesystem_table'
init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34:
first defined here
../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o):
In function `Init':
/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23:
multiple definition of `rtems_telnetd_maximum_ptys'
init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34:
first defined here
../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o):
In function `Init':
/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23:
multiple definition of `rtems_libio_number_iops'
init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34:
first defined here
../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o):(.rtemsroset._Sysinit.content.0.0x00040180+0x0):
multiple definition of `_Linker_set__Sysinit_rtems_filesystem_initialize'
init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34:
first defined here
collect2: error: ld returned 1 exit status


Here is my test case

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include 
#include 
#include 
#include 

#include  /* for device driver prototypes */

#include 
#include 
#include 
#include 

/* forward declarations to avoid warnings */
rtems_task Init(rtems_task_argument argument);

const char rtems_test_name[] = "GSOC 2016 I2C TESTING";
rtems_printer rtems_test_printer;

rtems_task Init(
  rtems_task_argument ignored
)
{
  rtems_print_printer_printf(_test_printer);
  rtems_test_begin();
  int fd,r;

  r = bbb_register_i2c_0();
  fd = open(BBB_I2C_0_BUS_PATH,O_RDWR);
  printf("value of fd is %d \n",fd);
  close(fd);
  rtems_test_end();
  exit( 0 );
}

/* NOTICE: the clock driver is explicitly disabled */
#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER

#define CONFIGURE_MAXIMUM_TASKS1
#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM

#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION

#define CONFIGURE_INIT
#include 


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

Which I2c framework to prefer for BSP

[punit vara]

Hi all !

I have just started reading about I2C from TRM to achieve my next
deliverable . As Gedare told there are two I2C frame work in RTEMS.
Which one I should use during implementation cpukit/libi2c or
cpukit/dev/i2c ? I would like to confirm before start coding.

Regards,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 2/2] Subject: Update PWM driver imported from BBBIO

[punit vara]

Thank you very much for detailed review of patch. I have done most of
the changes as you said here.

On Sat, Jul 2, 2016 at 2:42 AM, Martin Galvan
<martin.gal...@tallertechnologies.com> wrote:
> Hi Punit, thanks for the patch. As we spoke in the group chat with the other 
> mentors, this seems to
> be good for a first version. I'll be pointing out the required changes for 
> the next version, but
> unless somebody sees anything blocking this should be good to merge.
>
> Besides improving the code itself, my intention here is for you to learn from 
> having mistakes pointed out.

Yes It is great learning experience for me Martin :)

> On Fri, Jul 1, 2016 at 12:28 PM, Punit Vara <punitv...@gmail.com> wrote:
>  c/src/lib/libbsp/arm/beagle/Makefile.am   |   4 +
>  c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h | 162 +-
>
> I think we should follow a naming convention for pwm.c/h. I suggested 
> renaming bbb-pwm.h to just
> pwm.h, but I think someone else said to keep it this way?

Once I asked Ben and he told me to rename it bbb-pwm.h

>  libbsp_a_SOURCES += gpio/bbb-gpio.c
> +#pwm
>
> Whenever possible, try to follow the style of the file you're editing. For 
> example,
> here you should add a blank line between the comment and the previous line. 
> Also, "#pwm" -> "# PWM".

I renamed it and I already have black line between comment and the
previous line I don't know why it does not appear in patch.

> +#define BBB_CONTROL_CONF_GPMC_AD(n)   (0x800 + (n * 4))
> +#define BBB_CONTROL_CONF_LCD_DATA(n)   (0x8a0 + (n * 4))
>
> As Ketul suggested, it would be good if you did a quick check for which 
> macros are processor-specific,
> and named them AM335X_* instead of BBB_*.

I have renamed when Ketul suggested so this patch is according to
that. Above Macros are pinmux setting according to BBB that's why it
is BBB specific IMHO.

> As we said before, there should be a prominent comment here explaining how 
> this works,
> and why the TI StarterWare code isn't as accurate as this. It would also be 
> nice if
> we referred to the manual and the Google groups link explaining where the 
> value for
> SYSCLKOUT comes from, as we discussed in the previous patch. You could even 
> go further
> and write a README in the pwm directory with all we've learned. That would 
> allow for
> a shorter comment here. The README could also include a sample code of how to 
> use this API.

I will add this in README as we don't directly use SYSCLKOUT in BBBIO code.

> Additionally, I insist in that we should have a naming convention for the PWM 
> functions.
> Sometimes we use "pwm", others "pwmss", and others "ehrpwm". You should 
> decide on which
> one is better and follow that convention on the rest of the functions.


> +static uint32_t select_pwmss(uint32_t pwm_id)
>  {
> +uint32_t baseAddr=0;
> +   if (pwm_id == BBB_PWMSS0)
> +   {
> +   baseAddr = AM335X_EPWM_0_REGS;
> +   return baseAddr;
> +   }
> +   else if (pwm_id == BBB_PWMSS1)
> +   {
> +   baseAddr = AM335X_EPWM_1_REGS;
> +   return baseAddr;
> +   }
> +   else if (pwm_id == BBB_PWMSS2)
> +   {
> +   baseAddr = AM335X_EPWM_2_REGS;
> +   return baseAddr;
> +   }
> +   else
> +   {
> +   printf("Invalid PWM Id\n");
>
> As we said before, you should look into some way to mark these printfs as 
> debug-only, or remove them
> altogether.

I will remove printfs as for now and return false instead of just description.

> +static void module_clk_config(uint32_t pwmss_id)
>  {
> +if(pwmss_id == 0)
> +{
> +REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_EPWMSS0_CLKCTRL) |=
> +AM335X_CM_PER_EPWMSS0_CLKCTRL_MODULEMODE_ENABLE;
> +
> +while(AM335X_CM_PER_EPWMSS0_CLKCTRL_MODULEMODE_ENABLE !=
> +  (REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_EPWMSS0_CLKCTRL) &
> +   AM335X_CM_PER_EPWMSS0_CLKCTRL_MODULEMODE));
> +
> +while((AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST_FUNC <<
> +   AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST_SHIFT) !=
> +  (REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_EPWMSS0_CLKCTRL) &
> +   AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST));
>
> This is all a bit hard to read. Perhaps you could use variables to ease 
> reading? E.g.
>
> const uint32_t is_idle = AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST_FUNC <<
>  AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST_SHIFT;
> const uint32_t clkctrl = AM335X_CM_PER_ADDR + AM335X_CM_PER_EPWMSS0_CLKCTRL;
> const uint32_t idle_bits = AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST;
>
> while ((REG(clkctrl) & idle_bits) != is_idle) {

[PATCH v3 1/2] Subject: Add original BBBIO PWM driver to BBB BSP

[Punit Vara]

This patch perform following things:
- adds original BBBIO PWM code as it is.
- not added to Makefile otherwise it will break build

This code is added from

https://github.com/VegetableAvenger/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.c
---
 c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h |  41 +++
 c/src/lib/libbsp/arm/beagle/pwm/pwm.c | 407 ++
 2 files changed, 448 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
 create mode 100644 c/src/lib/libbsp/arm/beagle/pwm/pwm.c

diff --git a/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h 
b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
new file mode 100644
index 000..761eae2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
@@ -0,0 +1,41 @@
+#ifndef LIBBSP_ARM_BEAGLE_BBB_PWM_H
+#define LIBBSP_ARM_BEAGLE_BBB_PWM_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @brief  BeagleBone Black PWM Macros.
+ */
+#define BBBIO_PWMSS_COUNT   3
+#define BBBIO_PWMSS0   0
+#define BBBIO_PWMSS1   1
+#define BBBIO_PWMSS2   2
+
+#define MUXMODE0   0
+#define MUXMODE11
+#define MUXMODE2   2
+#define MUXMODE3   3
+#define MUXMODE4   4
+#define MUXMODE5   5
+#define MUXMODE6   6
+#define MUXMODE7   7
+
+#define EPWM_GROUP11
+#define EPWM_GROUP22
+#define EPWM_GROUP00
+
+int BBBIO_PWMSS_Setting(unsigned int PWMID , float HZ ,float dutyA ,float 
dutyB);
+int BBBIO_PWM_Init();
+void BBBIO_PWM_Release();
+int BBBIO_PWMSS_Status(unsigned int PWMID);
+void BBBIO_ehrPWM_Enable(unsigned int PWMSS_ID);
+void BBBIO_ehrPWM_Disable(unsigned int PWMSS_ID);
+
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_BEAGLE_BBB_PWM_H */
diff --git a/c/src/lib/libbsp/arm/beagle/pwm/pwm.c 
b/c/src/lib/libbsp/arm/beagle/pwm/pwm.c
new file mode 100644
index 000..f65ff89
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/pwm/pwm.c
@@ -0,0 +1,407 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "BBBiolib.h"
+/*---*/
+/*
+ * PWMSS Registers
+ *
+ * @Source : AM335x Technical Reference Manual ,page 1991
+ *   Table 15-5. PWMSS REGISTERS
+ *
+*/
+
+#define PWMSS0_MMAP_ADDR   0x4830
+#define PWMSS1_MMAP_ADDR   0x48302000
+#define PWMSS2_MMAP_ADDR   0x48304000
+#define PWMSS_MMAP_LEN 0x1000
+
+#define PWMSS_IDVER0x0
+#define PWMSS_SYSCONFIG0x4
+#define PWMSS_CLKCONFIG0x8
+#define PWMSS_CLKSTATUS0xC
+
+/* EPWM Registers
+ *
+ * @Source : AM335x Technical Reference Manual ,page 2084
+ *   Table 15-58. EPWM REGISTERS
+ *
+*/
+#define EPWM_TBCTL 0x0
+#define EPWM_TBSTS 0x2
+#define EPWM_TBPHSHR   0x4
+#define EPWM_TBPHS 0x6
+#define EPWM_TBCNT 0x8
+#define EPWM_TBPRD 0xA
+#define EPWM_CMPCTL0xE
+#define EPWM_CMPAHR0x10
+#define EPWM_CMPA  0x12
+#define EPWM_CMPB  0x14
+#define EPWM_AQCTLA0x16
+#define EPWM_AQCTLB0x18
+#define EPWM_AQSFRC0x1A
+#define EPWM_AQCSFRC   0x1C
+#define EPWM_DBCTL 0x1E
+#define EPWM_DBRED 0x20
+#define EPWM_DBFED 0x22
+/*---*/
+extern int memh;
+extern volatile unsigned int *CM_ptr;  /*c ontrol module */
+volatile unsigned int *cm_per_addr;
+
+
+const unsigned int PWMSS_AddressOffset[]={PWMSS0_MMAP_ADDR,
+ PWMSS1_MMAP_ADDR,
+ PWMSS2_MMAP_ADDR};
+volatile unsigned int *pwmss_ptr[3] ={NULL, NULL, NULL} ;
+volatile unsigned int *epwm_ptr[3]  ={NULL, NULL, NULL} ;
+volatile unsigned int *ecap_ptr[3]  ={NULL, NULL, NULL} ;
+volatile unsigned int *eqep_ptr[3]  ={NULL, NULL, NULL} ;
+
+#define TBCTL_CTRMODE_UP0x0
+#define TBCTL_CTRMODE_DOWN  0x1
+#define TBCTL_CTRMODE_UPDOWN0x2
+#define TBCTL_CTRMODE_FREEZE0x3
+/* 
---
 */
+/* PWMSS Timebase clock check
+ * check the timenase clock enable or not
+ *
+ * @param PWMSS_ID :  PWM sumsystem ID (BBBIO_PWMSS0 ,BBBIO_PWMSS1, 
BBBIO_PWMSS2)
+ *
+ * @return : 0 for disable timebase clock , 1 for enable for timebase clock
+ */
+static int PWMSS_TB_clock_check(unsigned int PWMSS_ID)
+{
+   volatile unsigned int* reg;
+   unsigned int reg_value ;
+
+   /* Control module check */
+   reg =(void *)CM_ptr + BBBIO_PWMSS_CTRL;
+   reg_value = *reg ;
+
+   return (reg_value & (1 << PWMSS_ID)) ;
+}
+
+/* 
---
 */
+/* PWM subsystem system control
+ * enable or disable module clock

[PATCH v2 1/2] Subject: Add original BBBIO PWM driver to BBB BSP

[Punit Vara]

This patch perform following things:
- adds original BBBIO PWM code as it is.
- not added to Makefile otherwise it will break build

This code is added from

https://github.com/VegetableAvenger/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.c
---
 c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h |  41 +++
 c/src/lib/libbsp/arm/beagle/pwm/pwm.c | 407 ++
 2 files changed, 448 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
 create mode 100644 c/src/lib/libbsp/arm/beagle/pwm/pwm.c

diff --git a/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h 
b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
new file mode 100644
index 000..761eae2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
@@ -0,0 +1,41 @@
+#ifndef LIBBSP_ARM_BEAGLE_BBB_PWM_H
+#define LIBBSP_ARM_BEAGLE_BBB_PWM_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @brief  BeagleBone Black PWM Macros.
+ */
+#define BBBIO_PWMSS_COUNT   3
+#define BBBIO_PWMSS0   0
+#define BBBIO_PWMSS1   1
+#define BBBIO_PWMSS2   2
+
+#define MUXMODE0   0
+#define MUXMODE11
+#define MUXMODE2   2
+#define MUXMODE3   3
+#define MUXMODE4   4
+#define MUXMODE5   5
+#define MUXMODE6   6
+#define MUXMODE7   7
+
+#define EPWM_GROUP11
+#define EPWM_GROUP22
+#define EPWM_GROUP00
+
+int BBBIO_PWMSS_Setting(unsigned int PWMID , float HZ ,float dutyA ,float 
dutyB);
+int BBBIO_PWM_Init();
+void BBBIO_PWM_Release();
+int BBBIO_PWMSS_Status(unsigned int PWMID);
+void BBBIO_ehrPWM_Enable(unsigned int PWMSS_ID);
+void BBBIO_ehrPWM_Disable(unsigned int PWMSS_ID);
+
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_BEAGLE_BBB_PWM_H */
diff --git a/c/src/lib/libbsp/arm/beagle/pwm/pwm.c 
b/c/src/lib/libbsp/arm/beagle/pwm/pwm.c
new file mode 100644
index 000..f65ff89
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/pwm/pwm.c
@@ -0,0 +1,407 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "BBBiolib.h"
+/*---*/
+/*
+ * PWMSS Registers
+ *
+ * @Source : AM335x Technical Reference Manual ,page 1991
+ *   Table 15-5. PWMSS REGISTERS
+ *
+*/
+
+#define PWMSS0_MMAP_ADDR   0x4830
+#define PWMSS1_MMAP_ADDR   0x48302000
+#define PWMSS2_MMAP_ADDR   0x48304000
+#define PWMSS_MMAP_LEN 0x1000
+
+#define PWMSS_IDVER0x0
+#define PWMSS_SYSCONFIG0x4
+#define PWMSS_CLKCONFIG0x8
+#define PWMSS_CLKSTATUS0xC
+
+/* EPWM Registers
+ *
+ * @Source : AM335x Technical Reference Manual ,page 2084
+ *   Table 15-58. EPWM REGISTERS
+ *
+*/
+#define EPWM_TBCTL 0x0
+#define EPWM_TBSTS 0x2
+#define EPWM_TBPHSHR   0x4
+#define EPWM_TBPHS 0x6
+#define EPWM_TBCNT 0x8
+#define EPWM_TBPRD 0xA
+#define EPWM_CMPCTL0xE
+#define EPWM_CMPAHR0x10
+#define EPWM_CMPA  0x12
+#define EPWM_CMPB  0x14
+#define EPWM_AQCTLA0x16
+#define EPWM_AQCTLB0x18
+#define EPWM_AQSFRC0x1A
+#define EPWM_AQCSFRC   0x1C
+#define EPWM_DBCTL 0x1E
+#define EPWM_DBRED 0x20
+#define EPWM_DBFED 0x22
+/*---*/
+extern int memh;
+extern volatile unsigned int *CM_ptr;  /*c ontrol module */
+volatile unsigned int *cm_per_addr;
+
+
+const unsigned int PWMSS_AddressOffset[]={PWMSS0_MMAP_ADDR,
+ PWMSS1_MMAP_ADDR,
+ PWMSS2_MMAP_ADDR};
+volatile unsigned int *pwmss_ptr[3] ={NULL, NULL, NULL} ;
+volatile unsigned int *epwm_ptr[3]  ={NULL, NULL, NULL} ;
+volatile unsigned int *ecap_ptr[3]  ={NULL, NULL, NULL} ;
+volatile unsigned int *eqep_ptr[3]  ={NULL, NULL, NULL} ;
+
+#define TBCTL_CTRMODE_UP0x0
+#define TBCTL_CTRMODE_DOWN  0x1
+#define TBCTL_CTRMODE_UPDOWN0x2
+#define TBCTL_CTRMODE_FREEZE0x3
+/* 
---
 */
+/* PWMSS Timebase clock check
+ * check the timenase clock enable or not
+ *
+ * @param PWMSS_ID :  PWM sumsystem ID (BBBIO_PWMSS0 ,BBBIO_PWMSS1, 
BBBIO_PWMSS2)
+ *
+ * @return : 0 for disable timebase clock , 1 for enable for timebase clock
+ */
+static int PWMSS_TB_clock_check(unsigned int PWMSS_ID)
+{
+   volatile unsigned int* reg;
+   unsigned int reg_value ;
+
+   /* Control module check */
+   reg =(void *)CM_ptr + BBBIO_PWMSS_CTRL;
+   reg_value = *reg ;
+
+   return (reg_value & (1 << PWMSS_ID)) ;
+}
+
+/* 
---
 */
+/* PWM subsystem system control
+ * enable or disable module clock

[PATCH 2/2] Subject: Update PWM driver imported from BBBIO

[Punit Vara]

This patch performs following things:
- adds registers to appropriate header file
- Changes APIs to build RTEMS successful

I have tested PWM driver with RGB LED and multimeter
https://youtu.be/jhjZO9amdSA

This code generate more accurate frequency compare to TI SW code.
There is licence issue with TISW as well. So BBBIO code has been 
added from

https://github.com/VegetableAvenger/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.c
---
 c/src/lib/libbsp/arm/beagle/Makefile.am   |   4 +
 c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h | 155 +-
 c/src/lib/libbsp/arm/beagle/preinstall.am |   4 +
 c/src/lib/libbsp/arm/beagle/pwm/pwm.c | 772 ++
 c/src/lib/libcpu/arm/shared/include/am335x.h  |  97 +++-
 5 files changed, 657 insertions(+), 375 deletions(-)

diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 20d3092..bf9a909 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -41,6 +41,7 @@ include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/beagleboneblack.h
 include_bsp_HEADERS += include/bbb-gpio.h
+include_bsp_HEADERS += include/bbb-pwm.h
 
 include_libcpu_HEADERS =
 include_libcpu_HEADERS += ../../../libcpu/arm/shared/include/arm-cp15.h
@@ -117,6 +118,9 @@ libbsp_a_SOURCES += misc/i2c.c
 # GPIO
 libbsp_a_SOURCES += gpio/bbb-gpio.c
 
+#pwm
+libbsp_a_SOURCES += pwm/pwm.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h 
b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
index 761eae2..6eb6fcb 100644
--- a/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
+++ b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
@@ -1,3 +1,23 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief BeagleBone Black BSP definitions.
+ */
+
+/**
+ * Copyright (c) 2016 Punit Vara <punitv...@gmail.com>
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+/** Some constants are taken from 
+ * 
https://github.com/VegetableAvenger/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.h
+ */
+
 #ifndef LIBBSP_ARM_BEAGLE_BBB_PWM_H
 #define LIBBSP_ARM_BEAGLE_BBB_PWM_H
 
@@ -8,31 +28,118 @@ extern "C" {
 /**
  * @brief  BeagleBone Black PWM Macros.
  */
-#define BBBIO_PWMSS_COUNT   3
-#define BBBIO_PWMSS0   0
-#define BBBIO_PWMSS1   1
-#define BBBIO_PWMSS2   2
-
-#define MUXMODE0   0
-#define MUXMODE11
-#define MUXMODE2   2
-#define MUXMODE3   3
-#define MUXMODE4   4
-#define MUXMODE5   5
-#define MUXMODE6   6
-#define MUXMODE7   7
-
-#define EPWM_GROUP11
-#define EPWM_GROUP22
-#define EPWM_GROUP00
-
-int BBBIO_PWMSS_Setting(unsigned int PWMID , float HZ ,float dutyA ,float 
dutyB);
-int BBBIO_PWM_Init();
-void BBBIO_PWM_Release();
-int BBBIO_PWMSS_Status(unsigned int PWMID);
-void BBBIO_ehrPWM_Enable(unsigned int PWMSS_ID);
-void BBBIO_ehrPWM_Disable(unsigned int PWMSS_ID);
+#define BBB_CONTROL_CONF_GPMC_AD(n)   (0x800 + (n * 4))
+#define BBB_CONTROL_CONF_LCD_DATA(n)   (0x8a0 + (n * 4))
+
+#define BBB_PWMSS_COUNT   3
+#define BBB_PWMSS0  0
+#define BBB_PWMSS1  1  
+#define BBB_PWMSS2  2
+
+#define BBB_P8_13_2B  3
+#define BBB_P8_19_2A  4
+#define BBB_P8_45_2A  5
+#define BBB_P8_46_2B  6
+#define BBB_P8_34_1B  7
+#define BBB_P8_36_1A  8
+#define BBB_P9_14_1A  9
+#define BBB_P9_16_1B  10
+#define BBB_P9_21_0B  11
+#define BBB_P9_22_0A  12
+#define BBB_P9_29_0B  13
+#define BBB_P9_31_0A  14
+
+#define BBB_MUX0  0
+#define BBB_MUX1  1
+#define BBB_MUX2  2
+#define BBB_MUX3  3
+#define BBB_MUX4  4
+#define BBB_MUX5  5
+#define BBB_MUX6  6
+#define BBB_MUX7  7
+
+#define BBB_EPWM1 1
+#define BBB_EPWM2 2
+#define BBB_EPWM0 0
+
+/**
+ * @brief  BeagleBone Black PWM API.
+ */
+
+/**
+ * @brief This function intilize clock and pinmuxing for pwm sub system.
+ *
+ * @param PWMSS_ID It is the instance number of EPWM of pwm sub system.
+ * 
+ * @return true if successful
+ **/
+bool beagle_pwm_init(uint32_t pwmss_id);
+
+/* PWMSS setting
+ *  set pulse argument of epwm module
+ *
+ *  @param pwm_id: EPWMSS number , 0~2
+ *  @param pwm_freq : frequency to be generated
+ *  @param dutyA: Duty Cycle in ePWM A
+ *  @param dutyB: Duty Cycle in ePWM B
+ *
+ *  @return : 1 for success , 0 for failed
+ *
+ *  @example:  PWMSS_Setting(0 , 50.0f , 50.0f , 25.0f);  // 
Generate 50HZ pwm in PWM0 ,
+ * 
 // duty cycle is 50% for ePWM0A , 25% for ePWM0B
+ 

Re: [PATCH] Subject: Add original BBBIO PWM driver to BBB BSP

[punit vara]

I have added registers definitions to am335x.h those are used in
BBBIO. Mainly I added so that we can know this much of register right
now BBBIO is using and I will add more definitions in second commit so
that we can track that new changes required that definitions. If you
say I will only add BBBIO code and  one header file. What is opinion
from others ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Subject: Add original BBBIO PWM driver to BBB BSP

[punit vara]

Hi all,

In next patch I will apply changes for working code as well as will
add licence information to pwm.c file. Right now I added URL to
commit. Should I go ahead for further changes ?

Thanks,
Punit Vara

On Wed, Jun 22, 2016 at 12:26 PM, Punit Vara <punitv...@gmail.com> wrote:
> This patch perform following things:
> - adds original BBBIO PWM code as it is.
> - not added to Makefile otherwise it will break build
> - adds required registers
> - adds declarations to BSP_HEADERS
>
> This code is added from
> 
> https://github.com/VegetableAvenger/BBBIOlib/blob/master/BBBio_lib/BBBiolib_PWMSS.c
> ---
>  c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h |  46 +++
>  c/src/lib/libbsp/arm/beagle/pwm/pwm.c | 407 
> ++
>  c/src/lib/libcpu/arm/shared/include/am335x.h  |  11 +-
>  3 files changed, 463 insertions(+), 1 deletion(-)
>  create mode 100644 c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
>  create mode 100644 c/src/lib/libbsp/arm/beagle/pwm/pwm.c
>
> diff --git a/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h 
> b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
> new file mode 100644
> index 000..bd70385
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/beagle/include/bbb-pwm.h
> @@ -0,0 +1,46 @@
> +/**
> + * @file
> + *
> + * @ingroup arm_beagle
> + *
> + * @brief BeagleBone Black BSP definitions.
> + */
> +
> +/**
> + * Copyright (c) 2016 Punit Vara <punitv...@gmail.com>
> + *
> + * The license and distribution terms for this file may be
> + * found in the file LICENSE in this distribution or at
> + * http://www.rtems.org/license/LICENSE.
> + */
> +
> +#ifndef LIBBSP_ARM_BEAGLE_BBB_PWM_H
> +#define LIBBSP_ARM_BEAGLE_BBB_PWM_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif /* __cplusplus */
> +
> +/**
> + * @brief  BeagleBone Black PWM functions.
> + */
> +#define BBBIO_PWMSS_COUNT   3
> +#define BBBIO_PWMSS0   0
> +#define BBBIO_PWMSS1   1
> +#define BBBIO_PWMSS2   2
> +
> +/**
> + * @brief  BeagleBone Black PWM API.
> + */
> +int BBBIO_PWMSS_Setting(unsigned int PWMID , float HZ ,float dutyA ,float 
> dutyB);
> +int BBBIO_PWM_Init();
> +void BBBIO_PWM_Release();
> +int BBBIO_PWMSS_Status(unsigned int PWMID);
> +void BBBIO_ehrPWM_Enable(unsigned int PWMSS_ID);
> +void BBBIO_ehrPWM_Disable(unsigned int PWMSS_ID);
> +
> +#ifdef __cplusplus
> +}
> +#endif /* __cplusplus */
> +
> +#endif /* LIBBSP_ARM_BEAGLE_BBB_PWM_H */
> diff --git a/c/src/lib/libbsp/arm/beagle/pwm/pwm.c 
> b/c/src/lib/libbsp/arm/beagle/pwm/pwm.c
> new file mode 100644
> index 000..f65ff89
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/beagle/pwm/pwm.c
> @@ -0,0 +1,407 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "BBBiolib.h"
> +/*---*/
> +/*
> + * PWMSS Registers
> + *
> + * @Source : AM335x Technical Reference Manual ,page 1991
> + *   Table 15-5. PWMSS REGISTERS
> + *
> +*/
> +
> +#define PWMSS0_MMAP_ADDR   0x4830
> +#define PWMSS1_MMAP_ADDR   0x48302000
> +#define PWMSS2_MMAP_ADDR   0x48304000
> +#define PWMSS_MMAP_LEN 0x1000
> +
> +#define PWMSS_IDVER0x0
> +#define PWMSS_SYSCONFIG0x4
> +#define PWMSS_CLKCONFIG0x8
> +#define PWMSS_CLKSTATUS0xC
> +
> +/* EPWM Registers
> + *
> + * @Source : AM335x Technical Reference Manual ,page 2084
> + *   Table 15-58. EPWM REGISTERS
> + *
> +*/
> +#define EPWM_TBCTL 0x0
> +#define EPWM_TBSTS 0x2
> +#define EPWM_TBPHSHR   0x4
> +#define EPWM_TBPHS 0x6
> +#define EPWM_TBCNT 0x8
> +#define EPWM_TBPRD 0xA
> +#define EPWM_CMPCTL0xE
> +#define EPWM_CMPAHR0x10
> +#define EPWM_CMPA  0x12
> +#define EPWM_CMPB  0x14
> +#define EPWM_AQCTLA0x16
> +#define EPWM_AQCTLB0x18
> +#define EPWM_AQSFRC0x1A
> +#define EPWM_AQCSFRC   0x1C
> +#define EPWM_DBCTL 0x1E
> +#define EPWM_DBRED 0x20
> +#define EPWM_DBFED 0x22
> +/*---*/
> +extern int memh;
> +extern volatile unsigned int *CM_ptr;  /*c ontrol module */
> +volatile unsigned int *cm_per_addr;
> +
> +
> +const unsigned int PWMSS_AddressOffset[]={PWMSS0_MMAP_ADDR,
> + PWMSS1_MMAP_ADDR,
> + 

Re: Subject: Add PWM driver for beagle bone black

[punit vara]

Thank you very much for detailed review. I will do each changes you
suggested. Though I have some specific doubt I would like to ask as
following.

On Wed, Jun 22, 2016 at 1:07 AM, Martin Galvan
<martin.gal...@tallertechnologies.com> wrote:
> Hi Punit, thanks for sending this. If I understood correctly this is the 
> BBBIO code
> plus some changes of your own, right? If so, I think it would be best to send 
> a patch
> with the BBBIO code as is, and then another with your changes on top of it. I 
> think
> that was what we were going for with StarterWare, too.
>

I would like to confirm it once again. Should I send a patch even if
it breaks the build right ?

> For imported code we usually stick to the coding style of whatever we're 
> importing.
> However, I see that bbb-pwm.c isn't actually that much code. If you feel like 
> it
> you could reformat it to follow a more standard coding style. The core RTEMS 
> files
> follow https://devel.rtems.org/wiki/Developer/Coding/Conventions, though BSP 
> code
> can have a bit more leeway.
>
> I prefer using stdint types such as uint32_t for driver code. Also, 
> const-correctness
> is always great to have.
>
> Additional comments are below. I don't know for certain which code is yours 
> and which
> comes from BBBIO, so I'll give a quick look at everything, then when you send 
> your
> changes alone I'll take a deeper look at those.
>
> On Tue, Jun 21, 2016 at 1:26 PM, Punit Vara <punitv...@gmail.com> wrote:
>> This patch adds required definitions, registers definitions and 
>> testsuit to
>> test pwm driver for beagle bone black.
>
> Overall I think a slightly more detailed log message is required. Where did 
> you
> get the code from, what testing did you perform, why we used BBBIO instead of 
> StarterWare
> (license + bugs), and so on. Anything that a future maintainer might find 
> useful.
>
>>  testsuites/samples/Makefile.am   |   2 +-
>>  testsuites/samples/configure.ac  |   1 +
>>  testsuites/samples/pwm/Makefile.am   |  19 ++
>>  testsuites/samples/pwm/init.c|  70 ++
>>  testsuites/samples/pwm/pwm.doc   |   9 +
>>  testsuites/samples/pwm/pwm.scn   |   3 +
>
> Unless I've missed something, right now RTEMS doesn't have BSP-specific 
> tests. You *could*,
> however, add some sort of README with an example of how to use the BBBIO API, 
> as documentation.
>
>> diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
>> b/c/src/lib/libbsp/arm/beagle/Makefile.am
>> index 20d3092..68bdbd4 100644
>> --- a/c/src/lib/libbsp/arm/beagle/Makefile.am
>> +++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
>> @@ -117,6 +117,9 @@ libbsp_a_SOURCES += misc/i2c.c
>>  # GPIO
>>  libbsp_a_SOURCES += gpio/bbb-gpio.c
>>
>> +#pwm
>> +libbsp_a_SOURCES += pwm/bbb-pwm.c
>
> IIRC only the GPIO-related files have the name of the BSP prepended to them 
> to help
> the build system distinguish them from the ones belonging to the generic API. 
> That is,
> this could probably be named pwm.c.

Sure I will do it.

>> diff --git a/c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c 
>> b/c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c
>> new file mode 100644
>> index 000..a2f1107
>> --- /dev/null
>> +++ b/c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c
>> @@ -0,0 +1,345 @@
>> +/* This file is based on following licence
>> + * Copyright (c) 2015, Shabaz, VegetableAvenger
>
> I'm not sure about this. I think it would be best if we didn't add such 
> aliases to
> copyright notices, and instead linked to the repository URL saying something 
> like
> "This code is based on the BBBIO sources, available at...". But maybe there's 
> a better
> way to go about this. What does the rest of you guys think?
>
>> + * Added clock functions and improved pwm_enable function
>
> I don't think these kind of messages should go here. If you want to make 
> clear that you changed
> imported code, do so in a more detailed way in the commit log or maybe atop 
> the function
> you changed.
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Add a space between #include and the file you're including.
>
>> +#define BASE_CLOCK 1
>
> We probably need a better name for this. We could name it SYSCLKOUT (since 
> that's the name the
> manual uses), and add a prominent comment explaining why we're using that 
> value (remember that
> the manual seldom mentions what the actual value is, save for a note below 
> table 15-something).
> It would also be nice to link to

[PATCH] Subject: Add PWM driver for beagle bone black

[Punit Vara]

This patch adds required definitions, registers definitions and 
testsuit to
test pwm driver for beagle bone black.
---
 c/src/lib/libbsp/arm/beagle/Makefile.am  |   3 +
 c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c| 345 ++
 c/src/lib/libbsp/shared/include/gpio.h   |  11 +
 c/src/lib/libcpu/arm/shared/include/am335x.h | 349 ++-
 testsuites/samples/Makefile.am   |   2 +-
 testsuites/samples/configure.ac  |   1 +
 testsuites/samples/pwm/Makefile.am   |  19 ++
 testsuites/samples/pwm/init.c|  70 ++
 testsuites/samples/pwm/pwm.doc   |   9 +
 testsuites/samples/pwm/pwm.scn   |   3 +
 10 files changed, 810 insertions(+), 2 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c
 create mode 100644 testsuites/samples/pwm/Makefile.am
 create mode 100644 testsuites/samples/pwm/init.c
 create mode 100644 testsuites/samples/pwm/pwm.doc
 create mode 100644 testsuites/samples/pwm/pwm.scn

diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 20d3092..68bdbd4 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -117,6 +117,9 @@ libbsp_a_SOURCES += misc/i2c.c
 # GPIO
 libbsp_a_SOURCES += gpio/bbb-gpio.c
 
+#pwm
+libbsp_a_SOURCES += pwm/bbb-pwm.c
+
 #RTC
 libbsp_a_SOURCES += rtc.c
 libbsp_a_SOURCES += ../../shared/tod.c
diff --git a/c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c 
b/c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c
new file mode 100644
index 000..a2f1107
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/pwm/bbb-pwm.c
@@ -0,0 +1,345 @@
+/* This file is based on following licence  
+ * Copyright (c) 2015, Shabaz, VegetableAvenger
+ * Copyright (c) 2016, Punit Vara
+ * Added clock functions and improved pwm_enable function   
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * Redistributions of source code must retain the above copyright notice, this
+ * list of conditions and the following disclaimer.
+
+ * Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * Neither the name of BBBIOlib nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+ * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BASE_CLOCK 1
+/**
+ * @brief This function intilize clock and pinmuxing for pwm sub system.
+ *
+ * @param PWMSS_ID It is the instance number of EPWM of pwm sub system.
+ **/
+void pwm_init(unsigned int baseAddr, unsigned int PWMSS_ID)
+{
+  module_clk_config(PWMSS_ID);
+  EPWMPinMuxSetup();
+  EPWM_clock_enable(baseAddr);
+  pwmss_tbclk_enable(PWMSS_ID);
+
+}   
+
+
+/**
+ * \brief   This function Enables TBCLK(Time Base Clock) for specific
+ *  EPWM instance of pwmsubsystem.
+ *
+ * \param   instance  It is the instance number of EPWM of pwmsubsystem.
+ *
+ **/
+void pwmss_tbclk_enable(unsigned int instance)
+{
+   switch(instance)
+   {
+
+   case 0:
+   REG(AM335X_PADCONF_BASE + CONTROL_PWMSS_CTRL) |=
+   BBBIO_PWMSS_CTRL_PWMSS0_TBCLKEN;
+   break;
+
+   case 1:
+   REG(AM335X_PADCONF_BASE + CONTROL_PWMSS_CTRL) |=
+   BBBIO_PWMSS_CTRL_PWMSS1_TBCLKEN;
+   break;
+
+   case 2:
+   REG(AM335X_PADCONF_BASE + CONTROL_PWMSS_CTRL) |=
+   BBBIO_PWMSS_CTRL_PWMSS2_TBCLKEN;
+   break;
+
+   default:
+   break;
+   }
+}
+
+/**
+ * \brief   This function Enables pinmuxing for PWM module.
+ *  
+ *
+ * \param   instance  It is the instance number of EPWM of pw

Re: Beaglebone BSP broken after updating new tools

[punit vara]

On Wed, Jun 8, 2016 at 7:33 PM, Gedare Bloom <ged...@rtems.org> wrote:
> Did you update the toolchain and rebase to git-pull the HEAD?
>
Thank you for response. Yes I successfully able to build RTEMS with
updated tool chain. :)

Thanking you,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Beaglebone BSP broken after updating new tools

[punit vara]

Yesterday  I have updated RTEMS toolchain. I am not able to build
beagle bone bsp. Getting following errors :

error: unknown type name 'fd_set'
error: unknown type name 'pid_t'

Any help to troubleshoot this error will be appreciated. All are
mostly data type error. I tried to look at commit history but yet not
found which commit broke the build.

Regards,
Punit vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PWM driver tested in RTEMS with RGB

[punit vara]

On Thu, May 12, 2016 at 6:55 PM, Martin Galvan
<martin.gal...@tallertechnologies.com> wrote:
> Hi Punit! Sorry I didn't answer, I was off sick for a couple days. Marcos
> and I are a bit crowded so we can't review every bit of your patch right now
> (plus we don't have our BBB anymore). Could you make the RGB test work using
> SW code only?
Hi all,

I tested test suite which only use TI SW API. Like as follow :

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/fail.c

Whatever frequency  I change LED glows continuously only. In between
CMPA or CMPB whichever is higher , that respective EPWMA or EPWMB is
more brighter.That is the only difference I found out.

Second test case which is with custom function not with TI SW only :

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/success.c

Here whatever frequency I pass as argument , LED blinks at same rate.
There is no difference. If I set different duty cycle for EPWMA and
EPWMB, LED glowing time is more for which duty cycle is higher. But it
seems in this case PWM wave generates , not sure at which frequency.

To calculate frequency(UP or DOWN count only) equation is

TPWM = (TBPRD + 1) x TBCLK
FPWM = 1/TPWM

In program we need to assign value to TBPRD register.

Another important equation to remember is

TBCLK = SYSCLKOUT/(HSPCLKDIV *CLKDIV)

How to calculate duty cycle ?

Simply value need to pass to CMPA or CMPB register.

I am trying to generate testcase which can generate different
frequencies with different duty cycle on LED with TI SW. I tried to
debug with printf but dont know how to use that results. Can you
suggest me any test cases so that I can able to find what is the
problem with code ? Any conclusion why in one case LED just blinks and
in another it just glows continuous. ?

Any help will be appreciated. :-)

Thank you,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: devel Digest, Vol 54, Issue 32

[punit vara]

On Mon, May 16, 2016 at 5:30 PM,   wrote:
> Message: 1
> Date: Sat, 14 May 2016 18:39:02 -0400
> From: "Olufowobi, Habeeb" 
> To: devel@rtems.org
> Subject: Qemu System Error
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hello
>
> I am trying to run the xilinx_zynq and lm4f BSP on the qemu but I have been
> getting the error message below. The only option I have seen to resolve
> this error was to disable libusb during configuration but wasn't working
> for me.
>
> Any ideas on how to fix this error?
>
> qemu-system-arm: symbol lookup error: qemu-system-arm: undefined symbol:
> libusb_get_port_numbers
>
>
Have you tried this ?

http://stackoverflow.com/questions/25595211/running-beaglebone-image-on-qemu-libusb-error
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PWM driver tested in RTEMS with RGB

[punit vara]

Please consider following code as reference original code.

https://github.com/punitvara/TI-Starterware

I have forked from sourceforge repo that I have already discussed.

https://sourceforge.net/p/starterwarefree/code/ci/master/tree/

On Tue, May 10, 2016 at 7:44 PM, punit vara <punitv...@gmail.com> wrote:
> On Fri, May 6, 2016 at 5:22 PM, Chris Johns <chr...@rtems.org> wrote:
>> On 6/05/2016 9:47 PM, punit vara wrote:
>>>
>>> Official TI wiki page.  http://processors.wiki.ti.com/index.php/StarterWare
>>> leads me to same repo.
>>>
>>> If you are saying here we need to be careful than I would like to have
>>> a suggestion from my mentors that from where should I copy the code ?
>>> I think few days back Martin and Marcos both discussed licence issue
>>> with Gedare. I hope they can help me regarding this.
>>
>> This is what I was after. The link is on a TI domain and as you indicate
>> it does point to the SF site.
>>
>> Thanks for providing this. The code looks fine to me.
>>
>> Chris
> Hi all!
>
> I have successfully added original Ti Starter Ware code to RTEMS.
> RTEMS build is also successful with this code.
> Well patch is quite big but I will reduce size as community suggests.
>
> Licence is added to .c file
> Coding style preserved to original TI SW.
> Full header file added from TI SW as it will be helpful for other BSP
> development for BBB.
>
> Please review code and let me know the issue.
>
> https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-Added-original-Ti-StarterWare-with-successful-build.patch
>
> This is my first patch after getting selected in GSOC'16. Any
> suggestions are most welcome.
> Thank you,
> Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PWM driver tested in RTEMS with RGB

[punit vara]

On Fri, May 6, 2016 at 5:22 PM, Chris Johns <chr...@rtems.org> wrote:
> On 6/05/2016 9:47 PM, punit vara wrote:
>>
>> Official TI wiki page.  http://processors.wiki.ti.com/index.php/StarterWare
>> leads me to same repo.
>>
>> If you are saying here we need to be careful than I would like to have
>> a suggestion from my mentors that from where should I copy the code ?
>> I think few days back Martin and Marcos both discussed licence issue
>> with Gedare. I hope they can help me regarding this.
>
> This is what I was after. The link is on a TI domain and as you indicate
> it does point to the SF site.
>
> Thanks for providing this. The code looks fine to me.
>
> Chris
Hi all!

I have successfully added original Ti Starter Ware code to RTEMS.
RTEMS build is also successful with this code.
Well patch is quite big needed moderator approval but I will reduce
size as community suggests.

Licence is added to .c file
Coding style preserved to original TI SW.
Full header file added from TI SW as it will be helpful for other BSP
development for BBB.

Please review code and let me know the issue.

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-Added-original-Ti-StarterWare-with-successful-build.patch

Please consider following code as reference original code.

https://github.com/punitvara/TI-Starterware

I have forked from sourceforge repo that I have already discussed.

https://sourceforge.net/p/starterwarefree/code/ci/master/tree/

This is my first patch after getting selected in GSOC'16. Any
suggestions are most welcome.

Thank you,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PWM driver tested in RTEMS with RGB

[punit vara]

On Fri, May 6, 2016 at 7:23 AM, Chris Johns <chr...@rtems.org> wrote:
> On 05/05/2016 22:25, punit vara wrote:
>>
>>
>> I have referred code from sourceforge.
>>
>> https://sourceforge.net/p/starterwarefree/code/ci/master/tree/
>>
>
> I am sorry but I am not comfortable with this repo at the moment and I would
> like to have origin of the code verified before any code from it enters
> RTEMS. The repo does not have a LICENSE file at the top and the
> AM335X_SoftwareManifest.pdf has "Ti Confidential" on every page yet it is
> public. If this code have been placed in a public repo after someone
> acknowledged an EULA then we need to be careful.
>
> Chris

Hi

Official TI wiki page.  http://processors.wiki.ti.com/index.php/StarterWare
leads me to same repo.

If you are saying here we need to be careful than I would like to have
a suggestion from my mentors that from where should I copy the code ?
I think few days back Martin and Marcos both discussed licence issue
with Gedare. I hope they can help me regarding this.

Regards,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PWM driver tested in RTEMS with RGB

[punit vara]

Sorry for late reply. Thank you for your detailed review. I am still
busy this week with my academic work.I would like to have suggestions
on my proposal.

Should I change anything in my proposal like title or any other detail
? Any suggestions ?

Is there any vim setup instruction for RTEMS coding style(i.e Linux
community has). If not ? I would love to develop vim plugin if it is
possible to develop in less time. It will be useful for every RTEMS
developer.

On Tue, Apr 26, 2016 at 8:21 PM, Martin Galvan
<martin.gal...@tallertechnologies.com> wrote:
> Hi Punit! Sorry for the delay; I finally got to review your code.
> First and foremost, it'd be great if you could tell us which
> StarterWare version/git commit are you using, so that we can keep it
> handy when reviewing your code. Sorry if you already mentioned it, my
> memory is a bit sketchy these days :)
>
> As a general comment I'd say you should keep a consistent coding style
> throughout the code you write yourself. While the core RTEMS style
> (spaces after parentheses, etc) isn't required in BSP code, at least
> indentations should be correct. Indentations in RTEMS are usually two
> spaces.
>
> More on coding style later.
>
> On Fri, Apr 15, 2016 at 4:48 PM, punit vara <punitv...@gmail.com> wrote:
>> This is my first patch I already sent you when I successfully merged TI SW 
>> code.
>>
>> https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch
>
> I take it you're referring to 0001-add-new-pwm-driver.patch. A few comments:
>
> 1) Whenever possible, try to keep the original coding style for
> imported code. This makes it easier to track changes and such. Same
> goes for e.g. the order in which functions are declared (e.g.
> EHRPWMConfigureAQActionOnA and B).
>
> 2) I think you should add the TI license to bbb-pwm.c as well. It
> would also be really nice if you added a comment atop the imported
> files saying which SW version/git commit they come from.

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch

I added Ti licence at last patch. Do I need to add any other licence ?
I will update my local repo with your other suggestion. I considered
all your suggestions. I will soon generate some patches and show you.
Then you can guide me further.

Once again thank you for mentoring every one.

Regards,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Thankful to RTEMS community for being accepted in GSOC 2016

[punit vara]

Hi !

Congratulations to those students who are selected for  GSOC 2016. I am honored
to be selected for RTEMS project in GSOC 2016. I am thankful to following
people who helped me to improve my proposal , who have utilized some of
their important time to review my progress :

Joel Sherrill
Gedare Bloom
Worth Burruss
Ketul Shah
Martin Galvan
Marcos Diaz

I am really sorry if I forget to name one who helped but I am thankful to
whole RTEMS community because I always get  good suggestions whenever I
need. I am thankful from bottom of my heart for being supporting community.
I would be really happy to contribute to the RTEMS project. I am also
feeling excited to work with great person , Ben Gras. :-)


Thank you,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: PWM driver tested in RTEMS with RGB

[punit vara]

On Fri, Apr 15, 2016 at 12:35 AM, Martin Galvan
<martin.gal...@tallertechnologies.com> wrote:
>
> On Thu, Apr 14, 2016 at 1:34 PM, punit vara <punitv...@gmail.com> wrote:
> > Hi all !
> >
> > I had successfully merged the TI Starter Ware Code with RTEMS.
>
> That's great. Could you show us the resulting directory structure
> (perhaps with a diffstat), as well as the changes to Makefile.am?
>

This is my first patch I already sent you when I successfully merged TI SW code.

https://github.com/punitvara/rtems_gsoc16/tree/master/pwm/patch

2. Second patch which shows I added useful registers from TI SW header files

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0002-add-register-for-pwm-driver.patch

After above two patches I created testsuite

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/fail.c

In this testsuite, LED is constantly glowing as I told. No matter what
counter I set or frequency set I am not able to get expected output.

3. Then I added three new function that can be seen in below patch.TI
Copy right is also added as Gedare Bloom suggested me.

https://github.com/punitvara/rtems_gsoc16/blob/master/pwm/patch/0001-PWM-successful-code-added.patch

You should look these definition in patch. I wrote this after first
failed testsuite.

- PWMSS_Setting
- ehrPWM_Enable
- ehrPWM_Disable
- EPWMPinMuxSetup  This last function I also used in first test case.

> > Then I tried
> > to test it with sample application with RGB. As a result I was able to glow
> > the LED with that code but unfortunately, LED was only glowing constantly.
> > It did not blink (at all !!!) according to duty cycle and frequency.
>
> Odd. Could you post your test program (or preferably a link to it)?
> Perhaps we can look into some of the APIs and see what's wrong.
>
> > Yesterday I written my own functions similarly as Worth Burruss suggested
> > me. But they are not exactly same as he told. Those functions are
> >
> > 1. To initialize PWM
> > 2. To Enable PWM
> > 3. To Disable PWM
> > 4. Pinmux for PWM module
> >
> > I have used some Ti Starter Ware clock config functions along with my own
> > written functions and successfully able to test PWM driver on RGB LED. Video
> > is uploaded on youtube and please find the link as below.
>
> So if I understand correctly, you were able to make this work by
> writing your own code to access the PWM instead of the StarterWare
> API? I'd like to see that code as well so we can compare it to
> StarterWare's.

Three functions I wrote are not enough to generate PWM. I have used
following definitions from TI SW code to generate PWM waveform.

- PWMSSModuleClkConfig()
- EHRPWMClockEnable()
- PWMSSTBClkEnable()

>
> > https://www.youtube.com/watch?v=KsdtgVj-ZxU
> >
> > Please let me know if is there any problems with video.
>
> Looks good!
>
> > Martin, you told there are problem with some functions it would be better if
> > you can share so that I can troubleshoot which TI Starter Ware code should I
> > edit. Any comments and suggestions from community members are most welcome.
> > I will soon share the code after suggestions or comments.
>
> I just ran a diff between our sources and the SW version we downloaded
> back then, found here:
>
> http://software-dl-1.ti.com/dsps/forms/self_cert_export.html?prod_no=AM335X_StarterWare_02_00_01_01_Setup.bin_url=http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/latest/
>
> (You need to register a free account to download it).
>
> From what I saw, most of the changes we did were removing unused code
> and fixing mostly cosmetic issues. I'm attaching the diff file so you
> can take a look at it. I think one of the most important differences
> are the changes in utils/delay.c; Sysdelay was replaced by usleep.
> Don't ask me why though, that was a long time ago and it wasn't me who
> did it :)
>
> I also saw that SW has a git repository, which seemingly has quite a
> few differences from the version we were using. Those seem to be
> mostly related to FatFS though.
>
> If I were you, I'd give the old SW code + our patch a shot, then if it
> works I'd try to replicate some of the changes on the SW git.
>
> Unfortunately, Marcos and I won't be able to test your progress
> because we don't have our BBBs available anymore. We can still review
> your code though, and I think Ben has a BBB if you want additional
> testing.
>
> On a related note, it would be better if you posted your progress on a
> single thread so it's easier to keep track of. No need to open a new
> one for each milestone.

>From now on wards I will reply on this thread so this would be easier
to track for you. Right now I added PWM APIs in
../lib

PWM driver tested in RTEMS with RGB

[punit vara]

Hi all !

I had successfully merged the TI Starter Ware Code with RTEMS. Then I tried
to test it with sample application with RGB. As a result I was able to glow
the LED with that code but unfortunately, LED was only glowing constantly.
It did not blink (at all !!!) according to duty cycle and frequency.
Yesterday I written my own functions similarly as Worth Burruss suggested
me. But they are not exactly same as he told. Those functions are

1. To initialize PWM
2. To Enable PWM
3. To Disable PWM
4. Pinmux for PWM module

I have used some Ti Starter Ware clock config functions along with my own
written functions and successfully able to test PWM driver on RGB LED.
Video is uploaded on youtube and please find the link as below.

https://www.youtube.com/watch?v=KsdtgVj-ZxU

Please let me know if is there any problems with video.

Application description :

PWM 2nd module is used with 100 Hz frequency, 20% Duty cycle on  EHRPWM A
pin and 50 % Duty cycle on EHRPWM B pin. More precise description is
written below video on youtube.

Martin, you told there are problem with some functions it would be better
if you can share so that I can troubleshoot which TI Starter Ware code
should I edit. Any comments and suggestions from community members are most
welcome.  I will soon share the code after suggestions or comments.

Thank you,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

BBB PWM driver development - GSOC 2016

[punit vara]

Recently Worth Burruss suggested me function prototype for getting started
to develop PWM driver.  I updated my blog
http://punitvara.github.io/rtems%20drivers/2016/02/28/basic-function with
sample functions.

rtems_status_code SetDutyCycle(int subSystemNumber,float HZ, float
DutyCycleA, float DutyCycleB);
void PWMSubSystemEnable(int subSytemNumber,bool EnableOrDisable);

I have written this function at
https://github.com/punitvara/rtems_gsoc16/blob/master/pwd/worth.c


Marcos, can you please look at blog and function definition? Do you have
advice for me ?

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

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

Hi Marcos and all,

As you suggested me I took StarterWare as reference and writing
function prototypes. I hosted my blog for PWM driver  development
tracking so I can note down my day to day work and you can easily read
in which direction I am working.
I will update this frequently. You can visit this link.

 http://punitvara.github.io/rtems%20drivers/2016/02/28/basic-function

Please review my post and suggest me if improvement is needed in
function prototypes. I hope it is easier way for you to evaluate and
review my work. :-)

Thanks,
Punit

On Wed, Mar 16, 2016 at 1:32 AM, Marcos Díaz
<marcos.d...@tallertechnologies.com> wrote:
> Don't forget that TI has some baremetal drivers (StarterWare) for
> beagle bone. You can base your work with it.
>
> On Tue, Mar 15, 2016 at 4:58 PM, Marcos Díaz
> <marcos.d...@tallertechnologies.com> wrote:
>> On Tue, Mar 15, 2016 at 4:20 PM, punit vara <punitv...@gmail.com> wrote:
>>> On Tue, Mar 15, 2016 at 12:24 PM, punit vara <punitv...@gmail.com> wrote:
>>>> On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello Punit and all,
>>>>>>>>
>>>>>>>> According to me, Punit you must have completed some gpio test through 
>>>>>>>> gpio API that was merged last year. So till the final result of 
>>>>>>>> accepted student you can start working with PWM driver that plays an 
>>>>>>>> important role for any embedded project. This would be a good 
>>>>>>>> kick-start for you as well as a strong reason to showcase in your 
>>>>>>>> proposal. Try to give hardware test and post the video if possible.
>>>>>>>>
>>>>>>>> Coming to further I2C and SPI can be next milestones. To me these 
>>>>>>>> should be at the highest priorities. I had done I2C driver but was not 
>>>>>>>> able to make the hardware test. So you can also refer that and come up 
>>>>>>>> with the output along with best modifications.
>>>>>>>>
>>>>>>>> Next target you can set for SPI after both drivers are tested and 
>>>>>>>> committed.
>>>>>>>>
>>>>>>>> For the references you can always have a loot at code of GPIO 
>>>>>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>>>>>
>>>>>>>> Any suggestions ?
>>>>>>>>
>>>>>>>> In case of any queries you can always ping.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ketul
>>>>>>>>
>>>>>>>> On 5 March 2016 at 01:02, Marcos Díaz 
>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>
>>>>>>>>> We use I2c but using drivers from TI's baremetal drivers they provide 
>>>>>>>>> in their StarterWare software suite.
>>>>>>>>> So, currently we cannot commit that into RTEMS.
>>>>>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>>>>>
>>>>>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>&

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Wed, Mar 23, 2016 at 12:08 AM, punit vara <punitv...@gmail.com> wrote:
> On Fri, Mar 18, 2016 at 9:13 PM, punit vara <punitv...@gmail.com> wrote:
>> On Fri, Mar 18, 2016 at 9:09 PM, punit vara <punitv...@gmail.com> wrote:
>>> On Wed, Mar 16, 2016 at 1:32 AM, Marcos Díaz
>>> <marcos.d...@tallertechnologies.com> wrote:
>>>> Don't forget that TI has some baremetal drivers (StarterWare) for
>>>> beagle bone. You can base your work with it.
>>>>
>>>> On Tue, Mar 15, 2016 at 4:58 PM, Marcos Díaz
>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>> On Tue, Mar 15, 2016 at 4:20 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>> On Tue, Mar 15, 2016 at 12:24 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>> On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> 
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello Punit and all,
>>>>>>>>>>>
>>>>>>>>>>> According to me, Punit you must have completed some gpio test 
>>>>>>>>>>> through gpio API that was merged last year. So till the final 
>>>>>>>>>>> result of accepted student you can start working with PWM driver 
>>>>>>>>>>> that plays an important role for any embedded project. This would 
>>>>>>>>>>> be a good kick-start for you as well as a strong reason to showcase 
>>>>>>>>>>> in your proposal. Try to give hardware test and post the video if 
>>>>>>>>>>> possible.
>>>>>>>>>>>
>>>>>>>>>>> Coming to further I2C and SPI can be next milestones. To me these 
>>>>>>>>>>> should be at the highest priorities. I had done I2C driver but was 
>>>>>>>>>>> not able to make the hardware test. So you can also refer that and 
>>>>>>>>>>> come up with the output along with best modifications.
>>>>>>>>>>>
>>>>>>>>>>> Next target you can set for SPI after both drivers are tested and 
>>>>>>>>>>> committed.
>>>>>>>>>>>
>>>>>>>>>>> For the references you can always have a loot at code of GPIO 
>>>>>>>>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>>>>>>>>
>>>>>>>>>>> Any suggestions ?
>>>>>>>>>>>
>>>>>>>>>>> In case of any queries you can always ping.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ketul
>>>>>>>>>>>
>>>>>>>>>>> On 5 March 2016 at 01:02, Marcos Díaz 
>>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> We use I2c but using drivers from TI's baremetal drivers they 
>>>>>>>>>>>> provide in their StarterWare software suite.
>>>>>>>>>>>> So, currently we cannot commit that into RTEMS.
>>>>>>>>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 2, 2016 at

warning: 'rcsid' defined but not used

[punit vara]

cpukit/pppd/auth.c:78:19: warning: 'rcsid' defined but not used
[-Wunused-const-variable]

In so many files rcsid is not used but defined as static. It is
useless I think. Should I send the patches for it ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Request for GPIO Examples

[punit vara]

Thank you Ketul and Worth Burruss that would be really useful for
testing. I am adding these suggestion to my proposal
https://goo.gl/cGCXbS. Any other suggestions are welcome. :-)

On Thu, Mar 24, 2016 at 10:54 AM, Ketul Shah <ketulshah1...@gmail.com> wrote:
> Hi Punit,
>
> Apart from what Worth Burruss suggested,
>
> First of all setting on off timing and testing on LED would be OK for
> primary testing.
>
> You can always test your PWM signals on DSO/CRO to have a clear picture of
> what is happening over signals.
>
> And if you can manage to have second BBB you can test signals on it too:-
> http://hackaday.com/2015/02/19/turn-your-beagleboneblack-in-to-a-14-channel-100msps-logic-analyzer/
>
> Also thinking towards a bit application side,
>
> Using PWM signals you can very DC motor speed using motor driver IC.
> RGB Led would be a great visual to test it and many more
>
> Hope this helps for your further testing...
>
> Ketul
>
> On 23 March 2016 at 19:51, Worth Burruss <wo...@motioncontrol.org> wrote:
>>
>> On 23 Mar 2016 at 0:57, punit vara wrote:
>>
>> > Hi Worth Burruss,
>> >
>> > This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
>> > bone black BSP which includes PWM drivers as well as I2C driver. Could
>> > you please suggest me testing methods to test PWM on BBB ?
>> >
>> > Regards,
>> > Punit
>> >
>>
>> Punit,
>>
>> I will preface this with my solutions tend to be overly complex and I do
>> not know specifically
>> what is available to use to test with in the BBB.  So this may not be what
>> you are looking for.
>> It also depends on the frequency of your PWM signals.
>>
>> When I think of test on hardware, I want to know it is working the way I
>> think it is working
>> (proving correctness).  For PWM, this means the duty cycle is correct.  I
>> would be using
>> another hardware counter timer to measure the High time followed by the
>> Low time and doing
>> the math to prove that the times are correct for the programmed duty
>> cycle.
>>
>> As an alternate, with appropriate selection of PWM frequency and software
>> timers, you can
>> do the High and low counting using the timers.
>>
>> As for me, I would find it hard to see the change in an LED's intensity
>> except in a crude
>> fashion, so would not meet my personal goal of proving correctness.   But
>> you may be
>> thinking of ON and OFF times in seconds, In which case an LED and maybe a
>> stop watch
>> would be appropriate.
>>
>> Hopefully this gives you some ideas.
>>
>> Thank you,
>>
>> Worth Burruss
>>
>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Request for GPIO Examples

[punit vara]

On Wed, Mar 23, 2016 at 7:51 PM, Worth Burruss <wo...@motioncontrol.org> wrote:
> On 23 Mar 2016 at 0:57, punit vara wrote:
>
>> Hi Worth Burruss,
>>
>> This year I proposed a plan (https://goo.gl/cGCXbS) to develop Beagle
>> bone black BSP which includes PWM drivers as well as I2C driver. Could
>> you please suggest me testing methods to test PWM on BBB ?
>>
>> Regards,
>> Punit
>>
>
> Punit,
>
> I will preface this with my solutions tend to be overly complex and I do not 
> know specifically
> what is available to use to test with in the BBB.  So this may not be what 
> you are looking for.
> It also depends on the frequency of your PWM signals.
>
> When I think of test on hardware, I want to know it is working the way I 
> think it is working
> (proving correctness).  For PWM, this means the duty cycle is correct.  I 
> would be using
> another hardware counter timer to measure the High time followed by the Low 
> time and doing
> the math to prove that the times are correct for the programmed duty cycle.
>
> As an alternate, with appropriate selection of PWM frequency and software 
> timers, you can
> do the High and low counting using the timers.
>
> As for me, I would find it hard to see the change in an LED's intensity 
> except in a crude
> fashion, so would not meet my personal goal of proving correctness.   But you 
> may be
> thinking of ON and OFF times in seconds, In which case an LED and maybe a 
> stop watch
> would be appropriate.
>
> Hopefully this gives you some ideas.
>
> Thank you,
>
> Worth Burruss
>
>
>
>
Did you mean to say ?  General purpose timer that is continuous
increasing can be configured to toggle the PWM output high when a
certain value reached and low when it overflows. I have referred this
from here (

Activating PWM via Timer Registers)

http://elinux.org/BeagleBoardPWM#OMAP_Mux_Configuration
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

PWM testing API

[punit vara]

What are the RTEMS APIs that worth reusing in testing of PWM driver?
Can someone please help to list out ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Fri, Mar 18, 2016 at 9:13 PM, punit vara <punitv...@gmail.com> wrote:
> On Fri, Mar 18, 2016 at 9:09 PM, punit vara <punitv...@gmail.com> wrote:
>> On Wed, Mar 16, 2016 at 1:32 AM, Marcos Díaz
>> <marcos.d...@tallertechnologies.com> wrote:
>>> Don't forget that TI has some baremetal drivers (StarterWare) for
>>> beagle bone. You can base your work with it.
>>>
>>> On Tue, Mar 15, 2016 at 4:58 PM, Marcos Díaz
>>> <marcos.d...@tallertechnologies.com> wrote:
>>>> On Tue, Mar 15, 2016 at 4:20 PM, punit vara <punitv...@gmail.com> wrote:
>>>>> On Tue, Mar 15, 2016 at 12:24 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>> On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Punit and all,
>>>>>>>>>>
>>>>>>>>>> According to me, Punit you must have completed some gpio test 
>>>>>>>>>> through gpio API that was merged last year. So till the final result 
>>>>>>>>>> of accepted student you can start working with PWM driver that plays 
>>>>>>>>>> an important role for any embedded project. This would be a good 
>>>>>>>>>> kick-start for you as well as a strong reason to showcase in your 
>>>>>>>>>> proposal. Try to give hardware test and post the video if possible.
>>>>>>>>>>
>>>>>>>>>> Coming to further I2C and SPI can be next milestones. To me these 
>>>>>>>>>> should be at the highest priorities. I had done I2C driver but was 
>>>>>>>>>> not able to make the hardware test. So you can also refer that and 
>>>>>>>>>> come up with the output along with best modifications.
>>>>>>>>>>
>>>>>>>>>> Next target you can set for SPI after both drivers are tested and 
>>>>>>>>>> committed.
>>>>>>>>>>
>>>>>>>>>> For the references you can always have a loot at code of GPIO 
>>>>>>>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>>>>>>>
>>>>>>>>>> Any suggestions ?
>>>>>>>>>>
>>>>>>>>>> In case of any queries you can always ping.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ketul
>>>>>>>>>>
>>>>>>>>>> On 5 March 2016 at 01:02, Marcos Díaz 
>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> We use I2c but using drivers from TI's baremetal drivers they 
>>>>>>>>>>> provide in their StarterWare software suite.
>>>>>>>>>>> So, currently we cannot commit that into RTEMS.
>>>>>>>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> 
>>>>>>>>>&

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Wed, Mar 16, 2016 at 1:32 AM, Marcos Díaz
<marcos.d...@tallertechnologies.com> wrote:
> Don't forget that TI has some baremetal drivers (StarterWare) for
> beagle bone. You can base your work with it.
>
> On Tue, Mar 15, 2016 at 4:58 PM, Marcos Díaz
> <marcos.d...@tallertechnologies.com> wrote:
>> On Tue, Mar 15, 2016 at 4:20 PM, punit vara <punitv...@gmail.com> wrote:
>>> On Tue, Mar 15, 2016 at 12:24 PM, punit vara <punitv...@gmail.com> wrote:
>>>> On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
>>>>> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hello Punit and all,
>>>>>>>>
>>>>>>>> According to me, Punit you must have completed some gpio test through 
>>>>>>>> gpio API that was merged last year. So till the final result of 
>>>>>>>> accepted student you can start working with PWM driver that plays an 
>>>>>>>> important role for any embedded project. This would be a good 
>>>>>>>> kick-start for you as well as a strong reason to showcase in your 
>>>>>>>> proposal. Try to give hardware test and post the video if possible.
>>>>>>>>
>>>>>>>> Coming to further I2C and SPI can be next milestones. To me these 
>>>>>>>> should be at the highest priorities. I had done I2C driver but was not 
>>>>>>>> able to make the hardware test. So you can also refer that and come up 
>>>>>>>> with the output along with best modifications.
>>>>>>>>
>>>>>>>> Next target you can set for SPI after both drivers are tested and 
>>>>>>>> committed.
>>>>>>>>
>>>>>>>> For the references you can always have a loot at code of GPIO 
>>>>>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>>>>>
>>>>>>>> Any suggestions ?
>>>>>>>>
>>>>>>>> In case of any queries you can always ping.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Ketul
>>>>>>>>
>>>>>>>> On 5 March 2016 at 01:02, Marcos Díaz 
>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>
>>>>>>>>> We use I2c but using drivers from TI's baremetal drivers they provide 
>>>>>>>>> in their StarterWare software suite.
>>>>>>>>> So, currently we cannot commit that into RTEMS.
>>>>>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>>>>>
>>>>>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes I have checked previous year work of ketul . He has done ADC 
>>>>>>>>>>>>> and GPIO BSP . It seems SPI,USB BSP need to be developed as I 
>>>>>>>>>>>>> have checked rtems.git and 

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Fri, Mar 18, 2016 at 9:09 PM, punit vara <punitv...@gmail.com> wrote:
> On Wed, Mar 16, 2016 at 1:32 AM, Marcos Díaz
> <marcos.d...@tallertechnologies.com> wrote:
>> Don't forget that TI has some baremetal drivers (StarterWare) for
>> beagle bone. You can base your work with it.
>>
>> On Tue, Mar 15, 2016 at 4:58 PM, Marcos Díaz
>> <marcos.d...@tallertechnologies.com> wrote:
>>> On Tue, Mar 15, 2016 at 4:20 PM, punit vara <punitv...@gmail.com> wrote:
>>>> On Tue, Mar 15, 2016 at 12:24 PM, punit vara <punitv...@gmail.com> wrote:
>>>>> On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello Punit and all,
>>>>>>>>>
>>>>>>>>> According to me, Punit you must have completed some gpio test through 
>>>>>>>>> gpio API that was merged last year. So till the final result of 
>>>>>>>>> accepted student you can start working with PWM driver that plays an 
>>>>>>>>> important role for any embedded project. This would be a good 
>>>>>>>>> kick-start for you as well as a strong reason to showcase in your 
>>>>>>>>> proposal. Try to give hardware test and post the video if possible.
>>>>>>>>>
>>>>>>>>> Coming to further I2C and SPI can be next milestones. To me these 
>>>>>>>>> should be at the highest priorities. I had done I2C driver but was 
>>>>>>>>> not able to make the hardware test. So you can also refer that and 
>>>>>>>>> come up with the output along with best modifications.
>>>>>>>>>
>>>>>>>>> Next target you can set for SPI after both drivers are tested and 
>>>>>>>>> committed.
>>>>>>>>>
>>>>>>>>> For the references you can always have a loot at code of GPIO 
>>>>>>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>>>>>>
>>>>>>>>> Any suggestions ?
>>>>>>>>>
>>>>>>>>> In case of any queries you can always ping.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ketul
>>>>>>>>>
>>>>>>>>> On 5 March 2016 at 01:02, Marcos Díaz 
>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>
>>>>>>>>>> We use I2c but using drivers from TI's baremetal drivers they 
>>>>>>>>>> provide in their StarterWare software suite.
>>>>>>>>>> So, currently we cannot commit that into RTEMS.
>>>>>>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> 
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com> 
>>>>>>>>>>>>> wrote:
>>>

Re: devel Digest, Vol 52, Issue 59

[punit vara]

> Date: Tue, 15 Mar 2016 13:15:14 -0500
> From: Joel Sherrill 
> To: "rtems-de...@rtems.org" 
> Subject: Request for GPIO Examples
> Message-ID:
> 

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Tue, Mar 15, 2016 at 12:24 PM, punit vara <punitv...@gmail.com> wrote:
> On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
>> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> wrote:
>>>>>
>>>>> Hello Punit and all,
>>>>>
>>>>> According to me, Punit you must have completed some gpio test through 
>>>>> gpio API that was merged last year. So till the final result of accepted 
>>>>> student you can start working with PWM driver that plays an important 
>>>>> role for any embedded project. This would be a good kick-start for you as 
>>>>> well as a strong reason to showcase in your proposal. Try to give 
>>>>> hardware test and post the video if possible.
>>>>>
>>>>> Coming to further I2C and SPI can be next milestones. To me these should 
>>>>> be at the highest priorities. I had done I2C driver but was not able to 
>>>>> make the hardware test. So you can also refer that and come up with the 
>>>>> output along with best modifications.
>>>>>
>>>>> Next target you can set for SPI after both drivers are tested and 
>>>>> committed.
>>>>>
>>>>> For the references you can always have a loot at code of GPIO 
>>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>>
>>>>> Any suggestions ?
>>>>>
>>>>> In case of any queries you can always ping.
>>>>>
>>>>> Cheers,
>>>>> Ketul
>>>>>
>>>>> On 5 March 2016 at 01:02, Marcos Díaz 
>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>
>>>>>> We use I2c but using drivers from TI's baremetal drivers they provide in 
>>>>>> their StarterWare software suite.
>>>>>> So, currently we cannot commit that into RTEMS.
>>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>>
>>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes I have checked previous year work of ketul . He has done ADC and 
>>>>>>>>>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have 
>>>>>>>>>> checked rtems.git and I am not sure about I2C .I asked last year 
>>>>>>>>>> student Ketul .According to him , I2c is also need to be modified. I 
>>>>>>>>>> tried to contact Ben but he is unreachable on mailing list :-(
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Let me reach out to Ketul and see if a private ping helps.
>>>>>>>>>
>>>>>>>>> Start with the assumption that USB needs work. That involves the 
>>>>>>>>> rtems-libbsd tree and
>>>>>>>>> there is likely code to import from FreeBSD that will help a lot.
>>>>>>>>>
>>>>>>>>> SPI and i2c are close to one another in my understanding. Likely 
>>>>>>>>> Ketul is referring to changes
>>>>>>>>> in the RTEMS i2c interfaces.
>>>>>>>>>
>>>>>>>>> My recollection is that the NIC had performance issues based on the 
>>>>>>>>> version of U-Boot
>>>>>>>>> used. There was some traffic at the end of GSoC about this. I don'

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Mon, Mar 14, 2016 at 7:07 PM, punit vara <punitv...@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>>
>>
>>
>> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> wrote:
>>>>
>>>> Hello Punit and all,
>>>>
>>>> According to me, Punit you must have completed some gpio test through gpio 
>>>> API that was merged last year. So till the final result of accepted 
>>>> student you can start working with PWM driver that plays an important role 
>>>> for any embedded project. This would be a good kick-start for you as well 
>>>> as a strong reason to showcase in your proposal. Try to give hardware test 
>>>> and post the video if possible.
>>>>
>>>> Coming to further I2C and SPI can be next milestones. To me these should 
>>>> be at the highest priorities. I had done I2C driver but was not able to 
>>>> make the hardware test. So you can also refer that and come up with the 
>>>> output along with best modifications.
>>>>
>>>> Next target you can set for SPI after both drivers are tested and 
>>>> committed.
>>>>
>>>> For the references you can always have a loot at code of GPIO 
>>>> API,MINIX,FreeBSD for BBB drivers.
>>>>
>>>> Any suggestions ?
>>>>
>>>> In case of any queries you can always ping.
>>>>
>>>> Cheers,
>>>> Ketul
>>>>
>>>> On 5 March 2016 at 01:02, Marcos Díaz <marcos.d...@tallertechnologies.com> 
>>>> wrote:
>>>>>
>>>>> We use I2c but using drivers from TI's baremetal drivers they provide in 
>>>>> their StarterWare software suite.
>>>>> So, currently we cannot commit that into RTEMS.
>>>>> But those drivers should be very useful to port to RTEMS.
>>>>>
>>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Yes I have checked previous year work of ketul . He has done ADC and 
>>>>>>>>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have 
>>>>>>>>> checked rtems.git and I am not sure about I2C .I asked last year 
>>>>>>>>> student Ketul .According to him , I2c is also need to be modified. I 
>>>>>>>>> tried to contact Ben but he is unreachable on mailing list :-(
>>>>>>>>>
>>>>>>>>
>>>>>>>> Let me reach out to Ketul and see if a private ping helps.
>>>>>>>>
>>>>>>>> Start with the assumption that USB needs work. That involves the 
>>>>>>>> rtems-libbsd tree and
>>>>>>>> there is likely code to import from FreeBSD that will help a lot.
>>>>>>>>
>>>>>>>> SPI and i2c are close to one another in my understanding. Likely Ketul 
>>>>>>>> is referring to changes
>>>>>>>> in the RTEMS i2c interfaces.
>>>>>>>>
>>>>>>>> My recollection is that the NIC had performance issues based on the 
>>>>>>>> version of U-Boot
>>>>>>>> used. There was some traffic at the end of GSoC about this. I don't 
>>>>>>>> know if it was
>>>>>>>> ever resolved.  But the NIC should work. Maybe worth benchmarking.
>>>>>>>
>>>>>>> We had more of these problems when trying to use I2C. It was fixed in
>>>>>>> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764.
>>>>>>>  I think we

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Wed, Mar 9, 2016 at 1:38 AM, punit vara <punitv...@gmail.com> wrote:
>
>
>
> On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:
>>
>>
>>
>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> wrote:
>>>
>>> Hello Punit and all,
>>>
>>> According to me, Punit you must have completed some gpio test through gpio 
>>> API that was merged last year. So till the final result of accepted student 
>>> you can start working with PWM driver that plays an important role for any 
>>> embedded project. This would be a good kick-start for you as well as a 
>>> strong reason to showcase in your proposal. Try to give hardware test and 
>>> post the video if possible.
>>>
>>> Coming to further I2C and SPI can be next milestones. To me these should be 
>>> at the highest priorities. I had done I2C driver but was not able to make 
>>> the hardware test. So you can also refer that and come up with the output 
>>> along with best modifications.
>>>
>>> Next target you can set for SPI after both drivers are tested and committed.
>>>
>>> For the references you can always have a loot at code of GPIO 
>>> API,MINIX,FreeBSD for BBB drivers.
>>>
>>> Any suggestions ?
>>>
>>> In case of any queries you can always ping.
>>>
>>> Cheers,
>>> Ketul
>>>
>>> On 5 March 2016 at 01:02, Marcos Díaz <marcos.d...@tallertechnologies.com> 
>>> wrote:
>>>>
>>>> We use I2c but using drivers from TI's baremetal drivers they provide in 
>>>> their StarterWare software suite.
>>>> So, currently we cannot commit that into RTEMS.
>>>> But those drivers should be very useful to port to RTEMS.
>>>>
>>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz 
>>>>> <marcos.d...@tallertechnologies.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Yes I have checked previous year work of ketul . He has done ADC and 
>>>>>>>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked 
>>>>>>>> rtems.git and I am not sure about I2C .I asked last year student Ketul 
>>>>>>>> .According to him , I2c is also need to be modified. I tried to 
>>>>>>>> contact Ben but he is unreachable on mailing list :-(
>>>>>>>>
>>>>>>>
>>>>>>> Let me reach out to Ketul and see if a private ping helps.
>>>>>>>
>>>>>>> Start with the assumption that USB needs work. That involves the 
>>>>>>> rtems-libbsd tree and
>>>>>>> there is likely code to import from FreeBSD that will help a lot.
>>>>>>>
>>>>>>> SPI and i2c are close to one another in my understanding. Likely Ketul 
>>>>>>> is referring to changes
>>>>>>> in the RTEMS i2c interfaces.
>>>>>>>
>>>>>>> My recollection is that the NIC had performance issues based on the 
>>>>>>> version of U-Boot
>>>>>>> used. There was some traffic at the end of GSoC about this. I don't 
>>>>>>> know if it was
>>>>>>> ever resolved.  But the NIC should work. Maybe worth benchmarking.
>>>>>>
>>>>>> We had more of these problems when trying to use I2C. It was fixed in
>>>>>> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764.
>>>>>>  I think we dont need tos ee these problems any more
>>>>>>>
>>>>>>>
>>>>>
>>>>> Marcos.. does this mean that the BBB i2c is complete now?
>>>>>
>>>>> And is my understanding that this covers SPI correct?
>>>>>
>>>>> What else on the BBB is left?
>>>>>
>>>>> --joel
>

Re: Regarding GSOC 2016 BBB Mentor

[punit vara]

On Fri, Mar 11, 2016 at 11:52 AM, Jarielle Catbagan <
jariellecatba...@gmail.com> wrote:

> Hello Punit,
>
> I was working on porting the MicroMonitor (uMon) bootloader to the BBB
> last year's GSoC 2015.  There is actually still some work that needs to be
> done.  At the moment, Ethernet functionality and booting application images
> still need to be implemented to get it to the point of making it a usable
> bootloader for the BBB.  If you're interested in pursuing this as a
> project, feel free to drop on by at umon-de...@rtems.org if you have any
> questions.
>
> Best,
> Jarielle
>
> On Thu, Mar 10, 2016 at 8:43 PM, punit vara <punitv...@gmail.com> wrote:
>
>> Hi,
>>
>> I am ready with RTEMS hello world on Beagle bone black (
>> https://www.youtube.com/watch?v=FyOHU02bsvw=6=PL2muodf7ZnYcS18wkilESuJpZGj4mYSMJ)
>> and interested to improve BBB BSP . Currently I am testing GPIO and will
>> work on PWM driver for showcasing on my proposal. But I am afraid that I
>> have not listened anything from Ben Gras. Is some else will mentor me  ? If
>> not then should I stick with my BBB idea or go for another RTEMS project
>> for which some one can mentor me ? I have already asked this question
>> before but I am little worried that is why I created new thread. Any
>> suggestions will be appreciated.
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
> Thank you Jarielle. I have idea too but I will look into your idea. But I
am worried about mentor .Usually Ben Gras mentor for BBB but this time I
don't know that's why I would like to know who can mentor me. If nobody is
going to mentor BBB this time then my proposal might be rejected :-(
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Regarding GSOC 2016 BBB Mentor

[punit vara]

Hi,

I am ready with RTEMS hello world on Beagle bone black (
https://www.youtube.com/watch?v=FyOHU02bsvw=6=PL2muodf7ZnYcS18wkilESuJpZGj4mYSMJ)
and interested to improve BBB BSP . Currently I am testing GPIO and will
work on PWM driver for showcasing on my proposal. But I am afraid that I
have not listened anything from Ben Gras. Is some else will mentor me  ? If
not then should I stick with my BBB idea or go for another RTEMS project
for which some one can mentor me ? I have already asked this question
before but I am little worried that is why I created new thread. Any
suggestions will be appreciated.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Sun, Mar 6, 2016 at 8:54 PM, punit vara <punitv...@gmail.com> wrote:

>
>
> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com>
> wrote:
>
>> Hello Punit and all,
>>
>> According to me, Punit you must have completed some gpio test through
>> gpio API that was merged last year. So till the final result of accepted
>> student you can start working with PWM driver that plays an important role
>> for any embedded project. This would be a good kick-start for you as well
>> as a strong reason to showcase in your proposal. Try to give hardware test
>> and post the video if possible.
>>
>> Coming to further I2C and SPI can be next milestones. To me these should
>> be at the highest priorities. I had done I2C driver but was not able to
>> make the hardware test. So you can also refer that and come up with the
>> output along with best modifications.
>>
>> Next target you can set for SPI after both drivers are tested and
>> committed.
>>
>> For the references you can always have a loot at code of GPIO
>> API,MINIX,FreeBSD for BBB drivers.
>>
>> Any suggestions ?
>>
>> In case of any queries you can always ping.
>>
>> Cheers,
>> Ketul
>>
>> On 5 March 2016 at 01:02, Marcos Díaz <marcos.d...@tallertechnologies.com
>> > wrote:
>>
>>> We use I2c but using drivers from TI's baremetal drivers they provide in
>>> their StarterWare software suite.
>>> So, currently we cannot commit that into RTEMS.
>>> But those drivers should be very useful to port to RTEMS.
>>>
>>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz <
>>>> marcos.d...@tallertechnologies.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Yes I have checked previous year work of ketul . He has done ADC and
>>>>>>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked
>>>>>>> rtems.git and I am not sure about I2C .I asked last year student Ketul
>>>>>>> .According to him , I2c is also need to be modified. I tried to contact 
>>>>>>> Ben
>>>>>>> but he is unreachable on mailing list :-(
>>>>>>>
>>>>>>>
>>>>>> Let me reach out to Ketul and see if a private ping helps.
>>>>>>
>>>>>> Start with the assumption that USB needs work. That involves the
>>>>>> rtems-libbsd tree and
>>>>>> there is likely code to import from FreeBSD that will help a lot.
>>>>>>
>>>>>> SPI and i2c are close to one another in my understanding. Likely
>>>>>> Ketul is referring to changes
>>>>>> in the RTEMS i2c interfaces.
>>>>>>
>>>>>> My recollection is that the NIC had performance issues based on the
>>>>>> version of U-Boot
>>>>>> used. There was some traffic at the end of GSoC about this. I don't
>>>>>> know if it was
>>>>>> ever resolved.  But the NIC should work. Maybe worth benchmarking.
>>>>>>
>>>>> We had more of these problems when trying to use I2C. It was fixed in
>>>>>
>>>>> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764.
>>>>> I think we dont need tos ee these problems any more
>>>>>
>>>>>>
>>>>>>
>>>> Marcos.. does this mean that the BBB i2c is complete now?
>>>>
>>>> And is my understanding that this covers SPI correct?
>>>>
>>>> What else on the BBB is left?
>>>>
>>>> --joel
>>>>
>>>>
>>>>> --joel
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill <j...@rtems.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary 

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah <ketulshah1...@gmail.com> wrote:

> Hello Punit and all,
>
> According to me, Punit you must have completed some gpio test through gpio
> API that was merged last year. So till the final result of accepted student
> you can start working with PWM driver that plays an important role for any
> embedded project. This would be a good kick-start for you as well as a
> strong reason to showcase in your proposal. Try to give hardware test and
> post the video if possible.
>
> Coming to further I2C and SPI can be next milestones. To me these should
> be at the highest priorities. I had done I2C driver but was not able to
> make the hardware test. So you can also refer that and come up with the
> output along with best modifications.
>
> Next target you can set for SPI after both drivers are tested and
> committed.
>
> For the references you can always have a loot at code of GPIO
> API,MINIX,FreeBSD for BBB drivers.
>
> Any suggestions ?
>
> In case of any queries you can always ping.
>
> Cheers,
> Ketul
>
> On 5 March 2016 at 01:02, Marcos Díaz <marcos.d...@tallertechnologies.com>
> wrote:
>
>> We use I2c but using drivers from TI's baremetal drivers they provide in
>> their StarterWare software suite.
>> So, currently we cannot commit that into RTEMS.
>> But those drivers should be very useful to port to RTEMS.
>>
>> On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill <j...@rtems.org> wrote:
>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz <
>>> marcos.d...@tallertechnologies.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Yes I have checked previous year work of ketul . He has done ADC and
>>>>>> GPIO BSP . It seems SPI,USB BSP need to be developed as I have checked
>>>>>> rtems.git and I am not sure about I2C .I asked last year student Ketul
>>>>>> .According to him , I2c is also need to be modified. I tried to contact 
>>>>>> Ben
>>>>>> but he is unreachable on mailing list :-(
>>>>>>
>>>>>>
>>>>> Let me reach out to Ketul and see if a private ping helps.
>>>>>
>>>>> Start with the assumption that USB needs work. That involves the
>>>>> rtems-libbsd tree and
>>>>> there is likely code to import from FreeBSD that will help a lot.
>>>>>
>>>>> SPI and i2c are close to one another in my understanding. Likely Ketul
>>>>> is referring to changes
>>>>> in the RTEMS i2c interfaces.
>>>>>
>>>>> My recollection is that the NIC had performance issues based on the
>>>>> version of U-Boot
>>>>> used. There was some traffic at the end of GSoC about this. I don't
>>>>> know if it was
>>>>> ever resolved.  But the NIC should work. Maybe worth benchmarking.
>>>>>
>>>> We had more of these problems when trying to use I2C. It was fixed in
>>>>
>>>> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764.
>>>> I think we dont need tos ee these problems any more
>>>>
>>>>>
>>>>>
>>> Marcos.. does this mean that the BBB i2c is complete now?
>>>
>>> And is my understanding that this covers SPI correct?
>>>
>>> What else on the BBB is left?
>>>
>>> --joel
>>>
>>>
>>>> --joel
>>>>>
>>>>>
>>>>> On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill <j...@rtems.org> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary <
>>>>>>> heshamelmat...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Punit,
>>>>>>>>
>>>>>>>> You can have a look at the open projects here [1] and find one or
>>>>>>>> more
>>>>>>>> that match your experience/interests.
>>>>>>>>
>>>>>>>> [1] https://devel.rtems.org/wiki/Develo

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

On Thu, Mar 3, 2016 at 1:26 AM, Joel Sherrill <j...@rtems.org> wrote:

>
>
> On Wed, Mar 2, 2016 at 1:41 PM, punit vara <punitv...@gmail.com> wrote:
>
>> Yes I have checked previous year work of ketul . He has done ADC and GPIO
>> BSP . It seems SPI,USB BSP need to be developed as I have checked rtems.git
>> and I am not sure about I2C .I asked last year student Ketul .According to
>> him , I2c is also need to be modified. I tried to contact Ben but he is
>> unreachable on mailing list :-(
>>
>>
> Let me reach out to Ketul and see if a private ping helps.
>
> Start with the assumption that USB needs work. That involves the
> rtems-libbsd tree and
> there is likely code to import from FreeBSD that will help a lot.
>
> SPI and i2c are close to one another in my understanding. Likely Ketul is
> referring to changes
> in the RTEMS i2c interfaces.
>
> My recollection is that the NIC had performance issues based on the
> version of U-Boot
> used. There was some traffic at the end of GSoC about this. I don't know
> if it was
> ever resolved.  But the NIC should work. Maybe worth benchmarking.
>
> --joel
>
>
> On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill <j...@rtems.org> wrote:
>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary <
>>> heshamelmat...@gmail.com> wrote:
>>>
>>>> Hi Punit,
>>>>
>>>> You can have a look at the open projects here [1] and find one or more
>>>> that match your experience/interests.
>>>>
>>>> [1] https://devel.rtems.org/wiki/Developer/OpenProjects
>>>>
>>>>
>>> I have added Ben Gras. He knows more about the BBB than anyone. I am
>>> unsure what is left
>>> to do. Have you compared the status of last year's projects versus the
>>> git repository?
>>>
>>> --joel
>>>
>>>
>>>> Regards,
>>>>
>>>> On Wed, Mar 2, 2016 at 7:14 PM, punit vara <punitv...@gmail.com> wrote:
>>>> >  I have asked for BBB BSP proposal before but I haven't found any good
>>>> > response from someone. What are the projects you are going to mentor
>>>> @joel ?
>>>> > Would anyone please suggest me to pick any other project ?
>>>> >
>>>> > ___
>>>> > devel mailing list
>>>> > devel@rtems.org
>>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>>
>>>>
>>>> --
>>>> Hesham
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>
> Thank you . Please let me know about Usb if you get some information. I
will also look into NIC benchmarking.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Gsoc 2016 project proposal

[punit vara]

I am interested in following projects apart from BBB BSP :

1. Improve Posix compliance
2.  TCP/IP stack update (Please suggest me more readings for this)

What are the prerequisites I need to do to improve my chances ? please let
me know.

On Thu, Mar 3, 2016 at 12:54 AM, Hesham Almatary <heshamelmat...@gmail.com>
wrote:

> Hi Punit,
>
> You can have a look at the open projects here [1] and find one or more
> that match your experience/interests.
>
> [1] https://devel.rtems.org/wiki/Developer/OpenProjects
>
> Regards,
>
> On Wed, Mar 2, 2016 at 7:14 PM, punit vara <punitv...@gmail.com> wrote:
> >  I have asked for BBB BSP proposal before but I haven't found any good
> > response from someone. What are the projects you are going to mentor
> @joel ?
> > Would anyone please suggest me to pick any other project ?
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> --
> Hesham
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal

[punit vara]

Yes I have checked previous year work of ketul . He has done ADC and GPIO
BSP . It seems SPI,USB BSP need to be developed as I have checked rtems.git
and I am not sure about I2C .I asked last year student Ketul .According to
him , I2c is also need to be modified. I tried to contact Ben but he is
unreachable on mailing list :-(

On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill <j...@rtems.org> wrote:

>
>
> On Wed, Mar 2, 2016 at 1:24 PM, Hesham Almatary <heshamelmat...@gmail.com>
> wrote:
>
>> Hi Punit,
>>
>> You can have a look at the open projects here [1] and find one or more
>> that match your experience/interests.
>>
>> [1] https://devel.rtems.org/wiki/Developer/OpenProjects
>>
>>
> I have added Ben Gras. He knows more about the BBB than anyone. I am
> unsure what is left
> to do. Have you compared the status of last year's projects versus the git
> repository?
>
> --joel
>
>
>> Regards,
>>
>> On Wed, Mar 2, 2016 at 7:14 PM, punit vara <punitv...@gmail.com> wrote:
>> >  I have asked for BBB BSP proposal before but I haven't found any good
>> > response from someone. What are the projects you are going to mentor
>> @joel ?
>> > Would anyone please suggest me to pick any other project ?
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Hesham
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Gsoc 2016 project proposal

[punit vara]

 I have asked for BBB BSP proposal before but I haven't found any good
response from someone. What are the projects you are going to mentor @joel
? Would anyone please suggest me to pick any other project ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding GSOC 2016 BSP for BBB

[punit vara]

On Fri, Feb 19, 2016 at 11:47 PM, Martin Galvan
 wrote:
> CAN, USB and I2C still need to be developed. We're currently using the AM335x
> StarterWare code and it works fine; you may want to base your work on it.
> Keep an eye open for licensing issues, though.
Thank you Martin. I started looking previous year work of BBB as well
as Rpi work for I2c and SPI . May I know whether are you going to
mentor for beagle bone black bsp this year ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] arm: Fixed typo in file bbb-gpio.c

[punit vara]

Your welcome Joel :-)

On Sat, Feb 20, 2016 at 3:44 AM, Joel Sherrill <j...@rtems.org> wrote:
> This should be committed now. Thanks.
>
> On Fri, Feb 19, 2016 at 12:24 PM, punitvara <punitv...@gmail.com> wrote:
>>
>> This patch fixes typo "moode".
>>
>> Signed-off: Punit Vara <punitv...@gmail.com>
>> ---
>>  c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> index 2a3f7e8..8532f54 100644
>> --- a/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> +++ b/c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c
>> @@ -269,7 +269,7 @@ rtems_status_code rtems_gpio_bsp_set_resistor_mode(
>>uint32_t pin,
>>rtems_gpio_pull_mode mode
>>  ) {
>> -  /* TODO: Add support for setting up resistor moode */
>> +  /* TODO: Add support for setting up resistor mode */
>>return RTEMS_NOT_DEFINED;
>>  }
>>
>> --
>> 1.9.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding GSOC 2016 BSP for BBB

[punit vara]

On Thu, Feb 18, 2016 at 12:09 PM, punit vara <punitv...@gmail.com> wrote:
> According to final report
> https://devel.rtems.org/wiki/GSoC/2015/Final_Report , Ketul shah's
> work can be extended to develop PWM driver and it seems i2c driver is
> not yet done correctly or have some problem. What would you suggest me
> to do further ?
>
> On Tue, Feb 16, 2016 at 1:13 PM, punit vara <punitv...@gmail.com> wrote:
>> On Mon, Feb 15, 2016 at 9:46 PM, Joel Sherrill <j...@rtems.org> wrote:
>>>
>>>
>>> On Mon, Feb 15, 2016 at 7:31 AM, punit vara <punitv...@gmail.com> wrote:
>>>>
>>>> I am in my final year of Master of embedded system course. Last year
>>>> only I came to know about GSOC .I came to know about amazing rtos
>>>> rtems while searching for embedded system projects. I was bit late to
>>>> proceed proposal last year as I was not aware that much.This could be
>>>> my last chance to get selected for GSOC 2016. I am interested for
>>>> developing BSP for BBB as I have beaglebone black. I have read some of
>>>> peripheral need support.   Could I take this project this year ? If
>>>> yes , any suggestions for improving my chance to get selected this
>>>> year are welcome.
>>>>
>>>
>>> I wasn't the mentor for the BB and Pi tasks last year although I tracked
>>> and helped answer questions.
>>>
>>> The BBB has a BSP with a number of the peripherals completed. I think you
>>> need to review the current BSP to see what is missing. Looking at the status
>>> reports from the projects last year will also help.
>>>
>>> I am honestly unsure of what remains.
>>>
>>> --joel
>>>
>>>>
>>>> Regards,
>>>> Punit Vara
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>> Last year Ketul has done BSP for BBB who is good friend of mine. He
>> has done BSP for GPIO and ADC. He told me apart from this most of
>> peripheral need support and also suggested me to ask Ben about this.
>> @Ben Can you please suggest me what further BSP idea I can take for
>> GSOC 2016 ? .Also please suggest me some reading so I can improve my
>> chances this time to get accepted in gsoc 2016. Yet I am going through
>> RTEMS docs provided on official site.But you may particular point me
>> out.
I have checked c/src/lib/libbsp/arm/beagle/ ...It seems SPI , USB is
yet to be developed.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding GSOC 2016 BSP for BBB

[punit vara]

According to final report
https://devel.rtems.org/wiki/GSoC/2015/Final_Report , Ketul shah's
work can be extended to develop PWM driver and it seems i2c driver is
not yet done correctly or have some problem. What would you suggest me
to do further ?

On Tue, Feb 16, 2016 at 1:13 PM, punit vara <punitv...@gmail.com> wrote:
> On Mon, Feb 15, 2016 at 9:46 PM, Joel Sherrill <j...@rtems.org> wrote:
>>
>>
>> On Mon, Feb 15, 2016 at 7:31 AM, punit vara <punitv...@gmail.com> wrote:
>>>
>>> I am in my final year of Master of embedded system course. Last year
>>> only I came to know about GSOC .I came to know about amazing rtos
>>> rtems while searching for embedded system projects. I was bit late to
>>> proceed proposal last year as I was not aware that much.This could be
>>> my last chance to get selected for GSOC 2016. I am interested for
>>> developing BSP for BBB as I have beaglebone black. I have read some of
>>> peripheral need support.   Could I take this project this year ? If
>>> yes , any suggestions for improving my chance to get selected this
>>> year are welcome.
>>>
>>
>> I wasn't the mentor for the BB and Pi tasks last year although I tracked
>> and helped answer questions.
>>
>> The BBB has a BSP with a number of the peripherals completed. I think you
>> need to review the current BSP to see what is missing. Looking at the status
>> reports from the projects last year will also help.
>>
>> I am honestly unsure of what remains.
>>
>> --joel
>>
>>>
>>> Regards,
>>> Punit Vara
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
> Last year Ketul has done BSP for BBB who is good friend of mine. He
> has done BSP for GPIO and ADC. He told me apart from this most of
> peripheral need support and also suggested me to ask Ben about this.
> @Ben Can you please suggest me what further BSP idea I can take for
> GSOC 2016 ? .Also please suggest me some reading so I can improve my
> chances this time to get accepted in gsoc 2016. Yet I am going through
> RTEMS docs provided on official site.But you may particular point me
> out.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Regarding GSOC 2016 BSP for BBB

[punit vara]

On Mon, Feb 15, 2016 at 9:46 PM, Joel Sherrill <j...@rtems.org> wrote:
>
>
> On Mon, Feb 15, 2016 at 7:31 AM, punit vara <punitv...@gmail.com> wrote:
>>
>> I am in my final year of Master of embedded system course. Last year
>> only I came to know about GSOC .I came to know about amazing rtos
>> rtems while searching for embedded system projects. I was bit late to
>> proceed proposal last year as I was not aware that much.This could be
>> my last chance to get selected for GSOC 2016. I am interested for
>> developing BSP for BBB as I have beaglebone black. I have read some of
>> peripheral need support.   Could I take this project this year ? If
>> yes , any suggestions for improving my chance to get selected this
>> year are welcome.
>>
>
> I wasn't the mentor for the BB and Pi tasks last year although I tracked
> and helped answer questions.
>
> The BBB has a BSP with a number of the peripherals completed. I think you
> need to review the current BSP to see what is missing. Looking at the status
> reports from the projects last year will also help.
>
> I am honestly unsure of what remains.
>
> --joel
>
>>
>> Regards,
>> Punit Vara
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
Last year Ketul has done BSP for BBB who is good friend of mine. He
has done BSP for GPIO and ADC. He told me apart from this most of
peripheral need support and also suggested me to ask Ben about this.
@Ben Can you please suggest me what further BSP idea I can take for
GSOC 2016 ? .Also please suggest me some reading so I can improve my
chances this time to get accepted in gsoc 2016. Yet I am going through
RTEMS docs provided on official site.But you may particular point me
out.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Warning: Subdir-objects is disabled

[punit vara]

On Mon, Feb 15, 2016 at 6:56 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> You should use the toolchain built with the source builder to do the
> bootstrapping
>
> On Mon, Feb 15, 2016 at 10:24 AM, Marcos Díaz <
> marcos.d...@tallertechnologies.com> wrote:
>
>> Check your automake and autoconf versions, I think they must be automake
>> 1.12.6 and autoconf 2.69 The bootstrapping should throw you no warnings
>>
>> On Mon, Feb 15, 2016 at 10:21 AM, punit vara <punitv...@gmail.com> wrote:
>>
>>> Today I was trying to bootstrap rtems. I have cloned repo.
>>>
>>> git clone git://git.rtems.org/rtems.git
>>>
>>> When I perform ./bootstrap It generates lots of warning
>>>
>>> Makefile.am:24: warning: source file 'start/start.S' is in a
>>> subdirectory,
>>> Makefile.am:24: but option 'subdir-objects' is disabled
>>>
>>> I have found solution that I should add
>>>
>>> AUTOMAKE_OPTIONS = subdir-objects
>>>
>>> at top of Makefile.am But still I am getting warnings. What could be
>>> the possible reason to stop this warnings. ? After that even I
>>> modified configure.ac
>>>
>>> AM_INIT_AUTOMAKE([subdir-objects])
>>>
>>> Any suggestions please?
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>>
>> __
>>
>> <http://www.tallertechnologies.com>
>>
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>>
>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype: markdiaz22
>>
>>
>
>
> --
>
> __
>
> <http://www.tallertechnologies.com>
>
>
> Marcos Díaz
>
> Software Engineer
>
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
>
> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype: markdiaz22
>
> Thanks. Done :-)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Warning: Subdir-objects is disabled

[punit vara]

Today I was trying to bootstrap rtems. I have cloned repo.

git clone git://git.rtems.org/rtems.git

When I perform ./bootstrap It generates lots of warning

Makefile.am:24: warning: source file 'start/start.S' is in a subdirectory,
Makefile.am:24: but option 'subdir-objects' is disabled

I have found solution that I should add

AUTOMAKE_OPTIONS = subdir-objects

at top of Makefile.am But still I am getting warnings. What could be
the possible reason to stop this warnings. ? After that even I
modified configure.ac

AM_INIT_AUTOMAKE([subdir-objects])

Any suggestions please?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Python problem

[punit vara]

On Sat, Feb 13, 2016 at 4:14 AM, Joel Sherrill <joel.sherr...@gmail.com> wrote:
> Jeff Mayes (here at OAR) has installed a fresh Ubuntu 15.10 to build the
> tools on. Normally it is quite simple and straightforward. I wanted to know
> if it was reproducible.
>
> I know on RPM distributions, you need to be careful when you mix 32 and 64
> bit packages. That is often a sign something is broken.
>
> --joel
>
> On Fri, Feb 12, 2016 at 4:22 PM, Jason Wong <jason.hcw...@gmail.com> wrote:
>>
>> Although I suspect that the reason you cannot install python2.7-dev is
>> that you have already installed python2.7-dev:i386 which is conflict with
>> python2.7-dev:amd64, you should show the error message when you are trying
>> to install python2.7-dev to make things clearer.
>>
>>
>> On 12 February 2016 at 22:38, punit vara <punitv...@gmail.com> wrote:
>>>
>>> On Fri, Feb 12, 2016 at 3:21 AM, Jason Wong <jason.hcw...@gmail.com>
>>> wrote:
>>> > I am using a docker image running Ubuntu 15.10, I have no problem
>>> > installing
>>> > both "python2.7-dev" and "libpython2.7-dev".
>>> > According to apt-cache, "python2.7-dev" depends on "python2.7".
>>> > If you install "python2.7-dev", then "python2.7" should be
>>> > automatically
>>> > installed.
>>> > Perhaps you should show us the message you got when you try to install
>>> > "python2.7-dev", and you should also report the problem to ubuntu
>>> > community
>>> > as well.
>>> >
>>> > root@c0e8f7d4cae3:/# apt-cache depends python2.7-dev
>>> > python2.7-dev
>>> >   Depends: python2.7
>>> >   Depends: libpython2.7-dev
>>> >   Depends: libpython2.7
>>> >   Depends: libexpat1-dev
>>> >  |Recommends: libc6-dev
>>> >   Recommends: 
>>> > libc6-dev
>>> >   Replaces: python2.7
>>> >
>>> >
>>> > On 11 February 2016 at 19:44, punit vara <punitv...@gmail.com> wrote:
>>> >>
>>> >> On Wed, Feb 10, 2016 at 11:45 PM, Joel Sherrill <j...@rtems.org>
>>> >> wrote:
>>> >> > We need the config.log from the subdirectory where the failure
>>> >> > occurred.
>>> >> > This looks like one from the top directory,
>>> >> >
>>> >> > Look at the build log to see what directory the build failed in and
>>> >> > grab
>>> >> > that one.
>>> >> >
>>> >> > FWIW a quick google for this issue on Ubuntu showed someone
>>> >> > suggested:
>>> >> >
>>> >> > sudo apt-get install python-dev
>>> >> >
>>> >> > Have you done that?
>>> >> >
>>> >> > --joel
>>> >> >
>>> >> > On Wed, Feb 10, 2016 at 11:50 AM, punit vara <punitv...@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> On Tue, Feb 9, 2016 at 8:21 PM, Joel Sherrill <j...@rtems.org>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> > On Tue, Feb 9, 2016 at 8:15 AM, punit vara <punitv...@gmail.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi <ad...@kodeit.net>
>>> >> >> >> wrote:
>>> >> >> >> > Hi,
>>> >> >> >> >
>>> >> >> >> > I was having the same problem yesterday and managed to find a
>>> >> >> >> > fix
>>> >> >> >> > by
>>> >> >> >> > installing libpython2.7-dev:
>>> >> >> >> >
>>> >> >> >> > sudo apt-get install libpython2.7-dev
>>> >> >> >> >
>>> >> >> >> > Aun-Ali Zaidi
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >> Thanks Aun-Ali. I have tried but again I am getting same error.
>>> >> >> >> Because this package would get installed when you install
>>> >> >> >> python2.7-dev
>>> >> >> >
>>> >> >> 

Re: Python problem

[punit vara]

On Fri, Feb 12, 2016 at 3:21 AM, Jason Wong <jason.hcw...@gmail.com> wrote:
> I am using a docker image running Ubuntu 15.10, I have no problem installing
> both "python2.7-dev" and "libpython2.7-dev".
> According to apt-cache, "python2.7-dev" depends on "python2.7".
> If you install "python2.7-dev", then "python2.7" should be automatically
> installed.
> Perhaps you should show us the message you got when you try to install
> "python2.7-dev", and you should also report the problem to ubuntu community
> as well.
>
> root@c0e8f7d4cae3:/# apt-cache depends python2.7-dev
> python2.7-dev
>   Depends: python2.7
>   Depends: libpython2.7-dev
>   Depends: libpython2.7
>   Depends: libexpat1-dev
>  |Recommends: libc6-dev
>   Recommends: 
> libc6-dev
>   Replaces: python2.7
>
>
> On 11 February 2016 at 19:44, punit vara <punitv...@gmail.com> wrote:
>>
>> On Wed, Feb 10, 2016 at 11:45 PM, Joel Sherrill <j...@rtems.org> wrote:
>> > We need the config.log from the subdirectory where the failure occurred.
>> > This looks like one from the top directory,
>> >
>> > Look at the build log to see what directory the build failed in and grab
>> > that one.
>> >
>> > FWIW a quick google for this issue on Ubuntu showed someone suggested:
>> >
>> > sudo apt-get install python-dev
>> >
>> > Have you done that?
>> >
>> > --joel
>> >
>> > On Wed, Feb 10, 2016 at 11:50 AM, punit vara <punitv...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Feb 9, 2016 at 8:21 PM, Joel Sherrill <j...@rtems.org> wrote:
>> >> >
>> >> >
>> >> > On Tue, Feb 9, 2016 at 8:15 AM, punit vara <punitv...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi <ad...@kodeit.net>
>> >> >> wrote:
>> >> >> > Hi,
>> >> >> >
>> >> >> > I was having the same problem yesterday and managed to find a fix
>> >> >> > by
>> >> >> > installing libpython2.7-dev:
>> >> >> >
>> >> >> > sudo apt-get install libpython2.7-dev
>> >> >> >
>> >> >> > Aun-Ali Zaidi
>> >> >> >
>> >> >>
>> >> >> Thanks Aun-Ali. I have tried but again I am getting same error.
>> >> >> Because this package would get installed when you install
>> >> >> python2.7-dev
>> >> >
>> >> >
>> >> > Can you look in the config.log for gdb where the failure occurred? Or
>> >> > even
>> >> > at the configure.in/ac script in its source. It is looking for a very
>> >> > specific
>> >> > file to link against and failing.
>> >> >
>> >> > yum have a "provides" subcommand to search for which package provides
>> >> > a specific file. Apt must have a similar capability.
>> >> >
>> >> > So you can figure out the file gdb needs to link and the
>> >> > corresponding
>> >> > package which includes it.
>> >> >
>> >> > --joel
>> >> >
>> >> >>
>> >> >> ___
>> >> >> devel mailing list
>> >> >> devel@rtems.org
>> >> >> http://lists.rtems.org/mailman/listinfo/devel
>> >> >
>> >> >
>> >>
>> >> Yes I agree with you Joel. From line 129 I found errors if you can
>> >> help me out. Perhaps somebody can help me I am attaching config.log
>> >> file from
>> >>
>> >>
>> >>
>> >> /home/punit/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.12-gdb-7.9-x86_64-linux-gnu-1/build
>> >
>> >
>> Yes I tried that before but same error.  I am attaching log file I
>> have sent config.log from failure subdirectory. I have provided
>> location in previous mail which is the same as shown in this log file.
>> If I am wrong let me.
>>
>> Thanks for support.
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
>
> --
> Regards,
> Jason Wong
root@punit-Compaq

Re: Python problem

[punit vara]

On Wed, Feb 10, 2016 at 11:45 PM, Joel Sherrill <j...@rtems.org> wrote:
> We need the config.log from the subdirectory where the failure occurred.
> This looks like one from the top directory,
>
> Look at the build log to see what directory the build failed in and grab
> that one.
>
> FWIW a quick google for this issue on Ubuntu showed someone suggested:
>
> sudo apt-get install python-dev
>
> Have you done that?
>
> --joel
>
> On Wed, Feb 10, 2016 at 11:50 AM, punit vara <punitv...@gmail.com> wrote:
>>
>> On Tue, Feb 9, 2016 at 8:21 PM, Joel Sherrill <j...@rtems.org> wrote:
>> >
>> >
>> > On Tue, Feb 9, 2016 at 8:15 AM, punit vara <punitv...@gmail.com> wrote:
>> >>
>> >> On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi <ad...@kodeit.net> wrote:
>> >> > Hi,
>> >> >
>> >> > I was having the same problem yesterday and managed to find a fix by
>> >> > installing libpython2.7-dev:
>> >> >
>> >> > sudo apt-get install libpython2.7-dev
>> >> >
>> >> > Aun-Ali Zaidi
>> >> >
>> >>
>> >> Thanks Aun-Ali. I have tried but again I am getting same error.
>> >> Because this package would get installed when you install
>> >> python2.7-dev
>> >
>> >
>> > Can you look in the config.log for gdb where the failure occurred? Or
>> > even
>> > at the configure.in/ac script in its source. It is looking for a very
>> > specific
>> > file to link against and failing.
>> >
>> > yum have a "provides" subcommand to search for which package provides
>> > a specific file. Apt must have a similar capability.
>> >
>> > So you can figure out the file gdb needs to link and the corresponding
>> > package which includes it.
>> >
>> > --joel
>> >
>> >>
>> >> ___
>> >> devel mailing list
>> >> devel@rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel
>> >
>> >
>>
>> Yes I agree with you Joel. From line 129 I found errors if you can
>> help me out. Perhaps somebody can help me I am attaching config.log
>> file from
>>
>>
>> /home/punit/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.12-gdb-7.9-x86_64-linux-gnu-1/build
>
>
Yes I tried that before but same error.  I am attaching log file I
have sent config.log from failure subdirectory. I have provided
location in previous mail which is the same as shown in this log file.
If I am wrong let me.

Thanks for support.
RTEMS Tools Project - Source Builder Error Report
 Build: error: building arm-rtems4.12-gdb-7.9-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder --log=l-arm.txt 
--prefix=/home/punit/development/rtems/4.12 4.12/rtems-arm
 Python: 2.7.10 (default, Aug  9 2015, 10:57:15) [GCC 4.9.2]
 
https://github.com/RTEMS/rtems-source-builder.git/origin/b87138ad01bac7e7c651585251118c28c9290b2e-modified
 Linux punit-Compaq-420 4.2.0-27-generic #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 
2016 x86_64
Tail of the build log:
checking whether getsubopt is declared without a macro... yes
checking whether grantpt is declared without a macro... yes
checking whether initstate is declared without a macro... yes
checking whether initstate_r is declared without a macro... yes
checking whether mkdtemp is declared without a macro... yes
checking whether mkostemp is declared without a macro... yes
checking whether mkostemps is declared without a macro... yes
checking whether mkstemp is declared without a macro... yes
checking whether mkstemps is declared without a macro... yes
checking whether posix_openpt is declared without a macro... yes
checking whether ptsname is declared without a macro... yes
checking whether ptsname_r is declared without a macro... yes
checking whether random is declared without a macro... yes
checking whether random_r is declared without a macro... yes
checking whether realpath is declared without a macro... yes
checking whether rpmatch is declared without a macro... yes
checking whether setenv is declared without a macro... yes
checking whether setstate is declared without a macro... yes
checking whether setstate_r is declared without a macro... yes
checking whether srandom is declared without a macro... yes
checking whether srandom_r is declared without a macro... yes
checking whether strtod is declared without a macro... yes
checking whether strtoll is declared without a macro... yes
checking whether strtoull is declared without a macro... yes
checking whether unlockpt is declared without a macro... yes
checking wh

Re: Python problem

[punit vara]

On Tue, Feb 9, 2016 at 8:21 PM, Joel Sherrill <j...@rtems.org> wrote:
>
>
> On Tue, Feb 9, 2016 at 8:15 AM, punit vara <punitv...@gmail.com> wrote:
>>
>> On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi <ad...@kodeit.net> wrote:
>> > Hi,
>> >
>> > I was having the same problem yesterday and managed to find a fix by
>> > installing libpython2.7-dev:
>> >
>> > sudo apt-get install libpython2.7-dev
>> >
>> > Aun-Ali Zaidi
>> >
>>
>> Thanks Aun-Ali. I have tried but again I am getting same error.
>> Because this package would get installed when you install
>> python2.7-dev
>
>
> Can you look in the config.log for gdb where the failure occurred? Or even
> at the configure.in/ac script in its source. It is looking for a very
> specific
> file to link against and failing.
>
> yum have a "provides" subcommand to search for which package provides
> a specific file. Apt must have a similar capability.
>
> So you can figure out the file gdb needs to link and the corresponding
> package which includes it.
>
> --joel
>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>

Yes I agree with you Joel. From line 129 I found errors if you can
help me out. Perhaps somebody can help me I am attaching config.log
file from

/home/punit/development/rtems/src/rtems-source-builder/rtems/build/arm-rtems4.12-gdb-7.9-x86_64-linux-gnu-1/build
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ../gdb-7.9/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-rtems4.12 --verbose --disable-nls --without-included-gettext --disable-win32-registry --disable-werror --enable-sim --without-zlib --with-expat --with-python --prefix=/home/punit/development/rtems/4.12 --bindir=/home/punit/development/rtems/4.12/bin --exec-prefix=/home/punit/development/rtems/4.12 --includedir=/home/punit/development/rtems/4.12/include --libdir=/home/punit/development/rtems/4.12/lib --mandir=/home/punit/development/rtems/4.12/share/man --infodir=/home/punit/development/rtems/4.12/share/info

## - ##
## Platform. ##
## - ##

hostname = punit-Compaq-420
uname -m = x86_64
uname -r = 4.2.0-27-generic
uname -s = Linux
uname -v = #32-Ubuntu SMP Fri Jan 22 04:49:08 UTC 2016

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/punit/development/rtems/src/rtems-source-builder/source-builder
PATH: /home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root-cxc/4.12/rtems-arm/home/punit/development/rtems/4.12/bin
PATH: /home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin


## --- ##
## Core tests. ##
## --- ##

configure:2326: checking build system type
configure:2340: result: x86_64-pc-linux-gnu
configure:2387: checking host system type
configure:2400: result: x86_64-pc-linux-gnu
configure:2420: checking target system type
configure:2433: result: arm-unknown-rtems4.12
configure:2487: checking for a BSD-compatible install
configure:2555: result: /usr/bin/install -c
configure:2566: checking whether ln works
configure:2588: result: yes
configure:2592: checking whether ln -s works
configure:2596: result: yes
configure:2603: checking for a sed that does not truncate output
configure:2667: result: /bin/sed
configure:2676: checking for gawk
configure:2692: found /usr/bin/gawk
configure:2703: result: gawk
configure:3945: checking for x86_64-linux-gnu-gcc
configure:3972: result: /usr/bin/gcc -O2 -pipe -I/home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/include
configure:4241: checking for C compiler version
configure:4250: /usr/bin/gcc -O2 -pipe -I/home/punit/development/rtems/src/rtems-source-builder/rtems/build/tmp/sb-root/4.12/rtems-arm/home/punit/development/rtems/4.12/include --version >&5
gcc (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:4261: $? = 0
configure:4250: /usr/bin/gcc -O2 -pipe -I/home/punit/develo

Re: Python problem

[punit vara]

On Tue, Feb 9, 2016 at 6:56 PM, Aun-Ali Zaidi  wrote:
> Hi,
>
> I was having the same problem yesterday and managed to find a fix by
> installing libpython2.7-dev:
>
> sudo apt-get install libpython2.7-dev
>
> Aun-Ali Zaidi
>

Thanks Aun-Ali. I have tried but again I am getting same error.
Because this package would get installed when you install
python2.7-dev
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Python problem

[punit vara]

I am facing python problem since long time. I updated my system to
ubuntu 15.10 from 15.04 as I was facing python problem but eventually
I ended up with the same problem I came across before.

Python -V shows python 2.7.10

But when Check error log it says

checking for python... /usr/local/bin/python
checking for python2.7... no
configure: error: python is missing or unusable
Makefile:8643: recipe for target 'configure-gdb' failed

When I try to do following

$ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev

In this I found out ubuntu is picking python2.7 instead of
python2.7-dev. It seems to me if anyhow I can force OS to pick
python2.7-dev then this problem can be solved But I don't know how to
do this.Can somebody please help regarding this? Any help would be
appreciated.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Dead Link

[punit vara]

In this link https://devel.rtems.org/wiki/TBR/UserManual/GeneralInformation

following link throws errors. Please remove or update it.

 Moodle-based eLeaning IRC channel site : http://www.rtems.org/moodle
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

ubuntu 15.04 build fail

[punit vara]

RTEMS Tools Project - Source Builder Error Report
 Build: error: building arm-rtems4.11-gdb-7.9-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder
--prefix=/home/punit/development/rtems/4.11 4.11/rtems-arm
 Python: 2.7.10 (default, Aug  9 2015, 10:57:15) [GCC 4.9.2]
 
https://github.com/RTEMS/rtems-source-builder.git/origin/eec82cd12621dbc6773a117e8de9ca0f1dc55043
 Linux punit-Compaq-420 3.19.0-33-generic #38-Ubuntu SMP Fri Nov 6
18:18:12 UTC 2015 x86_64
Tail of the build log:
checking whether getsubopt is declared without a macro... yes
checking whether grantpt is declared without a macro... yes
checking whether initstate is declared without a macro... yes
checking whether initstate_r is declared without a macro... yes
checking whether mkdtemp is declared without a macro... yes
checking whether mkostemp is declared without a macro... yes
checking whether mkostemps is declared without a macro... yes
checking whether mkstemp is declared without a macro... yes
checking whether mkstemps is declared without a macro... yes
checking whether posix_openpt is declared without a macro... yes
checking whether ptsname is declared without a macro... yes
checking whether ptsname_r is declared without a macro... yes
checking whether random is declared without a macro... yes
checking whether random_r is declared without a macro... yes
checking whether realpath is declared without a macro... yes
checking whether rpmatch is declared without a macro... yes
checking whether setenv is declared without a macro... yes
checking whether setstate is declared without a macro... yes
checking whether setstate_r is declared without a macro... yes
checking whether srandom is declared without a macro... yes
checking whether srandom_r is declared without a macro... yes
checking whether strtod is declared without a macro... yes
checking whether strtoll is declared without a macro... yes
checking whether strtoull is declared without a macro... yes
checking whether unlockpt is declared without a macro... yes
checking whether unsetenv is declared without a macro... yes
checking whether strstr works in linear time... yes
checking whether strstr works... (cached) yes
checking for nlink_t... yes
checking whether fchmodat is declared without a macro... yes
checking whether fstat is declared without a macro... yes
checking whether fstatat is declared without a macro... yes
checking whether futimens is declared without a macro... yes
checking whether lchmod is declared without a macro... yes
checking whether lstat is declared without a macro... yes
checking whether mkdirat is declared without a macro... yes
checking whether mkfifo is declared without a macro... yes
checking whether mkfifoat is declared without a macro... yes
checking whether mknod is declared without a macro... yes
checking whether mknodat is declared without a macro... yes
checking whether stat is declared without a macro... yes
checking whether utimensat is declared without a macro... yes
checking whether chdir is declared without a macro... yes
checking whether chown is declared without a macro... yes
checking whether dup is declared without a macro... yes
checking whether dup2 is declared without a macro... yes
checking whether dup3 is declared without a macro... yes
checking whether environ is declared without a macro... yes
checking whether euidaccess is declared without a macro... yes
checking whether faccessat is declared without a macro... yes
checking whether fchdir is declared without a macro... yes
checking whether fchownat is declared without a macro... yes
checking whether fdatasync is declared without a macro... yes
checking whether fsync is declared without a macro... yes
checking whether ftruncate is declared without a macro... yes
checking whether getcwd is declared without a macro... yes
checking whether getdomainname is declared without a macro... yes
checking whether getdtablesize is declared without a macro... yes
checking whether getgroups is declared without a macro... yes
checking whether gethostname is declared without a macro... yes
checking whether getlogin is declared without a macro... yes
checking whether getlogin_r is declared without a macro... yes
checking whether getpagesize is declared without a macro... yes
checking whether getusershell is declared without a macro... yes
checking whether setusershell is declared without a macro... yes
checking whether endusershell is declared without a macro... yes
checking whether group_member is declared without a macro... yes
checking whether isatty is declared without a macro... yes
checking whether lchown is declared without a macro... yes
checking whether link is declared without a macro... yes
checking whether linkat is declared without a macro... yes
checking whether lseek is declared without a macro... yes
checking whether pipe is declared without a macro... yes
checking whether pipe2 is declared without a macro... yes
checking whether pread is declared without a macro... yes
checking 

python dependencies Ubuntu 15.04

[punit vara]

sudo apt-get install python-all-dev

I have done this .Still python error.
Any help will be appreciated.
RTEMS Tools Project - Source Builder Error Report
 Build: error: building i386-rtems4.11-gdb-7.9-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder --log=l-i386.txt 
--prefix=/home/punit/developmentx/rtems/4.11 4.11/rtems-i386
 Python: 2.7.10 (default, Aug  9 2015, 10:57:15) [GCC 4.9.2]
 
https://github.com/punitvara/rtems-source-builder.git/origin/b65c131f2e11e352fde6efa0ec2fe5000dad3a4a-modified
 Linux punit-Compaq-420 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24 21:17:31 
UTC 2015 x86_64
Tail of the build log:
checking whether getsubopt is declared without a macro... yes
checking whether grantpt is declared without a macro... yes
checking whether initstate is declared without a macro... yes
checking whether initstate_r is declared without a macro... yes
checking whether mkdtemp is declared without a macro... yes
checking whether mkostemp is declared without a macro... yes
checking whether mkostemps is declared without a macro... yes
checking whether mkstemp is declared without a macro... yes
checking whether mkstemps is declared without a macro... yes
checking whether posix_openpt is declared without a macro... yes
checking whether ptsname is declared without a macro... yes
checking whether ptsname_r is declared without a macro... yes
checking whether random is declared without a macro... yes
checking whether random_r is declared without a macro... yes
checking whether realpath is declared without a macro... yes
checking whether rpmatch is declared without a macro... yes
checking whether setenv is declared without a macro... yes
checking whether setstate is declared without a macro... yes
checking whether setstate_r is declared without a macro... yes
checking whether srandom is declared without a macro... yes
checking whether srandom_r is declared without a macro... yes
checking whether strtod is declared without a macro... yes
checking whether strtoll is declared without a macro... yes
checking whether strtoull is declared without a macro... yes
checking whether unlockpt is declared without a macro... yes
checking whether unsetenv is declared without a macro... yes
checking whether strstr works in linear time... yes
checking whether strstr works... (cached) yes
checking for nlink_t... yes
checking whether fchmodat is declared without a macro... yes
checking whether fstat is declared without a macro... yes
checking whether fstatat is declared without a macro... yes
checking whether futimens is declared without a macro... yes
checking whether lchmod is declared without a macro... yes
checking whether lstat is declared without a macro... yes
checking whether mkdirat is declared without a macro... yes
checking whether mkfifo is declared without a macro... yes
checking whether mkfifoat is declared without a macro... yes
checking whether mknod is declared without a macro... yes
checking whether mknodat is declared without a macro... yes
checking whether stat is declared without a macro... yes
checking whether utimensat is declared without a macro... yes
checking whether chdir is declared without a macro... yes
checking whether chown is declared without a macro... yes
checking whether dup is declared without a macro... yes
checking whether dup2 is declared without a macro... yes
checking whether dup3 is declared without a macro... yes
checking whether environ is declared without a macro... yes
checking whether euidaccess is declared without a macro... yes
checking whether faccessat is declared without a macro... yes
checking whether fchdir is declared without a macro... yes
checking whether fchownat is declared without a macro... yes
checking whether fdatasync is declared without a macro... yes
checking whether fsync is declared without a macro... yes
checking whether ftruncate is declared without a macro... yes
checking whether getcwd is declared without a macro... yes
checking whether getdomainname is declared without a macro... yes
checking whether getdtablesize is declared without a macro... yes
checking whether getgroups is declared without a macro... yes
checking whether gethostname is declared without a macro... yes
checking whether getlogin is declared without a macro... yes
checking whether getlogin_r is declared without a macro... yes
checking whether getpagesize is declared without a macro... yes
checking whether getusershell is declared without a macro... yes
checking whether setusershell is declared without a macro... yes
checking whether endusershell is declared without a macro... yes
checking whether group_member is declared without a macro... yes
checking whether isatty is declared without a macro... yes
checking whether lchown is declared without a macro... yes
checking whether link is declared without a macro... yes
checking whether linkat is declared without a macro... yes
checking whether lseek is declared without a macro... yes
checking whether pipe is declared without 

[no subject]

[punit vara]

I am facing problem with python .I installed python but don't know why
still same problem .Can anybody tell me how to solve python
dependencies in Ubuntu 15.04 64 bit.
please find the attachment of error report.
RTEMS Tools Project - Source Builder Error Report
 Build: error: building i386-rtems4.11-gdb-7.9-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder --log=l-i386.txt 
--prefix=/root/development/rtems/4.11 4.11/rtems-i386
 Python: 2.7.10 (default, Aug  9 2015, 10:57:15) [GCC 4.9.2]
 RSB: not a valid repo
 Linux punit-Compaq-420 3.19.0-25-generic #26-Ubuntu SMP Fri Jul 24 21:17:31 
UTC 2015 x86_64
Tail of the build log:
checking whether getsubopt is declared without a macro... yes
checking whether grantpt is declared without a macro... yes
checking whether initstate is declared without a macro... yes
checking whether initstate_r is declared without a macro... yes
checking whether mkdtemp is declared without a macro... yes
checking whether mkostemp is declared without a macro... yes
checking whether mkostemps is declared without a macro... yes
checking whether mkstemp is declared without a macro... yes
checking whether mkstemps is declared without a macro... yes
checking whether posix_openpt is declared without a macro... yes
checking whether ptsname is declared without a macro... yes
checking whether ptsname_r is declared without a macro... yes
checking whether random is declared without a macro... yes
checking whether random_r is declared without a macro... yes
checking whether realpath is declared without a macro... yes
checking whether rpmatch is declared without a macro... yes
checking whether setenv is declared without a macro... yes
checking whether setstate is declared without a macro... yes
checking whether setstate_r is declared without a macro... yes
checking whether srandom is declared without a macro... yes
checking whether srandom_r is declared without a macro... yes
checking whether strtod is declared without a macro... yes
checking whether strtoll is declared without a macro... yes
checking whether strtoull is declared without a macro... yes
checking whether unlockpt is declared without a macro... yes
checking whether unsetenv is declared without a macro... yes
checking whether strstr works in linear time... yes
checking whether strstr works... (cached) yes
checking for nlink_t... yes
checking whether fchmodat is declared without a macro... yes
checking whether fstat is declared without a macro... yes
checking whether fstatat is declared without a macro... yes
checking whether futimens is declared without a macro... yes
checking whether lchmod is declared without a macro... yes
checking whether lstat is declared without a macro... yes
checking whether mkdirat is declared without a macro... yes
checking whether mkfifo is declared without a macro... yes
checking whether mkfifoat is declared without a macro... yes
checking whether mknod is declared without a macro... yes
checking whether mknodat is declared without a macro... yes
checking whether stat is declared without a macro... yes
checking whether utimensat is declared without a macro... yes
checking whether chdir is declared without a macro... yes
checking whether chown is declared without a macro... yes
checking whether dup is declared without a macro... yes
checking whether dup2 is declared without a macro... yes
checking whether dup3 is declared without a macro... yes
checking whether environ is declared without a macro... yes
checking whether euidaccess is declared without a macro... yes
checking whether faccessat is declared without a macro... yes
checking whether fchdir is declared without a macro... yes
checking whether fchownat is declared without a macro... yes
checking whether fdatasync is declared without a macro... yes
checking whether fsync is declared without a macro... yes
checking whether ftruncate is declared without a macro... yes
checking whether getcwd is declared without a macro... yes
checking whether getdomainname is declared without a macro... yes
checking whether getdtablesize is declared without a macro... yes
checking whether getgroups is declared without a macro... yes
checking whether gethostname is declared without a macro... yes
checking whether getlogin is declared without a macro... yes
checking whether getlogin_r is declared without a macro... yes
checking whether getpagesize is declared without a macro... yes
checking whether getusershell is declared without a macro... yes
checking whether setusershell is declared without a macro... yes
checking whether endusershell is declared without a macro... yes
checking whether group_member is declared without a macro... yes
checking whether isatty is declared without a macro... yes
checking whether lchown is declared without a macro... yes
checking whether link is declared without a macro... yes
checking whether linkat is declared without a macro... yes
checking whether lseek is declared without a macro... yes
checking whether pipe is 

create x86_64 BSP

[punit vara]

I have thought of creating BSP for x86_64 but unfortunately I was busy
in my exam and class hectic schedule.Shall I create or work on  BSP
for X86_64  ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel