date:20160724

Re: I2C testcase linking error

2016-07-24 Thread punit vara

https://github.com/punitvara/rtems/tree/new

You can reproduce linking error from this  new branch.

On Sat, Jul 23, 2016 at 11:57 PM, Ben Gras  wrote:

> All,
>
>
> I tried to reproduce this. The I2C branch of your repo doesn't build
> because of struct i2c not being defined. So I #if 0'd out all the
> function bodies in i2c.c, and then everything builds, without linker
> errors.
>
> What is your state now? Are you blocked on this (or anything else)
> still? If so, can you help me reproduce, e.g. by creating a branch that
> definitely exhibits the problem?
>
> I did build from scratch, if you have linking problems it may be an idea
> to rm -rf the beagle build dir and reconfigure and rebuild, in case
> there is a library hanging around with an extra object file it isn't
> supposed to have that the buildsystem isn't updating.
>
> Cheers,
>
> Ben
>
>
> On 22-07-16 14:26, punit vara wrote:
> >
> /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'
>
>
___
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

2016-07-24 Thread Chris Johns

On 23/07/2016 7:41 PM, vivek kukreja wrote:
> 
> Thank you for your prompt advice regarding tap interface.
> I followed this mail chain and successfully run the ping01 example in 
> rtems-libbsd:
> 
> https://lists.rtems.org/pipermail/users/2015-June/029063.html
> 
> Now I can ping and FTP into the QEMU instance from host machine!
> 

Great. If you enable NFS and connect to an NFS server you can write
capture files this way.

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

Re: I2C testcase linking error

2016-07-24 Thread Ben Gras

All,

Aha, I see the problem indeed.

From the output I conclude default-configuration.o is providing symbols
that conflict with your configuration symbols. This suggests
default-configuration.o is pulled in to satisfy some configuration
requirement. This suggests we should put more info in init.c.

I found a small change from your init.c that seems to "fix" this problem:
-#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
+#define CONFIGURE_FILESYSTEM_IMFS

I guess DEVFS is too limited to support the I2C subsystem but I didn't
go so deep as to find out what the ins and outs are once I saw this does
link :-)

On 24-07-16 09:06, punit vara wrote:
> https://github.com/punitvara/rtems/tree/new
>
> You can reproduce linking error from this  new branch. 
>
> On Sat, Jul 23, 2016 at 11:57 PM, Ben Gras  > wrote:
>
> All,
>
>
> I tried to reproduce this. The I2C branch of your repo doesn't build
> because of struct i2c not being defined. So I #if 0'd out all the
> function bodies in i2c.c, and then everything builds, without
> linker errors.
>
> What is your state now? Are you blocked on this (or anything else)
> still? If so, can you help me reproduce, e.g. by creating a branch
> that
> definitely exhibits the problem?
>
> I did build from scratch, if you have linking problems it may be
> an idea
> to rm -rf the beagle build dir and reconfigure and rebuild, in case
> there is a library hanging around with an extra object file it isn't
> supposed to have that the buildsystem isn't updating.
>
> Cheers,
>
> Ben
>
>
> On 22-07-16 14:26, punit vara wrote:
> >
> 
> /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'
>
>

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

Re: I2C testcase linking error

2016-07-24 Thread punit vara

Thanks a lot. :) I2C framework uses IMFS that why I think this solution
worked.

On Sun, Jul 24, 2016 at 11:52 PM, Ben Gras  wrote:

