Re: Raspberry Pi RTEMS applications JTAG debugging and U-boot TFTP image load

[Chris Johns]

On 21/07/2015 1:13 am, Pavel Pisa wrote:
> 
> Alternative is to use directly gdb load command from the debugger
> session but for some reasons I have for more HW and SW combinations
> received that some words has been loaded incorrectly/skipped
> if I use load directly from gdb/DDD command line.
> 

For the BeagleBoard xM (MIO) and Zynq (FSBL) I use OpenOCD to load the
first stage boot loader and run it then halt the processor and load the
executable. The boot loader does all the set up of the hardware.

For example ...

https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/beagleboardxm.mc#n58
https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/beagle/simscripts/bbxm.cfg#n8

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

Re: Raspberry Pi RTEMS applications JTAG debugging and U-boot TFTP image load

[Chris Johns]

On 21/07/2015 3:51 am, Gedare Bloom wrote:
> On Mon, Jul 20, 2015 at 11:13 AM, Pavel Pisa  wrote:
>>
>> I think that it worth to collect/archive the part of RTEMS specific
>> information even in RTEMS wiki. But there is no RPi page there yet
>>
>>   https://devel.rtems.org/wiki/TBR/BSP
>>
>> What should be the name of the page?
>> Is RaspberryPi good choice to match "raspberrypi" BSP name
>> in RTEMS.
> Yes. Thanks for this!

There is also the https://devel.rtems.org/wiki/Debugging and below. I
think we should look at adding JTAG here and so have
https://devel.rtems.org/wiki/Debugging/JTAG. We can have specific pages
for different processors and pods. The RPi can then reference this with
its specific hardware details.

So much of this stuff is repeated in each BSP and we should attempt to
capture it from the debugging point of view. The BSP can then
concentrate on the target specifics like a circuit or connector.

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

Re: RPi Graphic testing

[桥 杨]

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  写道：
> 
> 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 
> #include 
> #include 
> #include 
> 
> 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

[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 
#include 
#include 
#include 

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

[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  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=) 
> at 
> ../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/fbcons.c:79
> #2  fbcons_write_support_polled (minor=, 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=, 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 , 
> buf=, nbyte=, major= out>, minor=1) at 
> ../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:109
> #6  0x0001704c in device_write (iop=, buffer=, 
> count=) 
> 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=, 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=) 
> 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.m

Re: RPi Graphic testing

[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=) 
at 
../../../../../../../../../../git/rtems-yangqiao/c/src/lib/libbsp/arm/raspberrypi/console/fbcons.c:79
#2  fbcons_write_support_polled (minor=, 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=, 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 , 
buf=, nbyte=, major=, minor=1) at 
../../../../../../../../git/rtems-yangqiao/c/src/../../cpukit/libcsupport/src/sup_fs_deviceio.c:109
#6  0x0001704c in device_write (iop=, buffer=, 
count=) 
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=, 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=) 
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:  0x000x000x000x000x000x000x000x00
0x2e5:  0x000x000x000x000x000x000x000x00
0x2ed:  0x000x000x000x000x000x000x000x0

Re: Raspberry Pi RTEMS applications JTAG debugging and U-boot TFTP image load

[Gedare Bloom]

On Mon, Jul 20, 2015 at 11:13 AM, Pavel Pisa  wrote:
> Hello everybody,
>
> I have decided to prepare debugging environment
> during my attempts to test graphic Qiao Yang's
> framebuffer support for RPi and I expect that infomation
> can be interesting for more developers.
>
> The first, I do not like to copy RTEMS image each time
> to SD card for test on real hardware.
> So I have setup TFTP server on my computer and use
> next uEnv.txt sequence
>
> serverip=192.168.1.10
> ipaddr=192.168.1.33
> bootargs=place_for_kernel_options
> bootcmd=mw.l 0x2020 0x04a020; mw.l 0x2028 0x65b6c0; usb start; tftp 
> ${kernel_addr_r} 192.168.1.10:/rpi/rtems/app.img ; bootm
> ${kernel_addr_r}
>
> the tftp command can be replaced by dhcp for dynamic network setup.
>
> The first two memory modifications are used to enable
> JTAG pins on RPi P1 connector.
>
> The RTEMS executable is conevrted to U-boot image by next commands
> sequence
>
> arm-rtems4.11-objcopy -R -S --strip-debug -O binary ticker.exe ticker.bin || 
> exit 1
> cat ticker.bin | gzip -9 >ticker.gz
> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" -d 
> ticker.gz ticker.img
>
> The debugger setup is described on our university department group HW notes 
> page
>
>   
> https://rtime.felk.cvut.cz/hw/index.php/Raspberry_Pi#Raspberry_Pi_JTAG_debugguing
>
> I have used JTAG pod which I know best (i.e. PiKRON JT_USB5/JT_USB6) but
> all other FT2232 JTAGs should be usable with similar setup.
>
> Files for DDD and JTAG setup can be found in my RPi utilites repo
>
>   https://github.com/ppisa/rpi-utils/tree/master/jtag-debug
>
> uEnv.txt setup is switched for Linux kernel by default but RTEMS
> alternative line can be found there.
>
> To debug system it worth to insert some loop or wait to the system
> startup to have time to connect by JTAG to the system and then
> allow to continue by forcing jump out of the loop by debugger.
>
> Alternative is to use directly gdb load command from the debugger
> session but for some reasons I have for more HW and SW combinations
> received that some words has been loaded incorrectly/skipped
> if I use load directly from gdb/DDD command line.
>
> I think that it worth to collect/archive the part of RTEMS specific
> information even in RTEMS wiki. But there is no RPi page there yet
>
>   https://devel.rtems.org/wiki/TBR/BSP
>
> What should be the name of the page?
> Is RaspberryPi good choice to match "raspberrypi" BSP name
> in RTEMS.
Yes. Thanks for this!

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

