date:20140821

Re: feedback on Re: [PATCH v3] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

2014-08-21 Thread Sebastian Huber


On 21/08/14 11:21, Pavel Pisa wrote:

Hello Sebastian,

On Thursday 21 of August 2014 08:59:15 Sebastian Huber wrote:

On 20/08/14 20:17, Joel Sherrill wrote:

Hi

Initial quick feedback.  I build normally with --enable-rtems-debug
and the tms570ls3137_hdk variant failed to build with this
failure:

arm-rtems4.11-gcc --pipe -DHAVE_CONFIG_H   -I../../..
-I../../../../cpukit/../../../tms570ls3137_hdk/lib/include  -DASM
-march=armv7-r -mthumb -mbig-endian -O2 -ggdb3 -DNDEBUG -Wall
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
-Wnested-externs -march=armv7-r -mthumb -mbig-endian -O2 -ggdb3 -DNDEBUG


Why do we have this -ggdb3 -NDEBUG set?


May be, we have not understood right flags intended use.
I my understanding is, that CFLAGS_OPTIMIZE_V are used for
build without --enable-rtems-debug and flags CFLAGS_DEBUG_V
when --enable-rtems-debug is present.

Then BSP defines in preferred way. We have build with default
options (without internal debug). This means that RTEMS
binary should be optimized and without internal self debug
code (NDEBUG). But want to have as much debug information
for external debugger as possible. This is -ggdb/-ggdb3.


Such options should be set in a BSP independent way.  This NDEBUG is currently 
not controlled by configure options.




In the fact the settings has been taken from other boards.
Actually from
   arm/lpc176x/make/custom/lpc1768_mbed.cfg
but rtl22xx.cfg is the same and -g is in almost every other ARM *.cfg.


Looks like we have to clean this up.

[...]


--
Sebastian Huber, embedded brains GmbH

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

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] GPIO status and I2C start

2014-08-21 Thread Pavel Pisa

Hello everybody,

I am happy that the common GPIO API for RTEMS is developed
but I have some concerns about IRQ handlers registration.

On Sunday 06 of July 2014 00:58:23 Andre Marques wrote:
 Hello,

 The Raspberry Pi GPIO interrupts are already working, and a test case is
 available to test that [1]. A function is also provided to debounce a
 switch if needed. The test case requires two switches and two LEDS using
 the same setup described at [2] by only changing the pin numbers.

https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IRQ/init.c

http://wiki.rtems.org/wiki/index.php/Raspberry_Pi_BSP_Peripherals

The registered handler has no context parameter.This is unfortunate
because there is often need to do same or similar processing
for more interrupt sources and this way it means to write
individual handler or trampoline for each pin.

Please change registered handler prototype to same type
as rtems_interrupt_handler used in rtems_interrupt_handler_install

  typedef void (*rtems_interrupt_handler)(void *);

then function prototype of gpio_enable_interrupt() should add
void *arg and its value should be stored together with handler
pointer and pass to the handler when called.

In the fact, Linux kernel goes even more further where it
statically or runtime allocates numbers for individual
IO pins interrupt sources in the main interrupt table.
Then GPIO provides only function to map GPIO number
to IRQ source number and standard registration
of interrupt handler is used to register to individual
pin interrupt. That has advantage, that drivers of peripherals
do not need to distinguish if their peripheral is connected
to direct external IRQ source or to the GPIO pin which needs
cascade IRQ event processing. In RTEMS that would lead to
use of rtems_interrupt_handler_install even for GPIO IRQs.

But that would require more changes. But passing of context
to the handler is very important and fortunately RTEMS
has switched from other handler prototypes to this standard
years ago already.

Best wishes,

Pavel

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

Re: [PATCH v2] bsp/tms570: implemented support functions to satisfy complete tests build requirements.

2014-08-21 Thread Joel Sherrill

I pushed this and am building now. 