> All,
>
> Aha, I see the problem indeed.
> From the output I conclude default-configuration.o is providing symbols
> that conflict with your configuration symbols. This suggests
> default-configuration.o is pulled in to satisfy some configuration
> requirement. This suggests we should put more info in init.c.
>
> I found a small change from your init.c that seems to "fix" this problem:
> -#define CONFIGURE_USE_DEVFS_AS_BASE_FILESYSTEM
> +#define CONFIGURE_FILESYSTEM_IMFS
>
> I guess DEVFS is too limited to support the I2C subsystem but I didn't go
> so deep as to find out what the ins and outs are once I saw this does link
> :-)
>
>
> On 24-07-16 09:06, punit vara wrote:
>
> https://github.com/punitvara/rtems/tree/new
>
> You can reproduce linking error from this  new branch.
>
> On Sat, Jul 23, 2016 at 11:57 PM, Ben Gras 
> wrote:
>
>> All,
>>
>>
>> I tried to reproduce this. The I2C branch of your repo doesn't build
>> because of struct i2c not being defined. So I #if 0'd out all the
>> function bodies in i2c.c, and then everything builds, without linker
>> errors.
>>
>> What is your state now? Are you blocked on this (or anything else)
>> still? If so, can you help me reproduce, e.g. by creating a branch that
>> definitely exhibits the problem?
>>
>> I did build from scratch, if you have linking problems it may be an idea
>> to rm -rf the beagle build dir and reconfigure and rebuild, in case
>> there is a library hanging around with an extra object file it isn't
>> supposed to have that the buildsystem isn't updating.
>>
>> Cheers,
>>
>> Ben
>>
>>
>> On 22-07-16 14:26, punit vara wrote:
>> >
>> /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'
>>
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: I2C testcase linking error

2016-07-24 Thread Joel Sherrill

The linking error looks like some piece of configuration information is
missing from the application. This results in the configuration information
from the application but being complete and another set being pulled in
from librtemscpu.a. that has the default configuration in it.

On Jul 24, 2016 2:06 AM, "punit vara"  wrote:

> https://github.com/punitvara/rtems/tree/new
>
> You can reproduce linking error from this  new branch.
>
> On Sat, Jul 23, 2016 at 11:57 PM, Ben Gras 
> wrote:
>
>> All,
>>
>>
>> I tried to reproduce this. The I2C branch of your repo doesn't build
>> because of struct i2c not being defined. So I #if 0'd out all the
>> function bodies in i2c.c, and then everything builds, without linker
>> errors.
>>
>> What is your state now? Are you blocked on this (or anything else)
>> still? If so, can you help me reproduce, e.g. by creating a branch that
>> definitely exhibits the problem?
>>
>> I did build from scratch, if you have linking problems it may be an idea
>> to rm -rf the beagle build dir and reconfigure and rebuild, in case
>> there is a library hanging around with an extra object file it isn't
>> supposed to have that the buildsystem isn't updating.
>>
>> Cheers,
>>
>> Ben
>>
>>
>> On 22-07-16 14:26, punit vara wrote:
>> >
>> /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'
>>
>>
>
> ___
> 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] SDHC driver for PowerPC QoriQ

2016-07-24 Thread Nickolay Semyonov

From: Nickolay Semyonov 

Heavily tested with iozone.

---
 c/src/lib/libbsp/powerpc/qoriq/Makefile.am   |3 +
 c/src/lib/libbsp/powerpc/qoriq/esdhc/esdhc.c | 1215 ++
 c/src/lib/libbsp/powerpc/qoriq/include/bsp.h |2 +
 3 files changed, 1220 insertions(+)
 create mode 100644 c/src/lib/libbsp/powerpc/qoriq/esdhc/esdhc.c

diff --git a/c/src/lib/libbsp/powerpc/qoriq/Makefile.am 
b/c/src/lib/libbsp/powerpc/qoriq/Makefile.am
index dea5964..44a67b4 100644
--- a/c/src/lib/libbsp/powerpc/qoriq/Makefile.am
+++ b/c/src/lib/libbsp/powerpc/qoriq/Makefile.am
@@ -109,6 +109,9 @@ libbsp_a_SOURCES += shmsupp/lock.S \
shmsupp/intercom.c \
shmsupp/intercom-mpci.c
 
+# ESDHC
+libbsp_a_SOURCES += esdhc/esdhc.c
+
 libbsp_a_LIBADD = ../../../libcpu/@RTEMS_CPU@/shared/cpuIdent.rel \
