from:"Alan Cudmore"

Re: Raspberry/ARM processor halts when invalidating tlb

2013-08-22 Thread Alan Cudmore


Hi Hesham,
I don't have an answer for you, but you may be able to find some help or 
example code on the raspberrypi.org forums.

A couple of examples:
http://www.raspberrypi.org/phpBB3/viewtopic.php?t=40183p=336705
http://www.raspberrypi.org/phpBB3/viewtopic.php?t=40665p=332205

I avoided the MMU setup on the raspberry pi BSP, because I knew that the 
GPU based bootloader set up the memory for the ARM CPU. More info on the 
whole boot process here:

http://elinux.org/RPi_Software

Another nice thing to have for work like this is a JTAG debugger setup. 
I hope I can get an inexpensive setup for mine before I try to add any 
more drivers.
The readme at the repository below has some good info on setting up JTAG 
on the raspberry pi:

https://github.com/dwelch67/raspberrypi/tree/master/armjtag

Alan


On 8/22/2013 6:48 PM, Hesham Moustafa wrote:

Hey all,

I am working on Raspberry Pi BSP which has ARM1176JZF-S (ARMv6) 
processor on it. Here is what I am doing that causes the processor to 
halt:


At BSP startup, specifically in bsp_start_hook_0 function, I call 
another function that :
1- Initialize first level page tables (sections) with READ/WRITE 
permissions.

2- Invalidate TLB.
3- Enable MMU, Cache, Protection bits in control register.

Initialization is done correctly and the program reaches my 
application (test case), which tries to update first level page table 
entries to force another protection attributes for a memory region. At 
this part, after, or before, modifying the page table entry, I try to 
invalidate TLB but the program halts there. I disable MMU and Caches 
during updating page tables and invalidating TLB.


When removing the function call that invalidates the TLB, the program 
proceed to the end successfully.


Not sure why the processor halts when trying to invalidate the TLB at 
the second time. I hope someone can tell me the reason.


Regards,
Hesham


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


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

Re: How to start contributing towards RTEMS project

2013-09-02 Thread Alan Cudmore


The Raspberry Pi could use drivers:
SPI / SD card access,
I2C Bus
Ethernet ( this could be hard since it is a USB device ) ,
HDMI/graphics console,
Sound?

Alan

On 9/2/2013 4:35 PM, Karel Gardas wrote:

On 09/ 2/13 07:33 AM, Ritesh Harjani wrote:

I have Raspberry pi + ti stellaris lm4f120 launchpad, if it helps.


Well, if you'd like to do some coding exercise, then what about to 
write a driver for LM4F120's EEPROM? I've hoped to do this myself but 
my project has grown up to the size which does not fit into LM4F120's 
FLASH nor RAM so I'm migrating it to STM32F4 now...


Cheers,
Karel


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

[PATCH] Removed check for texinfo 5.x. Binutils 2.24 and gcc 4.8.2 build with GNU texinfo 5.1

2013-12-18 Thread Alan Cudmore

This is for RTEMS Source Builder. Binutils 2.23.x did not build on Ubuntu 13.10 
because of texinfo 5.1. The problem is fixed in Binutils 2.24, so the check for 
texinfo 5.x is no longer needed for this configuration.

---
 rtems/config/tools/rtems-gcc-4.8.2-newlib-cvs-1.cfg | 5 -
 1 file changed, 5 deletions(-)

diff --git a/rtems/config/tools/rtems-gcc-4.8.2-newlib-cvs-1.cfg 
b/rtems/config/tools/rtems-gcc-4.8.2-newlib-cvs-1.cfg
index 15942fc..4a5b642 100644
--- a/rtems/config/tools/rtems-gcc-4.8.2-newlib-cvs-1.cfg
+++ b/rtems/config/tools/rtems-gcc-4.8.2-newlib-cvs-1.cfg
@@ -19,11 +19,6 @@
 %define with_iconv 1
 %endif
 
-# Incompatible with Texinfo 5
-%if %{__makeinfo_ver} = 5.0
- %error Incomaptible version of makeinfo found!
-%endif
-
 #
 # Newlib is from CVS.
 #
-- 
1.8.3.2

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

[PATCH] For PR 2163 - RFS File System - fix group search algorithm bug

2013-12-18 Thread Alan Cudmore

This is for the RFS file system. There is a bug in the group search algorithm 
where it will skip groups, causing blocks to remain unallocated. This is 
dependant on the size of the blocks and number of blocks in a group, so it does 
not always show up. The fix corrects the skipping of groups during the search, 
allowing all of the blocks to be found. 
---
 cpukit/libfs/src/rfs/rtems-rfs-group.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-group.c 
b/cpukit/libfs/src/rfs/rtems-rfs-group.c
index b08e785..a3df955 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-group.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-group.c
@@ -232,10 +232,24 @@ rtems_rfs_group_bitmap_alloc (rtems_rfs_file_system* fs,
   return 0;
 }
 
+/*
+ * If we are still looking back and forth around the 
+ * group_start, then alternate the direction and 
+ * increment the offset on every other iteration.
+ * Otherwise we are marching through the groups, so just
+ * increment the offset.
+ */  
 if (updown)
+{
   direction = direction  0 ? -1 : 1;
+  if ( direction == -1 )
+offset++;
+} 
+else
+{
+   offset++;
+}
 
-offset++;
   }
 
   if (rtems_rfs_trace (RTEMS_RFS_TRACE_GROUP_BITMAPS))
-- 
1.8.3.2

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

[PATCH] For PR 2164 - RFS File System - fix bitmap_create_search loop bug

2013-12-18 Thread Alan Cudmore

This is for the RFS file system. There is a bug in the 
rtems_rfs_bitmap_create_search loop. It is supposed to iterate over the range 
of bits in a search element ( usually 32 bits ), so it should loop through bits 
0 through 31. Instead it loops through 0 - 32, causing some blocks not to be 
allocated. As in PR 2163, this depends on the block size and number of blocks 
in a file system. Block sizes and group sizes that are powers of 2 seem to work 
fine ( 512 byte blocks, 4096 block groups, etc ). When the block sizes are not 
powers of 2, then this loop error causes some of the blocks at the end of a 
group to be skipped, preventing 100% of the blocks from being used. A simple 
test for this and PR2163 is to create a RAM disk with block size 3900 and at 
least 1 full group ( 31200 blocks ). A file system with these sizes will not be 
able to allocate 100% of the blocks.
---
 cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c 
b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index c4050b2..b8bd0b3 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
@@ -599,7 +599,8 @@ rtems_rfs_bitmap_create_search (rtems_rfs_bitmap_control* 
control)
 
 size -= available;
 
