from:"QIAO YANG"

Re: RTEMS graphic testing on RPi

2015-09-19 Thread QIAO YANG



On Aug 24, 2015, at 05:20 AM, Pavel Pisa  wrote:


Hello Qiao and Joel,

I have rerun testing of actual RSB mainline testing
on RPi B device. Generally works well.

Used instructions included for archival there

git clone git://git.rtems.org/rtems-source-builder.git
cd rtems
../source-builder/sb-set-builder \
--prefix=/opt/rtems4.11 \
--rtems-bsp=arm/raspberrypi \
--log=graphic-build-log.txt \
--with-rtems-bsp=raspberrypi \
--pkg-tar-files \
4.11/graphics/freetype2.bset \
4.11/graphics/libjpeg.bset \
4.11/graphics/libpng.bset \
4.11/graphics/libtiff.bset \
4.11/graphics/t1lib.bset \
4.11/graphics/microwindows.bset


There are minor problems with t1lib patch and libpng version changes

diff --git a/rtems/config/4.11/graphics/libpng.bset 
b/rtems/config/4.11/graphics/libpng.bset
index 4df0e03..b858081 100644
--- a/rtems/config/4.11/graphics/libpng.bset
+++ b/rtems/config/4.11/graphics/libpng.bset
@@ -17,4 +17,4 @@
#
# Build libpng.
#
-graphics/libpng-1.5.22-1.cfg
+graphics/libpng-1.5.23-1.cfg
diff --git a/source-builder/config/t1lib-1.cfg 
b/source-builder/config/t1lib-1.cfg
index 38c3530..b11e1eb 100644
--- a/source-builder/config/t1lib-1.cfg
+++ b/source-builder/config/t1lib-1.cfg
@@ -20,7 +20,7 @@ BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
#
%source set t1lib 
ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/t1lib-%{t1lib_version}.tar.gz
%patch add t1lib 
https://raw.githubusercontent.com/yangqiao/rtems-tools/graphics/tools/4.11/t1lib/t1lib-5.1.2.diff
-%hash md5 t1lib-5.1.2.diff 196b0e39e36cab5afc6c5c280dcbe9bc
+%hash md5 t1lib-5.1.2.diff 98eeed85780227adf8525deab3679877


The t1lib pache isn't accepted into rtems-tools.

Since the md5 might changed (due to spaces, line breaks etc... That happened to 
microwindows patch accepted into rtems-tool ),  so I would like to see the 
t1lib pach commited first and I send the patch for rsb later to fix the patch 
url and also add the graphics-all.bset. I've already prepared these patches.

Here is the patch for t1lib to commit into rtems-tool:

---
tools/4.11/t1lib/t1lib-5.1.2.diff | 75 +++
1 file changed, 75 insertions(+)
create mode 100644 tools/4.11/t1lib/t1lib-5.1.2.diff

diff --git a/tools/4.11/t1lib/t1lib-5.1.2.diff 
b/tools/4.11/t1lib/t1lib-5.1.2.diff
new file mode 100644
index 000..532cd54
--- /dev/null
+++ b/tools/4.11/t1lib/t1lib-5.1.2.diff
@@ -0,0 +1,75 @@
+diff -ruN t1lib-5.1.2/configure t1lib-5.1.2-new/configure
+--- t1lib-5.1.2/configure2007-12-23 16:49:43.0 +0100
 t1lib-5.1.2-new/configure2015-08-14 10:32:37.985381959 +0200