Raspberry Pi RTEMS applications JTAG debugging and U-boot TFTP image load

[Pavel Pisa]

Hello everybody,

I have decided to prepare debugging environment
during my attempts to test graphic Qiao Yang's
framebuffer support for RPi and I expect that infomation
can be interesting for more developers.

The first, I do not like to copy RTEMS image each time
to SD card for test on real hardware.
So I have setup TFTP server on my computer and use
next uEnv.txt sequence

serverip=192.168.1.10
ipaddr=192.168.1.33
bootargs=place_for_kernel_options
bootcmd=mw.l 0x2020 0x04a020; mw.l 0x2028 0x65b6c0; usb start; tftp 
${kernel_addr_r} 192.168.1.10:/rpi/rtems/app.img ; bootm 
${kernel_addr_r}

the tftp command can be replaced by dhcp for dynamic network setup.

The first two memory modifications are used to enable
JTAG pins on RPi P1 connector.

The RTEMS executable is conevrted to U-boot image by next commands
sequence

arm-rtems4.11-objcopy -R -S --strip-debug -O binary ticker.exe ticker.bin || 
exit 1
cat ticker.bin | gzip -9 >ticker.gz
mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n "RTEMS" -d 
ticker.gz ticker.img

The debugger setup is described on our university department group HW notes page

  
https://rtime.felk.cvut.cz/hw/index.php/Raspberry_Pi#Raspberry_Pi_JTAG_debugguing

I have used JTAG pod which I know best (i.e. PiKRON JT_USB5/JT_USB6) but
all other FT2232 JTAGs should be usable with similar setup.

Files for DDD and JTAG setup can be found in my RPi utilites repo

  https://github.com/ppisa/rpi-utils/tree/master/jtag-debug

uEnv.txt setup is switched for Linux kernel by default but RTEMS
alternative line can be found there.

To debug system it worth to insert some loop or wait to the system
startup to have time to connect by JTAG to the system and then
allow to continue by forcing jump out of the loop by debugger.

Alternative is to use directly gdb load command from the debugger
session but for some reasons I have for more HW and SW combinations
received that some words has been loaded incorrectly/skipped
if I use load directly from gdb/DDD command line.

I think that it worth to collect/archive the part of RTEMS specific
information even in RTEMS wiki. But there is no RPi page there yet

  https://devel.rtems.org/wiki/TBR/BSP

What should be the name of the page?
Is RaspberryPi good choice to match "raspberrypi" BSP name
in RTEMS.

Best wishes,

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

RPi Graphic testing

[Pavel Pisa]

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

  bootcode.bin + start_cd.elf + start_x.elf

or config.txt setup.

Please, prepare zip archive with files found on your
boot partition, ideally with one or two RTEMS
applications. I try change components to mine
and check when it stop work.

Ideal option is, if you can place archive
to some public location and sent URL.
If it is a problem and it is larger than
200 kB or something sane like then send
it to me directly offlist. If there
is interrest, I have no problem to put it
on my page at university. Or you can use
some free store and download site.

On my setup, I am able to run mainline RTEMS
ticker without problems. When I run ticker
build from your sources then it gets through
autodetection but even if I try to modify
framebuffer RAM area directly there is no
change visible on the screen. Mode seems
to be setup correctly when I press info
button on the monitor.

I have spent most time till now to prepare
reasonable RPi debug setup.
More info in the next message.

