Re: [PATCH] score/i386: Add context switch restore external symbol as a marker.
On 22/07/16 08:52, Chris Johns wrote: On 22/07/2016 16:44, Sebastian Huber wrote: The stack pointer is part of the context. If you retrieve the PC from here it should work for all threads. All threads on the i386 arch or all threads on all archs? I would like to make this simpler for all archs. I do not mind if we require something being added to each arch to do this but I would like an interface somewhere and somehow. I don't think that the thread context reconstruction can be done in an architecture independent way. You have different register sets and different ways to store the PC. For example on x86 the PC is on the stack, on ARM you have Context_Control::register_lr, on PowerPC ppc_context::lr which is embedded in Context_Control due to cache line alignment, on SPARC you have Context_Control::o7, and so on. Sorry, I was meaning just a way to get the PC. I would rather provide a global function that provides the data for your consumer (libunwind?) with a common interface for all architectures and an architecture dependent implementation. The debugger could call this function. The consumer is a thread aware TCP gdb server running in RTEMS. For the stack checker extension we have for example _CPU_Context_Get_SP(). _CPU_Context_Get_PC() ? I would like this to be localised to the CPU implementation and something that is figured out when a new port is done. Yes, I think a _CPU_Context_Get_PC() would be the right way to do this. -- 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: [PATCH] score/i386: Add context switch restore external symbol as a marker.
On 22/07/2016 17:05, Sebastian Huber wrote: _CPU_Context_Get_PC() ? I would like this to be localised to the CPU implementation and something that is figured out when a new port is done. Yes, I think a _CPU_Context_Get_PC() would be the right way to do this. Excellent. Thanks for the feedback. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Help required with RTEMS Capture Engine.
Hello Jennifer, I just went through your commits on the Capture Engine and I see you have mentioned about disabling the engine before running trace. This is missing from the capture doc though. We will fix that. Thanks for clearing this out Jennifer. I'm working on live-tracing for GSoC and I think this should be my starting point. Regards, Vivek On Fri, Jul 22, 2016 at 6:09 AM, Chris Johns wrote: > On 22/07/2016 00:39, Jennifer Averett wrote: >> >> If I remember correctly the capture engine should not be >> running when you print and free records. The trace should >> have been stopped then records printed and freed so that >> the records in the buffer are visible when trace is turned >> back on. I don't think the buffer is protected when it is running. > > > Thanks. This makes streaming difficult and so it will need to change at some > point in time. The pre-smp version was designed to allow streaming. > > Vivek, you will have to run a trace and then stop the capture and extract > the data. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Updates and Problems on "Raspberry Pi USB and Ethernet Support" Project
RTEMS: https://github.com/deval-maker/rtems/tree/RPi Libbsd: https://github.com/deval-maker/rtems-libbsd/tree/rpi_usb Deval Shah On Fri, Jul 22, 2016 5:33 AM, Alan Cudmore alan.cudm...@gmail.com wrote: Hi Deval, That is great news! Is this in your bsdlib github repository? I would like to try it out soon. Thanks, Alan On Jul 21, 2016, at 12:57 PM, Deval Shah < deval.ma...@gmail.com > wrote: Hello all, Good news ! The usb_ethernet controller is working. Dr. Joel pointed out to check if I am actually getting the interrupt. So I checked there and found out that there was no entry for USB interrupt. As soon as I added that entry, everything started working. Now I am getting the Power in the USB devices when I plug them in also the Ethernet address. I am adding the init test log below. --- *** LIBBSD INIT 1 TEST *** nexus0: bcm283x_dwcotg0: on nexus0 usbus0 on bcm283x_dwcotg0 usbus0: 480Mbps High Speed USB v2.0 uhub0: on usbus0 Sleeping to see what happens uhub0: 1 port with 1 removable, self powered uhub1: on usbus0 uhub1: MTT enabled uhub1: 5 ports with 4 removable, self powered smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: 5a:ee:60:74:67:92 Stack usage by thread ID NAME LOW HIGH CURRENT AVAILABLE USED 0x09010001 IDLE 0x133148 - 0x134147 0x1340e0 4080 128 0x0a010001 UI1 0x134360 - 0x13c35f 0x13bf88 32752 1008 0x0a010002 TIME 0x13cab0 - 0x144aaf 0x1449f0 32752 332 0x0a010003 IRQS 0x144ab8 - 0x14cab7 0x14c9f8 32752 408 0x0a010004 _BSD 0x15f3f8 - 0x1673f7 0x167330 32752 352 0x0a010005 _BSD 0x167550 - 0x16f54f 0x16f488 32752 240 0x0a010006 _BSD 0x172bb0 - 0x17abaf 0x17aaf0 32752 232 0x0a010007 _BSD 0x17ad50 - 0x182d4f 0x182c88 32752 240 0x0a010008 _BSD 0x182e10 - 0x18ae0f 0x18ad50 32752 232 0x0a010009 _BSD 0x18afb0 - 0x192faf 0x192ee8 32752 240 0x0a01000a _BSD 0x1941d0 - 0x19c1cf 0x19c110 32752 232 0x0a01000b _BSD 0x19c238 - 0x1a4237 0x1a4178 32752 368 0x0a01000c _BSD 0x1a42a0 - 0x1ac29f 0x1ac1e0 32752 232 0x0a01000d _BSD 0x1ac308 - 0x1b4307 0x1b4248 32752 1420 0x0a01000e _BSD 0x1b4370 - 0x1bc36f 0x1bc2b0 32752 472 0x0a01000f _BSD 0x10 - 0x1e5dcf 0x1e5d10 32752 952 *** END OF TEST LIBBSD INIT 1 *** --- I am still not getting the device name attached in the USB port. So I will look into that now. I am not starting a new thread for now. (as per the chat in IRC, I told that I will create another thread to describe the problem.) I will if I get stuck again. Thank you for the help. Deval Shah On Tue, Jul 19, 2016 1:18 PM, Deval Shah deval.ma...@gmail.com wrote: Hello everyone, As per the conversation at IRC I booted the testsuit with turning USB and ethernet on. Also I ran FreeBSD on my Pi and got the bootup log as suggested by Alan and Chris. Here are some observations. 1. After turning on USB in u-boot, I was getting power on USB devices atached. (One of the device I have, has a LED idicator.) But as soon the testsuit (init01) starts, the power to USB goes off. And didn't start afterwords. 2. I am adding relevant part of the FreeBSD boot log of my Pi. (Lines marked with “*” are the ones also coming in my testsuit.) -- *bcm283x_dwcotg0: mem 0x98-0x99 on simplebus0 *usbus0 on bcm283x_dwcotg0 fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver “fb”. fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x1eaac000, screen_size 818688 cryptosoft0: Timecounters tick every 10.000 msec *usbus0: 480Mbps High Speed USB v2.0 bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF ugen0.1: at usbus0 *uhub0: on usbus0 mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/rootfs [rw]... warning: no time-of-day clock registered, system time will not be set accurately *uhub0: 1 port with 1 removable, self powered ugen0.2: at usbus0 #uhub1: on usbus0 #uhub1: MTT enabled Growing root partition to fill device GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them. mmcsd0s2 resized #uhub1: 5 ports with 4 removable, self powered mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 2062528, 2578112, 3093696, 3609280, 4124864, 4640448,ugen0.3: at usbus0 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:06:16:f9 5156032,ugen0.4: at usbus0 5671616, 6187200, 6702784, 7218368,ugen0.5: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; qui
[PATCH] score: Disable RTEMS_NO_RETURN for RTEMS_DEBUG
Do not use RTEMS_NO_RETURN hints for debug configurations to ease use of stack traces in case of fatal errors. --- cpukit/score/include/rtems/score/basedefs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/score/include/rtems/score/basedefs.h b/cpukit/score/include/rtems/score/basedefs.h index 7e691b5..c378635 100644 --- a/cpukit/score/include/rtems/score/basedefs.h +++ b/cpukit/score/include/rtems/score/basedefs.h @@ -99,7 +99,7 @@ */ #if defined(RTEMS_SCHEDSIM) #define RTEMS_NO_RETURN -#elif defined(__GNUC__) +#elif defined(__GNUC__) && !defined(RTEMS_DEBUG) #define RTEMS_NO_RETURN __attribute__((__noreturn__)) #else #define RTEMS_NO_RETURN -- 1.8.4.5 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Relax thread begin extension environment
Update #2752.
---
cpukit/score/src/threadhandler.c | 15 ---
testsuites/sptests/spextensions01/init.c | 74
2 files changed, 82 insertions(+), 7 deletions(-)
diff --git a/cpukit/score/src/threadhandler.c b/cpukit/score/src/threadhandler.c
index 2fa6d07..9f004b9 100644
--- a/cpukit/score/src/threadhandler.c
+++ b/cpukit/score/src/threadhandler.c
@@ -59,13 +59,6 @@ void _Thread_Handler( void )
_Thread_Restore_fp( executing );
/*
- * Take care that 'begin' extensions get to complete before
- * 'switch' extensions can run. This means must keep dispatch
- * disabled until all 'begin' extensions complete.
- */
- _User_extensions_Thread_begin( executing );
-
- /*
* Do not use the level of the thread control block, since it has a
* different format.
*/
@@ -86,6 +79,14 @@ void _Thread_Handler( void )
_Thread_Do_dispatch( cpu_self, level );
/*
+ * Invoke the thread begin extensions in the context of the thread entry
+ * function with thread dispatching enabled. This enables use of dynamic
+ * memory allocation, creation of POSIX keys and use of C++ thread local
+ * storage. Blocking synchronization primitives are allowed also.
+ */
+ _User_extensions_Thread_begin( executing );
+
+ /*
* RTEMS supports multiple APIs and each API can define a different
* thread/task prototype. The following code supports invoking the
* user thread entry point using the prototype expected.
diff --git a/testsuites/sptests/spextensions01/init.c
b/testsuites/sptests/spextensions01/init.c
index 091d66f..7eac443 100644
--- a/testsuites/sptests/spextensions01/init.c
+++ b/testsuites/sptests/spextensions01/init.c
@@ -25,6 +25,10 @@
#include
+#include
+#include
+#include
+
const char rtems_test_name[] = "SPEXTENSIONS 1";
static int counter;
@@ -33,6 +37,48 @@ static int active_extensions = 2;
static rtems_id master_task;
+static bool before_multitasking(void)
+{
+ return _System_state_Is_before_multitasking(_System_state_Get());
+}
+
+static bool life_protected(void)
+{
+ Thread_Control *executing;
+
+ executing = _Thread_Get_executing();
+
+ return (executing->Life.state & THREAD_LIFE_PROTECTED) != 0;
+}
+
+static void assert_normal_thread_context(void)
+{
+ assert(_Thread_Dispatch_is_enabled());
+ assert(!_RTEMS_Allocator_is_owner());
+ assert(!life_protected());
+}
+
+static void assert_life_protected_thread_context(void)
+{
+ assert(_Thread_Dispatch_is_enabled() || before_multitasking());
+ assert(!_RTEMS_Allocator_is_owner());
+ assert(life_protected() || before_multitasking());
+}
+
+static void assert_allocator_protected_thread_context(void)
+{
+ assert(_Thread_Dispatch_is_enabled() || before_multitasking());
+ assert(_RTEMS_Allocator_is_owner());
+ assert(life_protected() || before_multitasking());
+}
+
+static void assert_thread_dispatch_disabled_context(void)
+{
+ assert(!_Thread_Dispatch_is_enabled());
+ assert(!_RTEMS_Allocator_is_owner());
+ assert(!life_protected());
+}
+
static void assert_static_order(int index)
{
assert((counter % active_extensions) == index);
@@ -54,22 +100,26 @@ static void assert_reverse_order(int index)
static bool zero_thread_create(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(0);
+ assert_allocator_protected_thread_context();
return true;
}
static void zero_thread_start(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(0);
+ assert_thread_dispatch_disabled_context();
}
static void zero_thread_restart(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(0);
+ assert_life_protected_thread_context();
}
static void zero_thread_delete(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(0);
+ assert_allocator_protected_thread_context();
}
static void zero_thread_switch(rtems_tcb *a, rtems_tcb *b)
@@ -80,11 +130,13 @@ static void zero_thread_switch(rtems_tcb *a, rtems_tcb *b)
static void zero_thread_begin(rtems_tcb *a)
{
assert_static_order(0);
+ assert_normal_thread_context();
}
static void zero_thread_exitted(rtems_tcb *a)
{
assert_static_order(0);
+ assert_normal_thread_context();
}
static void zero_fatal(
@@ -101,27 +153,32 @@ static void zero_fatal(
static void zero_thread_terminate(rtems_tcb *a)
{
assert_static_order(0);
+ assert_life_protected_thread_context();
}
static bool one_thread_create(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(1);
+ assert_allocator_protected_thread_context();
return true;
}
static void one_thread_start(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(1);
+ assert_thread_dispatch_disabled_context();
}
static void one_thread_restart(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(1);
+ assert_life_protected_thread_context();
}
static void one_thread_delete(rtems_tcb *a, rtems_tcb *b)
{
assert_static_order(1);
+ assert_allocator_protected_thread_context();
}
static void one_thread_switch(rtems_tcb *a, rtems_tcb *b)
I2C testcase linking error
I was testing I2C test case for BBB. When I hit compile I have got following linking error. Any clue what may be error ? arm-rtems4.12-gcc -B../../../../../beagleboneblack/lib/ -specs bsp_specs -qrtems -mcpu=cortex-a8 -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cortex-a8 -o i2c0.exe init.o ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `_Thread_Get_executing': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../cpukit/../../../beagleboneblack/lib/include/rtems/score/percpu.h:704: multiple definition of `__getreent' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../beagleboneblack/lib/include/rtems/score/percpu.h:704: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `_Linker_set__Sysinit__RTEMS_tasks_Initialize_user_tasks_body' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `Configuration' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `rtems_minimum_stack_size' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `Configuration_POSIX_API' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `Configuration_RTEMS_API' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `_Thread_Control_add_on_count' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `_Thread_Control_add_ons' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o): In function `Init': /root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/cpukit/libmisc/../../../../../../../../NEW/c/src/../../cpukit/libmisc/dummy/default-configuration.c:23: multiple definition of `_Thread_Control_size' init.o:/root/development/rtems/b-NEW/arm-rtems4.12/c/beagleboneblack/testsuites/samples/i2c0/../../../../../../../../../NEW/c/src/../../testsuites/samples/i2c0/init.c:34: first defined here ../../../../../beagleboneblack/lib/librtemscpu.a(default-configuration.o
Help required with setting up TFTP communication between QEMU instance and host machine
Hi everyone, I'm working on improving the current tracing framework of RTEMS(Capture Engine and Trace Linker) for GSoC 2016. In the current phase, I have to transport trace files from RTEMS to host machine. I've built rtems-libbsd drivers for xilinx_zynq_19_qemu bsp and all examples are building with QEMU for arm. The testsuite has examples of a TFTP(and NFS) client running on the loopback interface, but I need help with configuring the ethernet interface. If someone has worked on setting up communication between RTEMS target and host machine, or has similar examples please share. Any help is appreciated! PS: As a hack I have tried setting up SSH between the QEMU instance and host but it's a hack. The transport mechanisms will be tested on hardware next. Regards, Vivek ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Help required with setting up TFTP communication between QEMU instance and host machine
On 23/07/2016 3:47 AM, vivek kukreja wrote: I'm working on improving the current tracing framework of RTEMS(Capture Engine and Trace Linker) for GSoC 2016. In the current phase, I have to transport trace files from RTEMS to host machine. I've built rtems-libbsd drivers for xilinx_zynq_19_qemu bsp and all examples are building with QEMU for arm. The testsuite has examples of a TFTP(and NFS) client running on the loopback interface, but I need help with configuring the ethernet interface. Please look at the rcconf01 test: https://git.rtems.org/rtems-libbsd/tree/testsuite/rcconf01/test_main.c#n43 Create an in memory rc.conf file with: hostname=vivek ifconfig_cgem0="inet 1.2.3.4 netmask 255.255.255.0" defaultrouter="1.2.3.1" Call 'rtems_bsd_run_rc_conf_script' with the script. If someone has worked on setting up communication between RTEMS target and host machine, or has similar examples please share. Any help is appreciated! If you are on Linux you need to set up a tap and then get qemu to use the tap. I do not use Linux so I cannot help. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