+@@ -24758,11 +24758,7 @@
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+   if test "$cross_compiling" = yes; then
+-  { { echo "$as_me:$LINENO: error: cannot run test program while cross 
compiling
+-See \`config.log' for more details." >&5
+-echo "$as_me: error: cannot run test program while cross compiling
+-See \`config.log' for more details." >&2;}
+-   { (exit 1); exit 1; }; }
++  ac_64bit_type=""
+ else
+   cat >conftest.$ac_ext <<_ACEOF
+ /* confdefs.h.  */
+diff -ruN t1lib-5.1.2/configure.in t1lib-5.1.2-new/configure.in
+--- t1lib-5.1.2/configure.in2007-12-23 16:49:43.0 +0100
 t1lib-5.1.2-new/configure.in2015-08-14 10:33:39.805379339 +0200
+@@ -225,14 +225,52 @@
+
+ dnl  Check which ANSI integer type is 64 bit
+
+-AC_CACHE_CHECK( "which ANSI integer type is 64 bit", ac_64bit_type,
+-AC_TRY_RUN([
++echo $ECHO_N "checking \"which ANSI integer type is 64 bit\"... $ECHO_C" >&6
++if test "${ac_64bit_type+set}" = set; then
++  echo $ECHO_N "(cached) $ECHO_C" >&6
++else
++  if test "$cross_compiling" = yes; then
++  ac_64bit_type=""
++else
++  cat >conftest.$ac_ext <<_ACEOF
++/* confdefs.h.  */
++_ACEOF
++cat confdefs.h >>conftest.$ac_ext
++cat >>conftest.$ac_ext <<_ACEOF
++/* end confdefs.h.  */
++
+ int main(void) {
+   if (sizeof(long)==8)
+ return(0);
+   else
+ return(1);
+-}], ac_64bit_type="long", ac_64bit_type=""))
++}
++_ACEOF
++rm -f conftest$ac_exeext
++if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
++  (eval $ac_link) 2>&5
++  ac_status=$?
++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
++  (exit $ac_status); } && { ac_try='./conftest$ac_exeext'
++  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
++  (eval $ac_try) 2>&5
++  ac_status=$?
++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
++  (exit $ac_status); }; }; then
++  ac_64bit_type="long"
++else
++  echo "$as_me: program exited with status $ac_status" >&5
++echo "$as_me: failed program was:" >&5
++sed 's/^/| /' conftest.$ac_ext >&5
++
++( exit $ac_status )
++ac_64bit_type=""
++fi
++rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext 
conftest.$ac_ext
++fi
++fi
++echo "$as_me:$LINENO: result: $ac_64bit_type" >&5
++echo "${ECHO_T}$ac_64bit_type" >&6
+ if test "$ac_64bit_type" = "long"
+ then
+   T1_AA_TYPE64="-DT1_AA_TYPE64=long"
--
2.1.0




#
# Prepare the source code.

We should get rid of microwindows patches

Re: Version 197 of GSoC 2015 Student Table has been modified incorrectly

2015-08-15 Thread QIAO YANG


sorry that I've brought some problems here.  My browser had a wired crash and I 
didn't notice that some are deleted by accident. Should we revert or I just add 
them back? 

On Aug 15, 2015, at 05:46 AM, Jarielle Catbagan jcatbaga...@gmail.com wrote:


Hello:

I've noticed that Version 197 of the GSoC 2015 Student Table, which
can be found here https://devel.rtems.org/wiki/GSoC/2015?version=197,
has resulted in the deletion of some students' status updates (myself
included). The latest version is Version 198. I was wondering what
is the most efficient way to possibly revert back the changes and to
merge in the new changes.

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

Re: [PATCH 1/1] add t1lib patch

2015-08-12 Thread QIAO YANG



On Aug 12, 2015, at 03:01 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote:





On 8/12/2015 8:18 AM, QIAO YANG wrote:

Hi,

So here I patch the configure.in file instead of its output. If this one is 
good to go, I'll send you the two other patches for microwindows-bset and 
t1lib-bset , with its' correct patch urls.


The patch has to include the source (configure.in) and generated
file (configure). Once the patch is applied, the configure script
should match what would be generated but the end user is not expected
to be able to generate the configure script.

Include both files and ensure the configure is actually generated
from the latest configure.in.


I've added the generation in the build process. After the configure.in is 
patched, I regenerate the configure script. Is that ok?





Best wishes


On Aug 12, 2015, at 02:16 AM, YANG QIAO yangqiao0...@me.com wrote:


From: YANG Qiao yangqiao0...@me.com mailto:yangqiao0...@me.com

---
tools/4.11/t1lib/t1lib-5.1.2.diff | 58 +++
1 file changed, 58 insertions(+)
create mode 100644 tools/4.11/t1lib/t1lib-5.1.2.diff

diff --git a/tools/4.11/t1lib/t1lib-5.1.2.diff 
b/tools/4.11/t1lib/t1lib-5.1.2.diff
new file mode 100644
index 000..1c59e2b
--- /dev/null
+++ b/tools/4.11/t1lib/t1lib-5.1.2.diff
@@ -0,0 +1,58 @@
+--- t1lib-5.1.2.orig/configure.in 2015-08-12 14:35:01.064674452 +0200
 t1lib-5.1.2/configure.in 2015-08-12 14:35:05.148674279 +0200
+@@ -225,14 +225,52 @@
+
+ dnl  Check which ANSI integer type is 64 bit
+
+-AC_CACHE_CHECK( which ANSI integer type is 64 bit, ac_64bit_type,
+- AC_TRY_RUN([
++echo $ECHO_N checking \which ANSI integer type is 64 bit\... $ECHO_C 6
++if test ${ac_64bit_type+set} = set; then
++ echo $ECHO_N (cached) $ECHO_C 6
++else
++ if test $cross_compiling = yes; then
++ ac_64bit_type=none
++else
++ cat conftest.$ac_ext _ACEOF
++/* confdefs.h. */
++_ACEOF
++cat confdefs.h conftest.$ac_ext
++cat conftest.$ac_ext _ACEOF
++/* end confdefs.h. */
++
+ int main(void) {
+ if (sizeof(long)==8)
+ return(0);
+ else
+ return(1);
+-}], ac_64bit_type=long, ac_64bit_type=none))
++}
++_ACEOF
++rm -f conftest$ac_exeext
++if { (eval echo $as_me:$LINENO: \$ac_link\) 5
++ (eval $ac_link) 25
++ ac_status=$?
++ echo $as_me:$LINENO: \$? = $ac_status 5
++ (exit $ac_status); }  { ac_try='./conftest$ac_exeext'
++ { (eval echo $as_me:$LINENO: \$ac_try\) 5
++ (eval $ac_try) 25
++ ac_status=$?
++ echo $as_me:$LINENO: \$? = $ac_status 5
++ (exit $ac_status); }; }; then
++ ac_64bit_type=long
++else
++ echo $as_me: program exited with status $ac_status 5
++echo $as_me: failed program was: 5
++sed 's/^/| /' conftest.$ac_ext 5
++
++( exit $ac_status )
++ac_64bit_type=none
++fi
++rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext 
conftest.$ac_ext
++fi
++fi
++echo $as_me:$LINENO: result: $ac_64bit_type 5
++echo ${ECHO_T}$ac_64bit_type 6
+ if test $ac_64bit_type = long
+ then
+ T1_AA_TYPE64=-DT1_AA_TYPE64=long
--
2.1.0



--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] add t1lib patch

2015-08-12 Thread QIAO YANG


Hi,

So here I patch the configure.in file instead of its output. If this one is 
good to go, I'll send you the two other patches for microwindows-bset and 
t1lib-bset , with its' correct patch urls.

Best wishes


On Aug 12, 2015, at 02:16 AM, YANG QIAO yangqiao0...@me.com wrote:


From: YANG Qiao yangqiao0...@me.com

---
tools/4.11/t1lib/t1lib-5.1.2.diff | 58 +++
1 file changed, 58 insertions(+)
create mode 100644 tools/4.11/t1lib/t1lib-5.1.2.diff

diff --git a/tools/4.11/t1lib/t1lib-5.1.2.diff 
b/tools/4.11/t1lib/t1lib-5.1.2.diff
new file mode 100644
index 000..1c59e2b
--- /dev/null
+++ b/tools/4.11/t1lib/t1lib-5.1.2.diff
@@ -0,0 +1,58 @@
+--- t1lib-5.1.2.orig/configure.in 2015-08-12 14:35:01.064674452 +0200
 t1lib-5.1.2/configure.in 2015-08-12 14:35:05.148674279 +0200
+@@ -225,14 +225,52 @@
+
+ dnl  Check which ANSI integer type is 64 bit
+
+-AC_CACHE_CHECK( which ANSI integer type is 64 bit, ac_64bit_type,
+- AC_TRY_RUN([
++echo $ECHO_N checking \which ANSI integer type is 64 bit\... $ECHO_C 6
++if test ${ac_64bit_type+set} = set; then
++ echo $ECHO_N (cached) $ECHO_C 6
++else
++ if test $cross_compiling = yes; then
++ ac_64bit_type=none
++else
++ cat conftest.$ac_ext _ACEOF
++/* confdefs.h. */
++_ACEOF
++cat confdefs.h conftest.$ac_ext
++cat conftest.$ac_ext _ACEOF
++/* end confdefs.h. */
++
+ int main(void) {
+ if (sizeof(long)==8)
+ return(0);
+ else
+ return(1);
+-}], ac_64bit_type=long, ac_64bit_type=none))
++}
++_ACEOF
++rm -f conftest$ac_exeext
++if { (eval echo $as_me:$LINENO: \$ac_link\) 5
++ (eval $ac_link) 25
++ ac_status=$?
++ echo $as_me:$LINENO: \$? = $ac_status 5
++ (exit $ac_status); }  { ac_try='./conftest$ac_exeext'
++ { (eval echo $as_me:$LINENO: \$ac_try\) 5
++ (eval $ac_try) 25
++ ac_status=$?
++ echo $as_me:$LINENO: \$? = $ac_status 5
++ (exit $ac_status); }; }; then
++ ac_64bit_type=long
++else
++ echo $as_me: program exited with status $ac_status 5
++echo $as_me: failed program was: 5
++sed 's/^/| /' conftest.$ac_ext 5
++
++( exit $ac_status )
++ac_64bit_type=none
++fi
++rm -f core *.core gmon.out bb.out conftest$ac_exeext conftest.$ac_objext 
conftest.$ac_ext
++fi
++fi
++echo $as_me:$LINENO: result: $ac_64bit_type 5
++echo ${ECHO_T}$ac_64bit_type 6
+ if test $ac_64bit_type = long
+ then
+ T1_AA_TYPE64=-DT1_AA_TYPE64=long
--
2.1.0

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

Re: [PATCH 1/2] add t1lib patch

2015-08-10 Thread QIAO YANG





ping Pavel..

how do these look?



Pavel won't be there until 23/08.



Yes there is a source file configue.in, but the problem is that, when we use 
cross-compile, we can't run a sample program to Check which ANSI integer type 
is 64 bit.

The source code is :

AC_CACHE_CHECK( which ANSI integer type is 64 bit, ac_64bit_type,
   AC_TRY_RUN([
int main(void) {
 if (sizeof(long)==8)
   return(0);
 else
   return(1);
}], ac_64bit_type=long, ac_64bit_type=none))

It surprises me that the output of same check for 32 bit do not throw an error 
when CC. I've also searched on Internet but the only solution I found is to 
modify the configure script directly. Apparently there isn't any code to avoid 
the error in source code. That's why I modified the output file.

On Aug 10, 2015, at 06:18 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote:


On 8/10/2015 7:48 AM, YANG QIAO wrote:

From: YANG Qiao yangqiao0...@me.com

---
tools/4.11/t1lib/t1lib-5.1.2.diff | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 tools/4.11/t1lib/t1lib-5.1.2.diff

diff --git a/tools/4.11/t1lib/t1lib-5.1.2.diff 
b/tools/4.11/t1lib/t1lib-5.1.2.diff
new file mode 100644
index 000..5e27472
--- /dev/null
+++ b/tools/4.11/t1lib/t1lib-5.1.2.diff
@@ -0,0 +1,15 @@
+--- t1lib-5.1.2.orig/configure 2015-06-28 23:12:59.394297125 +0200
 t1lib-5.1.2/configure 2015-06-28 23:15:44.066290147 +0200
+@@ -24758,11 +24758,7 @@
+ echo $ECHO_N (cached) $ECHO_C 6
+ else
+ if test $cross_compiling = yes; then
+- { { echo $as_me:$LINENO: error: cannot run test program while cross 
compiling
+-See \`config.log' for more details. 5
+-echo $as_me: error: cannot run test program while cross compiling
+-See \`config.log' for more details. 2;}
+- { (exit 1); exit 1; }; }
++ ac_64bit_type=none
+ else
+ cat conftest.$ac_ext _ACEOF
+ /* confdefs.h. */



--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rpi bsp] configure fb section in mmu table and improvement for mailbox

2015-08-07 Thread QIAO YANG


 On Aug 7, 2015, at 10:45 AM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:
 
 Hello Qiao Ynag,
 
 I am in a hurry now.
 
 On Friday 07 of August 2015 00:52:43 QIAO YANG wrote:
 You have the MMU part right. You know where VC memory starts.
 You round it down to 1MB range (because that is step size which
 ARM MMU provides in the actual RTEMS setup). Then you need to
 limit or enlarge area which would be available for later memory
 allocation support. The thing are safe if you limit memory
 size by ldscript. But limiting to something like 128 MB of usable
 memory is significant waste.
 
 if the limit RAM length setup in linkcmds is 128MB, I can't expend the
 working area to 256MB later in the code.
 It's only possible to initialize 
 the work area with a smaller area.  All memory sections addresses are
 calculated based on RAM, setup in linkcmds. So it will not be possible to
 change the length of RAM later .I can't understand this behavior. If it's
 how it expected, I would say that the RAM length is a hard limit and I'll
 take the smaller one when setting up the work area.
 
 Your idea use  arm_cp15_set_translation_table_entries for VC memory
 is good solution. But if the whole left memory should be used for
 application, then it is necessary to cover rest of the memory by
 ARMV7_MMU_DATA_READ_WRITE_CACHED translations. One option is to define
 memory size big enough to initially write all translations
 as ARMV7_MMU_DATA_READ_WRITE_CACHED or other option is to define
 initial memory as 128 MB for instance and then use separate
 call to arm_cp15_set_translation_table_entries() with
 ARMV7_MMU_DATA_READ_WRITE_CACHED for area 128 MB start of VC area
 and second call for VC area. I am not sure if ARMV7_MMU_DATA_READ_WRITE_CACHED
 is a good idea for that area. I expect that video core access is not coherent
 with CPU access. Then ARMV7_MMU_READ_WRITE should be used. It would be little
 slower but safe.

I’m not sure which flag is better. It’s easy to explain how the memory used.

EX: gpu_mem= 128MB.

Then we the memory from 0x1C00 to the end will be reserved for gpu. All the 
rest are used for arm cpu(0x0 - 0x1c00).
So what I’ve done is to limit the end of workarea to  0x1C00. So that we 
won’t corrupt the memory for gpu.

I’ve added an entry in the MMU table is just for that we have the access to the 
fb memory, and actually the fb memory is in the gpu area (from 0x1E513000 with 
size 0x6E7000). So all in all, the gpu’s memory is reserved for gnu, and all 
memory can be used by cpu is from 0x0 to 0x1c00.

I didn’t mention cp15 table above. What I was trying to explain is that, the 
physical memory size is set in linkcmds, and it’s used to determine  how the 
memory used, ex: where starts the mmu table, interrupt table, etc and their 
size. If the RAM length is smaller, we can’t make use of full memory because I 
can’t expend it in runtime(maybe we can but if i set the RAM to 128MB in 
linkcmds, and try to initialize work area with 256M, system will stop). If the 
length is bigger, then it’s sure that some memory access are overflow. So user 
has to setup the RAM size when compiling, and after the board booted, I’ll 
limit the work area (0x1c00, instead of all 0x2000 memory) so that the 
os won’t allocate the memory located in gpu area(0x1c00 - 0x2000) for 
user. Isn’t it what you want me to take care of?

I agree that I didn’t go further with the mmu flag, I’m not sure which would be 
appropriate. 


 
 I've done many tests with different memory split and see the changes in
 cmdline and also vc mailbox interfaces( get arm memory area tag and get vc
 memory area tag).
 
 With my rpi B/ B+, with 512MB memory:
 
 cmdline:  vc_mem.mem_base=0xec0 vc_mem.mem_size=0x1000
 arm mem base :0x0
 arm mem size :0x800
 vc mem base :0x800
 vc mem size :0x800
 fb base: 0xE513000
 fb size: 0x6E7000
 
 However I changed the gpu_mem in config.txt, the results above remained
 always the same. Finally, it turns out to be an update of firmware.
 
 * Please check out the latest firmware on github
 https://github.com/raspberrypi/firmware/tree/master/boot you may need the
 latest dtb, bootcode.bin, fixup.dat, and start.elf. I've tested them on my
 boards.
 
 arm base :0x0
 arm size :0x1C00
 vc base :0x1C00
 vc size :0x400
 fb base: 0x1E513000
 fb size: 0x6E7000
 
 I get to that when I return from trip.
 
 The memory split is setup with a min 16M and step of 8M , so no worry about
 1M page step alignment.
 
 OK.
 
 BTW, I've found out why the latest firmware didn't work earlier. It was
 because of the fb_mem base address returned by vc mailbox interface, didn't
 add the memory mapping (0x4000) while the new one added it on. So with
 the previous code it can't work with the latest firmware. Now I updated the
 code and I suggest you to use the latest firmware. I'll write it in a blog
 later.
 The area_start is probably OK that the same way as GBA uses.
 Size should

Re: [rpi bsp] add cmdline options

2015-08-03 Thread QIAO YANG


On Jul 29, 2015, at 07:56 AM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:


Hello Qiao Yang,

On Tuesday 28 of July 2015 01:35:45 Pavel Pisa wrote:

Hello Qiao Yang,

On Friday 24 of July 2015 18:04:47 QIAO YANG wrote:
 Some updates for you. I've found out that my previous problem with
 cmdline due to my minicom didn't wrap up the lines I've chosen the
 interface of vc to retrieve cmdline so that we don't need to parse the
 atag nor devicetree. Now we can use --video=... to choose resolution and
 --console=... to choose console.


I have got to little more testing. Ticker runs correctly
with console on serial port and even with graphics console.
But option --console=fbcons works only if it is the last option
on the line in cmdline.txt. Problem is in the comparison because
if there are more options then string provided by rpi_cmdline_arg()
continues after fbcons by blank character. I think that
copy of the string to the user provided buffer is not necessary
in rpi_cmdline_arg(). It would bring up issues with space enough
to fit data etc. I have use simple strncmp to resolve issue.
But something more elegant can be provided.

diff --git a/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c 
b/c/src/lib/libbsp/arm/raspberrypi
index 74cf78e..ad24d33 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c
@@ -91,7 +91,7 @@ void bsp_console_select(void)
if (opt)
{
opt += sizeof(--console=)-1;
- if (strcmp(opt,fbcons) == 0)
+ if (strncmp(opt,fbcons, sizeof(fbcons-1)) == 0)
{
Console_Port_Minor = BSP_CONSOLE_FB;
BSPPrintkPort = BSP_CONSOLE_FB;
@@ -99,8 +99,8 @@ void bsp_console_select(void)
}
else
{
- Console_Port_Minor = BSP_CONSOLE_FB;
- BSPPrintkPort = BSP_CONSOLE_FB;
+ Console_Port_Minor = BSP_CONSOLE_UART0;
+ BSPPrintkPort = BSP_CONSOLE_UART0;
}


/*


As for the interface to command line through VC, I expect that
this interface allows access only to value set in config.txt
but it is not changed by U-boot if used. If that is true
then use of ATAG or device tree would be better for flexibility.
It would be reusable on other ARM targets as well.
But that this can be tried in some follow up project.


It seems to me that behavior is as expected, VideoCore
returns what it parsed from cmdline.txt but arguments
set by U-boot are different. So long term term solution
is to implement shared ARM BSP atags and devicetree parser.
It can be minimal for start only to locate kernel command
line. It would help to other ARM BSPs in general.

MMU setup seems to be OK for me, but what I really
dislike is duplicate of arm-cp15-start.h to RPi.
Shared one should be used.

Les problem is to use different name for
arm_cp15_start_mmu_config_table to not clash
with the definition in header.

I think that the name arm_cp15_start_mmu_config_table
is not part of RTEMS API so it can be changed freely
and if original arm_cp15_start_mmu_config_table
is not defined then incorrect use is catch
easily.

Please, try to resolve this first. Then the suggested
change for strncmp and do more testing.

I suggest to adapt rpi_init_cmdline() a little.

void rpi_init_cmdline(void)
{
bcm2835_get_cmdline_entries get_cmdline_entries;
bcm2835_mailbox_get_cmdline(get_cmdline_entries);
int i; /*I suggest to be C89 compatible, do not
mix declaration with code in single block */
for (i = 0; i  MAX_CMDLINE_LENGTH; ++i)
{
_rpi_cmdline[i] = get_cmdline_entries.cmdline[i];
}
}

It is not necessary to place 512 bytes onto stack.
If you declare get_cmdline_entries static global

static bcm2835_get_cmdline_entries get_cmdline_entries;

Then you can read the line to this global.

If you declare then _rpi_cmdline as

char *_rpi_cmdline;


This is reasonable. I've updated it.



you only point it into right place and do not need
copy. You should add code, which ensures that command
line is zero terminated if you use strstr() later.

You can use something like


bcm2835_mailbox_get_cmdline(get_cmdline_entries);
get_cmdline_entries.cmdline[sizeof(get_cmdline_entries.cmdline) - 1] = 0;

After calling mailbox, I know exactly the length of cmdline and when I return 
the value to the entries, I've added a zero terminated character at the end. 




Generally code division to the functions
and files looks good.

Best wishes,

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

Re: [rpi bsp] configure fb section in mmu table and improvement for mailbox

2015-08-03 Thread QIAO YANG


On Jul 29, 2015, at 02:03 PM, Chris Johns chr...@rtems.org wrote:


On 29/07/2015 8:04 pm, Sebastian Huber wrote:


A custom workspace initialization can be done via
bsp_work_area_initialize().



On the zynq the ethernet driver from Ric (SLAC) for the in tree
(existing) IP stack there is:

uint8_t* start;
size_t size = 0x10;
uintptr_t boundary = (uintptr_t) 0;
uintptr_t alignment = (uintptr_t) 0x10;
start = (uint8_t*) rtems_heap_allocate_aligned_with_boundary(size,
alignment,
boundary);
arm_cp15_set_translation_table_entries(start,
@start[size],
ARMV7_MMU_DEVICE);


The arm_cp15_set_translation_table_entries function does help me to setup MMU 
entry at runtime.

What exactly means the boundary? For exemple, is it possible to allocate the 
memory with a given start address(memory from 0xC10 to 0xD10)? Because in my 
case, the start address and its length is given by GPU.

Actually, I've got everything worked without heap allocate and I've only setup the entry. Is it normal? I know little about how the memory managed and what happened here. 



This creates an MMU entry at runtime for a 1M aligned block of memory
that has the cache disabled.

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

Re: [rpi bsp] configure fb section in mmu table and improvement for mailbox

2015-08-03 Thread QIAO YANG




On Aug 03, 2015, at 08:34 AM, QIAO YANG yangqiao0...@me.com wrote:


On Jul 29, 2015, at 02:03 PM, Chris Johns chr...@rtems.org wrote:


On 29/07/2015 8:04 pm, Sebastian Huber wrote:


A custom workspace initialization can be done via
bsp_work_area_initialize().



On the zynq the ethernet driver from Ric (SLAC) for the in tree
(existing) IP stack there is:

uint8_t* start;
size_t size = 0x10;
uintptr_t boundary = (uintptr_t) 0;
uintptr_t alignment = (uintptr_t) 0x10;
start = (uint8_t*) rtems_heap_allocate_aligned_with_boundary(size,
alignment,
boundary);
arm_cp15_set_translation_table_entries(start,
@start[size],
ARMV7_MMU_DEVICE);


The arm_cp15_set_translation_table_entries function does help me to setup MMU 
entry at runtime.

What exactly means the boundary? For exemple, is it possible to allocate the 
memory with a given start address(memory from 0xC10 to 0xD10)? Because in my 
case, the start address and its length is given by GPU.

Actually, I've got everything worked without heap allocate and I've only setup the entry. Is it normal? I know little about how the memory managed and what happened here. 


I couldn't tell the difference between that I add a section in 
arm_cp15_start_mmu_config_table, then change the start address, end address to 
the right value, and that I add the entry at runtime. I didn't see any 
allocation in both ways. Maybe I just need to setup the entry? Or maybe what 
I've got is an undetermined result. 







This creates an MMU entry at runtime for a 1M aligned block of memory
that has the cache disabled.

Chris
___
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___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RSB] port graphic libraries into rsb

2015-07-25 Thread QIAO YANG


Hi Pavel Pisa,

I've fixed the leak. Please checkout my github.

https://github.com/yangqiao/rtems-source-builder/tree/graphics

Best wishes

On Jul 21, 2015, at 09:51 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:


Hello Qiao Yang

On Tuesday 21 of July 2015 14:21:07 QIAO YANG wrote:

Hi Pavel Pisa,

On Jul 19, 2015, at 10:35 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:
 Hello Chris and Qiao Yang,

 On Monday 20 of July 2015 01:12:33 Chris Johns wrote:
 On 20/07/2015 6:55 am, QIAO YANG wrote:
  I've ported the graphic libraries into rsb so that we can build them
  much easier. All Build passed, tested on arm with raspberrypi and i386
  with pc386.

 Fantastic and thank you.




 I use system wide prefix for my RTEMS install. When I specified that

 --prefix=/opt/rtems4.11

 When I specified that to sb-set-builder then it silently skips install
 steps. This leads not only to problem that I have not received resulting
 binaries (even not found them in temporary RSB trees) but even build of
 later packages dependant on previous ones failed.

 I resolved that by use of RSB option

 --pkg-tar-files

 tar files has been generated and I could extract content to the right
 directory and continue build with followup with sucesfull Microwindows
 package build. I have been able to use that (after tar extraction)
 to build and run my graphic application in QEMU then.

So the library works if I've got it right. No problem with the build
process.


The libraries are configured properly. Only thing to solve for you
is to find way how to limit all/as most as possible files installed
in improper directories. It is not fatal but can make troubles
and is misleading. Look for packages options --disable-test, samples
and some related options to direct install of support files to BSP
specific directories. Documentation can go to RTEMS prefix and shared
area. But includes, libraries, binaries and configs should not.


The other issues are for discussion with Chris Johns
and he woks on these. So rebase of your work onto
his newer RSB versions should help.

I have some more things for Microwindows. It seems that
Microwindows mainline (https://github.com/ghaerr/microwindows)
moves forward (commits by georgp24).

You are using alex-sever-h fork. I do not expect that he returns
to the project. We should consolidate code. I have his changes
in my fork. Some of these are not appropriate for mainline
some needs cheanup. But we should move closer to mainline.
As I find time, I try to prepare branch with changes suitable
for mainline. I would like to change Microwindows RTEMS config
and makefiles such way that NOKBD and NOMOUSE can be selected
for RTEMS by config. Same for some screen variants.

So the patches removing keyboard and mouse in Makefiles would
not be required. All things should be controlled by config.


 Because libraries build is specific than I expect that all build
 results should be installed in BSP directory, i.e.
 /opt/rtems4.11/i386-rtems4.11/pc686/{lib,bin,lib/include} in my case.
 It seems that JPEG library is configured right. But there are significant
 leakages from freetype, libpng, t1lib and libtiff to
 /opt/rtems4.11/bin and /opt/rtems4.11/share directories.
 t1lib even installs to /share/t1lib directly.

Do you mean that the libraries are not installed in the bsp dir?


Yes and no, libraries required to build RTEMS applications are installed
in the right place but there is significant level of noise - tools,
scripts etc installed in inappropriate places.

Add --pkg-tar-files RSB option and then you can easily see what
is content of each installed package - I hope, that it is 1:1 to what
is really installed/copied to the filesystem.


In fact,
I've got all libraries installed in the right place. Firstly, I doubt if
the bsp pc686 exists in arch i386. I can only find pc386 in mainline. Make
sure that the bsp name is correct. Secondly, verify the path you passed is
what the builder expects as chris explained. I haven't found out why the
JPEG works while others can't, but I do use the paths to determin where to
install.


RTEMS supports boards variants. This means that there are more boards
supported than only these seen as individual subdirectory of each
CPU architecture (these subdirectories are more or less equivalent to
machine or platform on Linux). The varinats usually differ in the compiler
flags and some defines which control source builds.

See

rtems/c/src/lib/libbsp/i386/pc386/make/custom

There are varinats
edison.cfg pc386.cfg pc486.cfg pc586.cfg pc586-sse.cfg
pc686.cfg pcp4.cfg

where pc686.cfg includes common pc386.cfg base but selects
pentium generation corresponding optimization
CPU_CFLAGS = -mtune=pentiumpro

and variant name for RTEMS
RTEMS_CPU_MODEL=pentiumpro


I followed alan's blog to setup my environment.

alias i386-kernel-configuer='cd $HOME/development/rtems-386/rtems-git/; \
./bootstrap; \
mkdir $HOME/development/rtems-386/build-rtems-386/; \
cd $HOME/development/rtems-386/build

[rpi bsp] configure fb section in mmu table and improvement for mailbox

2015-07-25 Thread QIAO YANG


Hi Pavel Pisa,

I've added the auto-configuration for fb section in mmu table.
I reserve a section at the end of mmu table, make the table non-const to avoid 
errors, allocate fb before mmu initialization and fill in the table with the 
right parameters.

As far as I've tested, I've found that the zero-length array did not behave 
like I expected. So I decided to go back to my first choice at the begining. 
What doesn't change is that we offer a structure of entries and a function for 
every operation/interface of videocore and hide the detail of tag structures.

I think it's much closer to what we expected. you may checkout my github and my 
dropbox.

https://github.com/yangqiao/rtems/tree/framebuffer
https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0

The commits log is messy, I'll rebase it afterward until we think it's 
acceptable.

Looking forward to your comments.

Best wishes.

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

[rpi bsp] add cmdline options

2015-07-24 Thread QIAO YANG


Hi,

Some updates for you. I've found out that my previous problem with cmdline due 
to my minicom didn't wrap up the lines I've chosen the interface of vc to 
retrieve cmdline so that we don't need to parse the atag nor devicetree. Now we 
can use --video=...  to choose resolution and --console=... to choose console.

Some notes:

1. the rpi's cmdline can be setup by a plain-text, single-line file cmdline.txt.
2. I've implemented only 32-bpp. So the bpp is ignored. I may add other pixel 
drawing mode if necessary.
3. If no device connected to hdmi port, the display size would be 656x416. I 
use this as a probe.
4. --console=fbcons will select the fb console. Otherwise we will use the 
default option (serial console).
5. If we pass supported parameters to videocore, it will correct it and return 
the value configured. So I didn't port the part of code which select resolution 
from a list, but this lead to a behavior that we can pass some parameters like 
12800x645  and get everything displayed.

I wonder if we have to limit the resolution in a mode_list.


here are precompiled binaries for tests.
https://www.dropbox.com/sh/9pvyf41zrjbx0hf/AAAIVJyCZPzXv0I1TnA5e7qUa?dl=0


Best wishes,
YANG Qiao
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RPi Graphic testing

2015-07-23 Thread QIAO YANG


On Jul 22, 2015, at 05:50 AM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:

Hello Qiao Yang,

On Wednesday 22 of July 2015 11:19:35 QIAO YANG wrote:
Hi,

When I updated to the latest firmware start.elf , the graphic doesn’t show
anymore. I haven’t yet found out what has been changed in the latest
firmware. I’ve uploaded my firmware. I’ve retested my latest commit, it
worked with hello, ticker and rbi samples.

https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0
https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0

I have been able to run your binary of ticker and its console is displayed
on the RPi correctly. Whwn I have used your binary and start.elf on my card
then it runs OK as well. I have tried even your binary when loaded
by u-boot from TFTP server. I have hard time to find right version
of U-boot with working network support.

Only older version works correctly and I am not sure
if that one was compiled by me or even loaded from some
site

U-Boot 2014.10-rc2-g600877e-dirty (Sep 25 2014 - 09:57:12)
 
here is a working u-boot for rpi, contributed by swarren.
git://github.com/swarren/u-boot.git
you can checkout his branches  rpi_dev*



But with right U-boot version the binary works as well.
I have build successfully ticker binary myself as well.

Then I have tested my complete graphic application example.
I have to disable keyboard and mouse config and then have
obstacle with framebuffer driver setup

#if (BSP_HAS_FRAME_BUFFER == 1)
#define CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
#endif

#define CONFIGURE_INIT
#include rtems/confdefs.h

Because raspberrypi BSP does not set define BSP_HAS_FRAME_BUFFER yet.
When I forced graphics inclusion then application starts.

But there seems to be some problem with some parameters obtained
from graphic driver probably or some other similar problem
because image is screwed on the couple of the first lines.
But start of the display seems to be right.

Parameters

[#]fb_var_screeninfo: xres : 1280
[#]fb_var_screeninfo: yres : 1024
[#]fb_var_screeninfo: bpp : 32

matches monitor info and values in the driver structures looks
reasonable either

fb_fix_info = {smem_start = 0xe6fa000 \377, smem_len = 5242880,
type = 0, visual = 2, line_length = 160}

But there is a mistake with computed line_length. It is number
of bytes for one image line. So next change is required

--- a/c/src/lib/libbsp/arm/raspberrypi/console/fb.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/console/fb.c
@@ -126,7 +126,8 @@ fb_init(void)
fb_var_info.bits_per_pixel = init_frame_buffer_entries.depth;
fb_fix_info.smem_start = init_frame_buffer_entries.base;
fb_fix_info.smem_len = init_frame_buffer_entries.size;
- fb_fix_info.line_length = fb_var_info.xres/VIDEO_FONT_WIDTH;
+ fb_fix_info.line_length = fb_var_info.xres *
+ ((fb_var_info.bits_per_pixel + 7) / 8);
I misunderstood the comment  /* number of chars per line */   I thought it 
was the number of characters.
Does this fix the mess of first few lines?  Or there may be some other problems?



printk([#]fb_var_screeninfo: xres : %lu\n, fb_var_info.xres);
printk([#]fb_var_screeninfo: yres : %lu\n, fb_var_info.yres);

As for the

fb_var_info = {xres = 1280, yres = 1024, bits_per_pixel = 32,
red = {offset = 0, length = 0, msb_right = 0},
green = {offset = 0, length = 0, msb_right = 0},
blue = {offset = 0, length = 0, msb_right = 0},
transp = {offset = 0, length = 0, msb_right = 0}}

the colors fields locations are missing but that information
is ignored by actual Microwindows so it is not problem for now.

In fact I didn't quite understand the use of color palette. In some other bsp's 
implementation, they just define the structure but I didn't see any hardware 
related code, and some just return zero. I've seen that we can setup the color 
palettes with videocore interface by mailbox. I can complete that later if 
necessary. Since it's ignored, I would place it with lower priority.



As for the memory map setup, the RTEMS does use only
single level pagetable/MMU regions setup for CP15 (MMU)
equipped arms. That means that maping works with 1 MB
blocks granularity.

Look at arm_cp15_start_setup_translation_table() and 
arm_cp15_start_set_translation_table_entries() functions in

in

c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h

and other related functions in in
c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c

The 1 MB granularity/page size is reflected by

#define ARM_MMU_SECT_BASE_SHIFT 20

in

c/src/lib/libcpu/arm/shared/include/arm-cp15.h

So if you detect size of the memory window for VideoCore,
you should align it/extend it down and up to 1 MB boundary
or at least consider that behavior of the mapping functions.

The actual limit of the memory usable for RTEMS application
below VideoCore region should be used to setup limit
for RTEMS workspace and application memory size later.
Excuse me, I'm not sure if I've got it right.
Do you mean

Re: [RSB] port graphic libraries into rsb

2015-07-23 Thread QIAO YANG


On Jul 21, 2015, at 09:51 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:

Hello Qiao Yang

On Tuesday 21 of July 2015 14:21:07 QIAO YANG wrote:
Hi Pavel Pisa,

On Jul 19, 2015, at 10:35 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:

Hello Chris and Qiao Yang,

On Monday 20 of July 2015 01:12:33 Chris Johns wrote:

On 20/07/2015 6:55 am, QIAO YANG wrote:
 I've ported the graphic libraries into rsb so that we can build them
 much easier. All Build passed, tested on arm with raspberrypi and i386
 with pc386.

Fantastic and thank you.




I use system wide prefix for my RTEMS install. When I specified that

--prefix=/opt/rtems4.11

When I specified that to sb-set-builder then it silently skips install
steps. This leads not only to problem that I have not received resulting
binaries (even not found them in temporary RSB trees) but even build of
later packages dependant on previous ones failed.

I resolved that by use of RSB option

--pkg-tar-files

tar files has been generated and I could extract content to the right
directory and continue build with followup with sucesfull Microwindows
package build. I have been able to use that (after tar extraction)
to build and run my graphic application in QEMU then.


So the library works if I've got it right. No problem with the build
process.

The libraries are configured properly. Only thing to solve for you
is to find way how to limit all/as most as possible files installed
in improper directories. It is not fatal but can make troubles
and is misleading. Look for packages options --disable-test, samples
and some related options to direct install of support files to BSP
specific directories. Documentation can go to RTEMS prefix and shared
area. But includes, libraries, binaries and configs should not.

The other issues are for discussion with Chris Johns
and he woks on these. So rebase of your work onto
his newer RSB versions should help.

I have some more things for Microwindows. It seems that
Microwindows mainline (https://github.com/ghaerr/microwindows)
moves forward (commits by georgp24).

You are using alex-sever-h fork. I do not expect that he returns
to the project. We should consolidate code. I have his changes
in my fork. Some of these are not appropriate for mainline
some needs cheanup. But we should move closer to mainline.
As I find time, I try to prepare branch with changes suitable
for mainline. I would like to change Microwindows RTEMS config
and makefiles such way that NOKBD and NOMOUSE can be selected
for RTEMS by config. Same for some screen variants.

So the patches removing keyboard and mouse in Makefiles would
not be required. All things should be controlled by config.
That would be great. I think I'll try to fix the problem with framebuffer first 
and I'll join you later. 




Because libraries build is specific than I expect that all build
results should be installed in BSP directory, i.e.
/opt/rtems4.11/i386-rtems4.11/pc686/{lib,bin,lib/include} in my case.
It seems that JPEG library is configured right. But there are significant
leakages from freetype, libpng, t1lib and libtiff to
/opt/rtems4.11/bin and /opt/rtems4.11/share directories.
t1lib even installs to /share/t1lib directly.


Do you mean that the libraries are not installed in the bsp dir?

Yes and no, libraries required to build RTEMS applications are installed
in the right place but there is significant level of noise - tools,
scripts etc installed in inappropriate places.

Add --pkg-tar-files RSB option and then you can easily see what
is content of each installed package - I hope, that it is 1:1 to what
is really installed/copied to the filesystem.
Thanks, I've got it and I'll send patches later. 




In fact,
I've got all libraries installed in the right place. Firstly, I doubt if
the bsp pc686 exists in arch i386. I can only find pc386 in mainline. Make
sure that the bsp name is correct. Secondly, verify the path you passed is
what the builder expects as chris explained. I haven't found out why the
JPEG works while others can't, but I do use the paths to determin where to
install.

RTEMS supports boards variants. This means that there are more boards
supported than only these seen as individual subdirectory of each
CPU architecture (these subdirectories are more or less equivalent to
machine or platform on Linux). The varinats usually differ in the compiler
flags and some defines which control source builds.

See

rtems/c/src/lib/libbsp/i386/pc386/make/custom

There are varinats
edison.cfg pc386.cfg pc486.cfg pc586.cfg pc586-sse.cfg
pc686.cfg pcp4.cfg

where pc686.cfg includes common pc386.cfg base but selects
pentium generation corresponding optimization
CPU_CFLAGS = -mtune=pentiumpro

and variant name for RTEMS
RTEMS_CPU_MODEL=pentiumpro

I followed alan's blog to setup my environment.

alias i386-kernel-configuer='cd $HOME/development/rtems-386/rtems-git/; \
./bootstrap; \
mkdir $HOME/development/rtems-386/build-rtems-386/; \
cd $HOME/development/rtems-386/build-rtems-386

Re: RPi Graphic testing

2015-07-22 Thread QIAO YANG

Hi,

When I updated to the latest firmware start.elf , the graphic doesn’t show 
anymore. I haven’t yet found out what has been changed in the latest firmware. 
I’ve uploaded my firmware. I’ve retested my latest commit, it worked with 
hello, ticker and rbi samples.

https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0 
https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0



 On Jul 21, 2015, at 1:13 AM, 桥 杨 yangqiao0...@me.com wrote:
 
 I'll try to retest my latest commit tomorrow with my rpi B and rpi B+.
 
 I disn't see any errors from the log and I havn't yet any idea why It didn't 
 work. Keep in touch when you do tests. I'm always reachable.
 
 Thanks for the instructions of memory table. I'll try that tomorrow.
 
 在 2015年7月21日，00:52，Pavel Pisa p...@cmp.felk.cvut.cz 写道：
 
 Hello Qiao Yang,
 
 On Monday 20 of July 2015 20:50:32 QIAO YANG wrote:
 So it has got the right pointer for frame buffer.
 
 Please set the macros
 
 BCM2835_FBMEM_BASE to 0x1C006000
 and BCM2835_FBMEM_SIZE to 0x50
 according to your log.
 
 I have got to testing at home where I have other RPi board
 and have no luck till. The memory setup is different there so I tried
 to recompiled for that one. I will rerun test at the university
 on the previous board again on Wednesday. If you have some
 enhancements, commit them to your RTEMS git, please.
 
 As for memory map adaptation, RTEMS does not include infrastructure
 for memory management setup changes at runtime but the before
 bsp_memory_management_initialize() is called then CPU runs in 1:1
 mapping where physical and virtual addresses match. The main
 reason to setup and enable MMU on ARM is that without MMU
 cache cannot be enabled so execution is slow. Even instruction
 cache can be enabled without MMU enable on some ARM models.
 So the system is mostly/completely operational before MMU
 enable.
 
 arm_cp15_start_mmu_config_table table is declared as const
 but if it is not marked that way and compiler error is prevented
 then it can be manipulated before bsp_memory_management_initialize();
 in bsp_start_hook_1() is called
 
 rtems/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c 
 bsp_start_hook_1(void)
 
 So it should be possible to parse ATAGs or even access VideoCore
 before MMU is configured.
 
 The MMU config requires arm_cp15_start_mmu_config_table to be global
 variable. There is other solution even if problem with
 const does not allows simple modification of the table
 (but brute cast in the function adding video region would work either).
 
 It is most probable possible to skip to call 
 bsp_memory_management_initialize() from the hook
 and use local variant of that code which would be RPi BSP
 specific
 
 rtems-yangqiao/c/src/lib/libbsp/arm/shared/mminit.c
 bsp_memory_management_initialize();
 
 #define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
 
 #include bsp/start.h
 #include bsp/arm-cp15-start.h
 #include bsp/linker-symbols.h
 #include bsp/mm.h
 
 BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
 {
 uint32_t ctrl = arm_cp15_get_control();
 
 ctrl |= ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_S | ARM_CP15_CTRL_XP;
 
 arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
   ctrl,
   (uint32_t *) bsp_translation_table_base,
   ARM_MMU_DEFAULT_CLIENT_DOMAIN,
   arm_cp15_start_mmu_config_table[0],
   arm_cp15_start_mmu_config_table_size
 );
 }
 
 So it is quite short sequence and even highly dynamic table can be used.
 
 The mechanism to obtain installed/board provided memory size
 is required even to setup correctly size of memory and heap
 available for RTEMS system workspace and user application.
 
 So this should be solved (at least in long term horizon) some
 more generic/autoconfigured way.
 
 Best wishes,
 
Pavel
 ___
 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

[RSB] port graphic libraries into rsb

2015-07-21 Thread QIAO YANG


Hi Pavel Pisa,

On Jul 19, 2015, at 10:35 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:


Hello Chris and Qiao Yang,

On Monday 20 of July 2015 01:12:33 Chris Johns wrote:

On 20/07/2015 6:55 am, QIAO YANG wrote:
 I've ported the graphic libraries into rsb so that we can build them
 much easier. All Build passed, tested on arm with raspberrypi and i386
 with pc386.

Fantastic and thank you.


I have reproduced build for i386. Thanks for instructions.
I return to the Microwindows suggestions in a separate message.

I would like to speak about source builder related questions first


 the libraries can be built with the command like:

 ../source-builder/sb-set-builder \
 --log=graphic-build-log.txt \
 --prefix=$HOME/development/rtems-386/bsps/4.11 \
 --with-rtems-bsp=pc386 \
 --host=i386-rtems4.11 \
 4.11/graphics/freetype2.bset \
 4.11/graphics/libjpeg.bset \
 4.11/graphics/libpng.bset \
 4.11/graphics/libtiff.bset \
 4.11/graphics/t1lib.bset \
 4.11/graphics/microwindows.bset \
 4.11/graphics/nxlib.bset

 Patches that I used is available on my github fork of rtems-tools.
 Waiting for more tests and reviews.

I am closing in on finishing ticket https://devel.rtems.org/ticket/2374
 
and I will test this after it has been resolved.


I use system wide prefix for my RTEMS install. When I specified that

--prefix=/opt/rtems4.11

When I specified that to sb-set-builder then it silently skips install
steps. This leads not only to problem that I have not received resulting
binaries (even not found them in temporary RSB trees) but even build of
later packages dependant on previous ones failed.

I resolved that by use of RSB option

--pkg-tar-files

tar files has been generated and I could extract content to the right
directory and continue build with followup with sucesfull Microwindows
package build. I have been able to use that (after tar extraction)
to build and run my graphic application in QEMU then.


So the library works if I've got it right. No problem with the build process.




But I have failed into other trap with RSB first. I am used never
run commands with current directory in the git. So I have setup
build directory for the test and tried to run next script

-
#!/bin/sh

SB_DIR=../../git/rtems-source-builder-yangqiao

SB_DIR=$(cd -L $SB_DIR ; pwd -L )

mkdir -p yangqiao-graphics

cd yangqiao-graphics

# --prefix=$HOME/development/rtems-386/bsps/4.11 \

$SB_DIR/source-builder/sb-set-builder \
--log=graphic-build-log.txt \
--prefix=/opt/rtems4.11 \
--with-rtems-bsp=pc686 \
--host=i386-rtems4.11 \
--configdir $SB_DIR/rtems/config \
--pkg-tar-files \
$SB_DIR/rtems/config/4.11/graphics/freetype2.bset \
$SB_DIR/rtems/config/4.11/graphics/libjpeg.bset \
$SB_DIR/rtems/config/4.11/graphics/libpng.bset \
$SB_DIR/rtems/config/4.11/graphics/libtiff.bset \
$SB_DIR/rtems/config/4.11/graphics/t1lib.bset \
$SB_DIR/rtems/config/4.11/graphics/microwindows.bset \
$SB_DIR/rtems/config/4.11/graphics/nxlib.bset
-

I tried to modify parameters different ways but it seems that
invocation outside of git/rtems-source-builder/rtems is not
supported. I.e. if --configdir is set then relative subdirectory
components pointing to *.cfg files are stripped. It can be good
idea on one hand if it is expected to put then all *.cfg files
to local/build specific/ directory but means finding and copying
of all dependences *.cfg.

I expect, that viceversa setup, i.e. CWD in git/rtems-source-builder/rtems
and option --topdir would work but I have not tested that.

I am not sure if described behavior is bug or feature and would like
to hear what is expected use.

The last question is on the border of RSB build and graphic packages
specific area.

Because libraries build is specific than I expect that all build
results should be installed in BSP directory, i.e.
/opt/rtems4.11/i386-rtems4.11/pc686/{lib,bin,lib/include} in my case.
It seems that JPEG library is configured right. But there are significant
leakages from freetype, libpng, t1lib and libtiff to
/opt/rtems4.11/bin and /opt/rtems4.11/share directories.
t1lib even installs to /share/t1lib directly.


Do you mean that the libraries are not installed in the bsp dir? In fact, I've 
got all libraries installed in the right place.
Firstly, I doubt if the bsp pc686 exists in arch i386. I can only find pc386 in 
mainline. Make sure that the bsp name is correct.
Secondly, verify the path you passed is what the builder expects as chris 
explained. I haven't  found out why the JPEG works while others can't, but I do 
use the paths to determin where to install.

I followed alan's blog to setup my environment.

alias i386-kernel-configuer='cd $HOME/development/rtems-386/rtems-git/; \
   ./bootstrap; \
   mkdir $HOME/development/rtems-386/build-rtems-386/; \
   cd $HOME/development/rtems-386/build-rtems-386/; \
   ../rtems-git/configure --target=i386-rtems4.11

Re: RPi Graphic testing

2015-07-20 Thread QIAO YANG

So it has got the right pointer for frame buffer.

Please set the macros

BCM2835_FBMEM_BASE to 0x1C006000 
and BCM2835_FBMEM_SIZE to 0x50
according to your log.

in file c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h

It’s not possible to setup memory map dynamically and the area is not fixed. I 
don’t have a better way to deal with it other than set a huge range to cover 
all possibilities.

waiting for your further report


 On Jul 20, 2015, at 8:38 PM, Pavel Pisa p...@cmp.felk.cvut.cz wrote:
 
 Hello Qiao Yang and other,
 
 On Monday 20 of July 2015 15:06:23 Pavel Pisa wrote:
 Hello Qiao Yang,
 
 I have spent more time with attempt to test
 your RPi code but I am not sucesfull.
 I have tried direct boot to application binary
 as well as U-boot based start.
 
 I expect that problem source can be version
 of my primary bootloader
 
 I have tested the build and it seems that real problem
 is really mismatch between VideoCore area sent
 to the monitor and RTEMS view because application
 seems to run OK, detects monitor
 
 U-Boot 2014.10-rc2-g600877e-dirty (Sep 25 2014 - 09:57:12)
 
 DRAM:  448 MiB
 
 
 
 [+] framebuffer initialize
 [+] framebuffer use display resolution 1280*1024
 [#]fb_var_screeninfo: xres : 1280
 [#]fb_var_screeninfo: yres : 1024
 [#]fb_var_screeninfo: bpp : 32
 [#]fb_fix_screeninfo: smem_start : 1C006000
 [#]fb_fix_screeninfo: smem_len : 50
 [#]fb_fix_screeninfo: line_length : 160
 [#]_RPI_initVideo: maxCol : 160
 [#]_RPI_initVideo: maxRow : 64
 [#]_RPI_initVideo: fb_mem : 1C006000
 
 and correctly advances to the Init() and test application,
 even character output is called right way to the RPi graphic
 console support. Stack trace for curiosity
 
 #0  _RPI_outch (c=48 '0') at 
 ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/outch.c:347
 #1  0xa320 in fbcons_write_polled (c=48 '0', minor=optimized out) 
 at 
 ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/fbcons.c:79
 #2  fbcons_write_support_polled (minor=optimized out, buf=0x10a6df 0\001, 
 len=1) 
 at 
 ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/fbcons.c:102
 #3  0xf8c0 in oproc (c=optimized out, tty=tty@entry=0x10eb50) 
 at 
 ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/termios.c:1192
 #4  0xfeb4 in rtems_termios_write (arg=0x10a700) 
 at 
 ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/termios.c:1214
 #5  0x000177ec in rtems_deviceio_write (iop=0x103d70 rtems_libio_iops+112, 
 buf=optimized out, nbyte=optimized out, major=optimized 
 out, minor=1) at 
 ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:109
 #6  0x0001704c in device_write (iop=optimized out, buffer=optimized out, 
 count=optimized out) 
 at 
 ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libfs/src/imfs/deviceio.c:82
 #7  0x0001a274 in __swrite (ptr=0x105a08, cookie=0x105c40, buf=0x10a897 0, 
 n=1) 
 at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/stdio.c:97
 #8  0x0001b95c in __sfvwrite_r (ptr=0x105a08, fp=0x105c40, uio=0x10a7e8) at 
 ../../../../../../../src/gcc-4.9/newlib/libc/stdio/fvwrite.c:99
 #9  0x0001a408 in __sprint_r (ptr=optimized out, fp=0x105c40, uio=0x10a7e8) 
 at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/vfprintf.c:437
 #10 0x0001b204 in _vfiprintf_r (data=0x105a08, fp=fp@entry=0x105c40, 
 fmt0=fmt0@entry=0x41 , ap=...) 
 at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/vfprintf.c:1774
 #11 0x00019f00 in fiprintf (fp=0x105c40, fmt=0x100398 %s%02lu:%02lu:%02lu   
 %02lu/%02lu/%04lu%s) 
 at ../../../../../../../src/gcc-4.9/newlib/libc/stdio/fiprintf.c:50
 #12 0x8ba4 in Test_task (unused=optimized out) 
 at 
 ../../../../../../../../../git/rtems-yangqiao/c/src/../../testsuites/samples/ticker/tasks.c:44
 #13 0x00019810 in _Thread_Handler () at 
 ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/score/src/threadhandler.c:95
 #14 0x000197a0 in TOD_TICKS_PER_SECOND_method () 
 at 
 ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/score/src/coretodtickspersec.c:28
 #15 0x2008 in ?? ()
 #16 0x2008 in ?? ()
 
 As for ATAGS, on my system it seems that argument passed by U-boot is 
 consistent. Memory content
 
 0x100:0x0005 0x54410001
 0x108:  0x 0x 0x
  ATAG_CORE block, 5 words complete, all zeros
 
 0x114:  0x0004 0x54410002 0x1c00 0x
  ATAG_MEM block, 4 words
  __u32   size = 0x1c00 ... 448 MiB
  __u32   start = 0x
 
 0x124:  0x0067 0x54410009
  ATAG_CMDLINE block, 0x67 words ... 412 - 8 bytes
  next ATAG at 0x124 + 0x067 * 4 = 0x2c0
 
 0x12c:dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1280 
 bcm2708_fb.fbheight=1024 bcm2708.boardrev=0xf bcm2708.serial=0x53a65607 
 smsc95xx.macaddr=B8:27:EB:A6:56:07 sdhci-bcm2708.emmc_clock_freq=25000

[PATCH 6/6] RSB: add nxlib bset

2015-07-19 Thread QIAO YANG


---
rtems/config/4.11/graphics/nxlib.bset  | 20 ++
rtems/config/graphics/nxlib-0.47-dev-1.cfg | 19 +
source-builder/config/nxlib-1.cfg  | 62 ++
3 files changed, 101 insertions(+)
create mode 100644 rtems/config/4.11/graphics/nxlib.bset
create mode 100644 rtems/config/graphics/nxlib-0.47-dev-1.cfg
create mode 100644 source-builder/config/nxlib-1.cfg

diff --git a/rtems/config/4.11/graphics/nxlib.bset 
b/rtems/config/4.11/graphics/nxlib.bset
new file mode 100644
index 000..a80fb0e
--- /dev/null
+++ b/rtems/config/4.11/graphics/nxlib.bset
@@ -0,0 +1,20 @@
+#
+# Build set for nxlib
+#
+
+%define release 1
+
+#
+# RTEMS Version
+#
+%define rtems_version 4.11
+
+#
+# The RTEMS URL paths.
+#
+%include rtems-urls.bset
+
+#
+# Build nxlib.
+#
+graphics/nxlib-0.47-dev-1.cfg
diff --git a/rtems/config/graphics/nxlib-0.47-dev-1.cfg 
b/rtems/config/graphics/nxlib-0.47-dev-1.cfg
new file mode 100644
index 000..deed54e
--- /dev/null
+++ b/rtems/config/graphics/nxlib-0.47-dev-1.cfg
@@ -0,0 +1,19 @@
+#
+# nxlib 0.47
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# nxlib Version
+#
+%define nxlib_version 0.47-dev
+
+#
+# nxlib Build configuration
+#
+%include %{_configdir}/nxlib-1.cfg
diff --git a/source-builder/config/nxlib-1.cfg 
b/source-builder/config/nxlib-1.cfg
new file mode 100644
index 000..0323ee8
--- /dev/null
+++ b/source-builder/config/nxlib-1.cfg
@@ -0,0 +1,62 @@
+#
+# nxlib
+#
+# This configuration file configure's, make's and install's nxlib.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  nxlib-v%{nxlib_version}-%{_host}-%{release}
+Summary:   nxlib is a wrapper library that provides closer compatibility to 
the Xlib API for Nano-X
+Version:   %{nxlib_version}
+Release:   %{release}
+URL: http://www.microwindows.org/
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# nxlib Source
+#
+%source set nxlib git://github.com/alex-sever-h/nxlib.git
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_nxlib=nxlib
+  %source setup nxlib -q -n nxlib
+
+  cd ${build_top}
+
+#
+# Build the source code.
+# The configure should be run in the source dir
+#
+%build
+  build_top=$(pwd)
+
+  %{build_directory}
+
+  mkdir -p ${build_dir}
+  cd ${build_dir}
+  cp -r ${build_top}/${source_dir_nxlib}/* .
+
+  export RTEMS_MAKEFILE_PATH=%{_exec_prefix}
+
+  make -f Makefile.rtems
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  %{__rmdir} $SB_BUILD_ROOT
+
+  cd ${build_dir}
+  mkdir -p $SB_BUILD_ROOT/%{_includedir}/X11
+  mkdir -p $SB_BUILD_ROOT/%{_libdir}
+  cp -r X11/*.h $SB_BUILD_ROOT/%{_includedir}/X11
+  cplibX11.a $SB_BUILD_ROOT/%{_libdir}
--
2.1.0



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

[PATCH 5/6] RSB: add nanoX bset

2015-07-19 Thread QIAO YANG


---
rtems/config/4.11/graphics/microwindows.bset  | 20 +++
rtems/config/graphics/microwindows-0.93-dev-1.cfg | 19 ++
source-builder/config/microwindows-1.cfg  | 71 +++
3 files changed, 110 insertions(+)
create mode 100644 rtems/config/4.11/graphics/microwindows.bset
create mode 100644 rtems/config/graphics/microwindows-0.93-dev-1.cfg
create mode 100644 source-builder/config/microwindows-1.cfg

diff --git a/rtems/config/4.11/graphics/microwindows.bset 
b/rtems/config/4.11/graphics/microwindows.bset
new file mode 100644
index 000..edae6d7
--- /dev/null
+++ b/rtems/config/4.11/graphics/microwindows.bset
@@ -0,0 +1,20 @@
+#
+# Build set for Nano-X Window System
+#
+
+%define release 1
+
+#
+# RTEMS Version
+#
+%define rtems_version 4.11
+
+#
+# The RTEMS URL paths.
+#
+%include rtems-urls.bset
+
+#
+# Build microwindows.
+#
+graphics/microwindows-0.93-dev-1.cfg
diff --git a/rtems/config/graphics/microwindows-0.93-dev-1.cfg 
b/rtems/config/graphics/microwindows-0.93-dev-1.cfg
new file mode 100644
index 000..c0cdc86
--- /dev/null
+++ b/rtems/config/graphics/microwindows-0.93-dev-1.cfg
@@ -0,0 +1,19 @@
+#
+# microwindows 0.92
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# microwindows Version
+#
+%define microwindows_version 0.93-dev
+
+#
+# microwindows Build configuration
+#
+%include %{_configdir}/microwindows-1.cfg
diff --git a/source-builder/config/microwindows-1.cfg 
b/source-builder/config/microwindows-1.cfg
new file mode 100644
index 000..b1944f3
--- /dev/null
+++ b/source-builder/config/microwindows-1.cfg
@@ -0,0 +1,71 @@
+#
+# microwindows
+#
+# This configuration file configure's, make's and install's microwindows.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  microwindows-v%{microwindows_version}-%{_host}-%{release}
+Summary:   microwindows is an Open Source Window System
+Version:   %{microwindows_version}
+Release:   %{release}
+URL: http://www.microwindows.org/
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# microwindows Source
+#
+%source set microwindows git://github.com/alex-sever-h/microwin.git
+%patch add microwindows 
https://raw.githubusercontent.com/yangqiao/rtems-tools/graphics/tools/4.11/microwindows/microwindows-0.93-dev.diff
+%hash md5 microwindows-0.93-dev.diff aea54ac45389ca06c956215bad32c24c
+%patch add microwindows 
https://raw.githubusercontent.com/yangqiao/rtems-tools/graphics/tools/4.11/microwindows/microwindows-0.93-dev-without-keyboard.diff
+%hash md5 microwindows-0.93-dev-without-keyboard.diff 
c78aacc33e9b346d5ac78b2b35f17809
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_microwindows=microwin
+  %source setup microwindows -q -n microwin
+  %patch setup microwindows -p1
+
+  cd ${build_top}
+
+#
+# Build the source code.
+# The configure should be run in the source dir
+#
+%build
+  build_top=$(pwd)
+
+  %{build_directory}
+
+  mkdir -p ${build_dir}/src
+  cd ${build_dir}/src
+  cp -r ${build_top}/${source_dir_microwindows}/src/* .
+
+  #%{host_build_flags}
+
+  export RTEMS_MAKEFILE_PATH=%{_exec_prefix}
+
+  make -f Makefile.rtems CONFIG=`pwd`/Configs/config.rtems -k all
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  %{__rmdir} $SB_BUILD_ROOT
+
+  cd ${build_dir}/src
+  mkdir -p $SB_BUILD_ROOT/%{_includedir}
+  mkdir -p $SB_BUILD_ROOT/%{_libdir}
+  mkdir -p $SB_BUILD_ROOT/%{_bindir}
+  cp -r include/* $SB_BUILD_ROOT/%{_includedir}
+  cp -r lib/*.a $SB_BUILD_ROOT/%{_libdir}
+  cp -r bin/* $SB_BUILD_ROOT/%{_bindir}
--
2.1.0



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

[PATCH 1/6] RSB : add libpng bset

2015-07-19 Thread QIAO YANG



rtems/config/4.11/graphics/libpng.bset| 20 ++
rtems/config/graphics/libpng-1.5.22-1.cfg | 22 +++
source-builder/config/libpng-1.cfg| 63 +++
3 files changed, 105 insertions(+)
create mode 100644 rtems/config/4.11/graphics/libpng.bset
create mode 100644 rtems/config/graphics/libpng-1.5.22-1.cfg
create mode 100644 source-builder/config/libpng-1.cfg

diff --git a/rtems/config/4.11/graphics/libpng.bset 
b/rtems/config/4.11/graphics/libpng.bset
new file mode 100644
index 000..4df0e03
--- /dev/null
+++ b/rtems/config/4.11/graphics/libpng.bset
@@ -0,0 +1,20 @@
+#
+# Build set for libpng
+#
+
+%define release 1
+
+#
+# RTEMS Version
+#
+%define rtems_version 4.11
+
+#
+# The RTEMS URL paths.
+#
+%include rtems-urls.bset
+
+#
+# Build libpng.
+#
+graphics/libpng-1.5.22-1.cfg
diff --git a/rtems/config/graphics/libpng-1.5.22-1.cfg 
b/rtems/config/graphics/libpng-1.5.22-1.cfg
new file mode 100644
index 000..48313b7
--- /dev/null
+++ b/rtems/config/graphics/libpng-1.5.22-1.cfg
@@ -0,0 +1,22 @@
+#
+# libpng 1.5.22
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# libpng Version
+#
+%define libpng_version 1.5.22
+%define libpng_src_dir_revision 15
+
+%hash md5 libpng-%{libpng_version}.tar.gz 8d10c6267c8da60454ef703c4cb11876
+
+#
+# libpng Build configuration
+#
+%include %{_configdir}/libpng-1.cfg
diff --git a/source-builder/config/libpng-1.cfg 
b/source-builder/config/libpng-1.cfg
new file mode 100644
index 000..ba03605
--- /dev/null
+++ b/source-builder/config/libpng-1.cfg
@@ -0,0 +1,63 @@
+#
+# libpng
+#
+# This configuration file configure's, make's and install's libpng.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  libpng-v%{libpng_version}-%{_host}-%{release}
+Summary:   libpng is the official PNG reference library
+Version:   %{libpng_version}
+Release:   %{release}
+URL: http://www.libpng.org/
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# libpng Source
+#
+%source set libpng 
ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng%{libpng_src_dir_revision}/libpng-%{libpng_version}.tar.gz
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_libpng=libpng-%{libpng_version}
+  %source setup libpng -q -n libpng-%{libpng_version}
+  %patch setup libpng -p1
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  %{build_directory}
+
+  mkdir -p ${build_dir}
+  cd ${build_dir}
+
+  %{host_build_flags}
+
+   ../${source_dir_libpng}/configure \
+--host=%{_host} \
+--prefix=%{_prefix} \
+--includedir=%{_includedir} \
+--libdir=%{_libdir} \
+--disable-shared
+
+  %{__make} %{?_smp_mflags} all
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  %{__rmdir} $SB_BUILD_ROOT
+
+  cd ${build_dir}
+  %{__make} DESTDIR=$SB_BUILD_ROOT install
+  cd ${build_top}
--
2.1.0

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

[PATCH 4/6] RSB: add t1lib bset (patch url should be changed after it is merged into rtems git server)

2015-07-19 Thread QIAO YANG


---
rtems/config/4.11/graphics/t1lib.bset   | 20 ++
rtems/config/graphics/t1lib-5.1.2-1.cfg | 21 ++
source-builder/config/t1lib-1.cfg   | 69 +
3 files changed, 110 insertions(+)
create mode 100644 rtems/config/4.11/graphics/t1lib.bset
create mode 100644 rtems/config/graphics/t1lib-5.1.2-1.cfg
create mode 100644 source-builder/config/t1lib-1.cfg

diff --git a/rtems/config/4.11/graphics/t1lib.bset 
b/rtems/config/4.11/graphics/t1lib.bset
new file mode 100644
index 000..63b4f73
--- /dev/null
+++ b/rtems/config/4.11/graphics/t1lib.bset
@@ -0,0 +1,20 @@
+#
+# Build set for adobe type 1 library
+#
+
+%define release 1
+
+#
+# RTEMS Version
+#
+%define rtems_version 4.11
+
+#
+# The RTEMS URL paths.
+#
+%include rtems-urls.bset
+
+#
+# Build t1lib.
+#
+graphics/t1lib-5.1.2-1.cfg
diff --git a/rtems/config/graphics/t1lib-5.1.2-1.cfg 
b/rtems/config/graphics/t1lib-5.1.2-1.cfg
new file mode 100644
index 000..da18ba1
--- /dev/null
+++ b/rtems/config/graphics/t1lib-5.1.2-1.cfg
@@ -0,0 +1,21 @@
+#
+# t1lib 5.1.2
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# t1lib Version
+#
+%define t1lib_version 5.1.2
+
+%hash md5 t1lib-%{t1lib_version}.tar.gz a5629b56b93134377718009df1435f3c
+
+#
+# t1lib Build configuration
+#
+%include %{_configdir}/t1lib-1.cfg
diff --git a/source-builder/config/t1lib-1.cfg 
b/source-builder/config/t1lib-1.cfg
new file mode 100644
index 000..83be6cb
--- /dev/null
+++ b/source-builder/config/t1lib-1.cfg
@@ -0,0 +1,69 @@
+#
+# t1lib
+#
+# This configuration file configure's, make's and install's t1lib.
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+Name:  t1lib-v%{t1lib_version}-%{_host}-%{release}
+Summary:   t1lib is the official PNG reference library
+Version:   %{t1lib_version}
+Release:   %{release}
+URL: http://www.t1lib.org/
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# t1lib Source
+#
+%source set t1lib 
ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/t1lib-%{t1lib_version}.tar.gz
+%patch add t1lib 
https://raw.githubusercontent.com/yangqiao/rtems-tools/graphics/tools/4.11/t1lib/t1lib-5.1.2.diff
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_t1lib=t1lib-%{t1lib_version}
+  %source setup t1lib -q -n t1lib-%{t1lib_version}
+  %patch setup t1lib -p1
+
+  cd ${build_top}
+
+#
+# Build the source code.
+# The configure should be run in the source dir
+#
+%build
+  build_top=$(pwd)
+
+  %{build_directory}
+
+  cd ${source_dir_t1lib}
+
+  %{host_build_flags}
+
+   ./configure \
+--host=%{_host} \
+--prefix=%{_prefix} \
+--includedir=%{_includedir} \
+--datadir=${_prefix}/share \
+--libdir=%{_libdir} \
+--disable-shared \
+--without-athena --without-x
+
+  %{__make} %{?_smp_mflags} without_doc
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  %{__rmdir} $SB_BUILD_ROOT
+
+  cd ${source_dir_t1lib}
+  %{__make} DESTDIR=$SB_BUILD_ROOT install
+  cd ${build_top}
--
2.1.0

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

arm atag retrieval problem

2015-07-11 Thread QIAO YANG


Hi,

I tried to retrieve atag command lines but I've got wired problems:
I ran a quick scan for atags, start from 0x100, and I've got an output like :

[ATAG_CORE] flags: 0, pagesize: 0, rootdev: 0
[ATAG_MEM] size: 800, start: 0
[ATAG_CMDLINE] found:
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 
bcm2708.boardrev=0xf bcm2708.serial=0x8247b4bb smsc95xx.macaddr=B8s
start addr:12C
size : 2E616D64
didn't find [ATAG_NONE]

which told me that:
1. The start address of atag cmdline is 0x12C
2. The size of this tag is 0x2E616D64
The size of the tag is abnormal.
From the output, it seems that I only retrieved part of the cmdline.


I've also tried to use the mailbox interface to get the cmdline. what I've got 
is exactly the same part of string without error reponse. Even if I tried to 
print the following characters, they are all empty.
I think that the atags area maybe rewritten in some way but I didn't managed to 
figure out. What bothers me most is the length of the tag, because the tag id 
is correct, part of the value is readable, there's no reason that the data 
between them is incorrect. The atag area should be written by videocore, who 
load the cmdline.txt where we can add additional lines.


Besides I've also got a question that how can I get the value of r2 that passed 
by bootloader to kernel image? It should store the value of start address of 
ATAG or the magic of device tree. What I've found in linux is that there is a 
function like init( *param), which is called when loading the kernel, and the 
function get the value of r2 as the parameter passed to it.  I wonder how can I 
get this value, though by default the atag starts from 0x100.


If it takes too long to implement the feature (atag, device tree ), I've 
got other ways to detect if a hdmi device is present and then disable/enable 
the graphic console. If I'm allowed to pass the atag/device tree implementation.


Best wishes.


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

Re: RPI graphic text console test invitation

2015-07-11 Thread QIAO YANG

I've finally found out that if we don't use u-boot to load the image, and just
use the bare metal to load the kernel binary, it works well. Anyway I can't
tell the reason .

On Jul 07, 2015, at 07:55 PM, QIAO YANG yangqiao0...@me.com wrote:

Hi all mentors and rpi bap student developers ,

First of all, I’ve written a blog to explicite how I to use the mailbox interfaces, and I would like to invite other students to try it out. If anyone need the mailbox related functions that I didn’t implement, you can ask me for them.

https://yangqiao.wordpress.com/2015/07/05/rtems-board-support-packages-raspberry-pi-mailbox-and-framebuffer-implementation/

As Pavel Pisa reported to me that he didn’t managed to get the video console to
display, I would like to invite you to try it out and report the status to me.
The setup of memory table might need to update, I’ve explained in the last
paragraph of the blog. It’s just a quick test and the feedback will help me a
lot. Thanks everyone in advance :).

Here is a blog about how to setup the graphic console, where is the code source
and which version to test:

https://yangqiao.wordpress.com/2015/07/05/rtems-bsp-raspberry-pi-graphic-text-console-with-frame-buffer/

I've got the graphic output work with my rpi B and samsung 27 display. But
I've found something wired that in serial console mode, my serial console stoped
early:

The word Corporation isn't event displayed completely.

While in graphic console mode, the output stopped at :

It bothers me and I'm trying to figure out the bug. But for the moment I've got
no idea and how to debug it.
But anyway the display should work and display something.

Since I can’t test it with different display by my self. I would be glad if you
can join me to test the driver and send me feedback, so that I can improve it .

Thank you in advance!
___
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

RPI graphic text console test invitation

2015-07-08 Thread QIAO YANG

Hi all mentors and rpi bap student developers ,

First of all, I’ve written a blog to explicite how I to use the mailbox
interfaces, and I would like to invite other students to try it out. If anyone
need the mailbox related functions that I didn’t implement, you can ask me for
them.

https://yangqiao.wordpress.com/2015/07/05/rtems-board-support-packages-raspberry-pi-mailbox-and-framebuffer-implementation/

Here is a blog about how to setup the graphic console, where is the code source
and which version to test:

https://yangqiao.wordpress.com/2015/07/05/rtems-bsp-raspberry-pi-graphic-text-console-with-frame-buffer/

I've got the graphic output work with my rpi B and samsung 27 display. But
I've found something wired that in serial console mode, my serial console
stoped early:

The word Corporation isn't event displayed completely.

While in graphic console mode, the output stopped at :

It bothers me and I'm trying to figure out the bug. But for the moment I've got
no idea and how to debug it.
But anyway the display should work and display something.

Since I can’t test it with different display by my self. I would be glad if you
can join me to test the driver and send me feedback, so that I can improve it .

Thank you in advance!

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

[RPI BSP] graphic text console test invitation

2015-07-06 Thread QIAO YANG

Hi all mentors and rpi bap student developers ,

https://yangqiao.wordpress.com/2015/07/05/rtems-board-support-packages-raspberry-pi-mailbox-and-framebuffer-implementation/

Here is a blog about how to setup the graphic console, where is the code source
and which version to test:

https://yangqiao.wordpress.com/2015/07/05/rtems-bsp-raspberry-pi-graphic-text-console-with-frame-buffer/

I've got the graphic output work with my rpi B and samsung 27 display. But
I've found something wired that in serial console mode, my serial console stoped
early:

The word Corporation isn't event displayed completely.

While in graphic console mode, the output stopped at :

It bothers me and I'm trying to figure out the bug. But for the moment I've got
no idea and how to debug it.
But anyway the display should work and display something.

Since I can’t test it with different display by my self. I would be glad if you
can join me to test the driver and send me feedback, so that I can improve it .

Thank you in advance!___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB Graphics Library] add patch for library source

2015-06-30 Thread QIAO YANG


Hi,

I'm now working on moving the graphic libraries from rtems-graphic-tool-kits 
into rsb, based on the existing work for libjpeg and the 
rtems-graphic-tool-kits's buid script.

The port of libpng, libtiff, freetype2 can be review on my github:
https://github.com/yangqiao/rtems-source-builder/commits/graphics

While I've got some problems when trying to add patch for source code.
As what I've read from other cfg files, we should first patch add the needed patches, 
then patch setup to apply them. When I try to add the patch under 
source-builder/patches/,  it warned me that the path doesn't have a proper protocl such as https, 
git  And I've found that some patches of gdb ..etc are in rtems-tools and the sb-build retrieve 
them from the git server. How can I add a patch from source-builder/patches/ instead of uploading 
to rtems-tools ? Or maybe I missed something?

Thanks in advance

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

[RPI BSP] zero length array in kernel and refactor of video char output

2015-06-24 Thread QIAO YANG



On Jun 23, 2015, at 07:15 AM, Gedare Bloom ged...@rtems.org wrote:

On Tue, Jun 23, 2015 at 7:43 AM, QIAO YANG yangqiao0...@me.com wrote:
Hi,

As suggested by gedare, I think using zero length array to represent the
mailbox buffer and tag data is a good way, much readable, clearer to
abstract the structure of mailbox buffer, tag.
I've done an attemp, here is the scratch:
https://github.com/yangqiao/rtems/commit/3ed7e9bde493bdc8e644fcefa285d99255201ada

The construction of a buffer is then decomposed by the following procedure:
1. Calculate the total length of buffer
2. Allocate and inite the buffer
3. Pack the request data into buffer
4. send the buffer by mailbox, then read the responce
5. Unpack the responce data into variables

I've tested it in userspace it works well but in kernel space I cannot
allocate the memory by malloc. Is there any alternative way to let us use
zero length array in the kernel driver?

It depends. BSP code can use malloc, but care should be taken about
where you use it. An alternative would be to use a free list.
 
I've retried to allocate zero-length-array statically and I've found some 
problems:
1. As described in GCC manual, the size of struct that contains an zero length 
array at the end, is determined by the size of the initializer's given array. 
But what I've found is that the the initializer don't initialize the zero 
length array. it has to be set afterward. I doubt that the problem comes from 
the cross compiler. Even if I don't give initializer for the array, I can get 
access to the elements. It's dangerous and it doesn't work as described in 
manual.

2. I'm afraid that a struct A that contains a zero length array of struct B, 
where struct B has a zero-length array, is not acceptable. As the second struct 
B2 doesn't know the length of B1, so the position of B2 would be shifted and 
override part of the structure B1.

So I propose to:
1. Don't queue the tags, we handle them one by one. one buffer , one tag.
2. Use the zero length array to define the structure of tag.
3. single function for each tag operation.
4. lock to ensure that only one function is in process to avoid mailbox 
conflict.

https://github.com/yangqiao/rtems/commit/971d3ccdab04171494a3b73684f4f6f243e230b9
I've only implement the function to get display size here. If it's ok I'll add 
some others.




Secondly, since part of functions in outch is considered sharable between
bsps. If my implementation is acceptable, I'll push the refactor code for
review. Here is my implementation
https://github.com/yangqiao/rtems/commit/858a9b091025acc4bfe912f41d70c9a73b99d773

You still need to attribute the original source of that file.

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

[RPI BSP] cleaned up and reqest for review

2015-06-14 Thread QIAO YANG



Hello sirs,

I've cleaned up my works for fb implementation and the graphic console. Now 
it's available on my github:

mailbox: 
https://github.com/yangqiao/rtems/commit/4b4239135d23d82c2a284c8c848d8f97cd3c5e41
videocore: 
https://github.com/yangqiao/rtems/commit/38c26a49126e5cff92ae389dba252cb180362c90
fb : 
https://github.com/yangqiao/rtems/commit/979a15412f84f8b0095a613d66cddbc3ca777efc
outch: 
https://github.com/yangqiao/rtems/commit/858a9b091025acc4bfe912f41d70c9a73b99d773
fbcons: 
https://github.com/yangqiao/rtems/commit/1d82ef8ff28e0ef6a062313ca4874fe720a32e6e

A screen shot for the graphic text console is in attachment.

Still some problem I've got difficulties to solve : 

1. Will rpi bsp has any kernel command line setup like i386? This would let us 
to choose fb console port or serial console port . Or maybe we just use 
compiler macro to enable/disable graphic console output?

2. I've found that printk don't output to serial port instead of fbcons even if 
I've set up the BSPPrintkPort to the fb console. Is it acceptable or what I 
missed in the console implementation? I've read through the i386 bsp but I 
can't find out the reason.

3. I still have no idea on  how can I find out all possible fb buffer's 
location as we need to enable the segment of memory in mmu configuration. I can 
find few document on how the cpu allocate the buffer. I'm trying to ask other 
communities, forums.

Something waiting to be done:
 
1. graphic console need the keyboard implementation . I would like to know the 
status of keyboard implementation.

2. generate a bitmap font file instead of the one I used under GPL. 

3. restructure the reusable code after the it's reviewed.

I will post a blog later for my works. 
I'll leave the commits for you to review.

On Jun 07, 2015, at 10:53 PM, QIAO YANG yangqiao0...@me.com wrote:

Hi,

I've got a few questions over the fbcons implementation details and edid 
lecture:

1.  I should place the video init function where exactly? In the end of 
bspstarthooks.c  hook_1() or in the bspstart.c ?

2.  I need to ensure the structure buffer is 16-byte aligned .  I use 
__attribute__((aligned (16))) to specific the alignement. Is there any rtems 
macro for this or it's ok that I use the compiler attribute for all structure 
definition?

3. Is it necessary to encapsule the communication with videocore interfaces 
with individual functions? Or just let the developper construct the buffer to 
send in a certain structure with the macros defined? 

4. I've read many others' implementations of framebuffer. I've found that they 
all just query the display size by the videocore interface and use that for the 
resolution setup. So I wonder if it's obliged to get the EDID blocks, parse it 
then decide the resolution.  I proposed that we try to get the resolution from 
cmdline setup, use it if it's supported. If the setup is not supported, we'll 
query the display size. Normally the query can't fail as all others will throw 
an error when the query failed and stop the fbinit in their code (except for 
qemu emulator,  width=0,height= 0 will be returned) . If the query does fail, 
we will then try the default resolution: 640*480. 


For now, I think I've just need some more time to cleanup, write test samples 
and then send patches. If everything's ok next week I'll move to test and adapt 
the graphic libraries.


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

[RPI BSP] fbcons implementation and EDID lecture

2015-06-08 Thread QIAO YANG


Hi,

I've got a few questions over the fbcons implementation details and edid 
lecture:

1.  I should place the video init function where exactly? In the end of 
bspstarthooks.c  hook_1() or in the bspstart.c ?

2.  I need to ensure the structure buffer is 16-byte aligned .  I use 
__attribute__((aligned (16))) to specific the alignement. Is there any rtems 
macro for this or it's ok that I use the compiler attribute for all structure 
definition?

3. Is it necessary to encapsule the communication with videocore interfaces 
with individual functions? Or just let the developper construct the buffer to 
send in a certain structure with the macros defined? 

4. I've read many others' implementations of framebuffer. I've found that they 
all just query the display size by the videocore interface and use that for the 
resolution setup. So I wonder if it's obliged to get the EDID blocks, parse it 
then decide the resolution.  I proposed that we try to get the resolution from 
cmdline setup, use it if it's supported. If the setup is not supported, we'll 
query the display size. Normally the query can't fail as all others will throw 
an error when the query failed and stop the fbinit in their code (except for 
qemu emulator,  width=0,height= 0 will be returned) . If the query does fail, 
we will then try the default resolution: 640*480. 


For now, I think I've just need some more time to cleanup, write test samples 
and then send patches. If everything's ok next week I'll move to test and adapt 
the graphic libraries.


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

[RPI BSP] fbcon implementation

2015-06-02 Thread QIAO YANG


Hello,

I've got a couple of questions about the fbcon implementation in detail, in 
order to cleanup my code and create a mergable patch for review.

For the graphic text output, I've implemented two functions _RPI_initvideo and 
_RPI_outch, used to print chars to graphic. They are declared in bsp.h and 
implemented in outch.c as we've done in i386 bsp.

1. The _RPI_initvideo function need to initialize framebuffer driver and get 
the informations. I think it would not be logical nor safe if I don't declare 
the fb_init function as static and call it from outside.  If I just wait for 
the initialization of fb driver, and expose getters for the fb infos, it works 
but we will miss all output before the fb initialized. Another proposition, we 
would always let the driver itself to decide the resolution and it won't change 
after the first init. Then the fb_init function can be exposed to others (just 
return if it's called a second time) and it can be called at the bsp startup or 
somewhere else.

I haven't yet come up with a better idea. It would be great if anyone has any 
better solutions.

2. The mmu configuration for framebuffer. I'm still confused about how to deal 
with it.

   Is there anyway to setup the memory in the code ? For exemple: after 
detected the size and start point of framebuffer, setup a given block (range) 
to  ARMV7_MMU_DATA_READ_WRITE in the code?

  I prefer to setup the mmu table after the fb initialized. If it's not possible, like we've discussed earlier, we should enable all possible area at startup. Since the start point varies for different devices, how can I find out the pages to be activate? 


3. Not like in i386, I've got to take a ascii font file for drawing characters. 
I've taken the hard cored 8*16 font from UBOOT code. I think maybe we can move 
the font file in a common directory for all bsps. It's not so important, just a 
suggestion. Also the EDID header may be moved for all bsps as well.


On May 04, 2015, at 12:08 PM, QIAO YANG yangqiao0...@me.com wrote:


Hello everyone,

Since I haven't yet received any respond of my last mail and I've now got the 
names of mentors who would instruct me, I create a new thread for a simple 
resume and post my questions .

First of all, I've managed to use mailbox channel to get a framebuffer pointer 
and its informations. I can draw some simple images with the pointer and also 
the pointer can be retrieved correctly by ioctrl from applications, with the fb 
device interface. Painting works as well.
I've already sent a patch with mailbox implementation, but I haven't yet 
confirmed if it's ready to be merged or any modification should be done.



To complete fb implementation:
1.  Some more functions need to be added : connected monitor EDID read and 
decoding for correct/optimal resolution selection. I don't know if we need a 
full VESA driver like what we've done on i386.

2.   If we've enabled l2 cache, the memory mapping would be 0x4000, while 
the mapping would be 0xC000 instead if l2 cache disabled. Normally it can 
be configured in the config.txt file.

The file 'config.txt' is read by GPU before the ARM core is initialized. It's 
used as an BIOS configuration. It can be used to setup hdmi output mode, l2 
cache, memory split etc. Such as memory split affect much the range of 
framebuffer address which should be covered in the mmu configuration table. 
What would be a better way to deal with it?  Should I enable the memory pages 
that cover all possible range(This can vary depend on gpu_mem_split) ?


To plan for fbcon implementation:
1.  Find instructions for cursor. I've found that it's possible to get some 
infos from mailbox property channel.

2. Implementations refering to i386/pc386/console/outch.c

3. Implementations refering to i386/pc386/console/vgacons


For GTK porting

I tried to compile gtk for it. The libpng ...  etc can be installed and I'm 
trying to make some samples for testing. Only the nxlib failed to build because 
we haven't yet the keyboard support (mouse support can be switched off, but I 
can't find out yet how to build the lib without keyboard).

That's all for a resume, plan, and questions report for my work.

Best regards,

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

Re: Mailbox methods for RPi

2015-06-01 Thread QIAO YANG


It's using the mailbox property channel to communicate with the videocore. I've 
noted down all available properties and the addresses used in a header file but 
not yet implemented all of them. I'm working on it this week. If you need this, 
you may put some marks here and I'll send a patch for the methodes as soon as 
possible. Latest this weekend I'll complete what we need for the moment as 
there are plenty of them. I don't think they are all useful, but should be 
completed. 

On Jun 01, 2015, at 08:33 AM, Yurii Shevtsov unge...@gmail.com wrote:


I have this lines in FreeBSD driver:
| bcm2835_mbox_set_power_state(dev, BCM2835_MBOX_POWER_ID_USB_HCD, TRUE);
How should I replace it?

Thanks in advance)
___
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

[RPI BSP] resume, plan and questions for fb, fbcon gtk

2015-05-04 Thread QIAO YANG


Hello everyone,

Since I haven't yet received any respond of my last mail and I've now got the 
names of mentors who would instruct me, I create a new thread for a simple 
resume and post my questions .

First of all, I've managed to use mailbox channel to get a framebuffer pointer 
and its informations. I can draw some simple images with the pointer and also 
the pointer can be retrieved correctly by ioctrl from applications, with the fb 
device interface. Painting works as well.
I've already sent a patch with mailbox implementation, but I haven't yet 
confirmed if it's ready to be merged or any modification should be done.



To complete fb implementation:
1.  Some more functions need to be added : connected monitor EDID read and 
decoding for correct/optimal resolution selection. I don't know if we need a 
full VESA driver like what we've done on i386.

2.   If we've enabled l2 cache, the memory mapping would be 0x4000, while 
the mapping would be 0xC000 instead if l2 cache disabled. Normally it can 
be configured in the config.txt file.

The file 'config.txt' is read by GPU before the ARM core is initialized. It's 
used as an BIOS configuration. It can be used to setup hdmi output mode, l2 
cache, memory split etc. Such as memory split affect much the range of 
framebuffer address which should be covered in the mmu configuration table. 
What would be a better way to deal with it?  Should I enable the memory pages 
that cover all possible range(This can vary depend on gpu_mem_split) ?


To plan for fbcon implementation:
1.  Find instructions for cursor. I've found that it's possible to get some 
infos from mailbox property channel.

2. Implementations refering to i386/pc386/console/outch.c

3. Implementations refering to i386/pc386/console/vgacons


For GTK porting

I tried to compile gtk for it. The libpng ...  etc can be installed and I'm 
trying to make some samples for testing. Only the nxlib failed to build because 
we haven't yet the keyboard support (mouse support can be switched off, but I 
can't find out yet how to build the lib without keyboard).

That's all for a resume, plan, and questions report for my work.

Best regards,

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

Re: [PATCH] [RPI BSP] mailbox

2015-04-24 Thread QIAO YANG


On Apr 23, 2015, at 10:20 AM, Alan Cudmore alan.cudm...@gmail.com wrote:


Hi Qiao,
Functionally, this code looks good to me. It builds without warnings for the Pi and Pi2, and I was able to make the calls to init the frame buffer on the Pi B+. 


When you did the frame buffer test, what was your MMU table entry for the 
mailbox/framebuffer?


In fact, I've got questions with the MMU table set up. It seems that the memory 
is enabled by page because I've found that I can also access to the address out 
of the range that I've set up.

Here is what I've added.

{
   .begin = 0xC11F4C8,
   .end =   0xC11F4C8 + 0x1000,
   .flags = ARMV7_MMU_DATA_READ_WRITE
 }

The fb buffer in my case appears to around 0xC11F4C8,  and the size is not the 
actual size. But it works. I know it's not proper, I just use this for tests.

If we've enabled l2 cache, the memory mapping would be 0x4000, while the 
mapping would be 0xC000 instead if l2 cache disabled. Normally it can be 
configured in the config.txt file. What do you think is a better way to find it 
out whether l2 cache is enabled in order to use the proper mapping?

I've read through the video core processor's available properties settings.
Here's what we can use for framebuffer:

allocate/release buffer
set blank screen
get/set/test display size
get/set/test buffer size
get/set/test depth
get/set/test pixel order
get/set/test alpha mode
get pitch
get/set/test virtual offset
get/set/test overscan
get/set/test palette
set cursor info
set cursor state

As I've already got a fb_init which works and we can get the pointer with 
ioctrl correctly and draw something,  what else should be implemented for fb?  
The other bsps' palettes are hard coded, I wonder if I should also setup the 
palette and allow users to adjust it by ioctrl. What about other properties? 
I'm not sure where to go from here.

I tried to compile gtk for it. The libpng etc can be installed and I'm working 
on some samples to test them. Only the nxlib failed because we haven't yet the 
keyboard support (mouse support can be switch off, but I can't find out how to 
build the lib without keyboard).


Thanks,
Alan



On Apr 19, 2015, at 3:17 PM, QIAO YANG yangqiao0...@me.com wrote:

Here is a modified patch for mailbox.  If there's still anything against the 
convention, please point it out and I'll correct it immediately. The mailbox 
implementation might also be needed by other rpi bsp developpers.

--

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index c6133df..70bc01d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/mmu.h
 include_bsp_HEADERS += include/usart.h
+include_bsp_HEADERS += include/mailbox.h
 include_bsp_HEADERS += include/raspberrypi.h
 
 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \

@@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c
 
 # I2C
 
+# Mailbox

+libbsp_a_SOURCES += misc/mailbox.c
+
 # Cache
 libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
 libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
new file mode 100644
index 000..fa6a0c2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
@@ -0,0 +1,33 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  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 LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+#define LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+extern unsigned int  raspberrypi_mailbox_read(unsigned int channel);
+extern void raspberrypi_mailbox_write(unsigned int channel, unsigned int data);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif  /* LIBBSP_ARM_RASPBERRYPI_MAILBOX_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index c33e22a..3240404 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -208,6 +208,55 @@
 
 /** @} */
 
+ /**

+ * @name Mailbox Registers
+ *
+ * @{
+ */
+
+#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
+
+#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
+#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
+#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
+#define BCM2835_MBOX_CONFIG

Re: [PATCH] [RPI BSP] mailbox

2015-04-24 Thread QIAO YANG


On Apr 23, 2015, at 10:27 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote:




On 4/19/2015 2:17 PM, QIAO YANG wrote:

Here is a modified patch for mailbox.  If there's still anything against the 
convention, please point it out and I'll correct it immediately. The mailbox 
implementation might also be needed by other rpi bsp developpers.


My understanding is that the mailbox is used to determine the board
version and memory size. 



What did you use the mailbox for to test it?


The mailbox is the main way to communicate with videocore processor, not only 
to get board informations and cpu state. I use this to get the framebuffer 
pointer and its related properties.



--

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index c6133df..70bc01d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
 include_bsp_HEADERS += include/irq.h
 include_bsp_HEADERS += include/mmu.h
 include_bsp_HEADERS += include/usart.h
+include_bsp_HEADERS += include/mailbox.h
 include_bsp_HEADERS += include/raspberrypi.h
 
 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \

@@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c
 
 # I2C
 
+# Mailbox

+libbsp_a_SOURCES += misc/mailbox.c
+
 # Cache
 libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
 libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
new file mode 100644
index 000..fa6a0c2
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
@@ -0,0 +1,33 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  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 LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+#define LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+
+#ifdef __cplusplus
+extern C {
+#endif /* __cplusplus */
+
+extern unsigned int  raspberrypi_mailbox_read(unsigned int channel);
+extern void raspberrypi_mailbox_write(unsigned int channel, unsigned int data);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif  /* LIBBSP_ARM_RASPBERRYPI_MAILBOX_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index c33e22a..3240404 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -208,6 +208,55 @@
 
 /** @} */
 
+ /**

+ * @name Mailbox Registers
+ *
+ * @{
+ */
+
+#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
+
+#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
+#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
+#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
+#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
+
+#define BCM2835_MBOX_SUCCESS (BCM2835_MBOX_BASE+0x8000)
+#define BCM2835_MBOX_FULL (BCM2835_MBOX_BASE+0x8000)
+#define BCM2835_MBOX_EMPTY (BCM2835_MBOX_BASE+0x4000)
+
+/**
+* @name Mailbox Channels
+*
+* @{
+*/
+
+/* Power Manager channel */
+#define BCM2835_MBOX_CHANNEL_PM 0
+/* Framebuffer channel */
+#define BCM2835_MBOX_CHANNEL_FB 1
+ /* Virtual UART channel */
+#define BCM2835_MBOX_CHANNEL_VUART  2
+ /* VCHIQ channel */
+#define BCM2835_MBOX_CHANNEL_VCHIQ  3
+ /* LEDs channel */
+#define BCM2835_MBOX_CHANNEL_LED4
+ /* Button channel */
+#define BCM2835_MBOX_CHANNEL_BUTTON 5
+ /* Touch screen channel */
+#define BCM2835_MBOX_CHANNEL_TOUCHS 6
+/* Property tags (ARM - VC) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_AVC   8
+ /* Property tags (VC - ARM) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_VCA   9
+
+/** @} */
+
+
+/** @} */
+
 
 /** @} */
 
diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c

new file mode 100644
index 000..2a63a41
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
@@ -0,0 +1,44 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  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
+ *
+ */
+
+#include stdint.h
+#include bsp/raspberrypi.h
+#include bsp/mailbox.h
+
+unsigned int raspberrypi_mailbox_read (unsigned int channel)
+{
+  unsigned int data;
+  unsigned int read_channel;
+
+  while ( 1 )
+  {
+while (BCM2835_REG (BCM2835_MBOX_STATUS )  BCM2835_MBOX_EMPTY);
+data

Re: [PATCH] [RPI BSP] mailbox

2015-04-19 Thread QIAO YANG

CLUDE)/bsp/$(dirstam $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/usart.hPREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/usart.h+$(PROJECT_INCLUDE)/bsp/mailbox.h: include/mailbox.h $(PROJECT_INCLUDE)/bsp/$(dirstamp)+ $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/mailbox.h+PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/mailbox.h+$(PROJECT_INCLUDE)/bsp/raspberrypi.h: include/raspberrypi.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/raspberrypi.hPREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/raspberrypi.hOn Apr 16, 2015, at 11:20 PM, Gedare Bloom ged...@rtems.org wrote:Are you working to make the corrections I mentioned?On Tue, Apr 7, 2015 at 10:05 AM, Gedare Bloom ged...@rtems.org wrote:On Mon, Apr 6, 2015 at 5:12 PM, QIAO YANG yangqiao0...@me.com wrote:-diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.amb/c/src/lib/libbsp/arm/raspberrypi/Makefile.amindex c6133df..70bc01d 100644--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am@@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.hinclude_bsp_HEADERS += include/irq.hinclude_bsp_HEADERS += include/mmu.hinclude_bsp_HEADERS += include/usart.h+include_bsp_HEADERS += include/mailbox.hinclude_bsp_HEADERS += include/raspberrypi.hinclude_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \@@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c# I2C+# Mailbox+libbsp_a_SOURCES += misc/mailbox.c+# Cachelibbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.clibbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.hdiff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.hb/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.hnew file mode 100644index 000..abdb258--- /dev/null+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h@@ -0,0 +1,7 @@Need file header documentation. Please seehttps://devel.rtems.org/wiki/Developer/Coding/Conventions+#ifndef MAILBOX_H+#define MAILBOX_H++extern unsigned int readmailbox(unsigned int channel);+extern void writemailbox(unsigned int channel, unsigned int data);+Please use function names with a "namespace". the usual convention inRTEMS is to use Package_Class_Method like raspberrypi_mailbox_read()and raspberrypi_mailbox_write().+#endif /* MAILBOX_H */\ No newline at end of filediff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.hb/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.hindex c33e22a..e4ce18f 100644--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h@@ -208,6 +208,52 @@/** @} */+ /**+ * @name Mailbox Registers+ *+ * @{+ */++/**+ * NOTE:+ */+#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)++#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)+#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)+#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)+#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)++/* Power Manager channel */+#define BCM2835_MBOX_CHANNEL_PM 0+/* Framebuffer channel */+#define BCM2835_MBOX_CHANNEL_FB 1+ /* Virtual UART channel */+#define BCM2835_MBOX_CHANNEL_VUART 2+ /* VCHIQ channel */+#define BCM2835_MBOX_CHANNEL_VCHIQ 3+ /* LEDs channel */+#define BCM2835_MBOX_CHANNEL_LED 4+ /* Button channel */+#define BCM2835_MBOX_CHANNEL_BUTTON 5+ /* Touch screen channel */+#define BCM2835_MBOX_CHANNEL_TOUCHS 6+/* Property tags (ARM - Video Core) channel */+#define BCM2835_MBOX_CHANNEL_PROP_AVC 8+ /* Property tags (Video Core - ARM) channel */+#define BCM2835_MBOX_CHANNEL_PROP_VCA 9++#define BCM2835_MBOX_SUCCESS (BCM2835_MBOX_BASE+0x8000)++#define BCM2835_MBOX_FULL (BCM2835_MBOX_BASE+0x8000)+#define BCM2835_MBOX_EMPTY (BCM2835_MBOX_BASE+0x4000)/** @} */+/** @} */diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.cb/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.cnew file mode 100644index 000..7bfb7e3--- /dev/null+++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c@@ -0,0 +1,22 @@Need file header documentation+#include stdint.h+#include bsp/raspberrypi.h+#include bsp/mailbox.h+unsigned int readmailbox ( unsigned int channel )+{+ unsigned int data;+ unsigned int read_channel;++ while ( 1 )+ {+ while ( BCM2835_REG ( BCM2835_MBOX_STATUS ) BCM2835_MBOX_EMPTY );+ data = "" ( BCM2835_MBOX_READ );+ read_channel = ( unsigned int ) ( data  0xF );+ if ( read_channel == channel )+ return ( data  0xFFF0 );+ }The white spaces look wrong here. Are they tabs? Or 8 blank spaces?Please check the style rules in the Coding Conventions page.+}+void writemailbox( unsigned int channel, unsigned int data )+{+ while ( BCM2835_REG ( BCM2835_MBOX_STATUS )  BCM2835_MBOX_FULL );+ BCM2835_REG (BCM2835_MBOX_WRITE) = ( data  0xFFF0 ) | (unsignedint) ( channel  0xF );+}\ No newline at end of filediff --git a/c/src/lib/libbsp/arm/raspberrypi/preinstall.amb/c/src/lib/libbsp/arm/raspberrypi/preinstal

[RPI BSP] Framebuffer interface. No such device

2015-04-12 Thread QIAO YANG


Hello everyone,

I've implemented a simple framebuffer driver. It can be loaded correctly and it can draw 
images . But when I try to open the framebuffer interface '/dev/fb0', I've always got 
No such device. I thought I've missed something. Anyone has an idea?

I've already registered the device name by:
      status = rtems_io_register_name (FRAMEBUFFER_DEVICE_0_NAME, major, 0);

And the interface /dev/fb0 exists.
I'm using Alan's rki to build the kernel image and test apps.

Thanks in advance___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RPI BSP] Framebuffer test

2015-04-07 Thread QIAO YANG

Hi Pavel Pisa,

On Apr 07, 2015, at 06:50 AM, Pavel Pisa ppisa4li...@pikron.com wrote:

Hello Yang Qiao,

On Tuesday 07 of April 2015 00:00:33 QIAO YANG wrote:

I've implemented a simple framebuffer, but I've got no idea how to test it.

I've got Alan's rki and I made a sample to test the mailbox, the
framebuffer information seems to be successfully set and get (width,
height, pitch, buffer pointer, buffersize etc). In linux we open the
interface and map the pointer to set the pixels. If I try to access the
pointer and set the memory directly in the driver to draw something, the
program will stay still when I try to assign value to a certain address of
memory, or maybe it's only allowed to use memset/ memcpy to set the memory?

I've also tried to load the driver and open it ( /dev/fb0 ) with open,
but it failed, while I can see the interface with ls /dev .

In order to test the framebuffer, how can I use the fb interface to print
something, or maybe access the memory directly? Is there any existing
sample for fb testing? If not, is it necessary to create a common sample
for all to print something?

I have not studied how it works on RPi. As I know from
other reading, some part of physical memory is reserved for
GPU/framebuffer by one of boot stages and configuration
can be changed by gpu_mem in config.txt

http://elinux.org/RPiconfig

It is great if you can setup display output mode.
How is setup framebuffer start address? In the fact
if you use same mode setup as is used in Linux then
you should have same framebuffer starting physical address.
RTEMS uses 1:1 CPU (virtual) to physical mapping.
It is necessary to check that framebuffer physical address
range is covered by 1:1 mapping initialization. This is in the
fact equivalent to mmap() address space/VMA and page table manipulation
on Linux. Check page table initialization at

rtems/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c

I am almost sure that you have to define additional rage
to cover framebuffer address range. You should use uncached
configuration

ARMV7_MMU_DATA_READ_WRITE

at least for start. Some performance can be gained if read caching
and write through + write combine is enabled for framebuffer area,
but I am not sure if there is defined matching CP15 combination
in

I have got it work after setting the MMU. Thanks!

rtems/c/src/lib/libcpu/arm/shared/include/arm-cp15.h

If this matches then you should be able to access framebuffer directly.
I.e. from some BSP/framebuffer driver initialization code or some application
linked to RTEMS system libraries some or you can modify some RTEMS
test example to access given address directly.

Which pixel format are you using - 16 bit RGB565, 24 bit RGB888
or 32 bit RGBA? I would suggest to use 32 bit format RGB + 8 bit
padding when there is enough memory for simplicity. It allows simple
XY to address conversion and accesses to pixel are aligned.

In fact, for the moment, I'm using 16bit RGBA for display. As for the memory,
rpi A has 256MB, rpi B has 512MB, and rpi2 has 1GB. I'm not as experience to
tell which format would be better but I'll consider that. Is there any kernel
configuration that would let user to determine the memory for GPU(it's like the
memory split on wheezy)?

Then you should test something like

memset((char *)startaddress, 0, size_x * size_y * 4);
for (i = 0; i 500; i++) {
((uint32_t *)startaddress)[i] = 0xff;
((uint32_t *)startaddress+1280)[i] = 0xff;
((uint32_t *)startaddress+1280*2)[i] = 0x00ff00;
((uint32_t *)startaddress+1280*3)[i] = 0xff;
}

and you should see white, red, green and blue strips an the to of the display.
If this goes well then you can check that physical address is passed right
by /dev/fb0 appropriate IOCTL to the graphic libraries.

I've got a screen shot for a rainbow square. I'm now moving to check the
interface.
fb_test.png

You can access and modify physical addresses even from terminal by
RTEMS shell medit command

rtems/cpukit/libmisc/shell/main_medit.c

You need to have shell compiled and started in your application or you
can compile and use RTEMS shell example for this testing.
Remember, the mapping is 1:1 and you are in kernel space
so you can access all peripherals and registers accessible to the CPU.

Then I suggest to test Microwindows to paint some more interesting
image on the screen.

I guess you've got my reply on the email, gtk building. It's weird that all libraries are installed successfully, but the compiler still complain about library missing. Do you have any idea what might be the problem? I'll try to compile some samples without the build scripts later.

Best wishes,

Pavel

regards,

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

[PATCH] [RPI BSP] mailbox

2015-04-06 Thread QIAO YANG


-

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index c6133df..70bc01d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -43,6 +43,7 @@ include_bsp_HEADERS += ../shared/include/arm-release-id.h
include_bsp_HEADERS += include/irq.h
include_bsp_HEADERS += include/mmu.h
include_bsp_HEADERS += include/usart.h
+include_bsp_HEADERS += include/mailbox.h
include_bsp_HEADERS += include/raspberrypi.h

include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
@@ -123,6 +124,9 @@ libbsp_a_SOURCES += misc/timer.c

# I2C

+# Mailbox
+libbsp_a_SOURCES += misc/mailbox.c
+
# Cache
libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c
libbsp_a_SOURCES += ../../../libcpu/arm/shared/include/cache_.h
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
new file mode 100644
index 000..abdb258
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
@@ -0,0 +1,7 @@
+#ifndef MAILBOX_H
+#define MAILBOX_H
+
+extern unsigned int readmailbox(unsigned int channel);
+extern void writemailbox(unsigned int channel, unsigned int data);
+
+#endif /* MAILBOX_H */
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index c33e22a..e4ce18f 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -208,6 +208,52 @@

/** @} */

+ /**
+ * @name Mailbox Registers
+ *
+ * @{
+ */
+
+/**
+ * NOTE:
+ */
+#define BCM2835_MBOX_BASE (RPI_PERIPHERAL_BASE+0xB880)
+
+#define BCM2835_MBOX_PEEK (BCM2835_MBOX_BASE+0x10)
+#define BCM2835_MBOX_READ (BCM2835_MBOX_BASE+0x00)
+#define BCM2835_MBOX_WRITE (BCM2835_MBOX_BASE+0x20)
+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
+#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
+
+/* Power Manager channel */
+#define BCM2835_MBOX_CHANNEL_PM0
+/* Framebuffer channel */
+#define BCM2835_MBOX_CHANNEL_FB1
+ /* Virtual UART channel */
+#define BCM2835_MBOX_CHANNEL_VUART 2
+ /* VCHIQ channel */
+#define BCM2835_MBOX_CHANNEL_VCHIQ 3
+ /* LEDs channel */
+#define BCM2835_MBOX_CHANNEL_LED   4
+ /* Button channel */
+#define BCM2835_MBOX_CHANNEL_BUTTON5
+ /* Touch screen channel */
+#define BCM2835_MBOX_CHANNEL_TOUCHS6
+/* Property tags (ARM - Video Core) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_AVC  8
+ /* Property tags (Video Core - ARM) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_VCA  9
+
+#define BCM2835_MBOX_SUCCESS (BCM2835_MBOX_BASE+0x8000)
+
+#define BCM2835_MBOX_FULL (BCM2835_MBOX_BASE+0x8000)
+#define BCM2835_MBOX_EMPTY (BCM2835_MBOX_BASE+0x4000)
+
+
+
+/** @} */
+

/** @} */

diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c 
b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
new file mode 100644
index 000..7bfb7e3
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
@@ -0,0 +1,22 @@
+#include stdint.h
+#include bsp/raspberrypi.h
+#include bsp/mailbox.h
+unsigned int readmailbox ( unsigned int channel )
+{
+   unsigned int data;
+   unsigned int read_channel;
+
+   while ( 1 )
+   {
+   while ( BCM2835_REG ( BCM2835_MBOX_STATUS )  
BCM2835_MBOX_EMPTY );
+   data = BCM2835_REG ( BCM2835_MBOX_READ );
+   read_channel = ( unsigned int ) ( data  0xF );
+   if ( read_channel == channel )
+   return ( data  0xFFF0 );
+   }
+}
+void writemailbox( unsigned int channel, unsigned int data )
+{
+   while ( BCM2835_REG ( BCM2835_MBOX_STATUS )  BCM2835_MBOX_FULL );
+   BCM2835_REG (BCM2835_MBOX_WRITE) = ( data  0xFFF0 ) | (unsigned int) ( 
channel  0xF );
+}
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/raspberrypi/preinstall.am 
b/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
index 70259e2..4cb7ed6 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/preinstall.am
@@ -126,6 +126,10 @@ $(PROJECT_INCLUDE)/bsp/usart.h: include/usart.h 
$(PROJECT_INCLUDE)/bsp/$(dirstam
   $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/usart.h
PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/usart.h

+$(PROJECT_INCLUDE)/bsp/mailbox.h: include/mailbox.h 
$(PROJECT_INCLUDE)/bsp/$(dirstamp)
+   $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/mailbox.h
+PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/mailbox.h
+
$(PROJECT_INCLUDE)/bsp/raspberrypi.h: include/raspberrypi.h 
$(PROJECT_INCLUDE)/bsp/$(dirstamp)
   $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/raspberrypi.h
PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/raspberrypi.h


-

Here is a patch for rpi bsp which include the operation and chanel 
defininitions

[RPI BSP] Framebuffer test

2015-04-06 Thread QIAO YANG


hello,

I've implemented a simple framebuffer, but I've got no idea how to test it.

I've got Alan's rki and I made a sample to test the mailbox, the framebuffer 
information seems to be successfully set and get (width, height, pitch, buffer 
pointer, buffersize etc). In linux we open the interface and map the pointer to 
set the pixels. If I try to access the pointer and set the memory directly in 
the driver to draw something, the program will stay still when I try to assign 
value to a certain address of memory, or maybe it's only allowed to use memset/ 
memcpy to set the memory?

I've also tried to load the driver and open it ( /dev/fb0 ) with open, but it failed, 
while I can see the interface with ls /dev .

In order to test the framebuffer, how can I use the fb interface to print 
something, or maybe access the memory directly? Is there any existing sample 
for fb testing? If not, is it necessary to create a common sample for all to 
print something?

Regards

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

[rtems-graphic-toolkit] version problem with microwin

2015-03-29 Thread QIAO YANG



On Mar 30, 2015, at 06:54 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote:




On 3/29/2015 5:38 PM, QIAO YANG wrote:

Hi,

I've tried to compile the rgt for pc386. But I can't get the right
version of microwin , not from the upstream nor from the alex-sever's
fork.

 Unable to checkout
'6b5dae5cdbc334ac1c3210bc2c4918668cb42aa4' in submodule path 'microwin'

Has anyone succeed to compile it recently ? Or maybe I've missed
anything.

I cloned the master when you were asking about it.

Change the git clone as needed in the script to git (hehehe) to clone.


I didn't noticed the file README.Microwindows  .

While, I've just retried with the latest from git, and the latest release 
version,  but always end up with the same build error:

   ...  /microwin/src/engine/image_png.c:35:27: error: dereferencing 
pointer to incomplete type
 GdImageBufferRead(pstruct-io_ptr, pointer, size);

This error will produce since 01/2010

With the earlier version, I've got error:

 rmdir fail to remove freetype/internal, directory doesn't exist

Which version have you used without error?  I doubt that if it's the microwins 
version problem. Can we see anything from it?



--
Joel Sherrill, Ph.D. Director of Research  Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985



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

[rsb error report] sb: Provide an unverified SSL context to the URL.

2015-03-29 Thread QIAO YANG


Hello,

I've just failed to build the rsb and found an error introduced by the latest 
commit:

commit 3237c8ee69d7398c3d2ccade9879a3dde7785db1
Author: Chris Johns chr...@rtems.org
Date:   Sun Mar 29 15:35:00 2015 +1100

   sb: Provide an unverified SSL context to the URL.
  
   The RTEMS servers are causing an exception when downloading patches. The solution is

   provided in PEP-0476 (https://www.python.org/dev/peps/pep-0476/#opting-out).


---

Here is the log

RTEMS Source Builder - Set Builder, v0.5.0
Build Set: 4.11/rtems-arm
Build Set: 4.11/rtems-autotools.bset
Build Set: 4.11/rtems-autotools-internal.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
Creating source directory: sources
download: ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz - 
sources/autoconf-2.69.tar.gz

download: ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: error
download: ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz: error
Build Set: Time 0:00:01.062428
Build Set: Time 0:00:01.063040
Build Set: Time 0:00:01.066303
Traceback (most recent call last):
 File ../source-builder/sb-set-builder, line 26, in module
   setbuilder.run()
 File ../source-builder/sb/setbuilder.py, line 469, in run
   b.build(deps)
 File ../source-builder/sb/setbuilder.py, line 328, in build
   bs.build(deps, nesting_count)
 File ../source-builder/sb/setbuilder.py, line 328, in build
   bs.build(deps, nesting_count)
 File ../source-builder/sb/setbuilder.py, line 342, in build
   self.build_package(configs[s], b)
 File ../source-builder/sb/setbuilder.py, line 178, in build_package
   _build.make()
 File ../source-builder/sb/build.py, line 422, in make
   self.prep(package)
 File ../source-builder/sb/build.py, line 318, in prep
   self.source_setup(package, args[1:])
 File ../source-builder/sb/build.py, line 221, in source_setup
   for source in self.source(setup_name):
 File ../source-builder/sb/build.py, line 175, in source
   download.get_file(src['url'], src['local'], self.opts, self.config)
 File ../source-builder/sb/download.py, line 554, in get_file
   if downloaders[dl](url, local, config, opts):
 File ../source-builder/sb/download.py, line 333, in _http_downloader
   _in = urllib2.urlopen(url, context = _ssl_context)
TypeError: urlopen() got an unexpected keyword argument 'context'

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

[rtems-graphic-toolkit] version problem with microwin

2015-03-29 Thread QIAO YANG


Hi,

I've tried to compile the rgt for pc386. But I can't get the right version of 
microwin , not from the upstream nor from the alex-sever's fork.

   Unable to checkout '6b5dae5cdbc334ac1c3210bc2c4918668cb42aa4' in 
submodule path 'microwin'

Has anyone succeed to compile it recently ?  Or maybe I've missed anything.___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RPi Support GSoC 2015

2015-03-18 Thread QIAO YANG


I've written a draft for implementing Frambuffer, HDMI console support and port 
graphic library tool kits for rpi.

Since I know little about the status of graphics tool kit at the moment and it 
would take some time for me to understand , I wonder what could be challenging 
for this part or could anyone give me some guidance or references? I'm looking 
into this part, any advice would help me boost.

Secondly, what is the status of current graphic kits and what should be done 
with the RSB? As gedare said:

adding the capability to build the library to the RTEMS Source Builder

I didn't quite understand it. Should we add the additional check/tools for the 
build environment in RSB or something else?


On Mar 18, 2015, at 05:17 AM, Yurii Shevtsov unge...@gmail.com wrote:


Hi)
Right now arm cross-compiler is being compiled. And of course I will
test Hello on actual RPi board. I would like to work with USB part of
task as I mentioned here
https://lists.rtems.org/pipermail/devel/2015-March/010462.html Which
part would yo like to take?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RPi Support GSoC 2015

2015-03-17 Thread QIAO YANG


Hi,

I've seen that you've compiled the kernel for SPARC, and run the sample with 
SPARC simulator. Maybe you should try to build the arm cross-compiler, compile 
the RPI BSP and run it on a arm simulator ( ex: QEMU) or on a RPI board?

Up to now I've seen you, Rohini and I who are willing to contribute for RPI 
BSP. Maybe we can share informations, references or ideas to prepare the 
proposal for the three part of work

Cheers! 


On Mar 17, 2015, at 10:56 PM, Yurii Shevtsov unge...@gmail.com wrote:


Patch:
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index d8fe450..8bf3604 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -28,7 +28,9 @@ rtems_task Init(
)
{
rtems_test_begin();
- printf( Hello World\n );
+ printf( Hello RTEMS\n );
+ printf( This is Yurii's Hello world\n );
+ printf( Have a nice day\n );
rtems_test_end();
exit( 0 );
}

Image: 
http://habrastorage.org/files/ef9/936/a2c/ef9936a2c3134fd89d4f7cf80ec56bc8.png

Working on hello for RPi

2015-03-13 18:19 GMT+02:00 Gedare Bloom ged...@gwu.edu:

On Fri, Mar 13, 2015 at 12:05 PM, Юрий Шевцов unge...@gmail.com wrote:

Am I right that completing Hello is just change and somehow submit lines in
samples/hello/init.c ? And how can I submit the proof, of course?)


Correct. You can send an email here with patch attached and a link to
a screenshot posted somewhere.


___
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___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

problem when runing rpi sample on gdb simu

2015-03-11 Thread QIAO YANG


Hello ,

I was wondering if the raspberry pi samples can run on arm-rtems4.11-gdb. I 
thought I had done the compilations correctly according to Mr Alan's blog, but 
it just stand still when running the sample in the simulator.

I'm not sure if it's my problem or it can only run on a real rpi board.  If 
it's my own problem I'll double check what I've done, if not I've got to wait 
until next week to post my hello demo when the cable arrives.

here's the output of gdb:

Reading symbols from 
./arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/hello.exe...done.
(gdb) tar sim
Connected to the simulator.
(gdb) load
Loading section .start, size 0x340 vma 0x8000
Loading section .text, size 0x17920 vma 0x8340
Loading section .init, size 0x18 vma 0x1fc60
Loading section .fini, size 0x18 vma 0x1fc78
Loading section .rodata, size 0xc30 vma 0x10
Loading section .ARM.exidx, size 0x8 vma 0x100c30
Loading section .eh_frame, size 0x48 vma 0x100c38
Loading section .init_array, size 0x4 vma 0x100c80
Loading section .fini_array, size 0x4 vma 0x100c84
Loading section .jcr, size 0x4 vma 0x100c88
Loading section .data, size 0x5e8 vma 0x100c90
Start address 0x8040
Transfer rate: 817184 bits in 1 sec.
(gdb) r
Starting program: 
/home/yangqiao/development/rtems/build-rtems-rpi/arm-rtems4.11/c/raspberrypi/testsuites/samples/hello/hello.exe

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

GSOC2015 idea Raspberry Pi BSP

2015-03-05 Thread QIAO YANG


Hello ,

I' a 3rd year chinese student studying software engineering (real-time system 
and embedded system) in France.  I've found the GSOC2015 idea 'Raspberry Pi BSP 
' very attractive and I would like to know more about it to prepare my proposal.

Since the wiki page hasn't a concrete introduction yet, I would like to know a 
bit more about it in order to make my first step to try out the existing codes 
and prepare the proposal.

After having read the wiki of the same project in GSOC2013,  I guess the BSP is a library 
which contains the apis of communication protocols to manipulate the peripherals. So 
maybe our goal is completing the futur works described on GSOC 2013's wiki 
https://devel.rtems.org/wiki/GSoC/2013/Raspberry_Pi_BSP_Peripherals, 
that :  add support to different model of RPI  etc... or something else?

Any references or instructions would be greatly helpful.

Looking forward to hearing from you soon :)

Best regards
---
YANG Qiao

Université de Tchnologie de Compiègne

Génie Informatique___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

46 matches

Mail list logo