Best wishes,

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

Re: [RSB] port graphic libraries into rsb

[Chris Johns]

On 20/07/2015 7:34 pm, Pavel Pisa 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.

Please see:

 https://devel.rtems.org/ticket/2374
 https://lists.rtems.org/pipermail/users/2015-July/029233.html

I suggest you update and see if the changes I have recently pushed help.

> 
> 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.
> 
> 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"

Just a small note. You should be able to make a build set file that is a
list of these build sets and use just use that. This a key feature,
being able to build up sets of packages to build in a controlled order.

> -
> 
> 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.

I suspect this is a bug. It should be supported.

> 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.

Let me take a look and get back to you.

> 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.

The original intent is to allow configurations outside of the RSB tree
and to have them supported.

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

Bug.

> 
> 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/s

Re: [RSB] port graphic libraries into rsb

[Pavel Pisa]

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.

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.

It would be great if it is possible to limit these leaks.
I expect that most can be prevented by right prefix path related
options during packages configuration. I would be probably reasonable
to disable build of test code and utilities by config options
if possible. They are of zero value as host RTEMS tools "/opt/rtems4.11/bin"
when compiled for target and even on target there are usable libraries
only because RTEMS does not load applications at runtime.

None of above is critical but it would worth to clean up for better
experience.

Best wises,

 Pavel



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

Re: [rtems-source-builder commit] rtems4.11: OpenMP support for ARM, PowerPC, SPARC

[Sebastian Huber]

On 20/07/15 09:03, Chris Johns wrote:

On 20/07/2015 4:01 pm, Sebastian Huber wrote:


On 19/07/15 01:57, Chris Johns wrote:

On 18/07/2015 11:38 pm, Sebastian Huber wrote:

- Chris Johns  schrieb:

On 18/07/2015 1:20 am, Joel Sherril wrote:

diff --git a/rtems/config/4.11/rtems-arm.bset
b/rtems/config/4.11/rtems-arm.bset
index 1e06796..c0bd04a 100644
--- a/rtems/config/4.11/rtems-arm.bset
+++ b/rtems/config/4.11/rtems-arm.bset
@@ -17,6 +17,11 @@
   %define enable_obsolete 1
 #
+# Enable OpenMP support
+#
+%define with_libgomp
+

I think this forces the option to be always on. Should a user be
able to
disable the option with --without-libgomp ?

More options more problems.

The more defaults we turn on the more regression testing we need to do.

The libgomp test suite is part of the GCC test suite, so it makes no big
difference to run it with libgomp enabled or not. It just takes a bit
longer to execute and you need an SMP target to do the run-time tests.
Since OpenMP makes only sense on SMP targets, this is not a real issue.


The wiki page for OpenMP shows the test results status is unclear.

The problem was the OpenMP 3.1 Validation Suite itself. The libgomp
support for RTEMS uses the POSIX configuration in GCC 4.9.3 which works
really well in terms of correctness. In terms of performance there are
severe problems, see https://devel.rtems.org/ticket/2274.



If we default to off and a user enables the feature that is different.
The need for regression testing and test results is not as critical.


   I don't think there are serious reasons to disable this option.  If
you don't need OpenMP, then you waste a couple of minutes in tool
build time and some megabytes of disk storage.

I am not concerned about the time to build or disk space. I am concerned
about a change so close to the release plus I have not seen any test
results. I know it is difficult to make available features while they
are being worked on however it is also reasonable for users to expect it
basically works when on by default so it is the default status that
concerns me and what it says.

The --enable-libgomp has absolutely no impact to your application if you
don't enable OpenMP (-fopenmp).


I am attempting to discuss the correctness of the tools being built and
how we manage this process as a project. It is not related to any
application I may build or the build time. We need to aim at limiting
what we release to what we can test.


The libgomp is part of GCC just like libstdc++. If you test GCC with its 
test suite, then libgomp is also covered. I don't see why the enabling 
of libgomp makes anything worse.




I have seen no evidence this stuff works on all the architectures it is
enabled on so if I upgrade the tools and see it breaks a build can I
just default it to off until fixed or does the breakage block a tools
upgrade ?


Which build should it break? I checked that I am able to build the tools 
with the RSB. It cannot break the RTEMS build, since we don't use 
-fopenmp here. If it really breaks anything, then I will fix it.


I tested the libgomp in the POSIX configuration and it worked really 
well except the performance issues. The operating system dependencies 
are quite limited, you just need POSIX threads, mutexes and semaphores.





Are there test results that can be published for all the arch's enabled ?
How do we run the tests so we can regression test ?

