from:"Ben Gras"

Re: GSOC student question

2017-05-26 Thread Ben Gras

Dear all,


On 05/22/2017 11:56 AM, Joel Sherrill wrote:
>
>
> On Mon, May 22, 2017 at 10:11 AM, Gedare Bloom  > wrote:
>
> I think the i2c was developed and tested only on the BeagleBone Black.
> I don't think anyone has used the xm yet, though I could be mistaken.
>
> Yes, I believe the old one should be replaced by the updated version.
>
>
> This is likely a stupid question. Do we have confidence that the new
> i2c works
> on all platforms that the old one did?

The previous i2c implementation in the beagle bsp never worked on
hardware, only to a limited degree in qemu; replacing it won't make
anything worse for anyone.

>
> --joel 
>
>
> On Mon, May 22, 2017 at 9:04 AM, Sichen Zhao
> > wrote:
> > Hi all,
> >
> > I am working on my GSOC project- Beaglebone BSP projects
> > There is a question, Is the code in beagle/misc/i2c.c for the
> beagle bone or
> > for the beagle xm or other processor?
> > I developed the i2c for Beaglebone Black(AM335X), So if i need
> remove the
> > old one i2c.c in misc when i send the patch?
> >
> > Best Regards
> > Sichen Zhao
>
>
>
>
> ___
> 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: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

2017-03-20 Thread Ben Gras

Dear all,

SZ, great initiative. Gedare and Sebastian have commented.

For my part, can I just check - the implementation is supposed to be
generic to i2c devices, correct?

If so, can you explain what read_eeprom is for? Is it just as demo? Is
the code generic otherwise?

Cheers,

Ben


