Re: GSoC 2015 - Clang support and Eclipse plugin work
Hi Charith, I see you were unable to submit a proposal. Do you plan to work on this still? :) Best, - Asiri On Tue, Mar 24, 2015 at 9:12 PM, Asiri Rathnayake asiri.rathnay...@gmail.com wrote: Hi Gedare, Joel, For clang support, I've made start by following the steps of [1]. I also have an industry contact (llvm/clang committer) who's willing to help me on that side of things. One question I have about this is, how It would be most helpful if your contact would be willing to sign-up in Google Melange as a mentor for RTEMS Project. Please have him/her contact me directly for any clarifications. +1 I've sent a request on Melange. I'm mostly familiar with the llvm backend work, but I think I know (or can find out) enough about Clang to help Charith with his work (if he gets selected, of course). Cheers, - Asiri do we define a success measure for this project? I mean, RTEMS seem to already compile with Clang with some local patches [1], but how do we Somewhat true, but I believe there are problems with using clang that have to do with the pervasive use of gcc spec files. A pre-requisite task may be to get the spec files completely eliminated, which there is an ongoing effort to do with the waf branch of RTEMS [1ing tghe]. I am suspicious that most of what is in the specs files is obsolete and already taken into account inside gcc by our rtems specific tweaks. GCC spec way extension is a way to accomplish things that can be done inside GCC but without modifying GCC source. The specs use predates us having many gcc tweaks. The short version is that a careful review may significantly reduce them. Also I have long had the idea that adding an option for an rtems bsp to gcc and clang could eliminate some needs also. The -B option is mostly to set an include and lib path to get the BSP. Random core dump of thoughts of unsure value. I think it makes the most sense to work from the waf branch and try to help push it forward. +1 evaluate whether the resulting binary is in good shape? should I also be thinking of some test-plan as part of the project? Secondly, will RTEMS has an extensive test-suite [2], and you should be prepared to run it before/after. We have a tool that helps with automation [3]. it be OK if I fork off clang in github and maintain the patches there? Yes, we prefer for gsoc development to be done on github. I haven't yet tried out the RTEMS Eclipse plugin (on my TODO list), but I have an interest in learning Eclipse plugin development. I suppose the objectives of this project would be implement as much as possible in the TODO list of [2]? Yes, but some of those may be obsolete. Perhaps users will chime in about what they would like to see in it. Agreed. And suggesting Eclipse capabilities that are useful is welcomed. Many thanks for your comments. - Charith PS: Hello World exercise attached herewith. Confirmed, thanks. Feel free to add yourself to the Tracking Table for 2015. [1] https://git.rtems.org/amar/waf.git/ [2] https://git.rtems.org/rtems/tree/testsuites [3] https://git.rtems.org/rtems-tools/tree/tester Gedare [1] https://devel.rtems.org/wiki/Projects/CLANG [2] https://devel.rtems.org/wiki/Developer/Eclipse/Information [3] https://devel.rtems.org/wiki/GSoC/GettingStarted ___ 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libi2c allowed to probe on device init
On 02/04/15 09:45, Alexandru-Sever Horin wrote: I have one question, though, is there a plan to port other Linux driver APIs like SPI ? Not from our side, but we need a proper SPI driver API. -- 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: or1k not running hello with sim-scripts or rtems-tester
Hi Dr. Joel, Do you have or1ksim simulator installed? Both depend on it. I ran hello world with sim-scripts now again and it's working fine. Regards, Hesham On Wed, Apr 1, 2015 at 9:09 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: Hi Hesham.. I can't get hello world to run with either framework. Can you take a look? Thanks. -- 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 -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libi2c allowed to probe on device init
Hello Alexandru-Sever,
in case you use the latest RTEMS version, then I would consider to use
the new I2C support:
https://docs.rtems.org/doxygen/cpukit/html/group__I2C.html
For example see:
https://git.rtems.org/rtems/tree/cpukit/dev/i2c
https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01
On 02/04/15 08:48, Alexandru-Sever Horin wrote:
From: Alexandru-Sever Horin alex.seve...@gmail.com
libi2c registration of a device fails if the device initialization fails
Benefits: allows for device probing on multiple addresses
---
cpukit/libi2c/libi2c.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
index 233cb68..315a761 100644
--- a/cpukit/libi2c/libi2c.c
+++ b/cpukit/libi2c/libi2c.c
@@ -736,6 +736,16 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
/* found a free slot; encode slot + 1 ! */
minor = ((i + 1) 13) | RTEMS_LIBI2C_MAKE_MINOR (busno, i2caddr);
+ /* before registering, try to initialize the device to check it's there */
+ if (drvtbl-ops-initialization_entry) {
+err = drvtbl-ops-initialization_entry (rtems_libi2c_major, minor, 0);
+if (err) {
+ LIBUNLOCK ();
+ /* returned value must be negative on failure */
+ return err 0 ? err : -err;
+}
+ }
+
if (name) {
size_t length = strlen (busses[busno].name) + strlen (name) + 2;
str = malloc (length);
@@ -751,9 +761,10 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
/* note that 'umask' is applied to 'mode' */
if (mknod (str, mode, dev)) {
- safe_printf( DRVNM
- Creating device node failed: %s; you can try to do it
manually...\n,
- strerror (errno));
+ safe_printf ( DRVNM
+Creating device node failed: %s;\n
+you can try to do it manually...\n,
+strerror (errno));
}
free (str);
@@ -761,17 +772,11 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
drvs[i].drv = drvtbl;
- if (drvtbl-ops-initialization_entry)
-err =
- drvs[i].drv-ops-initialization_entry (rtems_libi2c_major, minor,
- 0);
- else
-err = RTEMS_SUCCESSFUL;
-
LIBUNLOCK ();
- return err ? -err : minor;
+ return minor;
}
}
+
LIBUNLOCK ();
return -RTEMS_TOO_MANY;
}
--
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] cpukit/libi2c allowed to probe on device init
Hello Sebastian,
Thank you for the suggestion. The API compatible with Linux devices sounds
great.
However, the RTEMS version we are using is a few days before your patches,
and probably I will port a bt firther along the road.
I have one question, though, is there a plan to port other Linux driver
APIs like SPI ?
Thank you,
Alex H
On Thu, Apr 2, 2015 at 9:53 AM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
Hello Alexandru-Sever,
in case you use the latest RTEMS version, then I would consider to use the
new I2C support:
https://docs.rtems.org/doxygen/cpukit/html/group__I2C.html
For example see:
https://git.rtems.org/rtems/tree/cpukit/dev/i2c
https://git.rtems.org/rtems/tree/testsuites/libtests/i2c01
On 02/04/15 08:48, Alexandru-Sever Horin wrote:
From: Alexandru-Sever Horin alex.seve...@gmail.com
libi2c registration of a device fails if the device initialization fails
Benefits: allows for device probing on multiple addresses
---
cpukit/libi2c/libi2c.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
index 233cb68..315a761 100644
--- a/cpukit/libi2c/libi2c.c
+++ b/cpukit/libi2c/libi2c.c
@@ -736,6 +736,16 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
/* found a free slot; encode slot + 1 ! */
minor = ((i + 1) 13) | RTEMS_LIBI2C_MAKE_MINOR (busno,
i2caddr);
+ /* before registering, try to initialize the device to check
it's there */
+ if (drvtbl-ops-initialization_entry) {
+err = drvtbl-ops-initialization_entry (rtems_libi2c_major,
minor, 0);
+if (err) {
+ LIBUNLOCK ();
+ /* returned value must be negative on failure */
+ return err 0 ? err : -err;
+}
+ }
+
if (name) {
size_t length = strlen (busses[busno].name) + strlen (name) + 2;
str = malloc (length);
@@ -751,9 +761,10 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
/* note that 'umask' is applied to 'mode' */
if (mknod (str, mode, dev)) {
- safe_printf( DRVNM
- Creating device node failed: %s; you can try to do
it manually...\n,
- strerror (errno));
+ safe_printf ( DRVNM
+Creating device node failed: %s;\n
+you can try to do it manually...\n,
+strerror (errno));
}
free (str);
@@ -761,17 +772,11 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
drvs[i].drv = drvtbl;
- if (drvtbl-ops-initialization_entry)
-err =
- drvs[i].drv-ops-initialization_entry (rtems_libi2c_major,
minor,
- 0);
- else
-err = RTEMS_SUCCESSFUL;
-
LIBUNLOCK ();
- return err ? -err : minor;
+ return minor;
}
}
+
LIBUNLOCK ();
return -RTEMS_TOO_MANY;
}
--
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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libi2c allowed to probe on device init
From: Alexandru-Sever Horin alex.seve...@gmail.com
libi2c registration of a device fails if the device initialization fails
Benefits: allows for device probing on multiple addresses
---
cpukit/libi2c/libi2c.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
index 233cb68..315a761 100644
--- a/cpukit/libi2c/libi2c.c
+++ b/cpukit/libi2c/libi2c.c
@@ -736,6 +736,16 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
/* found a free slot; encode slot + 1 ! */
minor = ((i + 1) 13) | RTEMS_LIBI2C_MAKE_MINOR (busno, i2caddr);
+ /* before registering, try to initialize the device to check it's there
*/
+ if (drvtbl-ops-initialization_entry) {
+err = drvtbl-ops-initialization_entry (rtems_libi2c_major, minor, 0);
+if (err) {
+ LIBUNLOCK ();
+ /* returned value must be negative on failure */
+ return err 0 ? err : -err;
+}
+ }
+
if (name) {
size_t length = strlen (busses[busno].name) + strlen (name) + 2;
str = malloc (length);
@@ -751,9 +761,10 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
/* note that 'umask' is applied to 'mode' */
if (mknod (str, mode, dev)) {
- safe_printf( DRVNM
- Creating device node failed: %s; you can try to do it
manually...\n,
- strerror (errno));
+ safe_printf ( DRVNM
+Creating device node failed: %s;\n
+you can try to do it manually...\n,
+strerror (errno));
}
free (str);
@@ -761,17 +772,11 @@ rtems_libi2c_register_drv (const char *name,
rtems_libi2c_drv_t * drvtbl,
drvs[i].drv = drvtbl;
- if (drvtbl-ops-initialization_entry)
-err =
- drvs[i].drv-ops-initialization_entry (rtems_libi2c_major, minor,
- 0);
- else
-err = RTEMS_SUCCESSFUL;
-
LIBUNLOCK ();
- return err ? -err : minor;
+ return minor;
}
}
+
LIBUNLOCK ();
return -RTEMS_TOO_MANY;
}
--
2.3.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Uptime difference between FreeBSD and RTEMS
On 02/04/15 03:22, Chris Johns wrote: On 1/04/2015 7:07 pm, Alexander Krutwig wrote: during my work with FreeBSD timecounters, I found out that the FreeBSD timecounters start with an uptime value of 1 second. Developers of FreeBSD told me that this is due to problems in the ARP code. RTEMS uptime is initialized to an uptime value to 0 seconds. Are there any problems if the configuration of the RTEMS uptime is also initialized to 1 second for synchonization? Else, we would have different values for different API functions which is the second option. Are saying there are requirements around for systems to have networking up and running with the first second after RTEMS starting ? I am impressed you can boot, start the BSP timer running, files system up and working (flash?), initialised the network stack and have a valid link all within one 1 second. How long does a recent GigE PHY take to negotiate a link with a switch ? See also: https://lists.freebsd.org/pipermail/freebsd-hackers/2015-April/047504.html https://lists.freebsd.org/pipermail/freebsd-hackers/2015-April/047510.html The FreeBSD network stack is quite complex and I am not able to judge if a change in this area is correct or not. -- 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: or1k not running hello with sim-scripts or rtems-tester
Hi, I checked it out again. For sim-scripts qemu-or1k is working fine. or1ksim was waiting for GDB to connect, I submitted a patch to make it running right away. For RTEMS Tester, every test would run until it times out, because there is no way to force qemu to terminate from RTEMS (unlike or1ksim simulator). sim-scripts/or1ksim is sending a kill signal to qemu-system-or32 once it sees END OF TEST message, can this be done for RTEMS Tester? On Thu, Apr 2, 2015 at 10:53 AM, Hesham ALMatary heshamelmat...@gmail.com wrote: Hi Dr. Joel, Do you have or1ksim simulator installed? Both depend on it. I ran hello world with sim-scripts now again and it's working fine. Regards, Hesham On Wed, Apr 1, 2015 at 9:09 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: Hi Hesham.. I can't get hello world to run with either framework. Can you take a look? Thanks. -- 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 -- Hesham -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] or1k: Send halt signal to or1k simulators when rtems terminates
--- cpukit/score/cpu/or1k/rtems/score/cpu.h | 1 + cpukit/score/cpu/or1k/rtems/score/or1k-utility.h | 11 ++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/cpukit/score/cpu/or1k/rtems/score/cpu.h b/cpukit/score/cpu/or1k/rtems/score/cpu.h index 45aeb08..2d5fa14 100644 --- a/cpukit/score/cpu/or1k/rtems/score/cpu.h +++ b/cpukit/score/cpu/or1k/rtems/score/cpu.h @@ -702,6 +702,7 @@ void _CPU_Context_Initialize( #define _CPU_Fatal_halt(_source, _error ) \ printk(Fatal Error %d.%d Halted\n,_source, _error); \ + _OR1KSIM_CPU_Halt(); \ for(;;) /* end of Fatal Error manager macros */ diff --git a/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h b/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h index 6b238b1..fa8756a 100644 --- a/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h +++ b/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h @@ -362,7 +362,6 @@ static inline void _OR1K_mtspr(uint32_t reg, uint32_t value) #define _OR1K_CPU_Sleep() \ _OR1K_mtspr(CPU_OR1K_SPR_PMR, CPU_OR1K_SPR_PMR_SME) - #define _OR1K_CPU_Suspend() \ _OR1K_mtspr(CPU_OR1K_SPR_PMR, CPU_OR1K_SPR_PMR_SME) @@ -376,6 +375,16 @@ static inline void _OR1K_Sync_pipeline( void ) asm volatile(l.psync); } +/** + * @brief or1ksim simulator can be sent a halt signal from RTEMS to tell + * the running or1ksim process on the host machine to exit. The following + * implementation has no effect on QEMU or hardware implementation and will + * be treated as normal l.nop. + * + */ +#define _OR1KSIM_CPU_Halt() \ + asm volatile (l.nop 0xc) + #else /* ASM */ #endif /* ASM */ -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] or1k: Send halt signal to or1k simulators when rtems terminates
--- cpukit/score/cpu/or1k/rtems/score/cpu.h | 1 + cpukit/score/cpu/or1k/rtems/score/or1k-utility.h | 11 ++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/cpukit/score/cpu/or1k/rtems/score/cpu.h b/cpukit/score/cpu/or1k/rtems/score/cpu.h index 45aeb08..21cbb6d 100644 --- a/cpukit/score/cpu/or1k/rtems/score/cpu.h +++ b/cpukit/score/cpu/or1k/rtems/score/cpu.h @@ -702,6 +702,7 @@ void _CPU_Context_Initialize( #define _CPU_Fatal_halt(_source, _error ) \ printk(Fatal Error %d.%d Halted\n,_source, _error); \ +_OR1KSIM_CPU_Halt(); \ for(;;) /* end of Fatal Error manager macros */ diff --git a/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h b/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h index 6b238b1..fa8756a 100644 --- a/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h +++ b/cpukit/score/cpu/or1k/rtems/score/or1k-utility.h @@ -362,7 +362,6 @@ static inline void _OR1K_mtspr(uint32_t reg, uint32_t value) #define _OR1K_CPU_Sleep() \ _OR1K_mtspr(CPU_OR1K_SPR_PMR, CPU_OR1K_SPR_PMR_SME) - #define _OR1K_CPU_Suspend() \ _OR1K_mtspr(CPU_OR1K_SPR_PMR, CPU_OR1K_SPR_PMR_SME) @@ -376,6 +375,16 @@ static inline void _OR1K_Sync_pipeline( void ) asm volatile(l.psync); } +/** + * @brief or1ksim simulator can be sent a halt signal from RTEMS to tell + * the running or1ksim process on the host machine to exit. The following + * implementation has no effect on QEMU or hardware implementation and will + * be treated as normal l.nop. + * + */ +#define _OR1KSIM_CPU_Halt() \ + asm volatile (l.nop 0xc) + #else /* ASM */ #endif /* ASM */ -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] [rtems-tools] Add QEMU patch for openrisc to recognize halt signals
---
...rminate-qemu-process-upon-receiving-a-hal.patch | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
diff --git
a/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
b/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
new file mode 100644
index 000..8d8f0cd
--- /dev/null
+++ b/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
@@ -0,0 +1,33 @@
+From e4f207ced08631ae991776b227879754289d2a0c Mon Sep 17 00:00:00 2001
+From: Hesham ALMatary heshamelmat...@gmail.com
+Date: Thu, 2 Apr 2015 17:08:09 +0100
+Subject: [PATCH] openrisc: terminate qemu process upon receiving a halt
+ signal.
+
+or1ksim simulator currently handles l.nop 0xC instruction as a halt signal.
Do
+the same for QEMU.
+
+Signed-off-by: Hesham ALMatary heshamelmat...@gmail.com
+---
+ target-openrisc/translate.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
+index dc76789..b024f11 100644
+--- a/target-openrisc/translate.c
b/target-openrisc/translate.c
+@@ -750,6 +750,11 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
+ switch (op1) {
+ case 0x01:/* l.nop */
+ LOG_DIS(l.nop %d\n, I16);
++
++ if(I16 == 0xC) {
++exit(0);
++}
++
+ break;
+
+ default:
+--
+2.1.0
+
--
2.1.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] [RSB] Apply QEMU patch for openrisc that handles halt signals
---
bare/config/devel/qemu-git-1.cfg | 7 +++
1 file changed, 7 insertions(+)
diff --git a/bare/config/devel/qemu-git-1.cfg b/bare/config/devel/qemu-git-1.cfg
index 82544d4..035cf59 100644
--- a/bare/config/devel/qemu-git-1.cfg
+++ b/bare/config/devel/qemu-git-1.cfg
@@ -8,6 +8,8 @@
%include %{_configdir}/base.cfg
+%include %{_configdir}/bare-config.cfg
+
#
# Stable version. Qemu is fast moving.
#
@@ -42,6 +44,11 @@
%patch add qemu
https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
%hash md5 0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
59b684eaaee77f94bdef6a12b6e544e2
+#
+# Patch to send halt signal to qemu-system-or32 process when RTEMS terminates
+#
+%patch add qemu
%{rtems_http_git}/rtems-tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
+
%if %{_host} == mingw32
%patch add qemu
pw://patchwork.ozlabs.org/patch//raw/qemu-channel-win32-cdecls.patch
%endif
--
2.1.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] [RSB] Apply QEMU patch for openrisc that handles halt signals
---
bare/config/devel/qemu-git-1.cfg | 7 +++
1 file changed, 7 insertions(+)
diff --git a/bare/config/devel/qemu-git-1.cfg b/bare/config/devel/qemu-git-1.cfg
index 82544d4..035cf59 100644
--- a/bare/config/devel/qemu-git-1.cfg
+++ b/bare/config/devel/qemu-git-1.cfg
@@ -8,6 +8,8 @@
%include %{_configdir}/base.cfg
+%include %{_configdir}/bare-config.cfg
+
#
# Stable version. Qemu is fast moving.
#
@@ -42,6 +44,11 @@
%patch add qemu
https://gaisler.org/qemu/0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
%hash md5 0003-LEON3-Init-UART-timers-and-CPU-if-we-run-a-RAM-image.patch
59b684eaaee77f94bdef6a12b6e544e2
+#
+# Patch to send halt signal to qemu-system-or32 process when RTEMS terminates
+#
+%patch add qemu
%{rtems_http_git}/rtems-tools/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
+
%if %{_host} == mingw32
%patch add qemu
pw://patchwork.ozlabs.org/patch//raw/qemu-channel-win32-cdecls.patch
%endif
--
2.1.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] [rtems-tools] Add QEMU patch for openrisc to recognize halt signals
---
...rminate-qemu-process-upon-receiving-a-hal.patch | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
diff --git
a/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
b/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
new file mode 100644
index 000..bce856e
--- /dev/null
+++ b/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
@@ -0,0 +1,33 @@
+From 851489a73e99e156baee267d6162e31abfaa66a9 Mon Sep 17 00:00:00 2001
+From: Hesham ALMatary heshamelmat...@gmail.com
+Date: Thu, 2 Apr 2015 17:47:25 +0100
+Subject: [PATCH] openrisc: terminate qemu process upon receiving a halt
+ signal.
+
+or1ksim simulator currently handles l.nop 0xC instruction as
+a halt signal. Do the same for QEMU.
+
+Signed-off-by: Hesham ALMatary heshamelmat...@gmail.com
+---
+ target-openrisc/translate.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
+index dc76789..5fa8ede 100644
+--- a/target-openrisc/translate.c
b/target-openrisc/translate.c
+@@ -750,6 +750,11 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
+ switch (op1) {
+ case 0x01:/* l.nop */
+ LOG_DIS(l.nop %d\n, I16);
++
++if(I16 == 0xC) {
++exit(0);
++}
++
+ break;
+
+ default:
+--
+2.1.0
+
--
2.1.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