-if (bit == rtems_rfs_bitmap_element_bits ())
+/* Iterate from 0 to 1 less than the number of bits in an element */
+if (bit == (rtems_rfs_bitmap_element_bits () - 1))
 {
   bit = 0;
   search_map++;
-- 
1.8.3.2

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

[PATCH] For PR 2162 - RFS File System - statvfs reports 1 block free

2013-12-18 Thread Alan Cudmore

This is for the RFS file system. The statvfs call reports 1 block free when the 
file system is full because it does not account for the superblock in its 
calculation of free blocks. 
This is a simple fix that adjusts the number of blocks reported to account for 
the superblock. We may want to wait for a more complete solution such as 
locating the superblock in each group.
---
 cpukit/libfs/src/rfs/rtems-rfs-rtems.c | 2 +-
 cpukit/libfs/src/rfs/rtems-rfs-shell.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c 
b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
index e199ffe..d95a0f5 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
@@ -753,7 +753,7 @@ rtems_rfs_rtems_statvfs (
   sb-f_bsize   = rtems_rfs_fs_block_size (fs);
   sb-f_frsize  = rtems_rfs_fs_media_block_size (fs);
   sb-f_blocks  = rtems_rfs_fs_media_blocks (fs);
-  sb-f_bfree   = rtems_rfs_fs_blocks (fs) - blocks;
+  sb-f_bfree   = rtems_rfs_fs_blocks (fs) - blocks - 1; /* do not count the 
superblock */
   sb-f_bavail  = sb-f_bfree;
   sb-f_files   = rtems_rfs_fs_inodes (fs);
   sb-f_ffree   = rtems_rfs_fs_inodes (fs) - inodes;
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-shell.c 
b/cpukit/libfs/src/rfs/rtems-rfs-shell.c
index 96c0c17..b92041a 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-shell.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-shell.c
@@ -149,7 +149,7 @@ rtems_rfs_shell_data (rtems_rfs_file_system* fs, int argc, 
char *argv[])
 
   rtems_rfs_shell_unlock_rfs (fs);
 
-  bpcent = (blocks * 1000) / rtems_rfs_fs_blocks (fs);
+  bpcent = (blocks * 1000) / (rtems_rfs_fs_blocks (fs) - 1);
   ipcent = (inodes * 1000) / rtems_rfs_fs_inodes (fs);
 
   printf (   blocks used: %zd (%d.%d%%)\n,
-- 
1.8.3.2

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

Re: sparc 4.11 tools build failure on CentOS 6.x

2014-01-28 Thread Alan Cudmore

I was just able to build the sparc-rtems4.11 toolchain on Centos 6.5 , 
64 bit
This was on a fresh Centos 6.x VM with all updates, no previous RTEMS 
tools installed.


Alan

[alan@centosvm Desktop]$ sparc-rtems4.11-gcc -v
Using built-in specs.
COLLECT_GCC=sparc-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/home/alan/Projects/rtems/4.11/libexec/gcc/sparc-rtems4.11/4.8.2/lto-wrapper
Target: sparc-rtems4.11
Configured with: ../gcc-4.8.2/configure 
--prefix=/home/alan/Projects/rtems/4.11 
--bindir=/home/alan/Projects/rtems/4.11/bin 
--exec_prefix=/home/alan/Projects/rtems/4.11 
--includedir=/home/alan/Projects/rtems/4.11/include 
--libdir=/home/alan/Projects/rtems/4.11/lib 
--libexecdir=/home/alan/Projects/rtems/4.11/libexec 
--mandir=/home/alan/Projects/rtems/4.11/share/man 
--infodir=/home/alan/Projects/rtems/4.11/share/info 
--datadir=/home/alan/Projects/rtems/4.11/share --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=sparc-rtems4.11 --disable-libstdcxx-pch 
--with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib 
--disable-nls --without-included-gettext --disable-win32-registry 
--enable-version-specific-runtime-libs --disable-lto 
--enable-newlib-io-c99-formats --enable-newlib-iconv 
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 
--enable-threads --disable-plugin --enable-languages=c,c++

Thread model: posix
gcc version 4.8.2 20131016 (RTEMS 
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0) 
(GCC)




On 1/28/2014 10:38 PM, Chris Johns wrote:

On 29/01/2014 3:46 am, Joel Sherrill wrote:

Hi

Not sure what broke recently but something went wrong. :(

Can anyone build sparc-rtems4.11 tools with the rtems-source-builder
head?


Yes on FreeBSD 9 and on MacOS Mavrick 

 Build Set: Time 0:08:46.537755



 /bin/sh ../../gcc-4.8.2/gcc/mkconfig.sh bconfig.h
/usr/bin/g++ -O2 -pipe
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/tmp/sb-joel/4.11/rtems-sparc/home/joel/rtems-4.11-work/tools/include 


-c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.8.2/gcc
-I../../gcc-4.8.2/gcc/build -I../../gcc-4.8.2/gcc/../include
-I../../gcc-4.8.2/gcc/../libcpp/include
-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./gmp 

-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/gmp 

-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/build/./mpfr 

-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpfr 

-I/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sparc-rtems4.11-gcc-4.8.2-newlib-2.1.0-1/gcc-4.8.2/mpc/src 


-I../../gcc-4.8.2/gcc/../libdecnumber
-I../../gcc-4.8.2/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-4.8.2/gcc/../libbacktrace\
 -DBASEVER=\4.8.2\ -DDATESTAMP=\ 20131016\ \
 -DREVISION=\\ \
 -DDEVPHASE=\ (RTEMS
4.11-RSB(2be445d2aafae21849c5d626b3787e2ab1ac846b)-1,gcc-4.8.2/newlib-2.1.0)\ 



Same git hash I am using.


-DPKGVERSION=\(GCC) \ \
 -DBUGURL=\http://gcc.gnu.org/bugs.html\ -o build/version.o
../../gcc-4.8.2/gcc/version.c
{standard input}: Assembler messages:
{standard input}:33: Error: unknown pseudo-op: `.value'
{standard input}:183: Error: unknown pseudo-op: `.value'



Anything in your path that could up set up things ?
Do the installed RPMs verify ?

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


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

Re: GSoC 2014 | Poring RTEMS for OpenRISC

2014-03-04 Thread Alan Cudmore

I checked around at work and there is some interest in using the OpenRISC 
architecture, but no definite plans. 
Another idea is to advance the Microblaze port.

Alan

On Mar 4, 2014, at 1:22 PM, Hesham Moustafa heshamelmat...@gmail.com wrote:

 
 
 
 On Mon, Mar 3, 2014 at 6:54 PM, Gedare Bloom ged...@rtems.org wrote:
 Hesham,
 
 On Mon, Mar 3, 2014 at 11:06 AM, Hesham Moustafa
 heshamelmat...@gmail.com wrote:
 
 
 
  On Mon, Mar 3, 2014 at 5:06 PM, Joel Sherrill joel.sherr...@oarcorp.com
  wrote:
 
 
  On Mar 3, 2014 8:23 AM, Gedare Bloom ged...@rtems.org wrote:
  
   Hesham,
  
   The first question to figure out is why was the older port dropped.
 
  This I can answer. The tool chain rotted and had no maintainer. I also
  recall not having a simulator to test on.
 
  The final issue was some discrepancy between multiple openrisc CPU
  projects where I thought the focus on the architecture we had a port to was
  losing interest from them.
 
  Thanks Dr Joel, I also wanted to know the answer :)
  Was this architecture OpenRISC 1000 or another core ?
 If the toolchain is up-to-date and there are simulator and real hw
 architecture supported, then it can be a feasible project to do a
 port.
 
 Yes the toolchain is up-to-date and I worked on their or1ksim simulator 
 which can be connected to gdb. They support many boards, one of them is
 Atlys FPGA board which I have and worked on and I hope to create a BSP for.
 
   The second is what is your interest in porting to OpenRISC?
 
  Because I have been working on the last few months on FPGA project ( mips
  microprocessor).
  I wanted to port an OS to an opensource processor, and OpenRISC architecture
  is mature enough to port a complex RTOS like RTEMS.
 
  And who would use it?
 
  People using black box OpenRISC and others interested in Digital design,
  Computer architecture and
  HW/SW interfacing. Something like xilinx zynq ? except that both OpenRISC
  and RTEMS are opensource.
 If OpenRISC has settled on a specific reference architecture and has
 an adequately active community, then a port would be acceptable.
 
 I think they have. OpenRISC 1000 and 1200 architectures are both well 
 supported
 and used, and their community is active.
 
  Long term a port needs to be to a viable architecture from a is it alive
  view  this includes the cpu, tools, a way for us to test, etc
 
  Sure, that's what I hope to work on.
 In order to have a chance that your proposal will be accepted, you
 will need to demonstrate that the openrisc tools work for recent gcc /
 newlib with an adequate simulator. Based on wikipedia, you should be
 able to cross-compile Linux for the OpenRISC to run on Qemu, or you
 may like to just try to get a bare-metal application to run in the
 simulator.
 
 I have built their latest toolchain, gcc  4.9.0 and binutils 2.24.51. 
 with newlib. A helloworld program is working fine with or1k-elf-run, 
 or1k-elf-gdb (which connects to their or1ksim simulator) and qemu.
 
 The questions is, should this project include porting their toolchains to
 RTEMS toolchains (with their copyrights) ? or that may cause some 
 licence/copyrights problems ? 
 Gedare
 
   Gedare
  
   On Sun, Mar 2, 2014 at 12:39 AM, Hesham Moustafa
   heshamelmat...@gmail.com wrote:
Hi,
   
I am thinking of porting RTEMS for OpenRISC as a proposal for GSoC
project
this year.
I know there was an older port, but it's not available anymore on the
current RTEMS mainsteam.
Would this project be of useful to RTEMS and suitable for GSoC ?
   
Thanks,
Hesham
   
___
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
   
   ___
   rtems-devel mailing list
   rtems-devel@rtems.org
   http://www.rtems.org/mailman/listinfo/rtems-devel
 
 
 
 ___
 rtems-devel mailing list
 rtems-devel@rtems.org
 http://www.rtems.org/mailman/listinfo/rtems-devel

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

Re: GSoC 2014 | Porting RTEMS for OpenRISC

2014-03-05 Thread Alan Cudmore

There is a Microblaze port out there, but it has not been released.
But, I agree that the availability of the toolchain should be a factor.

Tough call: If we do the microblaze port, it may be duplicating work that
may eventually become available to the RTEMS project. If we do the OpenRISC
port, will it have the toolchain support and will it have users to keep it
from rotting?

Alan



On Wed, Mar 5, 2014 at 8:29 AM, Gedare Bloom ged...@rtems.org wrote:

 On Tue, Mar 4, 2014 at 8:58 PM, Hesham Moustafa
 heshamelmat...@gmail.com wrote:
 
 
 
  On Tue, Mar 4, 2014 at 8:47 PM, Gedare Bloom ged...@rtems.org wrote:
 
  On Tue, Mar 4, 2014 at 1:22 PM, Hesham Moustafa
 
  heshamelmat...@gmail.com wrote:
  
  
  
   On Mon, Mar 3, 2014 at 6:54 PM, Gedare Bloom ged...@rtems.org
 wrote:
  
   Hesham,
  
   On Mon, Mar 3, 2014 at 11:06 AM, Hesham Moustafa
   heshamelmat...@gmail.com wrote:
   
Long term a port needs to be to a viable architecture from a is
 it
alive
view  this includes the cpu, tools, a way for us to test, etc
   
Sure, that's what I hope to work on.
   In order to have a chance that your proposal will be accepted, you
   will need to demonstrate that the openrisc tools work for recent gcc
 /
   newlib with an adequate simulator. Based on wikipedia, you should be
   able to cross-compile Linux for the OpenRISC to run on Qemu, or you
   may like to just try to get a bare-metal application to run in the
   simulator.
  
   I have built their latest toolchain, gcc  4.9.0 and binutils 2.24.51.
   with newlib. A helloworld program is working fine with or1k-elf-run,
   or1k-elf-gdb (which connects to their or1ksim simulator) and qemu.
  
   The questions is, should this project include porting their toolchains
   to
   RTEMS toolchains (with their copyrights) ? or that may cause some
   licence/copyrights problems ?
  In order for RTEMS Project to accept the BSP for inclusion, the GCC
  toolchain must be available and prepared for upstream submission. If
  there is already OpenRISC (or1k) support accepted by GCC for linux, it
  should be straightforward to make it work for RTEMS. You will need to
  propose it as part of your GSOC, and you will need to make the proper
  steps including submitting FSF paperwork for contributing to GCC.
 
  They have their latest toolchain at github [1]. Also there is a linux
 port
  that can work
  on both or1ksim and real HW FPGA [2]. Not sure how the project would
  interface/interact with the existing or1k toolchain at github, gcc, and
  RTEMS. I would
  appreciate more clarification about this issue.
 
  [1] https://github.com/openrisc/or1k-src
  [2] http://openrisc.net/toolchain-build.html
 If the or1k toolchain is not already upstream to GCC, you will need to
 provide a solution for a workable toolchain for users, probably by
 integrating the toolchain build into the RTEMS Source Builder. You
 should also push patches to GCC if possible. You should do an analysis
 of how much difference there is between the or1k toolchain and the
 vanilla GCC/binutils/newlib, and figure out if there is any reason
 other than laziness that the or1k maintainers have not pushed their
 toolchain into the upstream gcc / sourceware repositories.

 I'm hesitant to accept any port that lacks a dedicated RTEMS
 maintainer or tools maintained upstream in gcc.

 At least for microblaze we know there exists some toolchain support
 already. I'm not sure if there is enough left to do with the
 microblaze port to warrant a GSOC or not. You would have to inquire
 with the developers who have done work on it already.

 -Gedare

 
  -Gedare
 
 
 ___
 rtems-devel mailing list
 rtems-devel@rtems.org
 http://www.rtems.org/mailman/listinfo/rtems-devel

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

Re: Raspberry Pi SD card support

2014-04-03 Thread Alan Cudmore

From my limited research, it looks like the emmc controller in the
Raspberry Pi BCM2835 may be the way to go.
It looks like it is a high level controller for the SD/MMC card slot on the
Pi.

Since this is a custom controller, I don't think there would be an existing
driver in RTEMS.

It seems that this emmc controller in the Pi may handle different types of
cards, and at a higher level than just using the SPI bus to access the
card. ( This is based on some searches of conversations on the raspberry pi
forums , not my experience )

You would have to write a driver for this emmc controller and provide the
interface to libblock for the file system interface on RTEMS. The code you
have linked above for rpi-boot looks like it has a permissive license, so
it *may* be possible to use this code in the RTEMS driver. There is some
other potentially useful code in there too.

I'll have to try the serial bootloader, I am also close to ordering an
inexpensive JTAG adapter to try loading and debugging through JTAG. uboot
is another possibility, using a TFTP server.

Alan




On Wed, Apr 2, 2014 at 12:02 PM, Andre Marques 
andre.lousa.marq...@gmail.com wrote:

 Hello,

 I'm intending to work in the SD card support for the Raspberry Pi BSP,
 using the SD mode instead of the SPI mode.

 The references I have gathered so far for this are as follows:

 The Raspberry Pi SOC guide: Broadcom BCM2835 Peripherals Guide (Chapter 5
 - EMMC)

 The simplified SD standard - https://www.sdcard.org/
 downloads/pls/simplified_specs/

 And the following github code - https://github.com/jncronin/
 rpi-boot/blob/master/emmc.c

 There is also the libchip/i2c/spi-sd-card libi2c driver, which can also be
 a reference (even though it uses SPI).

 Now, the questions:

 Should I use the Generic Disk Device driver, as the
 libchip/i2c/spi-sd-card ?

 Is there any driver using the SD mode for sd card access, or using an emmc
 interface currently in the RTEMS code base? I haven't found any.

 On a side note, I managed to send RTEMS applications to the RPi though the
 UART interface using the xmodem protocol.

 For that I used the following bootloader

 https://github.com/dwelch67/raspberrypi/tree/master/bootloader05

 It takes me 2 minutes to send 1 MB of data to the RPi, but this could be
 improved if it used 1024 byte block transfer instead of the default of 128.
 The bootloader loads the transfered program to memory and runs it. Then the
 RPi must be rebooted so a new program can be sent.

 It may not be the best way, but only requires an usb-to-uart cable, and
 avoids the current SD card dance to run programs on the Pi.

 Thank you for your time.

 --André Marques



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

Re: Raspberry Pi SD card support

2014-04-16 Thread Alan Cudmore

On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques 
andre.lousa.marq...@gmail.com wrote:

 On 04/04/14 20:19, Joel Sherrill wrote:

 On 4/4/2014 1:15 PM, Gedare Bloom wrote:

 The license looked fine to me.

 +1

 As always, we just need to be careful on a file per file basis just in
 case
 something else in rpi-boot has a different license.


 All files in rpi-boot use a similar licence, so I will be using some code
 from rpi-boot as a base for this.


Great.




  On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore alan.cudm...@gmail.com
 wrote:

  From my limited research, it looks like the emmc controller in the
 Raspberry
 Pi BCM2835 may be the way to go.
 It looks like it is a high level controller for the SD/MMC card slot on
 the
 Pi.

 Since this is a custom controller, I don't think there would be an
 existing
 driver in RTEMS.

 It seems that this emmc controller in the Pi may handle different types
 of
 cards, and at a higher level than just using the SPI bus to access the
 card.
 ( This is based on some searches of conversations on the raspberry pi
 forums
 , not my experience )

 You would have to write a driver for this emmc controller and provide
 the
 interface to libblock for the file system interface on RTEMS. The code
 you
 have linked above for rpi-boot looks like it has a permissive license,
 so it
 *may* be possible to use this code in the RTEMS driver. There is some
 other
 potentially useful code in there too.


 The mailbox access, mmio read and write and the timer code will also be
 usefull, and not only for emmc. This timer code differs from the
 misc/timer.h currently in the raspberrypi BSP, as it waits a certain amount
 of time (until some register gets updated). The misc/timer.h is a benchmark
 timer, so one of them would have to be renamed or reorganized.


Can an RTEMS timer be used for the mailbox communication?
Also, I don't think the benchmark timer code in the RTEMS Raspberry Pi BSP
is functional.

I have been contacted by someone who is currently working on a console
driver for the BSP, and has been able to display fonts. We may want to
include him, because I think the graphics code uses mailbox communication
to the GPU.

It is very interesting that the GPU is running a commercial RTOS, and we
will be communicating to it with RTEMS.



 My plan was to have at the root of the raspberrypi BSP a folder emmc for
 the emmc driver code, and the mailbox, mmio and timer on the misc folder,
 with the headers on the include folder. What do you think?

 I have been trying the rpi-boot emmc code for the past week, and I
 modified the hello test to use the emmc driver (an overly simplified
 version of the rpi-boot, just to read the slot info register for now), and
 my compilation process has been:

 1. Add/change files in Raspberrypi BSP
 2. Update Makefile.am
 3. Run bootstrap -p and bootstrap from the RaspberryPi BSP folder
 4. (Re)configure RTEMS
 5. make and make install RTEMS from the root folder

 That is pretty much what I do. Although it might be possible to test
drivers and code in the RKI image, then integrate it into the RTEMS tree
when it is ready.



 I have been using the --enable-maintainer-mode, but I am not sure about
 exacly what it simplifies, because I always needed to do those steps for it
 to compile and link correctly.


I don't know what this does either..


Alan



 --André Marques



 I'll have to try the serial bootloader, I am also close to ordering an
 inexpensive JTAG adapter to try loading and debugging through JTAG.
 uboot is
 another possibility, using a TFTP server.

 Alan




 On Wed, Apr 2, 2014 at 12:02 PM, Andre Marques
 andre.lousa.marq...@gmail.com wrote:

 Hello,

 I'm intending to work in the SD card support for the Raspberry Pi BSP,
 using the SD mode instead of the SPI mode.

 The references I have gathered so far for this are as follows:

 The Raspberry Pi SOC guide: Broadcom BCM2835 Peripherals Guide
 (Chapter 5
 - EMMC)

 The simplified SD standard -
 https://www.sdcard.org/downloads/pls/simplified_specs/

 And the following github code -
 https://github.com/jncronin/rpi-boot/blob/master/emmc.c

 There is also the libchip/i2c/spi-sd-card libi2c driver, which can
 also be
 a reference (even though it uses SPI).

 Now, the questions:

 Should I use the Generic Disk Device driver, as the
 libchip/i2c/spi-sd-card ?

 Is there any driver using the SD mode for sd card access, or using an
 emmc
 interface currently in the RTEMS code base? I haven't found any.

 On a side note, I managed to send RTEMS applications to the RPi though
 the
 UART interface using the xmodem protocol.

 For that I used the following bootloader

 https://github.com/dwelch67/raspberrypi/tree/master/bootloader05

 It takes me 2 minutes to send 1 MB of data to the RPi, but this could
 be
 improved if it used 1024 byte block transfer instead of the default of
 128.
 The bootloader loads the transfered program to memory and runs it.
 Then the
 RPi must be rebooted so a new program

Re: Raspberry Pi SD card support

2014-04-16 Thread Alan Cudmore

On Wed, Apr 16, 2014 at 4:49 PM, Joel Sherrill joel.sherr...@oarcorp.comwrote:


 On 4/16/2014 2:06 PM, Alan Cudmore wrote:




 On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques 
 andre.lousa.marq...@gmail.com wrote:

 On 04/04/14 20:19, Joel Sherrill wrote:

 On 4/4/2014 1:15 PM, Gedare Bloom wrote:

 The license looked fine to me.

 +1

 As always, we just need to be careful on a file per file basis just in
 case
 something else in rpi-boot has a different license.


  All files in rpi-boot use a similar licence, so I will be using some
 code from rpi-boot as a base for this.


  Great.




  On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore alan.cudm...@gmail.com
 wrote:

  From my limited research, it looks like the emmc controller in the
 Raspberry
 Pi BCM2835 may be the way to go.
 It looks like it is a high level controller for the SD/MMC card slot
 on the
 Pi.

 Since this is a custom controller, I don't think there would be an
 existing
 driver in RTEMS.

 It seems that this emmc controller in the Pi may handle different
 types of
 cards, and at a higher level than just using the SPI bus to access the
 card.
 ( This is based on some searches of conversations on the raspberry pi
 forums
 , not my experience )

 You would have to write a driver for this emmc controller and provide
 the
 interface to libblock for the file system interface on RTEMS. The code
 you
 have linked above for rpi-boot looks like it has a permissive license,
 so it
 *may* be possible to use this code in the RTEMS driver. There is some
 other
 potentially useful code in there too.


  The mailbox access, mmio read and write and the timer code will also be
 usefull, and not only for emmc. This timer code differs from the
 misc/timer.h currently in the raspberrypi BSP, as it waits a certain amount
 of time (until some register gets updated). The misc/timer.h is a benchmark
 timer, so one of them would have to be renamed or reorganized.


  Can an RTEMS timer be used for the mailbox communication?
 Also, I don't think the benchmark timer code in the RTEMS Raspberry Pi BSP
 is functional.

Do you mean rtems_timer_XXX or the timer in the BSP?


I mean the rtems_timer_ api. Maybe we can use this, or other RTEMS features
to implement the mailbox interface rather than just going directly to the
timer hardware like we see in the bare metal examples.



 The timer driver in the BSP is strictly for benchmarking -- nothing else.
 It is used
 by the tmtests and psxtmtests. It should not be used for any other purpose.

 How does the mailbox work? Describe it and we can figure out how to best
 address
 it.


The mailbox is the interface between the Video Core GPU and the ARM
processor on the Pi. Here are some docs:
https://github.com/raspberrypi/firmware/wiki/Mailboxes
https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

The details of the GPU have been closed, and the linux port has relied on a
binary blob for the GPU firmware, but Broadcom recently took a huge step in
opening it up:
http://www.raspberrypi.org/a-birthday-present-from-broadcom/

Hopefully this will help improve the understanding of this interface.

  I have been contacted by someone who is currently working on a console
 driver for the BSP, and has been able to display fonts. We may want to
 include him, because I think the graphics code uses mailbox communication
 to the GPU.

  It is very interesting that the GPU is running a commercial RTOS, and we
 will be communicating to it with RTEMS.

:)



 My plan was to have at the root of the raspberrypi BSP a folder emmc
 for the emmc driver code, and the mailbox, mmio and timer on the misc
 folder, with the headers on the include folder. What do you think?

 I have been trying the rpi-boot emmc code for the past week, and I
 modified the hello test to use the emmc driver (an overly simplified
 version of the rpi-boot, just to read the slot info register for now), and
 my compilation process has been:

 1. Add/change files in Raspberrypi BSP
 2. Update Makefile.am
 3. Run bootstrap -p and bootstrap from the RaspberryPi BSP folder
 4. (Re)configure RTEMS
 5. make and make install RTEMS from the root folder

  That is pretty much what I do. Although it might be possible to test
 drivers and code in the RKI image, then integrate it into the RTEMS tree
 when it is ready.

--enable-maintainer-mode is supposed to track regenerating the
 Makefile.in
 and configure files when you modify Makefile.am or configure.ac.

 The current build system has a serious deficiency in that it does **not**
 track the dependency of the test executables on any .a or .h file from
 RTEMS.
 So the best solution for quick builds is usually to remove the executable
 you
 are testing and then run make.

 Step 3 above is the minimum for a bootstrap. bootstrap -p is only needed
 when you add/delete/move .h files.



 I have been using the --enable-maintainer-mode, but I am

Re: Raspberry Pi SD card support

2014-04-17 Thread Alan Cudmore


On 4/17/2014 5:42 AM, Andre Marques wrote:

On 04/17/14 03:22, Alan Cudmore wrote:


On Wed, Apr 16, 2014 at 4:49 PM, Joel Sherrill 
joel.sherr...@oarcorp.com mailto:joel.sherr...@oarcorp.com wrote:



On 4/16/2014 2:06 PM, Alan Cudmore wrote:




On Thu, Apr 10, 2014 at 7:11 PM, Andre Marques
andre.lousa.marq...@gmail.com
mailto:andre.lousa.marq...@gmail.com wrote:

On 04/04/14 20:19, Joel Sherrill wrote:

On 4/4/2014 1:15 PM, Gedare Bloom wrote:

The license looked fine to me.

+1

As always, we just need to be careful on a file per file
basis just in case
something else in rpi-boot has a different license.


All files in rpi-boot use a similar licence, so I will be
using some code from rpi-boot as a base for this.


Great.



On Thu, Apr 3, 2014 at 10:06 PM, Alan Cudmore
alan.cudm...@gmail.com
mailto:alan.cudm...@gmail.com wrote:

 From my limited research, it looks like the
emmc controller in the Raspberry
Pi BCM2835 may be the way to go.
It looks like it is a high level controller for
the SD/MMC card slot on the
Pi.

Since this is a custom controller, I don't think
there would be an existing
driver in RTEMS.

It seems that this emmc controller in the Pi may
handle different types of
cards, and at a higher level than just using the
SPI bus to access the card.
( This is based on some searches of
conversations on the raspberry pi forums
, not my experience )

You would have to write a driver for this emmc
controller and provide the
interface to libblock for the file system
interface on RTEMS. The code you
have linked above for rpi-boot looks like it has
a permissive license, so it
*may* be possible to use this code in the RTEMS
driver. There is some other
potentially useful code in there too.


The mailbox access, mmio read and write and the timer code
will also be usefull, and not only for emmc. This timer code
differs from the misc/timer.h currently in the raspberrypi
BSP, as it waits a certain amount of time (until some
register gets updated). The misc/timer.h is a benchmark
timer, so one of them would have to be renamed or reorganized.


Can an RTEMS timer be used for the mailbox communication?
Also, I don't think the benchmark timer code in the RTEMS
Raspberry Pi BSP is functional.


Do you mean rtems_timer_XXX or the timer in the BSP?


I mean the rtems_timer_ api. Maybe we can use this, or other RTEMS 
features to implement the mailbox interface rather than just going 
directly to the timer hardware like we see in the bare metal examples.


Maybe the timer concept here is a little misleading. I was talking 
about a wait with timeout, until some register gets updated. The 
rtems_timer api schedules a routine to be executed after some period 
of time, but the register may (and should) be updated before the timeout.


I am not sure if this would be recommended, but using the rtems_timer 
api a timer could be set for a period of time (the timeout), and while 
the timer is going the driver would check if the register has been 
updated. If so the timer would be cancelled. Is this good practice 
with the rtems_timer api?


I agree that the rtems_timer might not be the best mechanism for the 
waiting on the mailbox.
If the CPU-GPU interface supports interrupts, then a non-blocking 
driver could be written.

Otherwise, what is the best approach?
 - a sleep call
 - polling a status register

While I am on the subject of polling, I just remembered that the UART 
driver in the BSP does not support interrupts. We should look at this 
sometime too.






The timer driver in the BSP is strictly for benchmarking --
nothing else. It is used
by the tmtests and psxtmtests. It should not be used for any
other purpose.

How does the mailbox work? Describe it and we can figure out how
to best address
it.


The mailbox is the interface between the Video Core GPU and the ARM 
processor on the Pi. Here are some docs:

https://github.com/raspberrypi/firmware/wiki/Mailboxes
https://github.com/raspberrypi/firmware/wiki/Accessing-mailboxes
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface



The mailbox interface is a register that has several channels (mail 
accounts) for different resources on the board, so a driver sends a 
buffer with a request

Re: Raspberry Pi SD card support

2014-04-17 Thread Alan Cudmore


I don't know if this code can be ported to RTEMS.
I downloaded the source and it is a graphics stack for Android 4.x.
I would have to understand more about the graphics architecture of 
Android and how that could relate to RTEMS.


For now, I would be happy if we can get a framebuffer driver that could 
be used as a HDMI console or host the RTEMS graphics toolkit.


Alan

On 4/16/2014 11:49 PM, Chris Johns wrote:

On 17/04/2014 12:22 pm, Alan Cudmore wrote:


The details of the GPU have been closed, and the linux port has relied
on a binary blob for the GPU firmware, but Broadcom recently took a huge
step in opening it up:
http://www.raspberrypi.org/a-birthday-present-from-broadcom/



Does this mean you could port this code to RTEMS ?

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


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

Re: [GSOC] RPi BSP RTEMS

2014-04-28 Thread Alan Cudmore

On Fri, Apr 25, 2014 at 6:07 PM, Andre Marques
andre.lousa.marq...@gmail.com wrote:

I'm taking this conversation to the list.

Sorry, I didn't realize that I did not reply to the list.

On 04/23/14 01:21, Alan Cudmore wrote:

On Tue, Apr 22, 2014 at 6:09 AM, Andre Marques
andre.lousa.marq...@gmail.com wrote:

Hello,

I am very pleased to have the opportunity to participate in GSoC with the
RTEMS project!

Welcome! We are glad to have you helping RTEMS.

Now, I have some questions:

1. Does anyone have any recommendation on the proposal?

I like the proposal, but there are a couple of things that may change
slightly:
1. You may want to look into making the UART driver work in interrupt
driven mode, as it is currently polled.

I will have a look at it.

2. For the Framebuffer support, I have been talking to someone off list
that is making progress on implementing a framebuffer driver. We may want
to collaborate with this person for the framebuffer.

Certainly. I was scheduling the framebuffer work for July, should that be
re-scheduled?

July may still work. This gives us time to see what gets accomplished and
the work can be integrating it into the RTEMS tree and testing.

2. Is there any interesting documentation or code you think I should be
looking at right now? For the past month I have been studying the RPi BSP
code and the RPi architecture for the emmc driver that I am doing for my
final project at the university.

From what I can see, you are off to a very good start!

3. There is no wiki page for the Raspberry Pi BSP (at least I have not
found any yet). May I create one using the Open Project template and link
it in the Open Projects page under the BSP section?

I did not create one, so please do.

4. I will create a dedicated development blog for the project very soon.
How frequently should it be updated until may 19?

5. How should the communication happen? Also I am not sure if the Amar
Takhar and Muhammad Adnan e-mails are the correct ones.

I will also be setting a github repository for this, and I am also
looking to get my own RPi and some peripherals (I have one at the
university right now).

I have been setting up my Pi for RTEMS development again. I recently
built u-boot and I am going to try to get it to boot RTEMS images from a
TFTP server. This may help speed up development.

I am also trying out a FT2232H MiniMod evaluation board that is supposed
to work with the Raspberry Pi JTAG interface and the OpenOCD project. It
also serves as the USB uart connector. I have it all wired up and I hope to
try getting it to talk to OpenOCD soon. If I get it working, I will
document everything. The FT2232H Minimod board was $20 USD.

Nice. Looking forward to that, as I still need to look at the debugging
part of the development.

The FT2232H MiniMod is working so far! I am able to use the UART and at the
same time load and run images over the JTAG interface using OpenOCD. Next,
I plan on trying GDB. I will try to document the setup soon, but it just
requires ~10 jumper wires to connect the MiniMod to the Pi GPIO header.

I need to use it, because I discovered that the RKI image no longer runs on
the Pi. The samples such as ticker still work, so I'm sure it is a problem
with the RKI code itself.

Meanwhile I have set up a development blog and a google calendar for the
project:

http://asuolgsoc2014.wordpress.com/

https://www.google.com/calendar/embed?src=mo5guprvls0ip24rnrjio4ogks%40group.calendar.google.comctz=Europe/Lisbon

I will try to come up with more news during the weekend.

Looks good.

Alan

Thank you,
André Marques.

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

Re: [GSOC] RPi BSP RTEMS

2014-04-28 Thread Alan Cudmore

I will definitely try that out. It would be great to automate all tests on
this board.
It seems less than 10 seconds to load a 1 megabyte RTEMS image to the Pi
using JTAG.

Alan


On Mon, Apr 28, 2014 at 7:20 PM, Chris Johns chr...@rtems.org wrote:

 On 29/04/2014 12:34 am, Alan Cudmore wrote:


 The FT2232H MiniMod is working so far! I am able to use the UART and at
 the same time load and run images over the JTAG interface using OpenOCD.
 Next, I plan on trying GDB. I will try to document the setup soon, but
 it just requires ~10 jumper wires to connect the MiniMod to the Pi GPIO
 header.


 The rtems-tester works well with OpenOCD and GDB. Please take a look at
 the recent BeagleBoard xM script Ben and I are currently using ...

 http://git.rtems.org/rtems-tools/tree/tester/rtems/
 testing/bsps/beagleboardxm.mc

 It took us a while to get a stable way to force a full reset on the xM's
 ARM. It takes about 3 hours to run all 500 tests.

 If you get a working configuration please send me a patch. Hard coded
 paths are ok at this stage of the rtems-test's development. I am yet to
 figure out a way to manage the host variations.

 Chris

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

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

Changes to shell API?

2014-04-29 Thread Alan Cudmore

I recently tried to compile and run my RTEMS kernel image ( 
github.com/alanc98/rki ) on the latest git head. I was able to get past 
a configuration option change:

#define CONFIGURE_MAXIMUM_TASKS 1024
kept the system from starting, so I changed it to 128 and it comes up.

But now I do not get a shell on the console. Are there any changes in 
the shell initialization that I need to update?


I was running this on the 4.11 git head a few months ago.

Is there any single place that documents recent changes in all of the 
configuration options ?


Thanks,
Alan


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

Re: [GSOC] RPi BSP RTEMS

2014-05-08 Thread Alan Cudmore

I have not had much time to figure out why GDB is not working with the
Pi/openOCD setup yet.

But I started documenting my setup. The hardware details are here:
http://alanstechnotes.blogspot.com/2014/05/a-low-cost-jtag-debugger-for-raspberry.html

Next I will document how to compile openOCD and use it to load RTEMS images
to the Pi.

Alan



On Fri, May 2, 2014 at 6:48 PM, Chris Johns chr...@rtems.org wrote:

 On 3/05/2014 3:07 am, Alan Cudmore wrote:

 Chris,
 I can use OpenOCD to load, run, break, resume, etc, but I am not having
 luck with GDB yet.


 Excellent.


  I can connect to the OpenOCD remote target server, send monitor
 commands, but I cannot load code through GDB or control the target.
 When I try loading through GDB, I end up with load failure messages.

 Any hints in configuring OpenOCD or GDB?


 Send me an OpenOCD and GDB session trace.

 Chris

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

Re: [GSOC] RPi BSP RTEMS

2014-05-13 Thread Alan Cudmore


On 5/13/2014 3:48 PM, Andre Marques wrote:

On 05/09/14 03:24, Alan Cudmore wrote:
I have not had much time to figure out why GDB is not working with 
the Pi/openOCD setup yet.


But I started documenting my setup. The hardware details are here:
http://alanstechnotes.blogspot.com/2014/05/a-low-cost-jtag-debugger-for-raspberry.html

Next I will document how to compile openOCD and use it to load RTEMS 
images to the Pi.


Alan




Hello Alan,

sorry for the delay, last week I had some work at the university and 
the emmc driver i'm doing for my final project is having some 
problems. I'm still trying to get myself the needed hardware for the 
debugger.


About the needed peripherals, I thought of this display to test the 
i2c and spi interfaces:


http://www.newhavendisplay.com/nhd0216k3zflgbwv3-p-5738.html

What do you think?


That should work. The jumpers look like they may need to be soldered to 
select SPI, I2C, or UART.


I have a few other I2C devices, I will have to pick up at least one SPI 
device.

A couple of other examples:
http://www.adafruit.com/product/1231
http://www.adafruit.com/products/1602
http://www.adafruit.com/products/1564

Alan






On Fri, May 2, 2014 at 6:48 PM, Chris Johns chr...@rtems.org 
mailto:chr...@rtems.org wrote:


On 3/05/2014 3:07 am, Alan Cudmore wrote:

Chris,
I can use OpenOCD to load, run, break, resume, etc, but I am
not having
luck with GDB yet.


Excellent.


I can connect to the OpenOCD remote target server, send monitor
commands, but I cannot load code through GDB or control the
target.
When I try loading through GDB, I end up with load failure
messages.

Any hints in configuring OpenOCD or GDB?


Send me an OpenOCD and GDB session trace.

Chris






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

Re: Fwd: Re: [GSOC] rtems GPIO API

2014-05-28 Thread Alan Cudmore

Andre,
If you have not seen this library, please check this out:
http://wiringpi.com

It looks like a good resource programming the Raspberry Pi GPIO. It may
give you some insight and ideas about the GPIO API. The code appears to be
LGPL.
Alan



On Sat, May 24, 2014 at 8:37 PM, Gedare Bloom ged...@rtems.org wrote:

 On Sat, May 24, 2014 at 12:08 PM, Andre Marques
 andre.lousa.marq...@gmail.com wrote:
  On 05/23/14 17:57, Chris Nott wrote:
 
 
  My two cents:
 
  On 22/05/2014 3:30 PM, Andre Marques wrote:
 
  Hello,
 
  I will start my GSOC project with a GPIO driver for the RPi BSP, and
  part of the GPIO driver code will not be specific to the RPi but to
  any board with a GPIO interface. With code reuse in mind and since I
  did not found any generic API for the GPIO interface in the RTEMS
  code base, I intend to propose here an initial *rough* draft of what
  this API may look like.
 
  To initialize the API:
 
  rtems_gpio_initialize (struct gpio_config)
 
  which would initialize the API with a specific GPIO peripheral
  configuration: number of gpio pins, gpio register addresses, ...
 
  To set a gpio pin as input or output (the direction would be a macro):
 
  rtems_gpio_direction (int gpio, int direction)
 
  To set a gpio pull resistor (either pull up/down or no pull resistor):
 
  rtems_gpio_set_Pull (int gpio, int pull)
 
  You probably want to add push-pull/open drain as a pin option.
 
  Some targets would have drive strength or other options as well, that
  may be useful to add in the GPIO API ?
 
 
  Possibly.
 
 
 
  Some GPIO I/O:
 
  rtems_gpio_set(int gpio)
  rtems_gpio_clr (int gpio)
  rtems_gpio_read_value (int gpio)
 
  Is it your intention to abstract GPIO as separate single-bit ports? It
  might be better to keep the GPIO in natural groupings, otherwise doing
  I/O through this API you would lose the ability to toggle multiple pins
  in a GPIO group at once, which is sometimes important.
 
 
  In that case it could be done as:
 
  rtems_gpio_set(int port, int gpio)
  rtems_gpio_clr (int port, int gpio)
 Prefer to use full names instead of abbreviations when length is not
 an issue, so here rtems_gpio_clear() is better.

  rtems_gpio_read_value (int port, int gpio)
 
  Where port would be a group of gpio pins, and a gpio number of  0 would
  mean all the gpio pins in a group?
 
 Would it make sense to define a struct to encapsulate a GPIO context
 (as a set of pins, perhaps some other metadata about the pins like
 strength, interrupts) that gets passed in to these functions?

 
 
 
  And interrupt management:
 
  rtems_int_enable (int gpio, rtems_interrupt_level int)
  rtems_int_disable (int gpio)
  rtems_int_clear (int gpio)
 
  Interrupts may be a little tricky to abstract in an API. The interrupt
  capability for GPIO pins varies a lot.
 
  Also you would need to be able to be able to configure what causes an
  interrupt, ie. edge capture options etc.
 
  I think what you are proposing is a good idea, but I think it might be
  worth taking a quick survey of the existing platforms supported in RTEMS
  to get an idea of the capabilities of the hardware before specifying the
  API.
 
 
  That can be done, but for now this API would be based on the non specific
  features of the Raspberry Pi board (so that they can be reused outside
 the
  RPi BSP). The API can obviously be further improved. Also, the RPi is the
  only board I have access to, so any feature that isn't there I would not
 be
  able to test, or may not even fit the generic purpose of this API.
 
 
  Also, this is only my opinion. I am not really sure what the intention
  is with regards to driver API in RTEMS. I expect there is probably going
  to be a choice between generic/flexible and performance. For example -
  do you support multiple _types_ of GPIO controller? Ie. some kind of
  GPIO device driver, which will require call-through-pointer tables and
  is going to be a little slower. I am looking at implementing a USB
  device API which has the same choice, and so far I think it is safe for
  USB to only provide one kind of USB device core driver per target, and
  thus avoid a layer of indirection.
 
 
  Would appreciate some feedback on this.
 
  --Andre Marques.
  ___
  rtems-devel mailing list
  rtems-devel@rtems.org
  http://www.rtems.org/mailman/listinfo/rtems-devel
 
 
 
 
  ___
  rtems-devel mailing list
  rtems-devel@rtems.org
  http://www.rtems.org/mailman/listinfo/rtems-devel
 
 
  ___
  rtems-devel mailing list
  rtems-devel@rtems.org
  http://www.rtems.org/mailman/listinfo/rtems-devel
 ___
 rtems-devel mailing list
 rtems-devel@rtems.org
 http://www.rtems.org/mailman/listinfo/rtems-devel

___
rtems-devel mailing list
rtems-devel@rtems.org

Re: Fwd: Re: [GSOC] rtems GPIO API

2014-05-28 Thread Alan Cudmore

OK, that's good to know. But it could at least help shape the RTEMS GPIO
API.

Alan



On Wed, May 28, 2014 at 3:08 PM, Gedare Bloom ged...@rtems.org wrote:

 On Wed, May 28, 2014 at 11:56 AM, Alan Cudmore alan.cudm...@gmail.com
 wrote:
  Andre,
  If you have not seen this library, please check this out:
  http://wiringpi.com
 
  It looks like a good resource programming the Raspberry Pi GPIO. It may
 give
  you some insight and ideas about the GPIO API. The code appears to be
 LGPL.
 Unfortunately, the LGPL is not suitable for the RTEMS code base [1].
 The code may still be useful to consider for some perspective, but it
 cannot be incorporated directly.

 -Gedare

 [1]
 http://gedare-csphd.blogspot.com/2013/05/software-licenses-with-rtems.html

  Alan
 
 
 
  On Sat, May 24, 2014 at 8:37 PM, Gedare Bloom ged...@rtems.org wrote:
 
  On Sat, May 24, 2014 at 12:08 PM, Andre Marques
  andre.lousa.marq...@gmail.com wrote:
   On 05/23/14 17:57, Chris Nott wrote:
  
  
   My two cents:
  
   On 22/05/2014 3:30 PM, Andre Marques wrote:
  
   Hello,
  
   I will start my GSOC project with a GPIO driver for the RPi BSP, and
   part of the GPIO driver code will not be specific to the RPi but to
   any board with a GPIO interface. With code reuse in mind and since I
   did not found any generic API for the GPIO interface in the RTEMS
   code base, I intend to propose here an initial *rough* draft of what
   this API may look like.
  
   To initialize the API:
  
   rtems_gpio_initialize (struct gpio_config)
  
   which would initialize the API with a specific GPIO peripheral
   configuration: number of gpio pins, gpio register addresses, ...
  
   To set a gpio pin as input or output (the direction would be a
 macro):
  
   rtems_gpio_direction (int gpio, int direction)
  
   To set a gpio pull resistor (either pull up/down or no pull
 resistor):
  
   rtems_gpio_set_Pull (int gpio, int pull)
  
   You probably want to add push-pull/open drain as a pin option.
  
   Some targets would have drive strength or other options as well, that
   may be useful to add in the GPIO API ?
  
  
   Possibly.
  
  
  
   Some GPIO I/O:
  
   rtems_gpio_set(int gpio)
   rtems_gpio_clr (int gpio)
   rtems_gpio_read_value (int gpio)
  
   Is it your intention to abstract GPIO as separate single-bit ports?
 It
   might be better to keep the GPIO in natural groupings, otherwise
 doing
   I/O through this API you would lose the ability to toggle multiple
 pins
   in a GPIO group at once, which is sometimes important.
  
  
   In that case it could be done as:
  
   rtems_gpio_set(int port, int gpio)
   rtems_gpio_clr (int port, int gpio)
  Prefer to use full names instead of abbreviations when length is not
  an issue, so here rtems_gpio_clear() is better.
 
   rtems_gpio_read_value (int port, int gpio)
  
   Where port would be a group of gpio pins, and a gpio number of  0
 would
   mean all the gpio pins in a group?
  
  Would it make sense to define a struct to encapsulate a GPIO context
  (as a set of pins, perhaps some other metadata about the pins like
  strength, interrupts) that gets passed in to these functions?
 
  
  
  
   And interrupt management:
  
   rtems_int_enable (int gpio, rtems_interrupt_level int)
   rtems_int_disable (int gpio)
   rtems_int_clear (int gpio)
  
   Interrupts may be a little tricky to abstract in an API. The
 interrupt
   capability for GPIO pins varies a lot.
  
   Also you would need to be able to be able to configure what causes an
   interrupt, ie. edge capture options etc.
  
   I think what you are proposing is a good idea, but I think it might
 be
   worth taking a quick survey of the existing platforms supported in
   RTEMS
   to get an idea of the capabilities of the hardware before specifying
   the
   API.
  
  
   That can be done, but for now this API would be based on the non
   specific
   features of the Raspberry Pi board (so that they can be reused outside
   the
   RPi BSP). The API can obviously be further improved. Also, the RPi is
   the
   only board I have access to, so any feature that isn't there I would
 not
   be
   able to test, or may not even fit the generic purpose of this API.
  
  
   Also, this is only my opinion. I am not really sure what the
 intention
   is with regards to driver API in RTEMS. I expect there is probably
   going
   to be a choice between generic/flexible and performance. For example
 -
   do you support multiple _types_ of GPIO controller? Ie. some kind of
   GPIO device driver, which will require call-through-pointer tables
 and
   is going to be a little slower. I am looking at implementing a USB
   device API which has the same choice, and so far I think it is safe
 for
   USB to only provide one kind of USB device core driver per target,
   and
   thus avoid a layer of indirection.
  
  
   Would appreciate some feedback on this.
  
   --Andre Marques.
   ___
   rtems-devel mailing list
   rtems

Re: Raspberry/ARM processor halts when invalidating tlb

Re: How to start contributing towards RTEMS project

[PATCH] Removed check for texinfo 5.x. Binutils 2.24 and gcc 4.8.2 build with GNU texinfo 5.1

[PATCH] For PR 2163 - RFS File System - fix group search algorithm bug

[PATCH] For PR 2164 - RFS File System - fix bitmap_create_search loop bug

[PATCH] For PR 2162 - RFS File System - statvfs reports 1 block free

Re: sparc 4.11 tools build failure on CentOS 6.x

Re: GSoC 2014 | Poring RTEMS for OpenRISC

Re: GSoC 2014 | Porting RTEMS for OpenRISC

Re: Raspberry Pi SD card support

Re: Raspberry Pi SD card support

Re: Raspberry Pi SD card support

Re: Raspberry Pi SD card support

Re: Raspberry Pi SD card support

Re: [GSOC] RPi BSP RTEMS

Re: [GSOC] RPi BSP RTEMS

Changes to shell API?

Re: [GSOC] RPi BSP RTEMS

Re: [GSOC] RPi BSP RTEMS

Re: Fwd: Re: [GSOC] rtems GPIO API

Re: Fwd: Re: [GSOC] rtems GPIO API

< 1 2 3

201 - 221 of 221 matches

Site Navigation

Mail list logo

Footer information