On 03/14/2017 10:05 AM, Sichen Zhao wrote:
> ---
>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 
> --
>  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
>  cpukit/dev/i2c/eeprom.c   |  24 +-
>  testsuites/samples/i2c0/init.c|  98 -
>  4 files changed, 777 insertions(+), 47 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
> b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> index 6b790e5..6a22125 100644
> --- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> @@ -21,11 +21,23 @@
>  #include 
>  #include 
>  
> +#define u16 unsigned int
> +
> +static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
> +static void omap24_i2c_init(i2c_bus *base);
> +static void flush_fifo(i2c_bus *base);
> +static int wait_for_bb(i2c_bus *base);
> +static int omap24_i2c_probe(i2c_bus *base);
> +static u16 wait_for_event(i2c_bus *base);
> +static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, int 
> alen, unsigned char *buffer, 
> +   int len);
> +static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
> +static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint addr,int 
> alen, unsigned char *buffer, 
> +int len);
>  /*
>  static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  {
>bool status =true;
> -
>  // We will check i2c_bus_id in am335x_i2c_bus_register
>  // Apart from mode and pull_up register what about SCREWCTRL & RXACTIVE 
> ??
>if (bus->i2c_bus_id == I2C1) {
> @@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  /* ref. Table 21-4 I2C Clock Signals */
>  /* 
>   For I2C1/2
> -
>   Interface clock - 100MHz - CORE_LKOUTM4 / 2 - pd_per_l4ls_gclk
> -
>   Functional clock - 48MHz - PER_CLKOUTM2 / 4 - pd_per_ic2_fclk
>  */
>  
> @@ -74,7 +84,6 @@ state. Functional clocks are guarantied to stay present. As 
> long as in
>  this configuration, power domain sleep transition cannot happen.*/
>   /* REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) |=
>  AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE;
> -
>while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) &
>AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE) != 
> AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE);
>  */
> @@ -86,30 +95,29 @@ this configuration, power domain sleep transition cannot 
> happen.*/
>if (bus->i2c_bus_id == I2C1) {
>REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) |=
>   AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE;
> -
>while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) &
>   AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE) != 
> AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE);
>} else if (bus->i2c_bus_id == I2C2) {
>REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) |=
>   AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE;
> -
>while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) &
>   AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE) != 
> AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE);
> -
>while(!(REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
> (AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_L4LS_GCLK |
>  AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_I2C_FCLK)));
> -
>}
>  }
>  */
>  
>  static void am335x_i2c0_pinmux(bbb_i2c_bus *bus)
>  {
> -  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
> +  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
> AM335X_CONF_I2C0_SDA);
> +  printf("bus->regs:%x\n", bus->regs);
> + 
> +  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>  
> -  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
> +  REG(0x44e1 + AM335X_CONF_I2C0_SCL) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN); 
>  }
>  
> @@ -314,14 +322,29 @@ void am335x_i2c_init(bbb_i2c_bus *bus, uint32_t 
> input_clock)
>  static bool am335x_i2c_busbusy(volatile bbb_i2c_regs *regs)
>  {
>bool status;
> -
> -  if (REG(>BBB_I2C_IRQSTATUS_RAW) & AM335X_I2C_IRQSTATUS_RAW_BB)
> +  unsigned short stat;
> +  int timeout = I2C_TIMEOUT;
> +
> +  REG(>BBB_I2C_IRQSTATUS)=0x;
> +  
> printf("REG(>BBB_I2C_IRQSTATUS_RAW):%x\n",REG(>BBB_I2C_IRQSTATUS_RAW)
>  );
> + // printf("%x\n",0x1400 & 0x1000 );
> + printf("REG(>BBB_I2C_IRQSTATUS_RAW) & 
> AM335X_I2C_IRQSTATUS_RAW_BB:%x\n",(REG(>BBB_I2C_IRQSTATUS_RAW) & 
> AM335X_I2C_IRQSTATUS_RAW_BB));
> +while(stat =( REG(>BBB_I2C_IRQSTATUS_RAW) & 
> AM335X_I2C_IRQSTATUS_RAW_BB) && timeout--)
>{
> -status = true; 
> -  } else {
> -status = false;
> +
>

Re: Building toolset for Beaglebone with RSB fails (for me).

2017-02-10 Thread Ben Gras

All,

I see, yes. Noted. I will try to find time for this soon but it may be a
little while.

Ben


On 02/10/2017 03:24 PM, Joel Sherrill wrote:
> GCC does not keep snapshots forever. Ben's instructions and git repo
> must be behind the master at git.rtems.org .
> clone the repos from there, use the master, and I believe his
> instructions will work. 
>
> Ben.. if you see this, maybe it is time to.merge some of your
> instructions into the new Sphinx documentation in a section for BB users.
>
> --joel
>
> On Feb 10, 2017 2:04 PM, "Tanu Hari Dixit"  > wrote:
>
> Hello Devs,
>
> I wanted to build the toolset for Beaglebone following the blog
> 
> (http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
> 
> ).
> However, the build failed.
> I got the following message.
>
> download:
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> 
> -> sources/gcc-6-20160526.tar.bz2
> download:
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> :
> error:  No such file or directory>
> error: downloading
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> :
> all paths have failed, giving up
> Build FAILED
>   See error report:
> 
> rsb-report-arm-rtems4.12-gcc-6-20160526-newlib-2.4.0.20160527-x86_64-linux-gnu-1.txt
> error: downloading
> ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160526/gcc-6-20160526.tar.bz2
> :
> all paths have failed, giving up
> Build Set: Time 0:01:46.366099
> Build FAILED
>
> Probably, the link is broken.
>
> It is probably using
> 
> rtems-source-builder/rtems/config/tools/rtems-gcc-6-20160526-newlib-2.4.0.20160527-1.cfg
>
> which sets this url which ultimately is used by
> rtems-source-builder/source-builder/config/gcc-common-1.cfg .
> Please correct me if I am wrong.
>
> How do I fix this? Is there something I am missing?
>
> 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

___
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

2016-07-02 Thread Ben Gras

All,

On Fri, Jul 1, 2016 at 11:12 PM, Martin Galvan
 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.

I agree!

[..]

> +
> +/* Currently these definitions are for BeagleBone Black board only
> + * Later on Beagle-xM board support can be added in this code.
> + * After support gets added if condition should be removed
>
> If you're referring to IS_AM335X/IS_DM3730, from what I've seen there are 
> always two
> versions of the code, one for each SoC. So I don't think this #if will be 
> removed,
> even after support is added for DM3730. Maybe Ben/Ketul know a bit more about 
> this than
> I do, though.

You're right, depending on how different the hardware is. It could be
(I haven't checked) that the hardware works the same but the base
address is different, such as with the UARTs.
In that case we can re-use this code and the differences will be
smaller. So I think here
simply removing "After support gets added if condition should be
removed" should be OK, although I don't consider it blocking for
merging.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Beaglebone: Fix the IRQ handling code

2016-02-27 Thread Ben Gras

I'm doing a rebase & build right now, thanks for the reminder.

On Fri, Feb 26, 2016 at 10:32 PM, Martin Galvan
<martin.gal...@tallertechnologies.com> wrote:
> Hi Ben! Sorry to bother, were you able to test my changes to the BBB
> interrupt handler?
>
> On Fri, Feb 12, 2016 at 11:09 AM, Martin Galvan
> <martin.gal...@tallertechnologies.com> wrote:
>> Thanks Ben! Indeed, any further testing is more than welcome :)
>>
>> On Thu, Feb 11, 2016 at 7:55 PM, Ben Gras <b...@shrike-systems.com> wrote:
>>> This looks like great work. Please let me test it (I'll try the GPIO
>>> interrupt trigger) & I'll merge it as soon as I have time.
>>>
>>> Thank you!
>>>
>>> Cheers,
>>> Ben
>>>
>>>
>>> On Thu, Feb 11, 2016 at 3:27 PM, Martin Galvan
>>> <martin.gal...@tallertechnologies.com> wrote:
>>>> This patch makes the following changes to the Beaglebone IRQ handling code:
>>>>
>>>> - Disable support for nested interrupts.
>>>> - Detect spurious IRQs using the SPURIOUSIRQ field of the INTC_SIR_IRQ 
>>>> register.
>>>> - Acknowledge spurious IRQs by setting the NewIRQAgr bit of the 
>>>> INTC_CONTROL
>>>>   register. This cleans the SPURIOUSIRQ field and allows new interrupts
>>>>   to be generated.
>>>> - Improve the get_mir_reg function a bit.
>>>>
>>>> The Beaglebone bsp_interrupt_dispach function has been troublesome for a 
>>>> while now.
>>>> We've seen it break the GPIO API 
>>>> (https://lists.rtems.org/pipermail/devel/2015-November/012995.html),
>>>> the RTEMS interrupt server 
>>>> (https://lists.rtems.org/pipermail/devel/2015-July/011865.html),
>>>> and now we've been getting spurious interrupts when trying to use the I2C 
>>>> module.
>>>>
>>>> We've done a lot of testing and concluded that the cause of most of these 
>>>> issues
>>>> is the way nested interrupts are being handled. The AM335X manual states 
>>>> that
>>>> the interrupt handling sequence should be as follows:
>>>>
>>>> 1. Identify the IRQ source by reading the ActiveIRQ field of the 
>>>> INTC_SIR_IRQ
>>>>register.
>>>> 2. Jump to the corresponding IRQ handler, which should serve the IRQ and
>>>>deassert the interrupt condition at the peripheral side.
>>>> 3. Enable the processing of new IRQs at the Interrupt Controller side by 
>>>> setting
>>>>the NewIRQAgr bit of the INTC_CONTROL register.
>>>> 4. Finally, enable IRQs at the CPU side. This is done later in
>>>>_ARMV4_Exception_interrupt.
>>>>
>>>> Right now the Beaglebone bsp_interrupt_dispach enables IRQs at the INTC 
>>>> and CPU
>>>> before jumping to the interrupt handler to allow for nested IRQs.
>>>> Before doing so, it calls bsp_interrupt_disable to mask the IRQ source and 
>>>> avoid
>>>> having it constantly fire new IRQs. After it's done it re-enables the IRQ
>>>> by calling bsp_interrupt_enable. These calls break the GPIO API and the
>>>> RTEMS interrupt server machinery, and we suspect it's also causing the 
>>>> spurious
>>>> interrupts we saw with the I2C module.
>>>>
>>>> The correct way to enable interrupt nesting according to both the manual 
>>>> and
>>>> the AM335X StarterWare code is to allow only interrupts of a higher 
>>>> priority
>>>> to preempt the current one. This can be achieved by setting the 
>>>> INTC_THRESHOLD
>>>> register to the priority of the current IRQ. However, in our case this 
>>>> isn't
>>>> necessary since all the interrupt priorities are set to 0 (the highest 
>>>> possible)
>>>> in bsp_interrupt_facility_initialize. We may implement this in a future 
>>>> patch,
>>>> if required.
>>>>
>>>> We've tested this quite extensively on a number of different applications, 
>>>> and
>>>> it's working fine.
>>>>
>>>> Closes #2580.
>>>> ---
>>>>  c/src/lib/libbsp/arm/beagle/irq.c   | 82 
>>>> +++--
>>>>  c/src/lib/libcpu/arm/shared/include/omap3.h |  3 +-
>>>>  2 files changed, 44 insertions(+), 41 deletions(-)
>>>>
>>>> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
>>&

Re: [PATCH] Beaglebone: Fix the IRQ handling code

2016-02-11 Thread Ben Gras

This looks like great work. Please let me test it (I'll try the GPIO
interrupt trigger) & I'll merge it as soon as I have time.

Thank you!

Cheers,
Ben


On Thu, Feb 11, 2016 at 3:27 PM, Martin Galvan
 wrote:
> This patch makes the following changes to the Beaglebone IRQ handling code:
>
> - Disable support for nested interrupts.
> - Detect spurious IRQs using the SPURIOUSIRQ field of the INTC_SIR_IRQ 
> register.
> - Acknowledge spurious IRQs by setting the NewIRQAgr bit of the INTC_CONTROL
>   register. This cleans the SPURIOUSIRQ field and allows new interrupts
>   to be generated.
> - Improve the get_mir_reg function a bit.
>
> The Beaglebone bsp_interrupt_dispach function has been troublesome for a 
> while now.
> We've seen it break the GPIO API 
> (https://lists.rtems.org/pipermail/devel/2015-November/012995.html),
> the RTEMS interrupt server 
> (https://lists.rtems.org/pipermail/devel/2015-July/011865.html),
> and now we've been getting spurious interrupts when trying to use the I2C 
> module.
>
> We've done a lot of testing and concluded that the cause of most of these 
> issues
> is the way nested interrupts are being handled. The AM335X manual states that
> the interrupt handling sequence should be as follows:
>
> 1. Identify the IRQ source by reading the ActiveIRQ field of the INTC_SIR_IRQ
>register.
> 2. Jump to the corresponding IRQ handler, which should serve the IRQ and
>deassert the interrupt condition at the peripheral side.
> 3. Enable the processing of new IRQs at the Interrupt Controller side by 
> setting
>the NewIRQAgr bit of the INTC_CONTROL register.
> 4. Finally, enable IRQs at the CPU side. This is done later in
>_ARMV4_Exception_interrupt.
>
> Right now the Beaglebone bsp_interrupt_dispach enables IRQs at the INTC and 
> CPU
> before jumping to the interrupt handler to allow for nested IRQs.
> Before doing so, it calls bsp_interrupt_disable to mask the IRQ source and 
> avoid
> having it constantly fire new IRQs. After it's done it re-enables the IRQ
> by calling bsp_interrupt_enable. These calls break the GPIO API and the
> RTEMS interrupt server machinery, and we suspect it's also causing the 
> spurious
> interrupts we saw with the I2C module.
>
> The correct way to enable interrupt nesting according to both the manual and
> the AM335X StarterWare code is to allow only interrupts of a higher priority
> to preempt the current one. This can be achieved by setting the INTC_THRESHOLD
> register to the priority of the current IRQ. However, in our case this isn't
> necessary since all the interrupt priorities are set to 0 (the highest 
> possible)
> in bsp_interrupt_facility_initialize. We may implement this in a future patch,
> if required.
>
> We've tested this quite extensively on a number of different applications, and
> it's working fine.
>
> Closes #2580.
> ---
>  c/src/lib/libbsp/arm/beagle/irq.c   | 82 
> +++--
>  c/src/lib/libcpu/arm/shared/include/omap3.h |  3 +-
>  2 files changed, 44 insertions(+), 41 deletions(-)
>
> diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
> b/c/src/lib/libbsp/arm/beagle/irq.c
> index c6485cd..d080a5e 100644
> --- a/c/src/lib/libbsp/arm/beagle/irq.c
> +++ b/c/src/lib/libbsp/arm/beagle/irq.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -43,77 +44,78 @@ static struct omap_intr omap_intr = {
>  };
>  #endif
>
> -static int irqs_enabled[BSP_INTERRUPT_VECTOR_MAX+1];
> +/* Enables interrupts at the Interrupt Controller side. */
> +static inline void omap_irq_ack(void)
> +{
> +  mmio_write(omap_intr.base + OMAP3_INTCPS_CONTROL, OMAP3_INTR_NEWIRQAGR);
>
> -volatile static int level = 0;
> +  /* Flush data cache to make sure all the previous writes are done
> + before re-enabling interrupts. */
> +  flush_data_cache();
> +}
>
>  void bsp_interrupt_dispatch(void)
>  {
> -  /* get irq */
> -  uint32_t reg = mmio_read(omap_intr.base + OMAP3_INTCPS_SIR_IRQ);
> -  int irq;
> -  irq = reg & OMAP3_INTR_ACTIVEIRQ_MASK;
> +  const uint32_t reg = mmio_read(omap_intr.base + OMAP3_INTCPS_SIR_IRQ);
>
> -  if(!irqs_enabled[irq]) {
> -   /* Ignore spurious interrupt */
> -  } else {
> -bsp_interrupt_vector_disable(irq);
> -
> -/* enable new interrupts, and flush data cache to make sure
> - * it hits the intc
> - */
> -mmio_write(omap_intr.base + OMAP3_INTCPS_CONTROL, OMAP3_INTR_NEWIRQAGR);
> -flush_data_cache();
> -mmio_read(omap_intr.base + OMAP3_INTCPS_SIR_IRQ);
> -flush_data_cache();
> -
> -/* keep current irq masked but enable unmasked ones */
> -uint32_t psr = _ARMV4_Status_irq_enable();
> -bsp_interrupt_handler_dispatch(irq);
> -
> -_ARMV4_Status_restore(psr);
> +  if ((reg & OMAP3_INTR_SPURIOUSIRQ_MASK) != OMAP3_INTR_SPURIOUSIRQ_MASK) {
> +const rtems_vector_number irq = reg & OMAP3_INTR_ACTIVEIRQ_MASK;
>
> -bsp_interrupt_vector_enable(irq);
> +

[PATCH] fail gracefully when pax is not found

2015-10-22 Thread Ben Gras

https://devel.rtems.org/ticket/2437

Attachment to that ticket is a clean fix for:

If pax is not found by configure, the empty PAX variable is used in e.g.
this line:

$(PAX) -w -f $@ $<

Causing the 'w' command to be invoked:

21:37:25 up 6 min, 3 users, load average: 1,90, 1,14, 0,49

USER TTY LOGIN@ IDLE JCPU PCPU WHAT
../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c
../../../../../../tools/build/rtems-bin2c -H dl.tar dl-tar.h
cannot open dl.tar for reading
cannot open dl.tar for reading
make[6]: * [dl-tar.c] Error 1
make[6]: * Waiting for unfinished jobs
make[6]: * [dl-tar.h] Error 1
make[6]: Leaving directory
`/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites/libtests/dl01'
make[5]: * [all-local] Error 1
make[5]: Leaving directory
`/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites/libtests'
make[4]: * [all] Error 2
make[4]: Leaving directory
`/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites/libtests'
make[3]: * [all-recursive] Error 1
make[3]: Leaving directory
`/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack/testsuites'
make[2]: * [all-recursive] Error 1
make[2]: Leaving directory
`/home/beng/development/rtems/b-beagle/arm-rtems4.11/c/beagleboneblack'
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory
`/home/beng/development/rtems/b-beagle/arm-rtems4.11/c'
make: * [all-recursive] Error 1


Thanks to several reporters of this problem, most recently Debajyoti
Majumdar and Claudio Scordino, while trying to build the tests with
the Beagle BSP.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

BBB GPIO status

2015-08-18 Thread Ben Gras

All,

I built  tested  pushed Ketul's GPIO BBB implementation, it's
working nicely with the generic GPIO layer.

Remaining to get working:
  - IRQ-triggering in digital in
  - pullup configuration

Well done Ketul!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Temporary fix for ethernet rx intr hang issue and Disable cache

2015-06-28 Thread Ben Gras

All,

I really don't want to merge a line like:

+if ( ! ( irq == 40 || irq == 41 || irq == 42 || irq == 43 ) )

in the generic interrupt dispatch function.

At minimum, replace the IRQ numbers with descriptive macro names and
comment on why it's needed and that it's temporary.



On Sun, Jun 28, 2015 at 11:54 AM, ragunath ragunath3...@gmail.com wrote:
 ---
  c/src/lib/libbsp/arm/beagle/configure.ac  |  3 +++
  c/src/lib/libbsp/arm/beagle/irq.c |  5 +++--
  c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c | 17 +
  3 files changed, 23 insertions(+), 2 deletions(-)

 diff --git a/c/src/lib/libbsp/arm/beagle/configure.ac 
 b/c/src/lib/libbsp/arm/beagle/configure.ac
 index b0c99a3..41cd939 100644
 --- a/c/src/lib/libbsp/arm/beagle/configure.ac
 +++ b/c/src/lib/libbsp/arm/beagle/configure.ac
 @@ -33,6 +33,9 @@ RTEMS_BSPOPTS_HELP([CONSOLE_POLLED],[polled console i/o 
 (e.g. to run testsuite)]
  RTEMS_BSPOPTS_SET([BBB_DEBUG],[beaglebone*],[0])
  RTEMS_BSPOPTS_HELP([BBB_DEBUG],[Enable BBB debug])

 +RTEMS_BSPOPTS_SET([BBB_CACHE_DISABLE],[beaglebone*],[0])
 +RTEMS_BSPOPTS_HELP([BBB_CACHE_DISABLE],[DISABLE CACHE IN BBB])
 +
  RTEMS_BSP_CLEANUP_OPTIONS(0, 0)
  RTEMS_BSP_LINKCMDS

 diff --git a/c/src/lib/libbsp/arm/beagle/irq.c 
 b/c/src/lib/libbsp/arm/beagle/irq.c
 index c6485cd..9f2429c 100644
 --- a/c/src/lib/libbsp/arm/beagle/irq.c
 +++ b/c/src/lib/libbsp/arm/beagle/irq.c
 @@ -73,7 +73,8 @@ void bsp_interrupt_dispatch(void)

  _ARMV4_Status_restore(psr);

 -bsp_interrupt_vector_enable(irq);
 +if ( ! ( irq == 40 || irq == 41 || irq == 42 || irq == 43 ) )
 +  bsp_interrupt_vector_enable(irq);
}
  }

 @@ -94,11 +95,11 @@ rtems_status_code 
 bsp_interrupt_vector_enable(rtems_vector_number vector)
uint32_t mask, cur;
uint32_t mir_reg = get_mir_reg(vector, mask);

 +  irqs_enabled[vector] = 1;
cur = mmio_read(omap_intr.base + mir_reg);
mmio_write(omap_intr.base + mir_reg, cur  ~mask);
flush_data_cache();

 -  irqs_enabled[vector] = 1;

return RTEMS_SUCCESSFUL;
  }
 diff --git a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c 
 b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
 index 157edfa..c8d6526 100644
 --- a/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
 +++ b/c/src/lib/libbsp/arm/beagle/startup/bspstartmmu.c
 @@ -44,10 +44,26 @@ BSP_START_TEXT_SECTION void 
 beagle_setup_mmu_and_cache(void)
  {
/* turn mmu off first in case it's on */
uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
 +#if BBB_CACHE_DISABLE
 +/* clear - mmu off  disable cache */
 +ARM_CP15_CTRL_M | ARM_CP15_CTRL_A | ARM_CP15_CTRL_I | ARM_CP15_CTRL_C,
 +#else
  ARM_CP15_CTRL_M | ARM_CP15_CTRL_A, /* clear - mmu off */
 +#endif /* BBB_CACHE_DISABLE */
  ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
);

 +#if BBB_CACHE_DISABLE
 +  arm_cp15_start_setup_translation_table(
 +(uint32_t *) bsp_translation_table_base,
 +ARM_MMU_DEFAULT_CLIENT_DOMAIN,
 +beagle_mmu_config_table[0],
 +RTEMS_ARRAY_SIZE(beagle_mmu_config_table)
 +  );
 +
 +  ctrl |= ARM_CP15_CTRL_M;
 +  arm_cp15_set_control(ctrl);
 +#else
arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
  ctrl,
  (uint32_t *) bsp_translation_table_base,
 @@ -55,4 +71,5 @@ BSP_START_TEXT_SECTION void beagle_setup_mmu_and_cache(void)
  beagle_mmu_config_table[0],
  RTEMS_ARRAY_SIZE(beagle_mmu_config_table)
);
 +#endif /* BBB_CACHE_DISABLE */
  }
 --
 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: RTC patch for BBB

2015-05-28 Thread Ben Gras

This changed is now merged. Congratulations  thank you Ragunath!

On Sun, May 3, 2015 at 1:02 PM, ragu nath ragunath3...@gmail.com wrote:
 Hi All,

 I have attached the RTC patch for BBB. I have addressed the comments
 given for my earlier submission.

 I am having problems with sending patch using git send-email. I
 understand this is the preferred way but I not able to send patch
 using git send-email. I am behind a http proxy and git was not able to
 configure the smtp server. I could not find any solutions in the net.
 Is there any known solutions to this problem? For time being I am
 attaching the patch. Meanwhile I will also try to figure out the
 solution for this problem



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

Re: RTC patch for BBB

2015-05-17 Thread Ben Gras

All,

I am happy to merge this.
On May 3, 2015 1:02 PM, ragu nath ragunath3...@gmail.com wrote:

 Hi All,

 I have attached the RTC patch for BBB. I have addressed the comments
 given for my earlier submission.

 I am having problems with sending patch using git send-email. I
 understand this is the preferred way but I not able to send patch
 using git send-email. I am behind a http proxy and git was not able to
 configure the smtp server. I could not find any solutions in the net.
 Is there any known solutions to this problem? For time being I am
 attaching the patch. Meanwhile I will also try to figure out the
 solution for this problem



 Thanks,
 Ragunath

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

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

