Re: Bump gcc and newlib for 4.12?
On Mar 28, 2016 7:25 PM, "Chris Johns" wrote: > > On 29/03/2016 11:05, Joel Sherrill wrote: >> >> >> Given the feature flag changes in newlib and some warning fine-tuning in >> gcc, I think we should bump the tools on the master on the master after >> the next newlib and pick up a close gcc snapshot. >> >> Hopefully I can merge the random/srandom patch in the next day or two >> and it be in time. >> >> Thoughts? >> > > If you are happy then fine by me. It would be good to get the newlib changes exposed to more users. I will test the tool bump locally before pushing it. I am also concerned that the feature flag change will force tweaks in user code. Plus we have a couple of spots I can't figure out how to remove warnings with the updated newlib. Seems to be when you need bintime and other things at the same time in the shell commands as one example. > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Bump gcc and newlib for 4.12?
On 29/03/2016 11:05, Joel Sherrill wrote: Given the feature flag changes in newlib and some warning fine-tuning in gcc, I think we should bump the tools on the master on the master after the next newlib and pick up a close gcc snapshot. Hopefully I can merge the random/srandom patch in the next day or two and it be in time. Thoughts? If you are happy then fine by me. It would be good to get the newlib changes exposed to more users. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Bump gcc and newlib for 4.12?
Hi Given the feature flag changes in newlib and some warning fine-tuning in gcc, I think we should bump the tools on the master on the master after the next newlib and pick up a close gcc snapshot. Hopefully I can merge the random/srandom patch in the next day or two and it be in time. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score603e: Rename PCI.h to pciimpl.h to avoid name clash on case insensitive file systems
closes #2677.
---
c/src/lib/libbsp/powerpc/score603e/Makefile.am | 2 +-
c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h | 42 --
c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c | 4 +--
.../lib/libbsp/powerpc/score603e/PCI_bus/pciimpl.h | 42 ++
.../libbsp/powerpc/score603e/PCI_bus/universe.c| 2 +-
c/src/lib/libbsp/powerpc/score603e/preinstall.am | 6 ++--
6 files changed, 49 insertions(+), 49 deletions(-)
delete mode 100644 c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h
create mode 100644 c/src/lib/libbsp/powerpc/score603e/PCI_bus/pciimpl.h
diff --git a/c/src/lib/libbsp/powerpc/score603e/Makefile.am
b/c/src/lib/libbsp/powerpc/score603e/Makefile.am
index 2e9eebb..07daafe 100644
--- a/c/src/lib/libbsp/powerpc/score603e/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/score603e/Makefile.am
@@ -32,7 +32,7 @@ console_SOURCES = console/85c30.c console/85c30.h
console/console.c \
console/tbl85c30.c console/consolebsp.h
include_bsp_HEADERS = ../../powerpc/shared/pci/pci.h \
- PCI_bus/PCI.h \
+ PCI_bus/pciimpl.h \
../../powerpc/shared/residual/residual.h \
../../powerpc/shared/residual/pnp.h \
../../powerpc/shared/console/consoleIo.h
diff --git a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h
b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h
deleted file mode 100644
index 7b1526f..000
--- a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/PCI.h
+++ /dev/null
@@ -1,42 +0,0 @@
-/**
- * @file
- *
- * This include file contains prototypes for chips attached to the
- * PCI bus.
- */
-
-/*
- * COPYRIGHT (c) 1989-2009.
- * On-Line Applications Research Corporation (OAR).
- *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#ifndef __PCI_h
-#define __PCI_h
-
-/*
- * PCI.c
- */
-
-void PCI_bus_write(
- volatile uint32_t * _addr,
- uint32_t _data
-);
-
-uint32_t PCI_bus_read(
- volatile uint32_t * _addr
-);
-
-uint32_t Read_pci_device_register(
- uint32_t address
-);
-
-void Write_pci_device_register(
- uint32_t address,
- uint32_t data
-);
-
-#endif
diff --git a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c
b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c
index a2e084a..a5f697b 100644
--- a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c
+++ b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/flash.c
@@ -1,5 +1,5 @@
/*
- * COPYRIGHT (c) 1989-2009.
+ * COPYRIGHT (c) 1989-2009,2016.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may be
@@ -14,7 +14,7 @@
#include
#include
-#include "PCI.h"
+#include
/*
* SCORE603e_FLASH_Disable
diff --git a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/pciimpl.h
b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/pciimpl.h
new file mode 100644
index 000..c0b21b4
--- /dev/null
+++ b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/pciimpl.h
@@ -0,0 +1,42 @@
+/**
+ * @file
+ *
+ * This include file contains prototypes for chips attached to the
+ * PCI bus.
+ */
+
+/*
+ * COPYRIGHT (c) 1989-2009, 2016.
+ * On-Line Applications Research Corporation (OAR).
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifndef __BSP_PCIimpl_h
+#define __BSP_PCIimpl_h
+
+/*
+ * PCI.c
+ */
+
+void PCI_bus_write(
+ volatile uint32_t * _addr,
+ uint32_t _data
+);
+
+uint32_t PCI_bus_read(
+ volatile uint32_t * _addr
+);
+
+uint32_t Read_pci_device_register(
+ uint32_t address
+);
+
+void Write_pci_device_register(
+ uint32_t address,
+ uint32_t data
+);
+
+#endif
diff --git a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/universe.c
b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/universe.c
index c373aa6..8565236 100644
--- a/c/src/lib/libbsp/powerpc/score603e/PCI_bus/universe.c
+++ b/c/src/lib/libbsp/powerpc/score603e/PCI_bus/universe.c
@@ -14,7 +14,7 @@
#include
#include
-#include "PCI.h"
+#include
typedef struct {
uint32_t PCI_ID; /* 0x8003 */
diff --git a/c/src/lib/libbsp/powerpc/score603e/preinstall.am
b/c/src/lib/libbsp/powerpc/score603e/preinstall.am
index da25a43..042bb47 100644
--- a/c/src/lib/libbsp/powerpc/score603e/preinstall.am
+++ b/c/src/lib/libbsp/powerpc/score603e/preinstall.am
@@ -69,9 +69,9 @@ $(PROJECT_INCLUDE)/bsp/pci.h: ../../powerpc/shared/pci/pci.h
$(PROJECT_INCLUDE)/
$(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/pci.h
PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/pci.h
-$(PROJECT_INCLUDE)/bsp/PCI.h: PCI_bus/PCI.h $(PROJECT_INCLUDE)/bsp/$(dirstamp)
- $(INSTALL_DATA) $< $(PROJECT_INCLUDE)/bsp/PCI.h
-PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/PCI.h
+$(PROJECT_INCLUDE)/bsp/pciimpl.h: PC
Re: BBB GSoC Projects was Re: Gsoc 2016 project proposal
Hi Marcos and all, As you suggested me I took StarterWare as reference and writing function prototypes. I hosted my blog for PWM driver development tracking so I can note down my day to day work and you can easily read in which direction I am working. I will update this frequently. You can visit this link. http://punitvara.github.io/rtems%20drivers/2016/02/28/basic-function Please review my post and suggest me if improvement is needed in function prototypes. I hope it is easier way for you to evaluate and review my work. :-) Thanks, Punit On Wed, Mar 16, 2016 at 1:32 AM, Marcos Díaz wrote: > Don't forget that TI has some baremetal drivers (StarterWare) for > beagle bone. You can base your work with it. > > On Tue, Mar 15, 2016 at 4:58 PM, Marcos Díaz > wrote: >> On Tue, Mar 15, 2016 at 4:20 PM, punit vara wrote: >>> On Tue, Mar 15, 2016 at 12:24 PM, punit vara wrote: On Mon, Mar 14, 2016 at 7:07 PM, punit vara wrote: > On Wed, Mar 9, 2016 at 1:38 AM, punit vara wrote: >> >> >> >> On Sun, Mar 6, 2016 at 8:54 PM, punit vara wrote: >>> >>> >>> >>> On Sun, Mar 6, 2016 at 2:09 PM, Ketul Shah >>> wrote: Hello Punit and all, According to me, Punit you must have completed some gpio test through gpio API that was merged last year. So till the final result of accepted student you can start working with PWM driver that plays an important role for any embedded project. This would be a good kick-start for you as well as a strong reason to showcase in your proposal. Try to give hardware test and post the video if possible. Coming to further I2C and SPI can be next milestones. To me these should be at the highest priorities. I had done I2C driver but was not able to make the hardware test. So you can also refer that and come up with the output along with best modifications. Next target you can set for SPI after both drivers are tested and committed. For the references you can always have a loot at code of GPIO API,MINIX,FreeBSD for BBB drivers. Any suggestions ? In case of any queries you can always ping. Cheers, Ketul On 5 March 2016 at 01:02, Marcos Díaz wrote: > > We use I2c but using drivers from TI's baremetal drivers they provide > in their StarterWare software suite. > So, currently we cannot commit that into RTEMS. > But those drivers should be very useful to port to RTEMS. > > On Wed, Mar 2, 2016 at 5:53 PM, Joel Sherrill wrote: >> >> >> >> On Wed, Mar 2, 2016 at 2:22 PM, Marcos Díaz >> wrote: >>> >>> >>> >>> On Wed, Mar 2, 2016 at 4:56 PM, Joel Sherrill >>> wrote: On Wed, Mar 2, 2016 at 1:41 PM, punit vara wrote: > > Yes I have checked previous year work of ketul . He has done ADC > and GPIO BSP . It seems SPI,USB BSP need to be developed as I > have checked rtems.git and I am not sure about I2C .I asked last > year student Ketul .According to him , I2c is also need to be > modified. I tried to contact Ben but he is unreachable on mailing > list :-( > Let me reach out to Ketul and see if a private ping helps. Start with the assumption that USB needs work. That involves the rtems-libbsd tree and there is likely code to import from FreeBSD that will help a lot. SPI and i2c are close to one another in my understanding. Likely Ketul is referring to changes in the RTEMS i2c interfaces. My recollection is that the NIC had performance issues based on the version of U-Boot used. There was some traffic at the end of GSoC about this. I don't know if it was ever resolved. But the NIC should work. Maybe worth benchmarking. >>> >>> We had more of these problems when trying to use I2C. It was fixed >>> in >>> https://git.rtems.org/rtems/commit/?id=8c5c53f4788eb74264a053f8293fed26da85b764. >>> I think we dont need tos ee these problems any more >> >> Marcos.. does this mean that the BBB i2c is complete now? >> >> And is my understanding that this covers SPI correct? >> >> What else on the BBB is left? >> >> --joel >> --joel > On Thu, Mar 3, 2016 at 12:57 AM, Joel Sherrill >>
Re: Rtems-test cortex-m3
Hello, we were trying to get Sebastian's patches to work on the latest qemu. It seems the board is running ok on qemu 2.5.50 without the patches except for: -Memory hack: The memory on this board is still fixed to default value. I already submit a patch that allows you to change the memory size we are waiting for revision. -Disable-priority_mask: this patch does not apply directly and rtems is running without it. So I run the rtems-test script: ./rtems-test --log=lm3s6965_qemu --timeout=60 --rtems-bsp=lm3s6965_qemu --rtems-tools=/home/aurelio-remonda/rtems/install /home/aurelio-remonda/rtems/build/arm-rtems4.11/c/lm3s6965/testsuites/ Passed: 342 Failed: 0 Timeouts: 175 Invalid:0 - Total:517 Average test time: 0:00:15.392969 Testing time : 2:12:38.165222 And then again with default time out: ./rtems-test --log=lm3s6965_qemu --rtems-bsp=lm3s6965_qemu --rtems-tools=/home/aurelio-remonda/rtems/install /home/aurelio-remonda/rtems/build/arm-rtems4.11/c/lm3s6965/testsuites/ Passed: 345 Failed: 0 Timeouts: 172 Invalid:0 - Total:517 Average test time: 0:00:46.056823 Testing time : 6:36:51.377917 So the test resulting in timeouts are known cases? Any of these test will pass if I set a larger timeout value? Do you think we can change the qemu version for this board? On Mon, Jan 11, 2016 at 4:54 PM, Aurelio Remonda wrote: > On Mon, Jan 11, 2016 at 3:47 AM, Sebastian Huber > wrote: >> >> >> On 08/01/16 17:41, Aurelio Remonda wrote: >>> >>> Thanks for your answers! I am running the tests for >>> realview_pbx_a9_qemu for the moment. >>> I have a few questions if you don't mind >>> >>> With the git repository version of rtems >>> ./rtems-test --log=realview_pbx_a9_qemu >>> --rtems-bsp=realview_pbx_a9_qemu >>> --rtems-tools=/home/aurelio-remonda/rtems_a9/install >>> >>> /home/aurelio-remonda/rtems_a9/build/arm-rtems4.11/c/realview_pbx_a9_qemu/testsuites/ >>> >>> The result is: >>> >>> Passed: 523 >>> Failed: 4 >>> Timeouts: 6 >>> Invalid:0 >>> - >>> Total:533 >>> >>> Failures: >>> sp69.exe >>> psxcleanup02.exe >>> sptimecounter02.exe >>> psxcancel.exe >>> Timeouts: >>> psxintrcritical01.exe >>> spintrcritical11.exe >>> spintrcritical07.exe >>> spintrcritical12.exe >>> spintrcritical06.exe >>> spintrcritical15.exe >>> Average test time: 0:00:01.244372 >>> Testing time : 0:11:03.250308 >>> >>> Are those expected fails? >> >> >> Yes, one issue is that timing related tests work bad on Qemu. >> > > So, those test never actually pass with qemu emulation? > >>> >>> On the other hand: >>> When i try to run with the version of rtems we use: >>> ./rtems-test --log=realview_pbx_a9_qemu >>> --rtems-bsp=realview_pbx_a9_qemu >>> --rtems-tools=/home/aurelio-remonda/rtems_gnc/install >>> >>> /home/aurelio-remonda/rtems_gnc/build/arm-rtems4.11/c/realview_pbx_a9_qemu/testsuites/ >>> >>> I get: >>> error: unknown application load error. >>> Any hints of what is the problem? >>> >>> >> >> I would run Qemu in the debugger to figure out the exact error. >> > > This is previous to qemu emulation, i found out i was using the last > rtems-test when it failed. So i start looking the last commits on > rtems-test and found out that on: > https://git.rtems.org/rtems-tools/commit/?id=606c08c8b521dce0121cddcabcc23f3e25ad2ffd > > On this particular piece of code of that patch: > diff --git a/rtemstoolkit/version.py b/rtemstoolkit/version.py > index 542a8e0..3c135b1 100644 > --- a/rtemstoolkit/version.py > +++ b/rtemstoolkit/version.py > @@ -35,9 +35,8 @@ > import sys > -import error > -import git > -import path > +from . import error > +from . import path > > import git was deleted. Is this a mistake? I try adding the line and > the script runs propertly. > Please let me know if im wrong. Thank you in advance. -- Aurelio Remonda Taller Technologies Argentina Software Engineer San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54-351-4217888 / 4218211 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
