Generating lock graph for nested mutex project
hi, Is there any tool which can be used to generate lock-graph for the JPF implementation of nested mutex. I have removed unnecessary re-entrant locks and want to further investigate on which other locks can be avoided with correct implementation. code repo: https://github.com/saurabhgadia4/lock-model/blob/rtemsjpf-0.4/rtems/Mutex.java Thanks, Saurabh Gadia ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RPi Graphic testing
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: [RSB] port graphic libraries into rsb
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-rtems-386/; \
../rtems-git/configure --target=i386-rtems4.11 \
--enable-rtemsbsp=pc386 \
--enable-tests=samples
Re: RPi Graphic testing
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
Raspberry Pi 2 SMP debug
Hi, I need to debug my code to check what is going wrong with SMP initialization. Any suggestions on how I can go about this in the absence of actual debugging hardware? Thanks. -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Raspberry Pi 2 SMP debug
On 22/07/15 13:19, Rohini Kulkarni wrote: Hi, I need to debug my code to check what is going wrong with SMP initialization. Any suggestions on how I can go about this in the absence of actual debugging hardware? Pavel Pisa wrote something about JTAG debugging of the Raspberry Pi recently: https://lists.rtems.org/pipermail/devel/2015-July/011962.html Another option is Qemu, but I don't know the options to simulate a Raspberry Pi. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