2015-04-26 Thread Ben Gras

All,

I think the API as it is (for digital GPIO's) is pretty close to
generic. I like my suggestion (gpio_* in my previous mail) better as
more generic. (More configuration is hidden from the application.)

Joel I just read your presentation.

I have come up with a minimal GPIO API based on the above (so
ultimately based on the RPI API) that just covers the GPIO digital out
case but allows expansion (with more defines and functions).

https://devel.rtems.org/wiki/TBR/User/BenGras

Is this an idea? Then we can merge this code implementing a reasonably
generic API without having to flesh out the whole thing.


On Fri, Apr 24, 2015 at 7:11 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


 On 4/24/2015 11:48 AM, Ben Gras wrote:
 All,

 Big improvement. The video shows that the bit logic for setting 
 clearing is likely sound - for the first byte at least ;-). Good test.

 My comments about the code are
   - gpio_select_pin write a whole 0 byte instead of updating a single
 bit, as we talked about on IRC
   - gedare's suggestion to use a single function to update bits in
 registers is good - you can use this for gpio_select_pin, gpio_set and
 gpio_clear.
   - i don't like the addition of arm_delay() in the bsp code. if it's
 not bsp-specific (and it isn't), it shouldn't be there.
   - the AM335X-specific code isn't made conditional

 My comment about the API that is:

 I don't like it that hardware-specific info (GPIO base registers) is
 somewhat external to the BSP. To my mind, the application should only
 deal with bank numbers and pin numbers. So either we need 128 more
 #defines of the GPIO_PIN struct in the current vein, meaning inline
 struct initializers are passed around (ew) and we rely on quite a lot
 of app discipline to keep it clean (ew); or we need an api like

 gpio_config(gpio_conf);  /* retrieve number of gpio banks  pins per
 bank, possibly more info */
 gpio_select_pin(gpio_pin, bank_number, pin_number, DIGITAL_OUTPUT);
 /* fill in gpio_pin struct to use this pin */
 gpio_set(gpio_pin);
 gpio_clear(gpio_pin);
 gpio_release_pin(gpio_pin);  /* allows repurposing this pin */

 this way the configuring of gpio_pin (containing hardware-specific
 info) is more internal to the BSP, and the app would have to actively
 subvert the api (look in the gpio_pin struct) and is less prone to be
 written badly by accident (hardcoding hardware addresses in the app).

 Thoughts anyone?
 We need a generic rtems_gpio_XXX API set. That was what I took at initial
 shot at with the multio code. I started mentally with separate APIs
 completely for analog and discretes but since I was handed a baseboard
 with 32 bit GPIO pins and an add-on board with ADCs, DACs, and more
 GPIOs, I needed a unified interface. The collection of various IO types
 on a board is common.

 The application should be completely independent of the BSP. My
 app will have to know that the red warning light is bank 1, pin 3
 on board X and bank 7, pin 12 when using another board. That
 is an application issue. The BSP/system configuration has to
 present a single API to the app.

 Remember that the system integrator may add boards. So the
 system configuration may include things not on the baseboard.
 The SIGAda 2009 presentation I sent privately a few days ago
 had that configuration and was what I did the API work I did for.


 On Thu, Apr 23, 2015 at 8:35 PM, Ketul Shah ketulshah1...@gmail.com wrote:
 Hi all,

 Ben Gras thanks for your comments and encouragement for merging with
 mainline as a motivation for me.

 I worked and redeveloped code for gpio driver also tried to approach towards
 common api. I tried to address most of the comments. Herewith I attached my
 patch. Would be happy to hear comments on that.

 You can also find out my gist or commit on https://github.com/RTEMS/rtems .
 I have been updating my work on https://github.com/ketul93/RTEMS-on-BBB.

 Live demo of the updated code is found on :- https://youtu.be/bXurelOA3i0

 Thanks.

 Regards,
 ketul


 On 20 April 2015 at 19:50, Ben Gras b...@shrike-systems.com wrote:
 All,

 Good contribution, thank you.

 For GSOC, this is good proof of being able to progress and get
 something real working based on documentation. Great!

 If you want this merged with mainline - which I fully encourage! -
 then I suggest the following should be added to/changed first:

   - make the code that uses AM335X (beaglebone) specific registers,
 AM335X-specific :) i.e. add  #if IS_AM335X around code that should
 only execute there. this BSP can be compiled for 2 different SOCs.
   - let it control all GPIO's - there are 4 banks of 32 each on the
 AM335x, but you only let the user control GPIO1. there should be a
 clean interface to control them all (clean means mostly: without
 duplicating code)
   - as Gedare mentioned on IRC, copy the RPi API. this is a first
 (second?) step to finding a generalized GPIO API.
   - don't add beagleboard.h, but add your definitions to
 libcpu/arm/shared/include

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

2015-04-24 Thread Ben Gras

All,

Big improvement. The video shows that the bit logic for setting 
clearing is likely sound - for the first byte at least ;-). Good test.

My comments about the code are
  - gpio_select_pin write a whole 0 byte instead of updating a single
bit, as we talked about on IRC
  - gedare's suggestion to use a single function to update bits in
registers is good - you can use this for gpio_select_pin, gpio_set and
gpio_clear.
  - i don't like the addition of arm_delay() in the bsp code. if it's
not bsp-specific (and it isn't), it shouldn't be there.
  - the AM335X-specific code isn't made conditional

My comment about the API that is:

I don't like it that hardware-specific info (GPIO base registers) is
somewhat external to the BSP. To my mind, the application should only
deal with bank numbers and pin numbers. So either we need 128 more
#defines of the GPIO_PIN struct in the current vein, meaning inline
struct initializers are passed around (ew) and we rely on quite a lot
of app discipline to keep it clean (ew); or we need an api like

gpio_config(gpio_conf);  /* retrieve number of gpio banks  pins per
bank, possibly more info */
gpio_select_pin(gpio_pin, bank_number, pin_number, DIGITAL_OUTPUT);
/* fill in gpio_pin struct to use this pin */
gpio_set(gpio_pin);
gpio_clear(gpio_pin);
gpio_release_pin(gpio_pin);  /* allows repurposing this pin */

this way the configuring of gpio_pin (containing hardware-specific
info) is more internal to the BSP, and the app would have to actively
subvert the api (look in the gpio_pin struct) and is less prone to be
written badly by accident (hardcoding hardware addresses in the app).

Thoughts anyone?



On Thu, Apr 23, 2015 at 8:35 PM, Ketul Shah ketulshah1...@gmail.com wrote:
 Hi all,

 Ben Gras thanks for your comments and encouragement for merging with
 mainline as a motivation for me.

 I worked and redeveloped code for gpio driver also tried to approach towards
 common api. I tried to address most of the comments. Herewith I attached my
 patch. Would be happy to hear comments on that.

 You can also find out my gist or commit on https://github.com/RTEMS/rtems .
 I have been updating my work on https://github.com/ketul93/RTEMS-on-BBB.

 Live demo of the updated code is found on :- https://youtu.be/bXurelOA3i0

 Thanks.

 Regards,
 ketul


 On 20 April 2015 at 19:50, Ben Gras b...@shrike-systems.com wrote:

 All,

 Good contribution, thank you.

 For GSOC, this is good proof of being able to progress and get
 something real working based on documentation. Great!

 If you want this merged with mainline - which I fully encourage! -
 then I suggest the following should be added to/changed first:

   - make the code that uses AM335X (beaglebone) specific registers,
 AM335X-specific :) i.e. add  #if IS_AM335X around code that should
 only execute there. this BSP can be compiled for 2 different SOCs.
   - let it control all GPIO's - there are 4 banks of 32 each on the
 AM335x, but you only let the user control GPIO1. there should be a
 clean interface to control them all (clean means mostly: without
 duplicating code)
   - as Gedare mentioned on IRC, copy the RPi API. this is a first
 (second?) step to finding a generalized GPIO API.
   - don't add beagleboard.h, but add your definitions to
 libcpu/arm/shared/include/am335x.h
   - the code should use a more consistent indenting style, and make
 variable names more descriptive than 'tmp'.
   - don't leave the configure changes in like in acinclude.m4

 bonus:
   - add DM3730 (beagleboard) support.

 Good luck!


 On Fri, Apr 17, 2015 at 7:51 PM, Ketul Shah ketulshah1...@gmail.com
 wrote:
  Hello,
 
  I have proposed in GSoC on Beagle BSP Improvements. As starting I
  started
  working for gpio driver development . At this stage I am able to
  demonstrate
  USR LEDs pattern.
 
  Videos of that can be found here on YouTube.
  https://youtu.be/B3mSsfo-PAQ 
  https://youtu.be/M1aKpOhUvv4.
 
  Herewith I have attached patch.txt file. Alternatively you can have
  https://gist.github.com/ketul93/2e0d2c4b8b586be62e1d that includes the
  newly
  added files code. I would be happy to hear your reviews and changes on
  my
  work.
 
  And also I have been updating my work on
  https://github.com/ketul93/RTEMS-on-BBB repo.
 
  It would be great to have your comments on my proposal.
 
  Thanks and regards,
  ketul
 
  ___
  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: [PATCH] Beagle BSP Improvements (GPIO driver)

2015-04-20 Thread Ben Gras

All,

Good contribution, thank you.

For GSOC, this is good proof of being able to progress and get
something real working based on documentation. Great!

If you want this merged with mainline - which I fully encourage! -
then I suggest the following should be added to/changed first:

  - make the code that uses AM335X (beaglebone) specific registers,
AM335X-specific :) i.e. add  #if IS_AM335X around code that should
only execute there. this BSP can be compiled for 2 different SOCs.
  - let it control all GPIO's - there are 4 banks of 32 each on the
AM335x, but you only let the user control GPIO1. there should be a
clean interface to control them all (clean means mostly: without
duplicating code)
  - as Gedare mentioned on IRC, copy the RPi API. this is a first
(second?) step to finding a generalized GPIO API.
  - don't add beagleboard.h, but add your definitions to
libcpu/arm/shared/include/am335x.h
  - the code should use a more consistent indenting style, and make
variable names more descriptive than 'tmp'.
  - don't leave the configure changes in like in acinclude.m4

bonus:
  - add DM3730 (beagleboard) support.

Good luck!


On Fri, Apr 17, 2015 at 7:51 PM, Ketul Shah ketulshah1...@gmail.com wrote:
 Hello,

 I have proposed in GSoC on Beagle BSP Improvements. As starting I started
 working for gpio driver development . At this stage I am able to demonstrate
 USR LEDs pattern.

 Videos of that can be found here on YouTube.
 https://youtu.be/B3mSsfo-PAQ 
 https://youtu.be/M1aKpOhUvv4.

 Herewith I have attached patch.txt file. Alternatively you can have
 https://gist.github.com/ketul93/2e0d2c4b8b586be62e1d that includes the newly
 added files code. I would be happy to hear your reviews and changes on my
 work.

 And also I have been updating my work on
 https://github.com/ketul93/RTEMS-on-BBB repo.

 It would be great to have your comments on my proposal.

 Thanks and regards,
 ketul

 ___
 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: Beagle bsp improvements RTC driver for beaglebone black

2015-04-04 Thread Ben Gras

All,

I built  tested the change based on current master. Looks great,
ragunath! I agree it's worth addressing Joel's comments. I have two
more:

 - please check in the device read/write functions that you're getting
the 'minor' argument that you expect (0), and not return valid data
otherwise.
 - git reports some spurious white space

can you address these  resubmit? I'll be happy to merge then. Thanks
for your contribution, very good companion to your GSOC proposal!



On Wed, Apr 1, 2015 at 7:48 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote:
 I noticed this wasn't merged.

 Ben.. ?

 some comments interspersed.

 On 3/10/2015 4:21 PM, ragu nath wrote:
 Hi All,

 I was exploring the beagle code base to find a task to get hands on
 experience with RTEMS internals. I found that Real time Clock (RTC) 
 support is
 missing for beaglebone. I made the effort to add the driver for the device.
 Included the patch for the driver. RTEMS already have a RTC framework.
 I defined the necessary structures to hook the driver to the framework.

 Enabled the driver by defining the macro
 CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER and tested the following.
 Testing is done from the shell using date and rtc commands.
 1. Able to read the time from rtc.
 2. Able to set the time
 3. Time values are preserved between reboots

 Pls review the patch and let me know if you have any comments.

 I have following doubts

 1. The support is applicable only to beaglebone black. It is not valid
 for beagleboard. Both of them seem to have same codebase.  Is there any 
 compile
 time flags available to not compile the driver for beagleboard?

 Look in the configure.ac in the BSP. There is already a cpp define generated
 based on the board variant for DM3730 or AM335x. Do you need more than
 that? I am not an expert on the differences between the various models so
 this is just a question.

 If the RTC has to be ignored completely for some variants, the configure.ac
 logic can be enhanced to generate a conditional the Makefile.am can use
 to conditionally build some files.


 2. What is procedure to commit the change (In case the patch is
 accepted)? Do we need to open a bug to track the changes?
 This normally would have been more than enough. But pinging if you don't
 get a response in a reasonable length of time.

 The patch didn't get included in my response so here are some odd comments.

 + disabl check spelling.
 + Steps to enable RTC should have * at front of each line in comment
 block
 + spaces around equal signs
 + Don't print from driver
 + I see an unneeded blank line before closing } in some methods
 + Put ; on busy spin loops on a separate line so it is obvious