../../../libcpu/@RTEMS_CPU@/shared/cache.rel \
../../../libcpu/@RTEMS_CPU@/@exceptions@/rtems-cpu.rel \
diff --git a/c/src/lib/libbsp/powerpc/qoriq/esdhc/esdhc.c 
b/c/src/lib/libbsp/powerpc/qoriq/esdhc/esdhc.c
new file mode 100644
index 000..ec06837
--- /dev/null
+++ b/c/src/lib/libbsp/powerpc/qoriq/esdhc/esdhc.c
@@ -0,0 +1,1215 @@
+/
+ * QorIQ ESDHC memory card driver for RTEMS.
+ *
+ * Copyright (c) 2016 Wolpike LTD.
+ * Author: Evgeniy Bobkov ev...@wolpike.com
+ *
+ * At the moment this driver only supports the SD cards, MMC cards are not 
supported.
+ 
/
+
+#define RTEMS_STATUS_CHECKS_USE_PRINTK
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef RTEMS_BSP_ESDHC_MEMCARD_DEVICE_PATH
+#define RTEMS_BSP_ESDHC_MEMCARD_DEVICE_PATH "/dev/memcard"
+#endif
+
+/*
+ * Set to: 0 - no debugging messages, 1 - only error and some init messages,
+ * 2 - all init mesages, 3 - print each read/write request from upper layer,
+ * 4 - print each SD command, 5 - print all transferred data.
+ */
+#define DEBUG 1
+
+/* Use DMA transfers (1 = DMA, 0 = PIO). */
+#define USE_DMA   1
+
+/*
+ * If SD read or write command fails (for example due to data timeout),
+ * we can retry the attempt. Attention: minimal value for this macro is 1,
+ * because it includes the very first attempt.
+ */
+#define MAX_READ_WRITE_RETRIES5
+
+/* Measure the delays of operations inside esdhc_exec_command() function */
+#define MEASURE_EXECCMD_DELAYS0
+
+/*
+ * Check that write operation was ok by reading back what was written
+ * to SD card and comparing the write and readback buffers.
+ */
+#define CHECK_WRITE_BY_READBACK   0
+
+/* Run the card read speed test after ESDHC initialization */
+#define RUN_CARD_READ_SPEED_TEST  0
+
+/* Run the card write speed test after ESDHC initialization. SD CARD DATA WILL 
BE DESTROYED! */
+#define RUN_CARD_WRITE_SPEED_TEST 0
+
+/*** Standard SD commands 
***/
+
+/* These bits form the command type within the command spec */
+#define SD_R_CRC  0x0100 /* CRC presents */
+#define SD_R_CMD_CODE 0x0200 /* Response must contain the same 
command code as the request */
+#define SD_R_NORESP   0x0400 /* No response is expected */
+#define SD_R_136  0x0800 /* Response length is 136 bits */
+#define SD_R_48   0x1000 /* Response length is 48 bits */
+#define SD_R_48_BUSY  0x2000 /* Response length is 48 bits, check 
busy after response */
+#define SD_T_READ 0x4000 /* This is a read command */
+#define SD_T_WRITE0x8000 /* This is a write command */
+
+/* Command response types */
+#define SD_R0 (SD_R_NORESP)
+#define SD_R1 (SD_R_CRC | SD_R_CMD_CODE | SD_R_48)
+#define SD_R1b(SD_R_CRC | SD_R_CMD_CODE | SD_R_48_BUSY)
+#define SD_R2 (SD_R_CRC | SD_R_136)
+#define SD_R3 (SD_R_48)
+#define SD_R4 (SD_R_48)
+#define SD_R5 (SD_R_CRC | SD_R_CMD_CODE | SD_R_48)
+#define SD_R6 (SD_R_CRC | SD_R_CMD_CODE | SD_R_48)
+#define SD_R7 (SD_R_CRC | SD_R_CMD_CODE | SD_R_48)
+
+/* Command specs */
+#define SD_CMD0   (0  | SD_R0)
+#define SD_CMD2   (2  | SD_R2)
+#define SD_CMD3   (3  | SD_R1)
+#define SD_CMD6   (6  | SD_R1 | SD_T_READ)
+#define SD_CMD7   (7  | SD_R1b)
+#define SD_CMD8   (8  | SD_R7)
+#define SD_CMD9   (9  | SD_R2)
+#define SD_CMD16  (16 | SD_R1)
+#define SD_CMD17  (17 | SD_R1 | SD_T_READ)
+#define SD_CMD18  (18 | SD_R1 | SD_T_READ)
+#define SD_CMD24  (24 | SD_R1 | SD_T_WRITE)
+#define SD_CMD25

