subject:"Re\: RPi Graphic testing"

Re: RPi Graphic testing

2015-07-22 Thread Pavel Pisa

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)

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);

   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.

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.

Best wishes,

 Pavel

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

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

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

Re: RPi Graphic testing

2015-07-20 Thread Pavel Pisa

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 
vc_mem.me...
0x1f4:  m_base=0x1ec0 vc_mem.mem_size=0x2000  dwc_otg.lpm_enable=0 
console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 
rootfstype=ext4 elevator=deadline rootwait ro init=/sbin/init-overla...
0x2bc:  y

0x2bd:  0x000x000x00
0x2c0:  0x000x000x000x000x000x000x00
ATAG_NONE, end of the list, all OK

0x2c8:  0x000x000x000x000x000x00
0x2cd:  0x000x000x000x000x000x000x000x00
0x2d5:  0x000x000x000x000x000x000x000x00
0x2dd:  0x000x000x000x000x000x000x00

Re: RPi Graphic testing

2015-07-20 Thread Pavel Pisa

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

Re: RPi Graphic testing

2015-07-20 Thread 桥杨

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

Re: RPi Graphic testing

Re: RPi Graphic testing

Re: RPi Graphic testing

Re: RPi Graphic testing

Re: RPi Graphic testing

Re: RPi Graphic testing

6 matches

Site Navigation

Mail list logo

Footer information