- if there is a known number of maximum spins, it should not
  lock up.
   - the spins do look the same so moving them to a subroutine
 and adding a maximum spin count would be a nice way to
make the code more robust and clearer.
 + Rather than RTEMS_DEBUG, may want to use a BB_DEBUG
or similar for debug code.
 + Watch columns lining up. RTC_Table comments don't line up
and value column in register macros in .h don't either.
 +
 Thanks,
 Ragunath

 --
 Joel Sherrill, Ph.D. Director of Research  Development
 joel.sherr...@oarcorp.comOn-Line Applications Research
 Ask me about RTEMS: a free RTOS  Huntsville AL 35805
 Support Available(256) 722-9985


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

Re: [PATCH] autoconf changes

2015-03-14 Thread Ben Gras

Ok reverted. Sorry for the noise everyone.


On Sat, Mar 14, 2015 at 10:05 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:


 On 3/14/2015 3:44 PM, Ben Gras wrote:
 I accidentally also merged this commti when I meant to just merge the
 beagle one.e

 Should I revert it or is this ok to leave in?
 Revert. I did a bootstrap and see two files that are different.

 #modified:   c/src/lib/libbsp/bfin/acinclude.m4
 #modified:   c/src/lib/libbsp/powerpc/acinclude.m4

 No big deal. But it would be nice to know what host did it this time.
 Chris has been fighting the sort order for a while. :(

 --joel

 On Sat, Mar 14, 2015 at 8:08 PM, Gedare Bloom ged...@gwu.edu wrote:
 Me too. I'm not sure why..

 On Sat, Mar 14, 2015 at 1:44 PM, Ben Gras b...@shrike-systems.com wrote:
 Everytime I ./bootstrap  ./bootstrap -p, I get these changes
 w.r.t. mainline. Just tried again with a new tools build. (With the
 prefix/bin dir first in $PATH of course.)

 Or is it just me?

 ---
  c/src/lib/libbsp/bfin/acinclude.m4| 4 ++--
  c/src/lib/libbsp/powerpc/acinclude.m4 | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/c/src/lib/libbsp/bfin/acinclude.m4 
 b/c/src/lib/libbsp/bfin/acinclude.m4
 index ab6082e..828fd89 100644
 --- a/c/src/lib/libbsp/bfin/acinclude.m4
 +++ b/c/src/lib/libbsp/bfin/acinclude.m4
 @@ -2,12 +2,12 @@
  AC_DEFUN([RTEMS_CHECK_BSPDIR],
  [
case $1 in
 -  TLL6527M )
 -AC_CONFIG_SUBDIRS([TLL6527M]);;
bf537Stamp )
  AC_CONFIG_SUBDIRS([bf537Stamp]);;
eZKit533 )
  AC_CONFIG_SUBDIRS([eZKit533]);;
 +  TLL6527M )
 +AC_CONFIG_SUBDIRS([TLL6527M]);;
*)
  AC_MSG_ERROR([Invalid BSP]);;
esac
 diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4 
 b/c/src/lib/libbsp/powerpc/acinclude.m4
 index 6442399..e46fa2b 100644
 --- a/c/src/lib/libbsp/powerpc/acinclude.m4
 +++ b/c/src/lib/libbsp/powerpc/acinclude.m4
 @@ -38,12 +38,12 @@ AC_DEFUN([RTEMS_CHECK_BSPDIR],
  AC_CONFIG_SUBDIRS([t32mppc]);;
tqm8xx )
  AC_CONFIG_SUBDIRS([tqm8xx]);;
 -  virtex )
 -AC_CONFIG_SUBDIRS([virtex]);;
virtex4 )
  AC_CONFIG_SUBDIRS([virtex4]);;
virtex5 )
  AC_CONFIG_SUBDIRS([virtex5]);;
 +  virtex )
 +AC_CONFIG_SUBDIRS([virtex]);;
*)
  AC_MSG_ERROR([Invalid BSP]);;
esac
 --
 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

 --
 Joel Sherrill, Ph.D. Director of Research  Development
 joel.sherr...@oarcorp.comOn-Line Applications Research
 Ask me about RTEMS: a free RTOS  Huntsville AL 35805
 Support Available(256) 722-9985

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

Re: I was confused

2014-12-25 Thread Ben Gras

All,

About qemu starting x86 executables: as Gedare said you will need some
sort of loader to load the ELF into memory (load segments to the right
place  jump into it at the right place).

Interestingly, qemu has a multiboot-compatible (see e.g.
http://www.gnu.org/software/grub/manual/multiboot/multiboot.html)
loader built-in which is very convenient. The reason it's so
convenient is that you don't need to give it a real filesystem in
order to run an executable. Patching in bootcode and a filesystem etc.
is a bit messy from a Makefile or shellscript.

This works very nicely for me, with working networking, invoked from a Makefile:

qemu-system-i386 -redir tcp:$(LOCALPORT)::$(HTTPPORT) -netdev
user,id=$(NETNAME) -device
ne2k_isa,irq=$(IRQ),iobase=$(IOBASE),netdev=$(NETNAME) -serial stdio
--no-reboot -kernel $(PGM)

this redirects localhost:$(LOCALPORT) to the $(HTTPPORT) on the quest
(tcp connections otherwise can't be made inwards with default qemu NAT
networking), NETNAME is just something arbitrary ('mynet0') to connect
the NIC and the VLAN, IRQ and IOBASE are defined in the Makefile (9
and 0x280) so that I can force the RTEMS driver to use those values
too and define them in one place, and PGM is the RTEMS .exe
executable.

It's the -kernel option that (somewhat magically) invokes the internal
qemu bootloader that loads the executable from the host system.

Good luck!




On Tue, Dec 23, 2014 at 7:53 PM, Dominik Táborský bre...@seznam.cz wrote:
 Hello,

 I am sorry for the subject line, but I am so confused right now I couldn't 
 think of with a better one.
 Not anymore. Do you know how when you want to ask a perfect question, you 
 find the answer yourself?

 Below is an excerpt from the make log. First line is obviously an invocation 
 of the compiler to compile just the init.c file from the hello world sample. 
 The last line links the executable. Where does the rest of RTEMS come in? Is 
 it in the -qrtems option? I coudln't find anything about -q option in the 
 gcc man page. So do you actually patch GCC sources before building your own 
 special RTEMS compiler toolkit?


 i386-rtems4.11-gcc -B../../../../../pc386/lib/ -specs bsp_specs -qrtems 
 -DHAVE_CONFIG_H -I. 
 -I../../../../../../../rtems/c/src/../../testsuites/samples/hello -I.. 
 -mtune=i386 -O2 -g -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/hello/init.c

 mv -f .deps/init.Tpo .deps/init.Po

 i386-rtems4.11-gcc -B../../../../../pc386/lib/ -specs bsp_specs -qrtems 
 -mtune=i386 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration 
 -Wstrict-prototypes -Wnested-externs   -Wl,-Ttext,0x0010  -mtune=i386   
 -o hello.exe init.o

 Just to make sure then: RTEMS and the target application are compiled into 
 one executable that just runs indefinitely. Correct?

 While I'm at it, I have trouble using Qemu. This might deserve a thread on 
 its own, but have you recently tested it? Running executables in sparc 
 simulator using GDB works fine, running qemu-system-* also seems ok, but 
 running qemu-i386 on x86 binaries or qemu-sparc with sparc executables gives 
 me just /path/to/exe: Invalid argument error, nothing else.

 And lastly, I get 404 when accessing Joel's pronounciation of RTEMS. 4th 
 question the FAQ: https://devel.rtems.org/wiki/TBR/Website/FAQ.


 Merry Christmas.

 Dominik
 ___
 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: I was confused

2014-12-25 Thread Ben Gras

BTW merry xmas everyone :-)


On Thu, Dec 25, 2014 at 9:59 AM, Ben Gras b...@shrike-systems.com wrote:
 All,

 About qemu starting x86 executables: as Gedare said you will need some
 sort of loader to load the ELF into memory (load segments to the right
 place  jump into it at the right place).

 Interestingly, qemu has a multiboot-compatible (see e.g.
 http://www.gnu.org/software/grub/manual/multiboot/multiboot.html)
 loader built-in which is very convenient. The reason it's so
 convenient is that you don't need to give it a real filesystem in
 order to run an executable. Patching in bootcode and a filesystem etc.
 is a bit messy from a Makefile or shellscript.

 This works very nicely for me, with working networking, invoked from a 
 Makefile:

 qemu-system-i386 -redir tcp:$(LOCALPORT)::$(HTTPPORT) -netdev
 user,id=$(NETNAME) -device
 ne2k_isa,irq=$(IRQ),iobase=$(IOBASE),netdev=$(NETNAME) -serial stdio
 --no-reboot -kernel $(PGM)

 this redirects localhost:$(LOCALPORT) to the $(HTTPPORT) on the quest
 (tcp connections otherwise can't be made inwards with default qemu NAT
 networking), NETNAME is just something arbitrary ('mynet0') to connect
 the NIC and the VLAN, IRQ and IOBASE are defined in the Makefile (9
 and 0x280) so that I can force the RTEMS driver to use those values
 too and define them in one place, and PGM is the RTEMS .exe
 executable.

 It's the -kernel option that (somewhat magically) invokes the internal
 qemu bootloader that loads the executable from the host system.

 Good luck!




 On Tue, Dec 23, 2014 at 7:53 PM, Dominik Táborský bre...@seznam.cz wrote:
 Hello,

 I am sorry for the subject line, but I am so confused right now I couldn't 
 think of with a better one.
 Not anymore. Do you know how when you want to ask a perfect question, you 
 find the answer yourself?

 Below is an excerpt from the make log. First line is obviously an invocation 
 of the compiler to compile just the init.c file from the hello world sample. 
 The last line links the executable. Where does the rest of RTEMS come in? Is 
 it in the -qrtems option? I coudln't find anything about -q option in 
 the gcc man page. So do you actually patch GCC sources before building your 
 own special RTEMS compiler toolkit?


 i386-rtems4.11-gcc -B../../../../../pc386/lib/ -specs bsp_specs -qrtems 
 -DHAVE_CONFIG_H -I. 
 -I../../../../../../../rtems/c/src/../../testsuites/samples/hello -I.. 
 -mtune=i386 -O2 -g -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/hello/init.c

 mv -f .deps/init.Tpo .deps/init.Po

 i386-rtems4.11-gcc -B../../../../../pc386/lib/ -specs bsp_specs -qrtems 
 -mtune=i386 -O2 -g -Wall -Wmissing-prototypes 
 -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs   
 -Wl,-Ttext,0x0010  -mtune=i386   -o hello.exe init.o

 Just to make sure then: RTEMS and the target application are compiled into 
 one executable that just runs indefinitely. Correct?

 While I'm at it, I have trouble using Qemu. This might deserve a thread on 
 its own, but have you recently tested it? Running executables in sparc 
 simulator using GDB works fine, running qemu-system-* also seems ok, but 
 running qemu-i386 on x86 binaries or qemu-sparc with sparc executables gives 
 me just /path/to/exe: Invalid argument error, nothing else.

 And lastly, I get 404 when accessing Joel's pronounciation of RTEMS. 4th 
 question the FAQ: https://devel.rtems.org/wiki/TBR/Website/FAQ.


 Merry Christmas.

 Dominik
 ___
 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

[PATCH] fix warnings found when building beagle bsp

2014-12-15 Thread Ben Gras

The extra includes in console_*.c are to solve a 'no previous prototype'
warning.

Solves #2212 in trac.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] fix warnings found when building beagle bsp

2014-12-15 Thread Ben Gras

Okay.


On Mon, Dec 15, 2014 at 6:39 PM, Gedare Bloom ged...@gwu.edu wrote:
 In the future try to use git-send-email if you can. Inline patches
 especially this small are much easier to review.

 Go ahead and apply.
 -Gedare

 On Mon, Dec 15, 2014 at 11:34 AM, Ben Gras b...@shrike-systems.com wrote:
 gah.


 On Mon, Dec 15, 2014 at 1:48 PM, Ben Gras b...@shrike-systems.com wrote:
 The extra includes in console_*.c are to solve a 'no previous prototype'
 warning.

 Solves #2212 in trac.

 ___
 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

[PATCH] beagle bsp - disable watchdog

2014-12-04 Thread Ben Gras

On recent u-boots, the watchdog is turned on / left enabled. The
Beaglebone Black rev. C ships with such a u-boot internally so any OS
booting from it must disable the watchdog or the user is required to
change the stock uboot.
From 4132f23920c743ec2dca0ffd63f8dcf833eb0a1b Mon Sep 17 00:00:00 2001
From: Ben Gras b...@rtems.org
Date: Thu, 4 Dec 2014 18:21:11 +0100
Subject: [PATCH] beagle bsp: disable watchdog on am335x

On recent u-boots, the watchdog is turned on / left enabled. The
Beaglebone Black rev. C ships with such a u-boot internally so any
application booting from it must disable the watchdog.

Therefore this change is needed to boot an RTEMS app out-of-the-box
on a BBB Rev C - otherwise the user button must be held during boot
(to bypass the stock uboot) or the internal uboot must be updated. To
allow for a better out-of-the-box experience, we just turn off the
watchdog.
---
 c/src/lib/libbsp/arm/beagle/clock.c  | 9 +
 c/src/lib/libcpu/arm/shared/include/am335x.h | 6 ++
 2 files changed, 15 insertions(+)

diff --git a/c/src/lib/libbsp/arm/beagle/clock.c b/c/src/lib/libbsp/arm/beagle/clock.c
index 13c0607..b2582d1 100644
--- a/c/src/lib/libbsp/arm/beagle/clock.c
+++ b/c/src/lib/libbsp/arm/beagle/clock.c
@@ -251,6 +251,15 @@ beagle_clock_initialize(void)
   OMAP3_TCLR_OVF_TRG | OMAP3_TCLR_AR | OMAP3_TCLR_ST);
   /* also initilize the free runnning timer */
   omap3_frclock_init();