FWIW gcc testing and the gcc testsuite is a big item we need to address
in a formal way so the whole regression testing of tools from building
to test results is available to all users and not hidden away on
developer machines with custom scripts.

Chris

Yes, regular and automated GCC tests are definitely something we need.
We have the scripts available in the rtems-testing repository.

They are to be obsoleted and that repo archived so please do not
encourage there use. The rtems-tools rtems-test command should be used
as it is to be supported on all hosts but it needs more work.


I don't encourage its use, my point is that we have all the ingredients 
that are necessary to do GCC testing with RTEMS. It just needs time to 
polish this stuff.




The rtems-testing scripts are specific to Linux, do not support gdb via
MI mode and the options and what happens is too variable.


It just
needs someone with enough time to polish the scripts and setup a machine
which does regular test runs and publish the results.

We need to teach rtems-test how to run gcc tests.


Yes, and we should do regular GCC trunk testing. Currently its mere luck 
that if we catch errors like this for example:


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mi

Re: [rtems-source-builder commit] rtems4.11: OpenMP support for ARM, PowerPC, SPARC

[Chris Johns]

On 20/07/2015 4:01 pm, Sebastian Huber wrote:
> 
> 
> On 19/07/15 01:57, Chris Johns wrote:
>> On 18/07/2015 11:38 pm, Sebastian Huber wrote:
>>> - Chris Johns  schrieb:
 On 18/07/2015 1:20 am, Joel Sherril wrote:
> diff --git a/rtems/config/4.11/rtems-arm.bset
> b/rtems/config/4.11/rtems-arm.bset
> index 1e06796..c0bd04a 100644
> --- a/rtems/config/4.11/rtems-arm.bset
> +++ b/rtems/config/4.11/rtems-arm.bset
> @@ -17,6 +17,11 @@
>   %define enable_obsolete 1
> #
> +# Enable OpenMP support
> +#
> +%define with_libgomp
> +
 I think this forces the option to be always on. Should a user be
 able to
 disable the option with --without-libgomp ?
>>> More options more problems.
>> The more defaults we turn on the more regression testing we need to do.
> 
> The libgomp test suite is part of the GCC test suite, so it makes no big
> difference to run it with libgomp enabled or not. It just takes a bit
> longer to execute and you need an SMP target to do the run-time tests.
> Since OpenMP makes only sense on SMP targets, this is not a real issue.
> 
>> The wiki page for OpenMP shows the test results status is unclear.
> 
> The problem was the OpenMP 3.1 Validation Suite itself. The libgomp
> support for RTEMS uses the POSIX configuration in GCC 4.9.3 which works
> really well in terms of correctness. In terms of performance there are
> severe problems, see https://devel.rtems.org/ticket/2274.
> 
> 
>>
>> If we default to off and a user enables the feature that is different.
>> The need for regression testing and test results is not as critical.
>>
>>>   I don't think there are serious reasons to disable this option.  If
>>> you don't need OpenMP, then you waste a couple of minutes in tool
>>> build time and some megabytes of disk storage.
>> I am not concerned about the time to build or disk space. I am concerned
>> about a change so close to the release plus I have not seen any test
>> results. I know it is difficult to make available features while they
>> are being worked on however it is also reasonable for users to expect it
>> basically works when on by default so it is the default status that
>> concerns me and what it says.
> 
> The --enable-libgomp has absolutely no impact to your application if you
> don't enable OpenMP (-fopenmp).
> 

I am attempting to discuss the correctness of the tools being built and
how we manage this process as a project. It is not related to any
application I may build or the build time. We need to aim at limiting
what we release to what we can test.

I have seen no evidence this stuff works on all the architectures it is
enabled on so if I upgrade the tools and see it breaks a build can I
just default it to off until fixed or does the breakage block a tools
upgrade ?

>>
>> Are there test results that can be published for all the arch's enabled ?
>> How do we run the tests so we can regression test ?
>>
>> FWIW gcc testing and the gcc testsuite is a big item we need to address
>> in a formal way so the whole regression testing of tools from building
>> to test results is available to all users and not hidden away on
>> developer machines with custom scripts.
>>
>> Chris
> 
> Yes, regular and automated GCC tests are definitely something we need.
> We have the scripts available in the rtems-testing repository. 

They are to be obsoleted and that repo archived so please do not
encourage there use. The rtems-tools rtems-test command should be used
as it is to be supported on all hosts but it needs more work.

The rtems-testing scripts are specific to Linux, do not support gdb via
MI mode and the options and what happens is too variable.

> It just
> needs someone with enough time to polish the scripts and setup a machine
> which does regular test runs and publish the results.

We need to teach rtems-test how to run gcc tests.

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