CMake build system for RTEMS

2016-07-24 Thread Nickolay Kolchin

CMake build system for RTEMS


Nickolay Semyonov 
Version 0.5

Why
---

1. Use ninja as build tool to improve compile time performance.
2. Get rid of Cygwin/MSYS on Windows. I.e. under Windows we need only
compiler,
cmake and ninja.
3. Better dependencies tracking.

Introduction


- No changes to RTEMS source code were made
- Only i386 currently supported. PowerPC (QoriQ) will be pushed in next
days.
- All checks 'really used in RTEMS code' are performed. I.e. we check for
  functions, include files, prototypes, type sizes, etc.
- 99% samples, sptests, libtests, tmtests, psxtests and psxtmtests are
  compiled.
- 4.11 branch was used. Can be easily adopted to 4.12.

Sample usage:

  $ git clone -b cmake https://github.com/Wolpike/rtems rtems-cmake
  $ cd rtems-cmake
  $ mkdir .build
  $ cd .build
  $ cmake -GNinja -DCMAKE_TOOLCHAIN_FILE=../cmake/cc/i386.cmake ..
  $ ninja

Samples will be in 'testsuites/samples'.

Technically we demonstrate that everything from current RTEMS build system
can
be done in CMake.

We are interested in inclusion this in official RTEMS and are ready to
provide
support if required.

Comparison with Autotools
-

It should be noted that currently autotools and cmake build different
source
code sets, so direct comparison is unfair. But I don't think numbers will
change drastically.

Also on Windows, performance gap is much wider due to Cygwin/MSYS slowness.

TODO: Windows benchmarks.

Tested on Macbook Pro, Retina, Mid 2012, 2,7 GHz Intel Core i7, 16GB.

On all tests 'ninja' wass executed as 'ninja' without additional arguments.

Make was executed with '-j9'.

Configure line:

  --target=i386-rtems \
  --enable-rtemsbsp=pc386 \
  --enable-cxx=yes \
  BSP_PRESS_KEY_FOR_RESET=0 \
  BSP_ENABLE_VGA=0

CMake:
  "-DCMAKE_TOOLCHAIN_FILE=../cmake/cc/i386.cmake -GNinja
-DBSP_ENABLE_VGA=OFF"

CMake "debug" addition: "-DCMAKE_BUILD_TYPE=Debug".
CMake "release" addition: "-DCMAKE_BUILD_TYPE=Release"

Complete testsuite build (--enable-tests)
~

- autotools bootstrap: 9m27.421s.
- autotools configure: 0m12.043s.
- autotools make: 5m15.640s
- autotools make (without changes): 0m19.523s
- autotools make clean: 0m4.509s
- autotools make (after clean): 3m50.755s

- cmake: 0m7.470s
- ninja (default): 0m43.871s
- ninja (debug): 2m34.534s
- ninja (release): 1m17.895s
- ninja (without changes): 0m0.210s
- ninja clean: 0m0.528s
- ninja (after clean): 0m43.288s

After changing 'cpukit/score/include/rtems/system.h':

- autotools make: 3m46.446s
- ninja (default): 0m40.253s

After changing 'cpukit/rtems/src/clockgettod.c' (real code change):

- autotools make: 0m20.993s (tests NOT rebuild !!!)
- ninja (default): 0m7.871s (tests rebuilded)

Only samples build from testsuite
~

- autotools configure: 0m12.043s.
- autotools make: 1m30.290s

- cmake: 0m5.807s
- ninja (default): 0m19.323s
- ninja (debug): 0m32.176s
- ninja (release): 0m31.434s

Conclusion
~~

- For automated CI with 'pull, bootstrap, configure, make' build cycle,
17.5x
  time difference is sounding.
- For 'normal' development 2.5x-5x time improvement is also nice.

Things not implemented
--

- 'managers' selection. Not sure about that. Never used this stuff.
- RTEMS_MULTIPROCESSING support. Need instructions for testing.
- RTEMS_SMP. On TODO list. Currently we don't have multicore systems in
  production, but this can be emulated in qemu-i386 as I understand.