Thanks.
On 8/21/2014 8:38 AM, Pavel Pisa wrote:
 This patch enables to build all RTEMS tests for tms570ls3137_hdk_sdram
 BSP variant in in default build. Debug build with --enable-rtems-debug set
 has succeed for samples subset of tests as well.
 ---
  c/src/lib/libbsp/arm/tms570/Makefile.am|  9 
  .../lib/libbsp/arm/tms570/clock/benchmark_timer.c  | 61 +
  c/src/lib/libbsp/arm/tms570/clock/clock.c  |  4 +-
  .../lib/libbsp/arm/tms570/include/system-clocks.h  | 62 
 ++
  .../arm/tms570/make/custom/tms570ls3137_hdk.cfg|  2 +-
  .../tms570/make/custom/tms570ls3137_hdk_intram.cfg |  2 +-
  .../tms570/make/custom/tms570ls3137_hdk_sdram.cfg  |  2 +-
  c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c  | 44 +++
  c/src/lib/libbsp/arm/tms570/preinstall.am  |  4 ++
  9 files changed, 186 insertions(+), 4 deletions(-)
  create mode 100644 c/src/lib/libbsp/arm/tms570/clock/benchmark_timer.c
  create mode 100644 c/src/lib/libbsp/arm/tms570/include/system-clocks.h
  create mode 100644 c/src/lib/libbsp/arm/tms570/misc/cpucounterread.c

 diff --git a/c/src/lib/libbsp/arm/tms570/Makefile.am 
 b/c/src/lib/libbsp/arm/tms570/Makefile.am
 index 02d7b66..e66cf79 100644
 --- a/c/src/lib/libbsp/arm/tms570/Makefile.am
 +++ b/c/src/lib/libbsp/arm/tms570/Makefile.am
 @@ -39,6 +39,7 @@ include_bsp_HEADERS += include/tms570-rti.h
  include_bsp_HEADERS += include/tms570-vim.h
  include_bsp_HEADERS += include/tms570-pom.h
  include_bsp_HEADERS += include/tms570-sci-driver.h
 +include_bsp_HEADERS += include/system-clocks.h
  
  include_HEADERS += ../../shared/include/tm27.h
  
 @@ -78,6 +79,7 @@ libbsp_a_SOURCES += ../../shared/bsppredriverhook.c
  libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c
  libbsp_a_SOURCES += ../../shared/sbrk.c
  libbsp_a_SOURCES += ../../shared/src/stackalloc.c
 +libbsp_a_SOURCES += ../../shared/cpucounterdiff.c
  
  # Startup
  libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
 @@ -105,6 +107,7 @@ libbsp_a_SOURCES += console/tms570-sci.c
  # Clock
  libbsp_a_SOURCES += ../../shared/clockdrv_shell.h
  libbsp_a_SOURCES += clock/clock.c
 +libbsp_a_SOURCES += clock/benchmark_timer.c
  
  # RTC
  
 @@ -115,9 +118,15 @@ libbsp_a_SOURCES += clock/clock.c
  # Benchmark Timer
  
  # Misc
 +libbsp_a_SOURCES += misc/cpucounterread.c
  
  # Watchdog
  
 +# Cache
 +libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
 +libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
 +libbsp_a_CPPFLAGS += -I$(srcdir)/../../../libcpu/arm/shared/include
 +
  # Start hooks
  libbsp_a_SOURCES += startup/bspstarthooks.c
  
 diff --git a/c/src/lib/libbsp/arm/tms570/clock/benchmark_timer.c 
 b/c/src/lib/libbsp/arm/tms570/clock/benchmark_timer.c
 new file mode 100644
 index 000..b45f0f4
 --- /dev/null
 +++ b/c/src/lib/libbsp/arm/tms570/clock/benchmark_timer.c
 @@ -0,0 +1,61 @@
 +/**
 + * @file benchmark_timer.c
 + *
 + * @ingroup tms570
 + *
 + * @brief clock functions definitions.
 + */
 +
 +/*
 + * Copyright (c) 2014 Pavel Pisa p...@cmp.felk.cvut.cz
 + *
 + * Czech Technical University in Prague
 + * Zikova 1903/4
 + * 166 36 Praha 6
 + * Czech Republic
 + *
 + * Based on LPC24xx and LPC1768 BSP
 + * by embedded brains GmbH and others
 + *
 + * The license and distribution terms for this file may be
 + * found in the file LICENSE in this distribution or at
 + * http://www.rtems.org/license/LICENSE.
 + */
 +
 +#include stdlib.h
 +
 +#include rtems.h
 +#include bsp.h
 +#include bsp/system-clocks.h
 +#include rtems/btimer.h
 +#include rtems/timerdrv.h
 +
 +bool benchmark_timer_find_average_overhead = false;
 +
 +static uint32_t benchmark_timer_base;
 +
 +void benchmark_timer_initialize(void)
 +{
 +  benchmark_timer_base = _CPU_Counter_read();
 +}
 +
 +uint32_t benchmark_timer_read(void)
 +{
 +  uint32_t delta = _CPU_Counter_read() - benchmark_timer_base;
 +
 +  if (benchmark_timer_find_average_overhead) {
 +return delta;
 +  } else {
 +/* TODO check on hardware */
 +if (delta  74) {
 +  return delta - 74;
 +} else {
 +  return 0;
 +}
 +  }
 +}
 +
 +void benchmark_timer_disable_subtracting_average_overhead(bool 
 find_average_overhead )
 +{
 +  benchmark_timer_find_average_overhead = find_average_overhead;
 +}
 diff --git a/c/src/lib/libbsp/arm/tms570/clock/clock.c 
 b/c/src/lib/libbsp/arm/tms570/clock/clock.c
 index 2a8bb5f..4dba949 100644
 --- a/c/src/lib/libbsp/arm/tms570/clock/clock.c
 +++ b/c/src/lib/libbsp/arm/tms570/clock/clock.c
 @@ -29,6 +29,7 @@
  #include bsp.h
  #include bsp/irq.h
  #include bsp/tms570-rti.h
 +#include rtems/counter.h
  
  /**
   *  holds HW counter value since last interrupt event
 @@ -49,6 +50,8 @@ static void 
 tms570_clock_driver_support_initialize_hardware( void )
  
uint32_t microsec_per_tick = 
 rtems_configuration_get_microseconds_per_tick();
  
 +  rtems_counter_initialize_converter(BSP_PLL_OUT_CLOCK);
 +
/*

[PATCH] bsp/tms570: disable huge memory demanding tests for internal RAM build variant.

2014-08-21 Thread Pavel Pisa

BSP completes build with tests and debug enabled for all three variants now

  tms570ls3137_hdk
  tms570ls3137_hdk_intram
  tms570ls3137_hdk_sdram

Even that all enabled tests builds for internal RAM variant, many
of them are expected to fail on hardware because whole tests
including code, data and runtime work area demands has to fit
into 256 kB of RAM.
---
 .../make/custom/tms570ls3137_hdk-testsuite.tcfg| 13 
 .../custom/tms570ls3137_hdk_intram-testsuite.tcfg  | 23 ++
 2 files changed, 23 insertions(+), 13 deletions(-)
 create mode 100644 
c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram-testsuite.tcfg

diff --git 
a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg 
b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg
index 6f722bc..b79994e 100644
--- a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg
+++ b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk-testsuite.tcfg
@@ -4,16 +4,3 @@
 # Format is one line per test that is _NOT_ built.
 #
 
-flashdisk01
-utf8proc01
-spstkalloc02
-fsdosfsname01
-jffs2_fserror
-jffs2_fslink
-jffs2_fspatheval
-jffs2_fspermission
-jffs2_fsrdwr
-jffs2_fssymlink
-jffs2_fstime
-pppd
-mghttpd01
diff --git 
a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram-testsuite.tcfg
 
b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram-testsuite.tcfg
new file mode 100644
index 000..f4f00e8
--- /dev/null
+++ 
b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram-testsuite.tcfg
@@ -0,0 +1,23 @@
+#
+# tms570ls3137 RTEMS Test Database.
+#
+# Format is one line per test that is _NOT_ built.
+#
+
+fileio
+iostream
+pppd
+loopback
+syscall01
+utf8proc01
+monitor02
+mghttpd01
+ftp01
+fsdosfsname01
+jffs2_fserror
+jffs2_fslink
+jffs2_fspatheval
+jffs2_fspermission
+jffs2_fsrdwr
+jffs2_fssymlink
+jffs2_fstime
-- 
1.9.1

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

Re: [PATCH] libchip/dwmac: Make PHY address user configurable.

2014-08-21 Thread Joel Sherrill

How does the user configure the address?

Other than that, I don't see anything.

--joel
On 8/21/2014 10:07 AM, Christian Mauderer wrote:
 From: Christian Mauderer christian.maude...@embedded-brains.de

 This patch allows the user to configure the PHY address for the DWMAC driver 
 by
 giving a pointer to a dwmac_user_cfg structure to network stak via
 rtems_bsdnet_config.ifconfig-drv_ctrl.
 ---
  c/src/libchip/network/dwmac-common.h |  1 +
  c/src/libchip/network/dwmac.c| 31 +++
  c/src/libchip/network/dwmac.h|  8 
  3 files changed, 28 insertions(+), 12 deletions(-)

 diff --git a/c/src/libchip/network/dwmac-common.h 
 b/c/src/libchip/network/dwmac-common.h
 index b61b833..05bf941 100644
 --- a/c/src/libchip/network/dwmac-common.h
 +++ b/c/src/libchip/network/dwmac-common.h
 @@ -227,6 +227,7 @@ typedef struct {
struct mbuf **mbuf_addr_rx;
struct mbuf **mbuf_addr_tx;
const dwmac_cfg *CFG;
 +  int MDIO_BUS_ADDR;
  } dwmac_common_context;
  
  struct dwmac_common_core_ops {
 diff --git a/c/src/libchip/network/dwmac.c b/c/src/libchip/network/dwmac.c
 index 20d87dc..499e02b 100644
 --- a/c/src/libchip/network/dwmac.c
 +++ b/c/src/libchip/network/dwmac.c
 @@ -131,7 +131,7 @@ static int dwmac_if_mdio_read(
if ( phy == -1 ) {
  reg_value = MACGRP_GMII_ADDRESS_PHYSICAL_LAYER_ADDRESS_SET(
reg_value,
 -  self-CFG-MDIO_BUS_ADDR
 +  self-MDIO_BUS_ADDR
);
} else {
  reg_value = MACGRP_GMII_ADDRESS_PHYSICAL_LAYER_ADDRESS_SET(
 @@ -187,7 +187,7 @@ static int dwmac_if_mdio_write(
if ( phy == -1 ) {
  reg_value = MACGRP_GMII_ADDRESS_PHYSICAL_LAYER_ADDRESS_SET(
reg_value,
 -  self-CFG-MDIO_BUS_ADDR
 +  self-MDIO_BUS_ADDR
);
} else {
  reg_value = MACGRP_GMII_ADDRESS_PHYSICAL_LAYER_ADDRESS_SET(
 @@ -347,7 +347,7 @@ static int dwmac_if_interface_stats( void *arg )
volatile macgrp  *macgrp   = self-macgrp;
int   media= 0;
bool  media_ok = dwmac_if_media_status(
 -self, media, self-CFG-MDIO_BUS_ADDR );
 +self, media, self-MDIO_BUS_ADDR );
uint32_t  oui;
uint8_t   model;
uint8_t   revision;
 @@ -364,7 +364,7 @@ static int dwmac_if_interface_stats( void *arg )
  printf( \n );
  eno = dwmac_get_phy_info(
self,
 -  self-CFG-MDIO_BUS_ADDR,
 +  self-MDIO_BUS_ADDR,
oui,
model,
revision );
 @@ -372,7 +372,7 @@ static int dwmac_if_interface_stats( void *arg )
  if ( eno == 0 ) {
printf( PHY 0x%02x: OUI = 0x%04 PRIX32 , Model = 0x%02 PRIX8 , 
 Rev = 
0x%02 PRIX8 \n,
 -  self-CFG-MDIO_BUS_ADDR,
 +  self-MDIO_BUS_ADDR,
oui,
model,
revision );
 @@ -387,7 +387,7 @@ static int dwmac_if_interface_stats( void *arg )
  );
  }
} else {
 -printf( PHY %d communication error\n, self-CFG-MDIO_BUS_ADDR );
 +printf( PHY %d communication error\n, self-MDIO_BUS_ADDR );
}
  
printf( \nHardware counters:\n );
 @@ -1250,7 +1250,7 @@ static int dwmac_update_autonegotiation_params( 
 dwmac_common_context *self )
uint32_t value= self-macgrp-mac_configuration;
int  media= 0;
bool media_ok = dwmac_if_media_status(
 -self, media, self-CFG-MDIO_BUS_ADDR );
 +self, media, self-MDIO_BUS_ADDR );
  
  
if ( media_ok ) {
 @@ -2065,7 +2065,8 @@ static int dwmac_if_attach(
const dwmac_callback_cfg*CALLBACK = driver_config-CALLBACK;
const dwmac_common_desc_ops *DESC_OPS =
  (const dwmac_common_desc_ops *) driver_config-DESC_OPS-ops;
 -
 +  const dwmac_user_cfg*user_cfg =
 +(const dwmac_user_cfg *) bsd_config-drv_ctrl;
  
assert( self != NULL );
assert( bsd_config != NULL );
 @@ -2135,9 +2136,15 @@ static int dwmac_if_attach(
}
  
if ( eno == 0 ) {
 -assert( 32 = driver_config-MDIO_BUS_ADDR );
 +if ( user_cfg == NULL ) {
 +  self-MDIO_BUS_ADDR = driver_config-MDIO_BUS_ADDR;
 +} else {
 +  self-MDIO_BUS_ADDR = user_cfg-MDIO_BUS_ADDR;
 +}
 +
 +assert( 32 = self-MDIO_BUS_ADDR );
  
 -if ( 32  driver_config-MDIO_BUS_ADDR ) {
 +if ( 32  self-MDIO_BUS_ADDR ) {
eno = EINVAL;
  }
}
 @@ -2317,7 +2324,7 @@ int dwmac_if_read_from_phy(
  
if ( arg != NULL ) {
  eno = dwmac_if_mdio_read(
 -  self-CFG-MDIO_BUS_ADDR,
 +  self-MDIO_BUS_ADDR,
self,
phy_reg,
value );
 @@ -2341,7 +2348,7 @@ int dwmac_if_write_to_phy(
  
if ( arg != NULL ) {
  eno = dwmac_if_mdio_write(
 -  self-CFG-MDIO_BUS_ADDR,
 +  self-MDIO_BUS_ADDR,
self,
phy_reg,
val );
 diff --git a/c/src/libchip/network/dwmac.h b/c/src/libchip/network/dwmac.h
 index 9ccf75a..2220aa7 100644
 --- a/c/src/libchip/network/dwmac.h
 +++ b/c/src/libchip/network/dwmac.h
 @@ -31,6 +31,14 @@
  extern C {

Re: [GSOC] GPIO status and I2C start

2014-08-21 Thread Alan Cudmore

Hi Pavel,
Thanks for the feedback, we will definitely get the parameter change in
when the code is submitted.

Alan



On Thu, Aug 21, 2014 at 8:20 AM, Pavel Pisa ppisa4li...@pikron.com wrote:

 Hello everybody,

 I am happy that the common GPIO API for RTEMS is developed
 but I have some concerns about IRQ handlers registration.

 On Sunday 06 of July 2014 00:58:23 Andre Marques wrote:
  Hello,
 
  The Raspberry Pi GPIO interrupts are already working, and a test case is
  available to test that [1]. A function is also provided to debounce a
  switch if needed. The test case requires two switches and two LEDS using
  the same setup described at [2] by only changing the pin numbers.


 https://github.com/asuol/rtems/blob/GPIO_API/testsuites/samples/LIBGPIO_TEST_IRQ/init.c

 http://wiki.rtems.org/wiki/index.php/Raspberry_Pi_BSP_Peripherals

 The registered handler has no context parameter.This is unfortunate
 because there is often need to do same or similar processing
 for more interrupt sources and this way it means to write
 individual handler or trampoline for each pin.

 Please change registered handler prototype to same type
 as rtems_interrupt_handler used in rtems_interrupt_handler_install

   typedef void (*rtems_interrupt_handler)(void *);

 then function prototype of gpio_enable_interrupt() should add
 void *arg and its value should be stored together with handler
 pointer and pass to the handler when called.

 In the fact, Linux kernel goes even more further where it
 statically or runtime allocates numbers for individual
 IO pins interrupt sources in the main interrupt table.
 Then GPIO provides only function to map GPIO number
 to IRQ source number and standard registration
 of interrupt handler is used to register to individual
 pin interrupt. That has advantage, that drivers of peripherals
 do not need to distinguish if their peripheral is connected
 to direct external IRQ source or to the GPIO pin which needs
 cascade IRQ event processing. In RTEMS that would lead to
 use of rtems_interrupt_handler_install even for GPIO IRQs.

 But that would require more changes. But passing of context
 to the handler is very important and fortunately RTEMS
 has switched from other handler prototypes to this standard
 years ago already.

 Best wishes,

 Pavel


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

Re: offlist or1k printf causes crash

2014-08-21 Thread Hesham Moustafa

On Thu, Aug 21, 2014 at 11:44 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:

 On 8/21/2014 4:04 PM, Christian Svensson wrote:
 On Thu, Aug 21, 2014 at 9:56 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 The sp must be updated before the memory can be used. This is just
 a bug otherwise.
 No, 128 byte redzone is an ABI thing both that OpenRISC and x86-64 have.
 The bug in GCC was that redzone was not respected IIRC (if it's the
 same bug that I have in mind).
 OK.

 Would it possibly need to be respected at the beginning of the interrupt?
 And at the transfer via _ISR_Dispatch?
I did so at the beginning of the interrupt, and before jumping to
_Thread_Dispatch from the _ISR_Handler; but I got the same behavior.
 R1 [SP]
 The stack pointer holds the limit of the current stack frame. The first 128 
 bytes below the stack pointer are reserved for leaf functions, and below 
 that are undefined. Stack pointer must be word aligned at all times.
 Christian.. can you review that code?
 Could you point me to the code? I don't know exactly which code and
 version is being used.
 http://git.rtems.org/rtems/tree/cpukit/score/cpu/or1k/rtems/score/cpu.h

 around line 548.  That is implemented using _OR1K_mtspr which is
 around line 336 of

 http://git.rtems.org/rtems/tree/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h

 These asm constraints are always so hard to get right.

 --
 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: offlist or1k printf causes crash

2014-08-21 Thread Joel Sherrill


On 8/21/2014 4:15 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 10:56 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 2:44 PM, Hesham Moustafa wrote:
 Hi,

 I have been debugging since a while or1k code hopefully I'd find
 what's wrong. Here's what I got.
 First I am moving this to devel@ so others can chime in.
 First, I asked about this problem at #openrisc IRC channel, they told
 me the problem might be that I have to take account of the red-zone, I
 asked what's the red-zone and Stefan said the following:
 the first 128 bytes of the stack has to be stepped over, leaf
 functions might use that without modifying the stack pointer, and gcc
 takes advantage of the fact that there is a red zone in non-leaf
 functions prologues too. i.e. it stores things on the stack and *then*
 update the stack pointer
 This is a bug in gcc. We have seen it on the ARM and there was a recent
 dust up from the Linux kernel community because it happened on x86-64.
 My understanding is that there was rework/improvement which triggered
 bugs in backends. But this needs to be fixed.

 The sp must be updated before the memory can be used. This is just
 a bug otherwise.
 He suggested that I add 128 bytes to stack pointer before I jump to
 _ISR_Handler (from start.S). I tried this solution and I was not
 lucky. You may have some ideas where/when this red-zone make problem.
 You probably need to
 Second, I discovered that there is unusual (unalign) exception happens
 when using printf (which does not happen with printk). When I stack, I
 found out the problem happens in rtems_semaphore_obtain(), when trying
 to access the_semaphore data which its pointer is returned (invalid
 pointer) from a call to _Objects_Get_isr_disable(). This exception
 only happens after DISPATCH_NEEDED is true and _ISR_Handler jumps to
 _Thread_Dispatch and make a successful context switch and run the
 first task. The following is a snapshot of the output when
 encountering this problem.
 What's the alignment of the task stack in the port? The stack may not be
 properly aligned for the widest access of the or1k.
 If you mean the following:
 #define CPU_STACK_ALIGNMENT0
 but even if with this macro assigned to 4 or 8, I got the same problem.
 and from linkcmds.base
 bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;
Hmm.. ok .. then we need to know the instruction. 8 is normally a wide
enough alignment since that is the usually like a double or 64-bit access.
 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
 Fatal Error 263572 Halted
 Can you tell what the instruction is? And the address it is trying to
 access.
 The _Objects_Get_isr_disable() function returns a weird address for
 Object (which in tern should be the_semaphore), this address is
 0x8007, it seems like the value of the SR register. All previous
 Object/the_semaphore addresses returned from
 _Objects_Get_isr_disable() are higher addresses, that's why I indicate
 that the last (0x8007) Object address is invalid.
_Objects_Get_isr_disable() will return an address from the RTEMS Workspace
which would tend to be a higher RAM address.

Random thought. Temporarily disable the real hardware clock tick driver
in your BSP and add the simulated clock tick driver. See h8sim BSP's
Makefile
for an example. We need to eliminate that your ISR code is doing the
right thing. You could be getting an interrupt at the wrong time and
just clobbering a register. Doing this will let the test run without
interrupts.

What is the value of _Watchdog_Ticks_since_boot at this fault?

 I set a break point at  a call to _Objects_Get_isr_disable() and
 continued until the call that returns the invalid Object pointer, and
 typed bt to get the following stack:
 Another possibility is that the register/memory constraints on
 enable/disable
 interrupts isn't right and it is confusing gcc. You could be randomly
 clobbering
 registers anytime ISRs are disabled/enabled.

 Christian.. can you review that code?
 
 #0  _Objects_Get_isr_disable (
 information=0x3ba54 _Semaphore_Information,
 id=436273156, location=0x406b4, level_p=0x406b0)
 at 
 ../../../../../../rtems/c/src/../../cpukit/score/src/objectgetisr.c:34
 #1  0x00014294 in _Semaphore_Get_interrupt_disable (
 id=436273156, location=0x406b4, level=0x406b0)
 at 
 ../../cpukit/../../../or1k_or1ksim/lib/include/rtems/rtems/semimpl.h:196
 #2  0x000142e0 in rtems_semaphore_obtain (id=436273156,
 option_set=0, timeout=0)
 at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semobtain.c:47
 #3  0xd648 in rtems_termios_write (arg=0x40730)
 at 
 ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/termios.c:1099
 #4  0x4380 in console_write (major=0, minor=0,
 arg=0x40730)
 at

Re: offlist or1k printf causes crash

2014-08-21 Thread Hesham Moustafa

On Thu, Aug 21, 2014 at 11:54 PM, Joel Sherrill
joel.sherr...@oarcorp.com wrote:

 On 8/21/2014 4:15 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 10:56 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 2:44 PM, Hesham Moustafa wrote:
 Hi,

 I have been debugging since a while or1k code hopefully I'd find
 what's wrong. Here's what I got.
 First I am moving this to devel@ so others can chime in.
 First, I asked about this problem at #openrisc IRC channel, they told
 me the problem might be that I have to take account of the red-zone, I
 asked what's the red-zone and Stefan said the following:
 the first 128 bytes of the stack has to be stepped over, leaf
 functions might use that without modifying the stack pointer, and gcc
 takes advantage of the fact that there is a red zone in non-leaf
 functions prologues too. i.e. it stores things on the stack and *then*
 update the stack pointer
 This is a bug in gcc. We have seen it on the ARM and there was a recent
 dust up from the Linux kernel community because it happened on x86-64.
 My understanding is that there was rework/improvement which triggered
 bugs in backends. But this needs to be fixed.

 The sp must be updated before the memory can be used. This is just
 a bug otherwise.
 He suggested that I add 128 bytes to stack pointer before I jump to
 _ISR_Handler (from start.S). I tried this solution and I was not
 lucky. You may have some ideas where/when this red-zone make problem.
 You probably need to
 Second, I discovered that there is unusual (unalign) exception happens
 when using printf (which does not happen with printk). When I stack, I
 found out the problem happens in rtems_semaphore_obtain(), when trying
 to access the_semaphore data which its pointer is returned (invalid
 pointer) from a call to _Objects_Get_isr_disable(). This exception
 only happens after DISPATCH_NEEDED is true and _ISR_Handler jumps to
 _Thread_Dispatch and make a successful context switch and run the
 first task. The following is a snapshot of the output when
 encountering this problem.
 What's the alignment of the task stack in the port? The stack may not be
 properly aligned for the widest access of the or1k.
 If you mean the following:
 #define CPU_STACK_ALIGNMENT0
 but even if with this macro assigned to 4 or 8, I got the same problem.
 and from linkcmds.base
 bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;
 Hmm.. ok .. then we need to know the instruction. 8 is normally a wide
 enough alignment since that is the usually like a double or 64-bit access.
 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
 Fatal Error 263572 Halted
 Can you tell what the instruction is? And the address it is trying to
 access.
 The _Objects_Get_isr_disable() function returns a weird address for
 Object (which in tern should be the_semaphore), this address is
 0x8007, it seems like the value of the SR register. All previous
 Object/the_semaphore addresses returned from
 _Objects_Get_isr_disable() are higher addresses, that's why I indicate
 that the last (0x8007) Object address is invalid.
 _Objects_Get_isr_disable() will return an address from the RTEMS Workspace
 which would tend to be a higher RAM address.

 Random thought. Temporarily disable the real hardware clock tick driver
 in your BSP and add the simulated clock tick driver. See h8sim BSP's
 Makefile
 for an example. We need to eliminate that your ISR code is doing the
 right thing. You could be getting an interrupt at the wrong time and
 just clobbering a register. Doing this will let the test run without
 interrupts.

 What is the value of _Watchdog_Ticks_since_boot at this fault?

5. Pleaes note that I replaced ticker wake_after call (to avoid
waiting long time) with the following
status = rtems_task_wake_after(
  task_index * 5
);

And it was making the context switch to the first task, the unalign
happens when task 1 (after the context switch) tries to use printf and
semaphore obtain.
 I set a break point at  a call to _Objects_Get_isr_disable() and
 continued until the call that returns the invalid Object pointer, and
 typed bt to get the following stack:
 Another possibility is that the register/memory constraints on
 enable/disable
 interrupts isn't right and it is confusing gcc. You could be randomly
 clobbering
 registers anytime ISRs are disabled/enabled.

 Christian.. can you review that code?
 
 #0  _Objects_Get_isr_disable (
 information=0x3ba54 _Semaphore_Information,
 id=436273156, location=0x406b4, level_p=0x406b0)
 at 
 ../../../../../../rtems/c/src/../../cpukit/score/src/objectgetisr.c:34
 #1  0x00014294 in _Semaphore_Get_interrupt_disable (
 id=436273156, location=0x406b4, level=0x406b0)
 at 
 ../../cpukit/../../../or1k_or1ksim/lib/include/rtems/rtems/semimpl.h:196
 #2  0x000142e0 in

Re: offlist or1k printf causes crash

2014-08-21 Thread Joel Sherrill


On 8/21/2014 5:00 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 11:54 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 4:15 PM, Hesham Moustafa wrote:
 On Thu, Aug 21, 2014 at 10:56 PM, Joel Sherrill
 joel.sherr...@oarcorp.com wrote:
 On 8/21/2014 2:44 PM, Hesham Moustafa wrote:
 Hi,

 I have been debugging since a while or1k code hopefully I'd find
 what's wrong. Here's what I got.
 First I am moving this to devel@ so others can chime in.
 First, I asked about this problem at #openrisc IRC channel, they told
 me the problem might be that I have to take account of the red-zone, I
 asked what's the red-zone and Stefan said the following:
 the first 128 bytes of the stack has to be stepped over, leaf
 functions might use that without modifying the stack pointer, and gcc
 takes advantage of the fact that there is a red zone in non-leaf
 functions prologues too. i.e. it stores things on the stack and *then*
 update the stack pointer
 This is a bug in gcc. We have seen it on the ARM and there was a recent
 dust up from the Linux kernel community because it happened on x86-64.
 My understanding is that there was rework/improvement which triggered
 bugs in backends. But this needs to be fixed.

 The sp must be updated before the memory can be used. This is just
 a bug otherwise.
 He suggested that I add 128 bytes to stack pointer before I jump to
 _ISR_Handler (from start.S). I tried this solution and I was not
 lucky. You may have some ideas where/when this red-zone make problem.
 You probably need to
 Second, I discovered that there is unusual (unalign) exception happens
 when using printf (which does not happen with printk). When I stack, I
 found out the problem happens in rtems_semaphore_obtain(), when trying
 to access the_semaphore data which its pointer is returned (invalid
 pointer) from a call to _Objects_Get_isr_disable(). This exception
 only happens after DISPATCH_NEEDED is true and _ISR_Handler jumps to
 _Thread_Dispatch and make a successful context switch and run the
 first task. The following is a snapshot of the output when
 encountering this problem.
 What's the alignment of the task stack in the port? The stack may not be
 properly aligned for the widest access of the or1k.
 If you mean the following:
 #define CPU_STACK_ALIGNMENT0
 but even if with this macro assigned to 4 or 8, I got the same problem.
 and from linkcmds.base
 bsp_stack_align = DEFINED (bsp_stack_align) ? bsp_stack_align : 8;
 Hmm.. ok .. then we need to know the instruction. 8 is normally a wide
 enough alignment since that is the usually like a double or 64-bit access.
 *** BEGIN OF TEST CLOCK TICK ***
 TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
 TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
 Fatal Error 263572 Halted
 Can you tell what the instruction is? And the address it is trying to
 access.
 The _Objects_Get_isr_disable() function returns a weird address for
 Object (which in tern should be the_semaphore), this address is
 0x8007, it seems like the value of the SR register. All previous
 Object/the_semaphore addresses returned from
 _Objects_Get_isr_disable() are higher addresses, that's why I indicate
 that the last (0x8007) Object address is invalid.
 _Objects_Get_isr_disable() will return an address from the RTEMS Workspace
 which would tend to be a higher RAM address.

 Random thought. Temporarily disable the real hardware clock tick driver
 in your BSP and add the simulated clock tick driver. See h8sim BSP's
 Makefile
 for an example. We need to eliminate that your ISR code is doing the
 right thing. You could be getting an interrupt at the wrong time and
 just clobbering a register. Doing this will let the test run without
 interrupts.

 What is the value of _Watchdog_Ticks_since_boot at this fault?

 5. Pleaes note that I replaced ticker wake_after call (to avoid
 waiting long time) with the following
 status = rtems_task_wake_after(
   task_index * 5
 );

 And it was making the context switch to the first task, the unalign
 happens when task 1 (after the context switch) tries to use printf and
 semaphore obtain.
Either your context switch or ISR code appears to be messing the stack up.
Switching out the real hW tick for the simulated idle task one will help us
figure out which one. Plus you can run most tests with this feature
and see how things go.
 I set a break point at  a call to _Objects_Get_isr_disable() and
 continued until the call that returns the invalid Object pointer, and
 typed bt to get the following stack:
 Another possibility is that the register/memory constraints on
 enable/disable
 interrupts isn't right and it is confusing gcc. You could be randomly
 clobbering
 registers anytime ISRs are disabled/enabled.

 Christian.. can you review that code?
 
 #0  _Objects_Get_isr_disable (
 information=0x3ba54 _Semaphore_Information,
 id=436273156, location=0x406b4, level_p=0x406b0)
 at

Re: feedback on Re: [PATCH v3] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

Re: [GSOC] GPIO status and I2C start

Re: [PATCH v2] bsp/tms570: implemented support functions to satisfy complete tests build requirements.

[PATCH] bsp/tms570: disable huge memory demanding tests for internal RAM build variant.

Re: [PATCH] libchip/dwmac: Make PHY address user configurable.

Re: [GSOC] GPIO status and I2C start

Re: offlist or1k printf causes crash

Re: offlist or1k printf causes crash

Re: offlist or1k printf causes crash

Re: offlist or1k printf causes crash

10 matches

Site Navigation

Mail list logo

Footer information