+
+#if IS_AM335X
+  /* Disable AM335X watchdog */
+  mmio_write(AM335X_WDT_BASE+AM335X_WDT_WSPR, 0x);
+  while(mmio_read(AM335X_WDT_BASE+AM335X_WDT_WWPS) != 0) ;
+  mmio_write(AM335X_WDT_BASE+AM335X_WDT_WSPR, 0x);
+  while(mmio_read(AM335X_WDT_BASE+AM335X_WDT_WWPS) != 0) ;
+#endif
+
 }
 
 static void beagle_clock_at_tick(void)
diff --git a/c/src/lib/libcpu/arm/shared/include/am335x.h b/c/src/lib/libcpu/arm/shared/include/am335x.h
index 4b5ea73..265cc36 100644
--- a/c/src/lib/libcpu/arm/shared/include/am335x.h
+++ b/c/src/lib/libcpu/arm/shared/include/am335x.h
@@ -274,3 +274,9 @@
 /* Control posted mode and functional SW reset */
 #define AM335X_TIMER_TCAR20x058
 /* Second captured value of counter register */
+#define AM335X_WDT_BASE0x44E35000
+/* Watchdog timer */
+#define AM335X_WDT_WWPS0x34
+/* Command posted status */
+#define AM335X_WDT_WSPR0x48
+/* Activate/deactivate sequence */
-- 
1.9.1

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

[PATCH] fix for default configuration for pc386 bsp

2014-12-02 Thread Ben Gras

All,

If USE_VBE_RM is not on, vesa_realmode_bootup_init shouldn't be
referenced, but it's always defined, so the test shoudl be #if instead
of #ifdef.
From 97c14a7558671826bf21f323f7ee593f3e311e15 Mon Sep 17 00:00:00 2001
From: Ben Gras b...@shrike-systems.com
Date: Tue, 2 Dec 2014 23:36:59 +0100
Subject: [PATCH] pc386 bsp fix for default mode

If USE_VBE_RM is 0, vesa_realmode_bootup_init() is not available so the
test should be #if instead of #ifdef.
---
 c/src/lib/libbsp/i386/pc386/start/start.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/c/src/lib/libbsp/i386/pc386/start/start.S b/c/src/lib/libbsp/i386/pc386/start/start.S
index ab92a4f..48fe30b 100644
--- a/c/src/lib/libbsp/i386/pc386/start/start.S
+++ b/c/src/lib/libbsp/i386/pc386/start/start.S
@@ -62,7 +62,7 @@ BEGIN_CODE
 	PUBLIC (start)		# GNU default entry point
 
 	EXTERN (boot_card)
-#ifdef USE_VBE_RM
+#if USE_VBE_RM
 EXTERN (vesa_realmode_bootup_init)
 #endif
 	EXTERN (_load_segments)
@@ -205,7 +205,7 @@ SYM (zero_bss):
 +---*/
 	call _IBMPC_initVideo
 
-#ifdef USE_VBE_RM
+#if USE_VBE_RM
 callvesa_realmode_bootup_init
 #endif
 
-- 
1.9.1

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

Re: [PATCH] more data structures public in mongoose.h

2014-12-02 Thread Ben Gras

Hi Nick  rtems-devel,

I could've sworn I needed the struct mg_connection declaration even to
just declare a function with its argument - but just to verify I tried
it again and I'm fine. So, for now, I'm retracting the patch.

Thanks for the tip!


On Thu, Nov 20, 2014 at 2:15 AM, Nick Withers nick.with...@anu.edu.au wrote:
 On Wed, 2014-11-19 at 19:16 +0100, Ben Gras wrote:
 The attached patch is a proposed solution to a problem I am having
 with interfacing with the mongoose httpd for which I've found no
 canonical (or any other) clean solution.

 The problem is that some of the data structures needed for some
 operations, specifically writing callbacks that get invoked for some
 HTTP requests, are declared in mongoose.c and therefore are not
 available to external programs, i.e. clients of mongoose. This is the
 mg_connection struct  its dependencies. It is passed as an argument
 to callbacks, and even without referencing the object the code won't
 compile if the struct isn't fully known.

 Would struct mg_request_info *mg_get_request_info(struct mg_connection
 *) help you? I use that to pull out the user_data field (passed to
 mongoose_start()) in Mongoose callbacks.

 You don't need to have the definition of struct mg_connection exposed
 for this scenario, at least.
 --
 Nick Withers

 Embedded Systems Programmer
 Department of Nuclear Physics, Research School of Physics and Engineering
 The Australian National University (CRICOS: 00120C)

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

[PATCH] more data structures public in mongoose.h

2014-11-19 Thread Ben Gras

The attached patch is a proposed solution to a problem I am having with
interfacing with the mongoose httpd for which I've found no canonical (or
any other) clean solution.

The problem is that some of the data structures needed for some operations,
specifically writing callbacks that get invoked for some HTTP requests, are
declared in mongoose.c and therefore are not available to external
programs, i.e. clients of mongoose. This is the mg_connection struct  its
dependencies. It is passed as an argument to callbacks, and even without
referencing the object the code won't compile if the struct isn't fully
known.

The change is moving some declarations from mongoose.c to mongoose.h.

Unfortunately this diverges from the original code, then again mongoose
isn't tracked any more since the license change I take it, so perhaps
that's not so bad. I've made the changes __rtems__-conditional so it's
clear where the divergence is.
From 60e135fcc6ae74aa334211046b8f8cc6dd413041 Mon Sep 17 00:00:00 2001
From: Ben Gras b...@shrike-systems.com
Date: Tue, 18 Nov 2014 17:29:36 +0100
Subject: [PATCH] mongoose.h

---
 cpukit/mghttpd/mongoose.c | 21 +++
 cpukit/mghttpd/mongoose.h | 67 +++
 2 files changed, 88 insertions(+)