- wrapup. High priority. Currently we don't combine RTEMS libraries in
rtemscpu
  and rtemsbsp. We don't like manual repacking process, but direct linking
may
  require changes in RTEMS source code.
- Documentation. Low priority.
- We generate 'exe' file as RTEMS_XXX_EXECUTABLE result. No 'nxe', 'ralf',
  'bin' or other. It is assumed, that 'exe' file is passed directly to CI
or
  firmware making script.
- ADA support. Need help with testing.
- jffs2, zlib. On TODO list.
- drvmgr. Need help with testing.
- nfsclient. On TODO list, low priority.
- tar tests. On TOOD list.
- Building several BSP at once. This can be done. Low priority.
- Makefile compatibility. This will be pushed in next days.
- libdl. Need help with testing.
- 'rel' files are dropped. They are needed for 'managers' and probably to
  improve code locality. Currently no plans for support.
- Consider using 'FeatureSummary' for RTEMS configuration options.
- RTEMS_NEWLIB is always TRUE. I'm not sure if RTEMS can be compiled
without
  newlib.
- native tools are not build. I.e. no bin2boot.
- CPack support and RTEMS_C_EXECUTABLE recipe will be pushed in next days.
- Support for Eclipse, QCreator and CLion project creation via CMake is not
  tested. 100% includes won't show in project list. No plans to support
this.

P.S. I'm aware about 'waf' build system for RTEMS, but haven't checked. It
would be interesting to compare performance.

Re: CMake build system for RTEMS

2016-07-24 Thread Chris Johns


On 25/07/2016 11:56, Nickolay Kolchin wrote:

We are interested in inclusion this in official RTEMS and are ready to
provide support if required.


Thank you for the offer. If you are interested in contributing to RTEMS 
I am happy to chat about some areas where we need help. Getting 4.11 and 
then 4.12 out means we can move to 5.0 which is the waf build.



P.S. I'm aware about 'waf' build system for RTEMS, but haven't checked. It
would be interesting to compare performance.


I suggest you check it out ..

 https://git.rtems.org/amar/waf.git/

RTEMS is committed to using waf in rtems.git as well as libbsd and other 
areas. It is Python base and we use python in other areas of the project 
for example the RSB. The switch to waf also comes with removal of 
pre-installed header files and that by itself is a massive undertaking. 
The other big area is bring the configuration of RTEMS under control.


The waf branch is stalled because of issues unrelated to it and this is 
unfortunate. The 4.11 release needs to be made but this has stalled 
while I find time to complete the change in the documentation. We will 
then quickly move to 4.12 as a release and after that we are planning on 
5.0 and a waf based build system. The inability for us to release 4.11 
is a problem within the project and it has stalled a number of things 
and I apologise to you and the community for this because it means 
effort is duplicated. Until we can get suitable time spent on the 
remaining tasks things will not change and this includes any build 
system. The current build system needs to go and we all know this and we 
are doing as little as possible with it.


My personal experiences of cmake have been very ordinary and so I have 
no interest in using cmake in RTEMS. I am sorry about this.


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

Re: [PATCH] SDHC driver for PowerPC QoriQ

2016-07-24 Thread Sebastian Huber


Hello Nickolay,

the sources must have a proper license header. Is there a particular 
reason why you didn't use the standard SDHC driver:


https://git.rtems.org/rtems-libbsd/tree/freebsd/sys/dev/sdhci/sdhci.c

It depends a bit on your QorIQ variant, some have nasty silicon bugs in 
the SDHC area.


Please don't use rtems_disk_create_phys() for new code, use 
rtems_blkdev_create() instead.


On 25/07/16 03:47, Nickolay Semyonov wrote:

From: Nickolay Semyonov 

Heavily tested with iozone.


--
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: I2C testcase linking error

Re: Help required with setting up TFTP communication between QEMU instance and host machine

Re: I2C testcase linking error

Re: I2C testcase linking error

Re: I2C testcase linking error

[PATCH] SDHC driver for PowerPC QoriQ

CMake build system for RTEMS

Re: CMake build system for RTEMS

Re: [PATCH] SDHC driver for PowerPC QoriQ

9 matches

Site Navigation

Mail list logo

Footer information