diff --git a/cpukit/mghttpd/mongoose.c b/cpukit/mghttpd/mongoose.c
index dd243d3..e1e2c1e 100644
--- a/cpukit/mghttpd/mongoose.c
+++ b/cpukit/mghttpd/mongoose.c
@@ -245,11 +245,22 @@ typedef struct DIR {
 #define ERRNO errno
 #define INVALID_SOCKET (-1)
 #define INT64_FMT PRId64
+#ifndef __rtems__	/* defined in mongoose.h for RTEMS */
 typedef int SOCKET;
+#endif
 #define WINCDECL
 
 #endif // End of Windows and UNIX specific includes
 
+#ifdef __rtems__
+
+/* For RTEMS, some definitions are moved from mongoose.c to mongoose.h.
+ * See mongoose.h for more info.  - BJG 18/11/2014
+ */
+
+#include mongoose.h
+#endif
+
 #ifndef HAVE_POLL
 struct pollfd {
   SOCKET fd;
@@ -259,7 +270,9 @@ struct pollfd {
 #define POLLIN 1
 #endif
 
+#ifndef __rtems__
 #include mongoose.h
+#endif
 
 #define MONGOOSE_VERSION 3.9
 #define PASSWORDS_FILE_NAME .htpasswd
@@ -327,11 +340,13 @@ static const char *http_500_error = Internal Server Error;
 #include openssl/ssl.h
 #include openssl/err.h
 #else
+#if !defined(__rtems__)	/* defined in mongoose.h for RTEMS */
 // SSL loaded dynamically from DLL.
 // I put the prototypes here to be independent from OpenSSL source installation.
 typedef struct ssl_st SSL;
 typedef struct ssl_method_st SSL_METHOD;
 typedef struct ssl_ctx_st SSL_CTX;
+#endif	/* !defined(__rtems__) */
 
 struct ssl_func {
   const char *name;   // SSL function name
@@ -419,6 +434,7 @@ static const char *month_names[] = {
   Jul, Aug, Sep, Oct, Nov, Dec
 };
 
+#if !defined(__rtems__)	/* defined in mongoose.h for RTEMS */
 // Unified socket address. For IPv6 support, add IPv6 address structure
 // in the union u.
 union usa {
@@ -428,6 +444,7 @@ union usa {
   struct sockaddr_in6 sin6;
 #endif
 };
+#endif	/* !defined(__rtems__) */
 
 // Describes a string (chunk of memory).
 struct vec {
@@ -447,6 +464,7 @@ struct file {
 };
 #define STRUCT_FILE_INITIALIZER {0, 0, 0, NULL, NULL, 0}
 
+#if !defined(__rtems__)	/* defined in mongoose.h for RTEMS */
 // Describes listening socket, or socket which was accept()-ed by the master
 // thread and queued for future handling by the worker thread.
 struct socket {
@@ -456,6 +474,7 @@ struct socket {
   unsigned is_ssl:1;// Is port SSL-ed
   unsigned ssl_redir:1; // Is port supposed to redirect everything to SSL port
 };
+#endif	/* !defined(__rtems__) */
 
 // NOTE(lsm): this enum shoulds be in sync with the config_options below.
 enum {
@@ -522,6 +541,7 @@ struct mg_context {
   pthread_cond_t sq_empty;   // Signaled when socket is consumed
 };
 
+#if !defined(__rtems__)	/* defined in mongoose.h for RTEMS */
 struct mg_connection {
   struct mg_request_info request_info;
   struct mg_context *ctx;
@@ -543,6 +563,7 @@ struct mg_connection {
   time_t last_throttle_time;  // Last time throttled data was sent
   int64_t last_throttle_bytes;// Bytes sent this second
 };
+#endif
 
 // Directory entry
 struct de {
diff --git a/cpukit/mghttpd/mongoose.h b/cpukit/mghttpd/mongoose.h
index ad7c40f..cd09b33 100644
--- a/cpukit/mghttpd/mongoose.h
+++ b/cpukit/mghttpd/mongoose.h
@@ -29,8 +29,51 @@ extern C {
 #endif // __cplusplus
 
 struct mg_context; // Handle for the HTTP service itself
+#ifndef __rtems__
 struct mg_connection;  // Handle for the individual connection
+#else
+
+/* For RTEMS, some definitions are moved from mongoose.c to mongoose.h.
+ * The purpose is so that clients of the mongoose functions can get
+ * passed objects of type mg_connection, which is needed for callbacks.
+ * For RTEMS, therefore we include mg_connection and its dependencies
+ * in mongoose.h and remove them from mongoose.c.
+ *
+ *  - BJG 18/11/2014
+ */
+
+#if !defined(NO_SSL_DL)
+typedef struct ssl_st SSL;
+typedef struct ssl_method_st

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

2014-11-04 Thread Ben Gras

I just checked, it runs on the bbxm hardware too, not just the emulator.


On Mon, Nov 3, 2014 at 1:20 PM, Ben Gras b...@shrike-systems.com wrote:

 All,

 Ok, as promised, I rebased and re-tested and have found  included a
 portable way of making the SD card image (included in sdcard.sh), to be
 merged with RSB (i.e. some of the tools sdcard.sh relies on are missing in
 mainline RSB). Some of Gedare's initial feedback is processed thanks to
 Brandon Matthews. It's tested to run on the original beaglebone, beaglebone
 black and qemu linaro. (The assumption is it'll run on the bbxm hardware as
 well as it was before rebasing.)

 The result is split into 2 patches to show what was Claas's initial work.
 This makes them a bit unreadable for the final result from the patches
 unfortunately.

 As before, see
 http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
 on how to build all the tools, RTEMS executables, sdcard images, and run
 the test set from linaro qemu.



 On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com wrote:

 All,

 OK, that seems like a fruitful way to proceed to me.

 Then I will do some minor cleanups, rebase, do all the tests again, and
 re-submit. There's just one problem I know of that I want to fix before the
 first commit happens, and that is that the FAT fs made by mtools doesn't
 boot on the HW it seems. (It does on the emulator.) A last-minute change -
 switching to mtools instead of dosfstools to use to make the SD card image
 because the latter is so linux-only.

 Stay tuned.




 On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org wrote:

 Ben, As far as getting this merged, all of my comments can be done as
 a follow-on commit. -Gedare

 On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com
 wrote:
  Thanks for the fast  detailed review. Let me get back to it/you.
 
  In the meantime, any other feedback? From anyone I mean.
 
 
 
  On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
 wrote:
 
  Hi Ben,
  Great work. I have a few comments. I skipped the i2c.h and i2c.c
  files. Most of my comments are about style and a few requests to
  refactor some of the larger files. The refactoring can be added to
  your TODO if you like. Please fix the style issues if it is not a
  burden.
 
  +++ b/c/src/lib/libbsp/arm/beagle/README
  +$ ../claas-rtems/configure --target=arm-rtems4.11
  --enable-rtemsbsp=beaglebonewhite beagleboardxm
  Replace claas-rtems with rtems. If RSB support is available, make a
  note about it.
 
  +++ b/c/src/lib/libbsp/arm/beagle/TODO
  [...]
  open:
  + . how to handle the interrupt?
 
  What does this mean?
 
  +++ b/c/src/lib/libbsp/arm/beagle/clock.c
  Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
 
  It might be sensible to put the struct definitions in a .h file if
  these omap registers might be re-usable.
 
  +static struct omap_timer_registers regs_v2 = {
  This might be better to put behind an #if IS_AM335X since it is not
  used otherwise?
 
  +
  +
  +
  Avoid more than one blank line in a row.
 
  +static int done = 0;
  It would be nice if you got rid of this, but otherwise give it a more
  useful name like mmio_init_done
 
  +static void beagle_clock_handler_install(rtems_interrupt_handler isr)
  +  if (sc != RTEMS_SUCCESSFUL) {
  +rtems_fatal_error_occurred(0xdeadbeef);
  I think there is some capabilities in ARM for bsp fatal error codes
  now. They should be preferred to be used to help debug these fatal
  conditions.
 
  +static inline uint32_t beagle_clock_nanoseconds_since_last_tick(void)
  +  return (read_frc() - (uint64_t) last_tick_nanoseconds) * 10
  / FRCLOCK_HZ;
  This line is  80 characters, please break it or shrink it.
 
  +++ b/c/src/lib/libbsp/arm/beagle/console/console-config.c
  +#define CONSOLE_UART_LSR (*(volatile unsigned int
  *)(BSP_CONSOLE_UART_BASE+0x14))
  Line  80 characters, even with the spacing modified.
 
  +static void beagle_console_init(void)
 
  +while ((CONSOLE_SYSS  1) == 0)
  +  ;
  Is this a fatal loop or is it waiting for hardware to clear something?
 
  +if ((CONSOLE_LSR  (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==
  CONSOLE_LSR_THRE) {
  Again  80 characters. Is the test logically equivalent to: if (
  (CONSOLE_LSR  CONSOLE_LSR_THRE) == CONSOLE_LSR_THRE)
 
  +while ((CONSOLE_LSR  CONSOLE_LSR_TEMT) == 0)
  +  ;
  Is this a fatal loop or is it waiting for hardware?
 
  +++ b/c/src/lib/libbsp/arm/beagle/include/bsp.h
  This bsp.h is really long. Probably it should be refactored into other
  headers, including non-public ones.
 
  +static inline void dsb(void)
  +{
  +asm volatile(dsb : : : memory);
  Fix the indentation.
 
  +static inline void flush_data_cache(void)
  Perhaps this should be using _CPU_cache_flush_entire_data()? Perhaps
  there is a difference in that the cache manager code flushes and
  cleans the cache...
 
  +
  +
  +
  +
  Excess

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

2014-11-03 Thread Ben Gras

All,


Joel merged these and I updated my blog post to reflect the mainline repo.
Thanks Joel!

On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com wrote:

 All,

 I have new patches with some last-minute smoothings added; removed
 obsolete beagle.cfg, TODO, and separated the more generic ARM headers into
 a separate commit. The new 3 commits are attached (and in my RTEMS github
 repo).

 Gedare, there is also a diff w.r.t. the previous submission attached as
 requested.



 On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org wrote:

 Hi,

 I don't have time to review, but am OK in principle with committing
 this code as it is tested, with the caveat that my previous comments
 be addressed post-merge.

 If you have a diff / commits on top of what you sent before, I'd be
 glad to give those a quick look.

 Thanks for your contribution!
 Gedare

 On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com wrote:
  All,
 
  Ok, as promised, I rebased and re-tested and have found  included a
  portable way of making the SD card image (included in sdcard.sh), to be
  merged with RSB (i.e. some of the tools sdcard.sh relies on are missing
 in
  mainline RSB). Some of Gedare's initial feedback is processed thanks to
  Brandon Matthews. It's tested to run on the original beaglebone,
 beaglebone
  black and qemu linaro. (The assumption is it'll run on the bbxm
 hardware as
  well as it was before rebasing.)
 
  The result is split into 2 patches to show what was Claas's initial
 work.
  This makes them a bit unreadable for the final result from the patches
  unfortunately.
 
  As before, see
 
 http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
  on how to build all the tools, RTEMS executables, sdcard images, and
 run the
  test set from linaro qemu.
 
 
 
  On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com
 wrote:
 
  All,
 
  OK, that seems like a fruitful way to proceed to me.
 
  Then I will do some minor cleanups, rebase, do all the tests again, and
  re-submit. There's just one problem I know of that I want to fix
 before the
  first commit happens, and that is that the FAT fs made by mtools
 doesn't
  boot on the HW it seems. (It does on the emulator.) A last-minute
 change -
  switching to mtools instead of dosfstools to use to make the SD card
 image
  because the latter is so linux-only.
 
  Stay tuned.
 
 
 
 
  On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org
 wrote:
 
  Ben, As far as getting this merged, all of my comments can be done as
  a follow-on commit. -Gedare
 
  On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com
  wrote:
   Thanks for the fast  detailed review. Let me get back to it/you.
  
   In the meantime, any other feedback? From anyone I mean.
  
  
  
   On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
 wrote:
  
   Hi Ben,
   Great work. I have a few comments. I skipped the i2c.h and i2c.c
   files. Most of my comments are about style and a few requests to
   refactor some of the larger files. The refactoring can be added to
   your TODO if you like. Please fix the style issues if it is not a
   burden.
  
   +++ b/c/src/lib/libbsp/arm/beagle/README
   +$ ../claas-rtems/configure --target=arm-rtems4.11
   --enable-rtemsbsp=beaglebonewhite beagleboardxm
   Replace claas-rtems with rtems. If RSB support is available, make a
   note about it.
  
   +++ b/c/src/lib/libbsp/arm/beagle/TODO
   [...]
   open:
   + . how to handle the interrupt?
  
   What does this mean?
  
   +++ b/c/src/lib/libbsp/arm/beagle/clock.c
   Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
  
   It might be sensible to put the struct definitions in a .h file if
   these omap registers might be re-usable.
  
   +static struct omap_timer_registers regs_v2 = {
   This might be better to put behind an #if IS_AM335X since it is not
   used otherwise?
  
   +
   +
   +
   Avoid more than one blank line in a row.
  
   +static int done = 0;
   It would be nice if you got rid of this, but otherwise give it a
 more
   useful name like mmio_init_done
  
   +static void beagle_clock_handler_install(rtems_interrupt_handler
 isr)
   +  if (sc != RTEMS_SUCCESSFUL) {
   +rtems_fatal_error_occurred(0xdeadbeef);
   I think there is some capabilities in ARM for bsp fatal error codes
   now. They should be preferred to be used to help debug these fatal
   conditions.
  
   +static inline uint32_t
 beagle_clock_nanoseconds_since_last_tick(void)
   +  return (read_frc() - (uint64_t) last_tick_nanoseconds) *
 10
   / FRCLOCK_HZ;
   This line is  80 characters, please break it or shrink it.
  
   +++ b/c/src/lib/libbsp/arm/beagle/console/console-config.c
   +#define CONSOLE_UART_LSR (*(volatile unsigned int
   *)(BSP_CONSOLE_UART_BASE+0x14))
   Line  80 characters, even with the spacing modified.
  
   +static void beagle_console_init(void)
  
   +while ((CONSOLE_SYSS

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

2014-11-03 Thread Ben Gras

Indeed. I did right away verify I can build  run  test everything for the
beaglebones and the bbxm from mainline. So that seems to have gone fine.

The supporting tools and RSB stuff I am in contact with Chris about.


On Mon, Nov 3, 2014 at 10:23 PM, Joel Sherrill joel.sherr...@oarcorp.com
wrote:


 On 11/3/2014 3:06 PM, Ben Gras wrote:

  All,


  Joel merged these and I updated my blog post to reflect the mainline
 repo. Thanks Joel!

  Thank you Ben for the nice submission!!!

 Now to make sure it is reproducible from here and we have merged
 all the bits into the tools, etc.

  On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com wrote:

  All,

  I have new patches with some last-minute smoothings added; removed
 obsolete beagle.cfg, TODO, and separated the more generic ARM headers into
 a separate commit. The new 3 commits are attached (and in my RTEMS github
 repo).

 Gedare, there is also a diff w.r.t. the previous submission attached as
 requested.



 On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org wrote:

 Hi,

 I don't have time to review, but am OK in principle with committing
 this code as it is tested, with the caveat that my previous comments
 be addressed post-merge.

 If you have a diff / commits on top of what you sent before, I'd be
 glad to give those a quick look.

 Thanks for your contribution!
 Gedare

 On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com
 wrote:
  All,
 
  Ok, as promised, I rebased and re-tested and have found  included a
  portable way of making the SD card image (included in sdcard.sh), to be
  merged with RSB (i.e. some of the tools sdcard.sh relies on are
 missing in
  mainline RSB). Some of Gedare's initial feedback is processed thanks to
  Brandon Matthews. It's tested to run on the original beaglebone,
 beaglebone
  black and qemu linaro. (The assumption is it'll run on the bbxm
 hardware as
  well as it was before rebasing.)
 
  The result is split into 2 patches to show what was Claas's initial
 work.
  This makes them a bit unreadable for the final result from the patches
  unfortunately.
 
  As before, see
 
 http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
  on how to build all the tools, RTEMS executables, sdcard images, and
 run the
  test set from linaro qemu.
 
 
 
  On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com
 wrote:
 
  All,
 
  OK, that seems like a fruitful way to proceed to me.
 
  Then I will do some minor cleanups, rebase, do all the tests again,
 and
  re-submit. There's just one problem I know of that I want to fix
 before the
  first commit happens, and that is that the FAT fs made by mtools
 doesn't
  boot on the HW it seems. (It does on the emulator.) A last-minute
 change -
  switching to mtools instead of dosfstools to use to make the SD card
 image
  because the latter is so linux-only.
 
  Stay tuned.
 
 
 
 
  On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org
 wrote:
 
  Ben, As far as getting this merged, all of my comments can be done as
  a follow-on commit. -Gedare
 
  On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com
  wrote:
   Thanks for the fast  detailed review. Let me get back to it/you.
  
   In the meantime, any other feedback? From anyone I mean.
  
  
  
   On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
 wrote:
  
   Hi Ben,
   Great work. I have a few comments. I skipped the i2c.h and i2c.c
   files. Most of my comments are about style and a few requests to
   refactor some of the larger files. The refactoring can be added to
   your TODO if you like. Please fix the style issues if it is not a
   burden.
  
   +++ b/c/src/lib/libbsp/arm/beagle/README
   +$ ../claas-rtems/configure --target=arm-rtems4.11
   --enable-rtemsbsp=beaglebonewhite beagleboardxm
   Replace claas-rtems with rtems. If RSB support is available, make
 a
   note about it.
  
   +++ b/c/src/lib/libbsp/arm/beagle/TODO
   [...]
   open:
   + . how to handle the interrupt?
  
   What does this mean?
  
   +++ b/c/src/lib/libbsp/arm/beagle/clock.c
   Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
  
   It might be sensible to put the struct definitions in a .h file if
   these omap registers might be re-usable.
  
   +static struct omap_timer_registers regs_v2 = {
   This might be better to put behind an #if IS_AM335X since it is
 not
   used otherwise?
  
   +
   +
   +
   Avoid more than one blank line in a row.
  
   +static int done = 0;
   It would be nice if you got rid of this, but otherwise give it a
 more
   useful name like mmio_init_done
  
   +static void beagle_clock_handler_install(rtems_interrupt_handler
 isr)
   +  if (sc != RTEMS_SUCCESSFUL) {
   +rtems_fatal_error_occurred(0xdeadbeef);
   I think there is some capabilities in ARM for bsp fatal error
 codes
   now. They should be preferred to be used to help debug these fatal
   conditions.
  
   +static

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

2014-11-03 Thread Ben Gras

Good idea, I did it.

On Mon, Nov 3, 2014 at 10:32 PM, Gedare Bloom ged...@rtems.org wrote:

 Please send a note to rtems-users, some may be interested to hear this
 addition. -Gedare

 On Mon, Nov 3, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com wrote:
  Indeed. I did right away verify I can build  run  test everything for
 the
  beaglebones and the bbxm from mainline. So that seems to have gone fine.
 
  The supporting tools and RSB stuff I am in contact with Chris about.
 
 
  On Mon, Nov 3, 2014 at 10:23 PM, Joel Sherrill 
 joel.sherr...@oarcorp.com
  wrote:
 
 
  On 11/3/2014 3:06 PM, Ben Gras wrote:
 
  All,
 
 
  Joel merged these and I updated my blog post to reflect the mainline
 repo.
  Thanks Joel!
 
  Thank you Ben for the nice submission!!!
 
  Now to make sure it is reproducible from here and we have merged
  all the bits into the tools, etc.
 
  On Mon, Nov 3, 2014 at 8:40 PM, Ben Gras b...@shrike-systems.com
 wrote:
 
  All,
 
  I have new patches with some last-minute smoothings added; removed
  obsolete beagle.cfg, TODO, and separated the more generic ARM headers
 into a
  separate commit. The new 3 commits are attached (and in my RTEMS github
  repo).
 
  Gedare, there is also a diff w.r.t. the previous submission attached as
  requested.
 
 
 
  On Mon, Nov 3, 2014 at 3:01 PM, Gedare Bloom ged...@rtems.org wrote:
 
  Hi,
 
  I don't have time to review, but am OK in principle with committing
  this code as it is tested, with the caveat that my previous comments
  be addressed post-merge.
 
  If you have a diff / commits on top of what you sent before, I'd be
  glad to give those a quick look.
 
  Thanks for your contribution!
  Gedare
 
  On Mon, Nov 3, 2014 at 7:20 AM, Ben Gras b...@shrike-systems.com
  wrote:
   All,
  
   Ok, as promised, I rebased and re-tested and have found  included a
   portable way of making the SD card image (included in sdcard.sh), to
   be
   merged with RSB (i.e. some of the tools sdcard.sh relies on are
   missing in
   mainline RSB). Some of Gedare's initial feedback is processed thanks
   to
   Brandon Matthews. It's tested to run on the original beaglebone,
   beaglebone
   black and qemu linaro. (The assumption is it'll run on the bbxm
   hardware as
   well as it was before rebasing.)
  
   The result is split into 2 patches to show what was Claas's initial
   work.
   This makes them a bit unreadable for the final result from the
 patches
   unfortunately.
  
   As before, see
  
  
 http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html
   on how to build all the tools, RTEMS executables, sdcard images, and
   run the
   test set from linaro qemu.
  
  
  
   On Sat, Aug 30, 2014 at 5:50 PM, Ben Gras b...@shrike-systems.com
   wrote:
  
   All,
  
   OK, that seems like a fruitful way to proceed to me.
  
   Then I will do some minor cleanups, rebase, do all the tests again,
   and
   re-submit. There's just one problem I know of that I want to fix
   before the
   first commit happens, and that is that the FAT fs made by mtools
   doesn't
   boot on the HW it seems. (It does on the emulator.) A last-minute
   change -
   switching to mtools instead of dosfstools to use to make the SD
 card
   image
   because the latter is so linux-only.
  
   Stay tuned.
  
  
  
  
   On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org
   wrote:
  
   Ben, As far as getting this merged, all of my comments can be done
   as
   a follow-on commit. -Gedare
  
   On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras 
 b...@shrike-systems.com
   wrote:
Thanks for the fast  detailed review. Let me get back to
 it/you.
   
In the meantime, any other feedback? From anyone I mean.
   
   
   
On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org
 
wrote:
   
Hi Ben,
Great work. I have a few comments. I skipped the i2c.h and
 i2c.c
files. Most of my comments are about style and a few requests
 to
refactor some of the larger files. The refactoring can be added
to
your TODO if you like. Please fix the style issues if it is
 not a
burden.
   
+++ b/c/src/lib/libbsp/arm/beagle/README
+$ ../claas-rtems/configure --target=arm-rtems4.11
--enable-rtemsbsp=beaglebonewhite beagleboardxm
Replace claas-rtems with rtems. If RSB support is available,
 make
a
note about it.
   
+++ b/c/src/lib/libbsp/arm/beagle/TODO
[...]
open:
+ . how to handle the interrupt?
   
What does this mean?
   
+++ b/c/src/lib/libbsp/arm/beagle/clock.c
Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
   
It might be sensible to put the struct definitions in a .h file
if
these omap registers might be re-usable.
   
+static struct omap_timer_registers regs_v2 = {
This might be better to put behind an #if IS_AM335X since it is
not
used otherwise?
   
+
+
+
Avoid more than one blank line in a row

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

2014-08-30 Thread Ben Gras

All,

OK, that seems like a fruitful way to proceed to me.

Then I will do some minor cleanups, rebase, do all the tests again, and
re-submit. There's just one problem I know of that I want to fix before the
first commit happens, and that is that the FAT fs made by mtools doesn't
boot on the HW it seems. (It does on the emulator.) A last-minute change -
switching to mtools instead of dosfstools to use to make the SD card image
because the latter is so linux-only.

Stay tuned.




On Wed, Aug 20, 2014 at 4:20 PM, Gedare Bloom ged...@rtems.org wrote:

 Ben, As far as getting this merged, all of my comments can be done as
 a follow-on commit. -Gedare

 On Thu, Jul 24, 2014 at 4:28 PM, Ben Gras b...@shrike-systems.com wrote:
  Thanks for the fast  detailed review. Let me get back to it/you.
 
  In the meantime, any other feedback? From anyone I mean.
 
 
 
  On Thu, Jul 24, 2014 at 4:45 PM, Gedare Bloom ged...@rtems.org wrote:
 
  Hi Ben,
  Great work. I have a few comments. I skipped the i2c.h and i2c.c
  files. Most of my comments are about style and a few requests to
  refactor some of the larger files. The refactoring can be added to
  your TODO if you like. Please fix the style issues if it is not a
  burden.
 
  +++ b/c/src/lib/libbsp/arm/beagle/README
  +$ ../claas-rtems/configure --target=arm-rtems4.11
  --enable-rtemsbsp=beaglebonewhite beagleboardxm
  Replace claas-rtems with rtems. If RSB support is available, make a
  note about it.
 
  +++ b/c/src/lib/libbsp/arm/beagle/TODO
  [...]
  open:
  + . how to handle the interrupt?
 
  What does this mean?
 
  +++ b/c/src/lib/libbsp/arm/beagle/clock.c
  Why is the entire file ifdef'd on ARM_MULTILIB_ARCH_V4?
 
  It might be sensible to put the struct definitions in a .h file if
  these omap registers might be re-usable.
 
  +static struct omap_timer_registers regs_v2 = {
  This might be better to put behind an #if IS_AM335X since it is not
  used otherwise?
 
  +
  +
  +
  Avoid more than one blank line in a row.
 
  +static int done = 0;
  It would be nice if you got rid of this, but otherwise give it a more
  useful name like mmio_init_done
 
  +static void beagle_clock_handler_install(rtems_interrupt_handler isr)
  +  if (sc != RTEMS_SUCCESSFUL) {
  +rtems_fatal_error_occurred(0xdeadbeef);
  I think there is some capabilities in ARM for bsp fatal error codes
  now. They should be preferred to be used to help debug these fatal
  conditions.
 
  +static inline uint32_t beagle_clock_nanoseconds_since_last_tick(void)
  +  return (read_frc() - (uint64_t) last_tick_nanoseconds) * 10
  / FRCLOCK_HZ;
  This line is  80 characters, please break it or shrink it.
 
  +++ b/c/src/lib/libbsp/arm/beagle/console/console-config.c
  +#define CONSOLE_UART_LSR (*(volatile unsigned int
  *)(BSP_CONSOLE_UART_BASE+0x14))
  Line  80 characters, even with the spacing modified.
 
  +static void beagle_console_init(void)
 
  +while ((CONSOLE_SYSS  1) == 0)
  +  ;
  Is this a fatal loop or is it waiting for hardware to clear something?
 
  +if ((CONSOLE_LSR  (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) ==
  CONSOLE_LSR_THRE) {
  Again  80 characters. Is the test logically equivalent to: if (
  (CONSOLE_LSR  CONSOLE_LSR_THRE) == CONSOLE_LSR_THRE)
 
  +while ((CONSOLE_LSR  CONSOLE_LSR_TEMT) == 0)
  +  ;
  Is this a fatal loop or is it waiting for hardware?
 
  +++ b/c/src/lib/libbsp/arm/beagle/include/bsp.h
  This bsp.h is really long. Probably it should be refactored into other
  headers, including non-public ones.
 
  +static inline void dsb(void)
  +{
  +asm volatile(dsb : : : memory);
  Fix the indentation.
 
  +static inline void flush_data_cache(void)
  Perhaps this should be using _CPU_cache_flush_entire_data()? Perhaps
  there is a difference in that the cache manager code flushes and
  cleans the cache...
 
  +
  +
  +
  +
  Excess newlines. Done a few places in this file.
 
  The comments following the defines for various AM33X_INT_ values go
  off the end of the 80 column character width. Same for some other
  comments following defines for OMAP3_TIMER, AM33X_DMTIMER1, and
  AM335X_TIMER_. And further below for the CM_ WKUP and CM_PER_TIMER7
  defines, and CLKSEL_TIMER1MS_CLK_SEL_SEL5.
 
  +#define OMAP3_TCLR_AR   (1  1)  /* Autoreload or one-shot mode */
  +#define OMAP3_TCLR_PRE  (1  5)  /* Prescaler on */
  +#define OMAP3_TCLR_PTV  2
  This PTV is odd compared to the other defines here. Is it 2 == (11),
  or is there a typo here?
 
  Tabs are used in the OMAP3_CM_ defines, it should be space characters.
  Also tabs are used in the read/write actlr, ttbcr, dacr, rrbr0
  functions and the refresh_tlb function.
 
  +/* i2c stuff */
  +typedef struct {
  ...
  +} beagle_i2c;
  Shouldn't this go in beagle/include/i2c.h?
 
  All of this mmu handling code should be refactored. Where possible, it
  should use the existing code in arm-cp15.h
 
  +++ b/c/src/lib/libbsp/arm/beagle/include/i2c.h
  This header defines static, non

Re: We should release 4.11

2014-08-20 Thread Ben Gras

All,

I'd love the Beagle BSP. I am fighting to find time to polish it, re-test
it, and re-submit the patches.

To decide whether that's feasible, is freezing the code for the release
'any day now' or more like 'any week now'?



On Tue, Aug 19, 2014 at 11:43 PM, Joel Sherrill joel.sherr...@oarcorp.com
wrote:


 On 8/19/2014 4:34 PM, Chris Johns wrote:
  On 20/08/2014 2:38 am, Gedare Bloom wrote:
  Anything holding it up at the moment?
  It would be good to get a formal tool set definition into
 rtems-tools.git.
 
  I am currently testing a change to newlib 19-Aug-2014 which removes an
  old patch we had.
 We need to make sure that we are on a path for the RSB, Debian and RPMs
 to come
 from the same tool versions and patches.

 Also there is likely a todo list for RTEMS itself. Not sure what that is
 off the top
 of my head but a few items:

 + Merge Beagle BSP
 + Merge pending GSOC work
 + 386 context switch SMP synchronization is not right. Others were updated.

 What's the status of the dynamic loader? I suspect it is on its own
 independent
 release arc.


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

 --
 Joel Sherrill, Ph.D. Director of Research  Development
 joel.sherr...@oarcorp.comOn-Line Applications Research
 Ask me about RTEMS: a free RTOS  Huntsville AL 35805
 Support Available(256) 722-9985

 ___
 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: [PATCH] (2 commits squashed into one) Beagle BSP for review

2014-07-24 Thread Ben Gras

(1024*16)));
commented-out.. delete it?

+BSP_START_TEXT_SECTION void beagle_setup_mmu_and_cache(void)
__attribute__ ((weak));
More than 80 characters.

diff --git a/c/src/lib/libbsp/bfin/acinclude.m4
b/c/src/lib/libbsp/bfin/acinclude.m4
index ab6082e..828fd89 100644
--- a/c/src/lib/libbsp/bfin/acinclude.m4
+++ b/c/src/lib/libbsp/bfin/acinclude.m4
diff --git a/c/src/lib/libbsp/powerpc/acinclude.m4
b/c/src/lib/libbsp/powerpc/acinclude.m4
index 6442399..e46fa2b 100644
--- a/c/src/lib/libbsp/powerpc/acinclude.m4
+++ b/c/src/lib/libbsp/powerpc/acinclude.m4
Don't include these changes. Check your tool versions, and if the
correct version of tools does this, provide a separate patch for
generated files.

-Gedare

On Wed, Jul 23, 2014 at 9:00 PM, Ben Gras b...@shrike-systems.com wrote:
All,

Full details on how to reproduce all the work from source repositories to
scripts utilities to write a complete sd card booting RTEMS and test
the
whole thing:

http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html

I am submitting the attached patch for review for merging. If accepted
for
merging, please use the top two commits on

https://github.com/bengras/rtems/tree/beaglebone-wip

which have the same net effect but preserve Claas' work because of the
earlier commit. The squashed version attached is for more convenient
review.

I was ironing out more wrinkles but given recent interest it seems
smarter
to merge sooner and keep polishing from mainline. Nevertheless I have
put a
lot of work into getting it into good shape already.

I have rebased everything on the very latest master and verified

That building all the tools and utilities from scratch work, using the
RTEMS
Source Builder repository (Ubuntu + FreeBSD).
That building the beaglebone and bbxm BSPs and linking them with all the
testsuite programs works (Ubuntu + FreeBSD).
That the beaglexm-emulating linaro qemu executes all of those tests
properly, invoked using a single command line with the scripts in the
RTEMS
tools repository, even though not all pass currently (Ubuntu + FreeBSD).
That loading running over JTAG works, both interactively with gdb and
in a
batch using gdb and the test runner.
That running RTEMS executables using u-boot on the beaglebones from sd
card
work; both with and without MMU enabled at RTEMS start time.
That Claas' earlier commit builds.

Thanks so far to Chris and Brandon for help, support, instructions and
advice in various forms :)

Test results on qemu:
Passed: 497 Failed: 3 Timeouts: 1 Invalid:0

The test results on bbxm over jtag (older):
Passed: 475 Failed: 7 Timeouts: 10 Invalid:0

I want to iron out more wrinkles and build support (ethernet) but giving
the
bsp more exposure and having it in mainline so i don't have to keep
rebasing
testing would be nice at this point.

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

Re: Beagle bsp submit question

2014-07-14 Thread Ben Gras

Ok great. Yes it was gsoc and the commit mentions it.
On Jul 14, 2014 8:10 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote:


 On Jul 14, 2014 12:27 PM, Ben Gras b...@shrike-systems.com wrote:
 
  Dear all,
 
  I'm pretty close to be able to submit an initial version of the Beagle*
 bsp. I'm doing last-minute testing and commit cleanup and that's going
 really well.
 
  It is technically based on Claas Ziemke's GSOC BSP for the Beagleboard.
 Long story short, I rebased it and started hacking on it.
 
  I'm planning to submit it as two commits so his work is cleanly
 preserved. Is that OK?

 Yes. I think that is not just OK buy gives credit where it is due. The
 message on his work should probably mention GSOC. Isn't that what sponsored
 the work?

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

[PATCH] uart-output-char.h: extra offset definition.

2014-07-12 Thread Ben Gras

All,

This patch is submitted as its values are used in my to-be-submitted
beagle bsp.

---
 c/src/lib/libbsp/shared/include/uart-output-char.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/c/src/lib/libbsp/shared/include/uart-output-char.h 
b/c/src/lib/libbsp/shared/include/uart-output-char.h
index b009350..4242901 100644
--- a/c/src/lib/libbsp/shared/include/uart-output-char.h
+++ b/c/src/lib/libbsp/shared/include/uart-output-char.h
@@ -34,6 +34,7 @@
 #define CONSOLE_IIR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x08))
 #define CONSOLE_FCR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x08))
 #define CONSOLE_LCR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x0C))
+#define CONSOLE_MCR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x10))
 #define CONSOLE_LSR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x14))
 #define CONSOLE_SCR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x1C))
 #define CONSOLE_ACR (*(volatile uint32_t *) (BSP_CONSOLE_UART_BASE + 0x20))
@@ -43,6 +44,7 @@
 
 #define CONSOLE_LSR_RDR 0x1
 #define CONSOLE_LSR_THRE 0x20
+#define CONSOLE_LSR_TEMT 0x40
 
 #define BSP_CONSOLE_UART_INIT(dll) \
   do { \
-- 
1.8.3.4

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

Re: BSP question: nested interrupts?

2014-05-02 Thread Ben Gras

All,

Based on the replies, my question wasn't phrased precisely enough -
possibly by underestimating how different our contexts are that we're
operating in. Wouldn't be the first time!

What I was really asking was: does RTEMS expect from a BSP that interrupts
will nest? Or doesn't it matter to the correct functioning of RTEMS? Or is
it something more subtle like 'if interrupt set X is active, interrupt set
Y must still be able to occur.'

I gather it's (ideally?) the latter, where Y are based on the highest
priority level in X. Which is fine for me, that's pretty close to the
current state of the beagle code. I was having a hard time allowing X to
occur (without infinite recursion) while X was still active. The active irq
was probably masked implicitly in other BSPs I looked at.




On Thu, May 1, 2014 at 7:53 PM, Chris Nott chr...@vl.com.au wrote:

  Ben,

 Just reviewing interrupts now. I'm not sure your question fully makes
 sense. Unlike smaller embedded arms (eg. Cortex-M3), he interrupts on
 Cortex-A8 are two-phase. There is an external (to the ARM core) interrupt
 controller that feeds interrupts to the ARM IRQ and FIRQ lines. The ARM
 process itself actually only has those two interrupt signals.

 It looks like the code currently handles IRQ and FIRQ serially, so any
 interrupts at each level would be handled serially regardless of priority
 set in the INTC. Presumably what we eventually want to do here for both IRQ
 and FIRQ handlers is, receive the interrupt, immediately set the INTC
 priority to the received interrupt level to block lower priority interrupts
 (including the current interrupt), then acknowledge IRQ/FIRQ and dispatch
 the actual interrupt handler at a lower CPU priority so we can nest
 IRQ/FIRQ and handle higher priority interrupts.

 I'm not quite familiar with ARM family yet to be sure how this is normally
 accomplished or if there is an existing supported ARM with the same
 interrupt controller structure. TI provide sample source including
 interrupt handler that supports this stuff. It might be a good place to
 start playing with it, the source pretty much compiles fine in the RTEMS
 environment.

 Chris.



 On 28/04/2014 4:32 AM, Ben Gras wrote:

Dear all,

  I have a question about managing interrupts in a BSP that I have not been
 able to answer satisfactorily by looking at other BSP code, nor looking
 throught the documentation or googling. Or asking on the IRC channel :)

  My question is: are BSPs expected to allow nested interrupts?
 Specifically, must bsp_interrupt_dispatch() turn interrupts on before
 calling bsp_interrupt_handler_dispatch for everything else to work properly?

  Some BSPs do this, some don't. In the Beagle BSP I can do this by
 masking the currently active interrupt and then enabling them at the CPU
 level; but enabling all interrupts before the hw-specific handler is called
 won't deassert the irq at the peripheral so I'm having trouble seeing how
 that should work.

  Example: if we are in a timer ISR and loop on polling the uptime ticks,
 do we expect the ticks to be able to increase? I'm wondering if any of the
 remaining failing tests are due to this. But also what the best shape of a
 BSP is.

  Thanks!


 ___
 rtems-devel mailing 
 listrtems-devel@rtems.orghttp://www.rtems.org/mailman/listinfo/rtems-devel



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


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

Re: BSP question: nested interrupts?

2014-04-28 Thread Ben Gras

Ok, so the same interrupt will never nest itself then?

Good, thanks!


On Mon, Apr 28, 2014 at 2:14 PM, Sebastian Huber 
sebastian.hu...@embedded-brains.de wrote:

 On 2014-04-28 13:32, Ben Gras wrote:

 Dear all,

 I have a question about managing interrupts in a BSP that I have not been
 able
 to answer satisfactorily by looking at other BSP code, nor looking
 throught the
 documentation or googling. Or asking on the IRC channel :)

 My question is: are BSPs expected to allow nested interrupts?
 Specifically,
 must bsp_interrupt_dispatch() turn interrupts on before calling
 bsp_interrupt_handler_dispatch for everything else to work properly?


 If you want nested interrupts, then you can do it like this BSP:

 http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/
 lpc24xx/irq/irq-dispatch.c



 Some BSPs do this, some don't. In the Beagle BSP I can do this by masking
 the
 currently active interrupt and then enabling them at the CPU level; but
 enabling all interrupts before the hw-specific handler is called won't
 deassert
 the irq at the peripheral so I'm having trouble seeing how that should
 work.


 This is the job of the interrupt controller.  It must block interrupts of
 lower or equal priority.


 Example: if we are in a timer ISR and loop on polling the uptime ticks,
 do we
 expect the ticks to be able to increase? I'm wondering if any of the
 remaining
 failing tests are due to this. But also what the best shape of a BSP is.

 Thanks!


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



 --
 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.
 ___
 rtems-devel mailing list
 rtems-devel@rtems.org
 http://www.rtems.org/mailman/listinfo/rtems-devel

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

Re: [GSOC] RPi BSP RTEMS

2014-04-28 Thread Ben Gras

All,

FWIW to anyone interested in working on the RPi BSP, I noticed the logic in
irq.c is suspect; these tests:

if (BCM2835_REG(BCM2835_IRQ_BASIC) 0x1)

else if ( BCM2835_REG(BCM2835_IRQ_BASIC)
BCM2835_BIT(19))

presumably intended to use bitwise ANDs. Assuming the current RPi BSP is
your starting point, that is hopefully a little shortcut I can contribute.

On Mon, Apr 28, 2014 at 4:34 PM, Alan Cudmore alan.cudm...@gmail.comwrote:

On Fri, Apr 25, 2014 at 6:07 PM, Andre Marques
andre.lousa.marq...@gmail.com wrote:

I'm taking this conversation to the list.

Sorry, I didn't realize that I did not reply to the list.

On 04/23/14 01:21, Alan Cudmore wrote:

On Tue, Apr 22, 2014 at 6:09 AM, Andre Marques
andre.lousa.marq...@gmail.com wrote:

Hello,

I am very pleased to have the opportunity to participate in GSoC with
the RTEMS project!

Welcome! We are glad to have you helping RTEMS.

Now, I have some questions:

1. Does anyone have any recommendation on the proposal?

I like the proposal, but there are a couple of things that may change
slightly:
1. You may want to look into making the UART driver work in interrupt
driven mode, as it is currently polled.

I will have a look at it.

2. For the Framebuffer support, I have been talking to someone off list
that is making progress on implementing a framebuffer driver. We may want
to collaborate with this person for the framebuffer.

Certainly. I was scheduling the framebuffer work for July, should that be
re-scheduled?

July may still work. This gives us time to see what gets accomplished and
the work can be integrating it into the RTEMS tree and testing.

2. Is there any interesting documentation or code you think I should be
looking at right now? For the past month I have been studying the RPi BSP
code and the RPi architecture for the emmc driver that I am doing for my
final project at the university.

From what I can see, you are off to a very good start!

3. There is no wiki page for the Raspberry Pi BSP (at least I have not
found any yet). May I create one using the Open Project template and link
it in the Open Projects page under the BSP section?

I did not create one, so please do.

4. I will create a dedicated development blog for the project very soon.
How frequently should it be updated until may 19?

5. How should the communication happen? Also I am not sure if the Amar
Takhar and Muhammad Adnan e-mails are the correct ones.

I will also be setting a github repository for this, and I am also
looking to get my own RPi and some peripherals (I have one at the
university right now).

I have been setting up my Pi for RTEMS development again. I recently
built u-boot and I am going to try to get it to boot RTEMS images from a
TFTP server. This may help speed up development.

I am also trying out a FT2232H MiniMod evaluation board that is
supposed to work with the Raspberry Pi JTAG interface and the OpenOCD
project. It also serves as the USB uart connector. I have it all wired up
and I hope to try getting it to talk to OpenOCD soon. If I get it working,
I will document everything. The FT2232H Minimod board was $20 USD.

Nice. Looking forward to that, as I still need to look at the debugging
part of the development.

The FT2232H MiniMod is working so far! I am able to use the UART and at
the same time load and run images over the JTAG interface using OpenOCD.
Next, I plan on trying GDB. I will try to document the setup soon, but it
just requires ~10 jumper wires to connect the MiniMod to the Pi GPIO
header.

I need to use it, because I discovered that the RKI image no longer runs
on the Pi. The samples such as ticker still work, so I'm sure it is a
problem with the RKI code itself.

Meanwhile I have set up a development blog and a google calendar for the
project:

http://asuolgsoc2014.wordpress.com/

https://www.google.com/calendar/embed?src=mo5guprvls0ip24rnrjio4ogks%40group.calendar.google.comctz=Europe/Lisbon

I will try to come up with more news during the weekend.

Looks good.

Alan

Thank you,
André Marques.

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

Re: GSOC student question

Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

Re: Building toolset for Beaglebone with RSB fails (for me).

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

Re: [PATCH] Beaglebone: Fix the IRQ handling code

Re: [PATCH] Beaglebone: Fix the IRQ handling code

[PATCH] fail gracefully when pax is not found

BBB GPIO status

Re: [PATCH] Temporary fix for ethernet rx intr hang issue and Disable cache

Re: RTC patch for BBB

Re: RTC patch for BBB

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

Re: [PATCH] Beagle BSP Improvements (GPIO driver)

Re: Beagle bsp improvements RTC driver for beaglebone black

Re: [PATCH] autoconf changes

Re: I was confused

Re: I was confused

[PATCH] fix warnings found when building beagle bsp

Re: [PATCH] fix warnings found when building beagle bsp

[PATCH] beagle bsp - disable watchdog

[PATCH] fix for default configuration for pc386 bsp

Re: [PATCH] more data structures public in mongoose.h

[PATCH] more data structures public in mongoose.h

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Re: We should release 4.11

Re: [PATCH] (2 commits squashed into one) Beagle BSP for review

Re: Beagle bsp submit question

[PATCH] uart-output-char.h: extra offset definition.

Re: BSP question: nested interrupts?

Re: BSP question: nested interrupts?

Re: [GSOC] RPi BSP RTEMS

36 matches

Site Navigation

Mail list logo

Footer information