[STHORM] Integration issue - SDK v2013.1 - p12Runtime not properly initializing the platform descriptor

Patrick Bellasi

unread,

Mar 1, 2013, 1:24:24 PM3/1/13

to Germain Haugou, bosp-...@googlegroups.com

Hi Germain!

Finally we got the SThorm HW here in our office.

Now we are trying to get a working setup with BarbequeRTRM which is able to talk with the accelerator firmware. So far, when we run barbeque, wither:

1. it stops waiting for platform data loading

or

2. is load a wrong set of platform data (e.g. 8 cluster descriptors instead of the expected 4)

This is how we configured the current setup, please check each point and let us know if we have to do something in a different way.

.:: SDK

We are using SDK 2013.1 which provides a new sthormStart script, this is the initialization we are doing in the shell used thereafter:

// First define some required env variables

$> export ANDROID_SDK_ROOT=/opt/android-sdk-linux
$> export ANDROID_NDK_ROOT=/opt/android-ndk-r7
$> export ANDROID_TOOLSET_ROOT=$ANDROID_SDK_ROOT/tools
$> export SX=/opt/SDK-release-2013.1/tools/STxP70

// Enter the SDK root
$> cd /top/SDK-release-2013.1
$> source env/sdk_setup.sh

// Add some missing definitions (should these be defined by the sdk_setup.sh?!?)
$> export STHORM_SDK_OCL_HOME=$STHORM_SDK_HOME
$> export P2012_STHORM_IP_ADDR=192.168.1.10

.:: Update firmware via the sthormStart script

We use the sthormStart script with the target board connected via ethernet. This is an output of the script:

// Deploy all the SThrom specific firmware
$> sthormStart
+ '[' '' == beecube ']'
+ '[' -z 192.168.1.10 ']'
++ adb -s 192.168.1.10:5555 shell cat /proc/modules
++ grep p2012
+ isLoaded=
+ '[' -n '' ']'
+ adb disconnect 192.168.1.10:5555
+ echo 'Connecting to board'
Connecting to board
+ adb connect 192.168.1.10
connected to 192.168.1.10:5555
+ echo 'Uploading files'
Uploading files
+ adb -s 192.168.1.10:5555 shell mkdir /tmp
+ adb -s 192.168.1.10:5555 shell mkdir -p /lib/modules
+ adb -s 192.168.1.10:5555 shell mkdir -p /vendor/lib
+ adb -s 192.168.1.10:5555 shell mkdir -p /vendor/etc
+ '[' '' == beecube ']'
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/linux/driver/sthorm/lib/modules/p2012_dbg.ko /tmp
3408 KB/s (158978 bytes in 0.045s)
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/linux/driver/sthorm/lib/modules/p2012d_dbg /lib/modules
731 KB/s (31035 bytes in 0.041s)
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/linux/driver/sthorm/lib/modules/mknod_jmz /lib/modules
150 KB/s (6425 bytes in 0.041s)
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/linux/lib/lib/libp2012.so /vendor/lib
545 KB/s (23044 bytes in 0.041s)
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/host/arm/lib/liboclUtil.so /vendor/lib
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/host/arm/lib/libOpenCL.so /vendor/lib
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/host/arm/lib/libClamCSocket.so /vendor/lib
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/host/arm/lib/libClamC.so /vendor/lib
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/daemon/arm/lib/libocldClient.so /vendor/lib
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/p12Runtime/xp70/lib/p12Runtime.exe /vendor/lib
4509 KB/s (1905430 bytes in 0.412s)
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/daemon/arm/bin/oclDaemon /lib/modules
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/comete/android/lib/libcomete.so /vendor/lib
731 KB/s (30496 bytes in 0.040s)
+ adb -s 192.168.1.10:5555 push /modules/OpenCL/fabric/xp70/lib/sthormCl.so /vendor/lib
+ '[' -e p2012.ini ']'
+ adb -s 192.168.1.10:5555 push /opt/SDK-release-2013.1/modules/bin/p2012.ini /vendor/etc/p2012.ini
10 KB/s (437 bytes in 0.041s)
+ cat /opt/SDK-release-2013.1/modules/bin/driverStart
+ sed s/DRIVER_OPTIONS//
+ chmod u+x driverStart
+ adb -s 192.168.1.10:5555 push driverStart /lib/modules/driverStart
11 KB/s (497 bytes in 0.041s)
+ echo 'Launching driver'
Launching driver
+ trap devboard_handler SIGINT SIGKILL SIGHUP SIGQUIT SIGTERM SIGSTOP
+ adb -s 192.168.1.10:5555 shell /lib/modules/driverStart
mknod.c main(15)
Start P2012 Daemon:
==================
DD[user-1420] p2012d_pipe.c, main(260) : DBG Start P2012 Daemon:
p2012d_pipe.c initDDTraceLevel(39) trace_level=0
p2012d_pipe.c main(305) P2012d: waiting for client (opening pipes) ...

NOTE: at this point we simply reboot the board, and nevermore use the startSthorm script.

The idea of this script is just to deploy on the bard the most recent software provided with SDK v2013.1

.:: Deploy the BarbequeRTRM

After a fresh restart of the board, we setup the adb connection and than deploy the BarbequeRTRM using the make target provided by the BOSP building system, which, by default, it deploys all the BBQ related software under /data/bosp.

.:: Start BarbequeRTRM (with default init.rc)

After the board as started, first of all we stop all Android services (just to have a light environment)

$> adb shell stop

and this is the system status at that point:

(1:501)$ adb shell ps
USER     PID   PPID VSIZE RSS     WCHAN    PC         NAME
root      1     0     332    192   c00a3da4 000086e8 S init
root      2     0     0      0     c0036d4c 00000000 S kthreadd
root      3     2     0      0     c0024588 00000000 S ksoftirqd/0
root      4     2     0      0     c00332e8 00000000 S kworker/0:0
root      5     2     0      0     c00332e8 00000000 S kworker/u:0
root      6     2     0      0     c0056bc4 00000000 S migration/0
root      7     2     0      0     c0056bc4 00000000 S migration/1
root      8     2     0      0     c00332e8 00000000 S kworker/1:0
root      9     2     0      0     c0024588 00000000 S ksoftirqd/1
root      10    2     0      0     c0033058 00000000 S khelper
root      11    2     0      0     c01fa5b8 00000000 S kdevtmpfs
root      12    2     0      0     c00332e8 00000000 S kworker/u:1
root      325   2     0      0     c007b03c 00000000 S sync_supers
root      327   2     0      0     c007be08 00000000 S bdi-default
root      328   2     0      0     c0033058 00000000 S kblockd
root      343   2     0      0     c023659c 00000000 S khubd
root      438   2     0      0     c0033058 00000000 S rpciod
root      439   2     0      0     c00332e8 00000000 S kworker/0:1
root      452   2     0      0     c00760ec 00000000 S kswapd0
root      453   2     0      0     c00c5acc 00000000 S fsnotify_mark
root      454   2     0      0     c0033058 00000000 S nfsiod
root      523   2     0      0     c0033058 00000000 S e000d000.spi
root      562   2     0      0     c0033058 00000000 S kpsmoused
root      581   2     0      0     c00332e8 00000000 S kworker/u:2
root      588   2     0      0     c0033058 00000000 S binder
root      598   2     0      0     c02a1a04 00000000 S mmcqd/0
root      607   2     0      0     c00332e8 00000000 S kworker/1:1
root      608   2     0      0     c0125b8c 00000000 S kjournald
root      609   1     304    4     c00a3da4 000086e8 S /sbin/ueventd
system    956   1     832    212   c02ba3a8 b6f18670 S /system/bin/servicemanager
root      957   1     4020   540   ffffffff b6fb0c74 S /system/bin/vold
root      958   1     6312   760   ffffffff b6f65c74 S /system/bin/netd
root      959   1     696    204   c02caaa4 b6f95f78 S /system/bin/debuggerd
root      960   1     1368   592   c003ac4c b6ef2c74 S /system/bin/rild
media     963   1     19860 5584 ffffffff b6f17670 S /system/bin/mediaserver
bluetooth 964   1     1336   500   c00a3da4 b6f063fc S /system/bin/dbus-daemon
root      965   1     844    232   c02caaa4 b6f6df78 S /system/bin/installd
keystore 966   1     1736   472   c02caaa4 b6f3cf78 S /system/bin/keystore
root      968   2     0      0     c00b3e08 00000000 S flush-179:0
log       1019 1     692    204   c01dced4 b6f77438 S /system/bin/logwrapper
root      1020 1     5508   684   ffffffff b6e88670 S /vendor/modules/oclDaemon
root      1022 1     772    400   c01dced4 b6f48438 S /system/bin/sh
root      1023 1     6508   172   ffffffff 0000825c S /sbin/adbd
root      1028 1019 2800   216   ffffffff b6eae4b8 S /vendor/modules/p2012d_dbg
root      1036 2     0      0     c00332e8 00000000 S kworker/0:2
root      1161 1023 860    460   c00a3da4 b6f5f794 S logcat
root      1177 1023 760    292   c00103d0 b6f19e54 S /system/bin/sh
root      1179 1177 956    256   00000000 b6f16438 R ps

It is worth to notice that both the P2012 daemon (p2012d_dbg) and the OpenCL daemon (oclDaemon) are running.

Germain: correct me if I'm wrong, but I expect at least the P2012 daemon not running if the accelerator if managed by BBQ. Is that correct? Otherwise, could this daemon interfere somehow with BBQ?

Now, if we start the BarbequeRTRM daemon, the platform initialization is completed but the enumeration we get is wrong.

This is the logcat (where I've removed some entries for brevity)

V/bq.pp   ( 1169): PLAT P2012: ... Loading platform data ...
V/bq.df.rm.opt( 1169): DF[rm.opt] Deferrable thread STARTED
I//vendor/modules/p2012d_dbg( 1019): p2012d_pipe.c main(305) P2012d: waiting for client (opening pipes) ...
I/bq.pp   ( 1169): PLAT PRX: Platform [com.st.sthorm] initialization COMPLETED
V/bq.ra   ( 1169): Report on state view: 0
I/bq.ra   ( 1169): =========================================================================
I/bq.ra   ( 1169): |   RESOURCES                   |     USED    | UNRESERVED |     TOTAL   |
I/bq.ra   ( 1169): |-------------------------------+-------------+---------------------------|
I/bq.ra   ( 1169): | sys0.acc0.grp0.mem0         I :    0.000e+0 | 1535.873e+9 | 1535.873e+9 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe0          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe1          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe10         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe11         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe12         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe13         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe14         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe15         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe2          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe3          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe4          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe5          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe6          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe7          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe8          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp0.pe9          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
[... removed entries sys0.acc0.grp[1..6] for brevity ...]
I/bq.ra   ( 1169): | sys0.acc0.grp7.mem0         I :    0.000e+0 |    0.000e+0 |    0.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe0          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe1          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe10         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe11         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe12         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe13         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe14         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe15         I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe2          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe3          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe4          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe5          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe6          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe7          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe8          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.grp7.pe9          I :    0.000e+0 | 100.000e+0 | 100.000e+0 |
I/bq.ra   ( 1169): | sys0.acc0.mem0              I :    0.000e+0 |    1.000e+6 |    1.000e+6 |
I/bq.ra   ( 1169): =========================================================================
V/bq.pp   ( 1169): Worker[bq.pp]: Registered
V/bq.pp   ( 1169): PLAT PRX: Monitoring thread STARTED

And this is the kernel log trace, generate while the enumeration is performed (simplified a bit to keep just the meaningful info):

[ 3674.920000] p2012_daemon_ioctl(1589) : case P2012_P2012D_OPEN
[ 3674.950000] p2012_daemon_ioctl(1606) : p2012Priv = d85bac00
[ 3674.990000] p2012_allocSysQueues PrivateHandle(1096) : p2012Priv = d85bac00
[ 3675.020000] p2012_daemon_ioctl(1299) : case P2012_CREATE_QUEUE from(5) to (4)
[ 3675.060000] p2012_daemon_ioctl(1335) : data.back_link= (null)
[ 3675.090000] p2012_setProcess(485) : backlink= (null)
[ 3675.120000] p2012_daemon_ioctl(1299) : case P2012_CREATE_QUEUE from(4) to (5)
[ 3675.160000] p2012_daemon_ioctl(1335) : data.back_link= (null)
[ 3675.190000] p2012_setProcess(485) : backlink= (null) _SEND_MSG
[ 3675.240000] p2012_daemon_ioctl(1435) : case P2012_BBQ_INIT
[ 3675.270000] p2012_daemon_ioctl(1440) : case P2012_BBQ_INIT handle = 70500000
[ 3675.310000] p2012_daemon_ioctl(1441) : case P2012_BBQ_INIT size = 524288, 0x80000
[ 3675.340000] p2012_ld_mmap(2285) : vm_pgoff=460032=0x70500
[ 3675.370000] p2012_ld_mmap(2286) : offset=1884291072=0x70500000
[ 3675.400000] p2012_ld_mmap(2287) : vma_size=524288=0x80000
[ 3675.430000] p2012_ld_mmap(2319) : curr->busAddr=0x70500000
[ 3675.460000] p2012_ld_mmap(2320) : curr->userLogicalAddr=0x (null)
[ 3675.500000] p2012_ld_mmap(2322) : curr->busAddr=0x70500000
[ 3675.530000] p2012_ld_mmap(2323) : curr->userLogicalAddr=0x (null)
[ 3675.560000] p2012_ld_mmap(2373) : userLogicalAddr=b66f2000
[ 3675.590000] p2012_ld_mmap(2374) : busAddr=0x70500000
[ 3675.620000] p2012_ld_mmap(2375) : kernelLogicalAddr=e1500000

What we can see from this last log is that the descriptor is properly mapped by the P2012 device driver.

A further checking on /proc/BBQ_PID/maps shows this mapping:

b66f2000-b6772000 rwxs 70500000 00:0d 266 /dev/p2012

where we can verify that a region of 524288 Bytes has been mapped starting @b66f2000, as properly reported by the device driver log.

Thus: no problems related to the Linux device driver which is handling the message queue initialization and descriptor mapping.

However, as you could notice from the BBQ log, the reported amount of memory is wrong (1535 GB) as well as the number of clusters (sys.acc.grp named resources) is not correct, indeed we enumerate up to 8 clusters, while only the first 4 have a not null empty memory resource.

Please consider that, when BOSP is build, we include the p2012_pil.h header file provided by the P2012 SDK, i.e.

${CONFIG_EXTERNAL_P2012_SDK}/modules/linux/lib/include/p2012_pil.h

thus it could not be the chance for a mis-alignment on data structures definition.

What I suspect is an in-correct version of the STHORM run-time, which probably does not properly initialize the device descriptor.

Could that be the reason? How we could check the version of this p12Runtime.exe and if it properly initialize the descriptor?

A further investigation on the memory content of the ManagedDevice_t descriptor, i.e.:

typedef struct ManagedDevice {
runtimeConf_t rtConf;
DeviceDescriptor_t descr;
NotifyDescriptor_t notif;
PlatformDescriptor_t pdesc;
PlatformConstraints_t pcons;
} ManagedDevice_t;

has sown some strange values. For example, regarding the runtimeConf_t (which as far as I know is a backward compatibility data structure) reports 0 for the number of clusters and PEs. But, even more interesting, we actually read 8 as number of clusters when dumping the content of the PlatformDescriptor_t:

typedef struct PlatformDescriptor {
#define PLATFORM_CLUSTERS_MAX 4
uint32_t clusters_count;
uint32_t pes_count;
ClusterDescriptor_t cluster[PLATFORM_CLUSTERS_MAX];
} PlatformDescriptor_t;

===========================================================
Dumped values:
===========================================================
./dumpDescriptor.sh 0x70500000 0x1DC 2

Value at address 0x705001DC (0xb6fbf1dc): 0x8 (clusters_count)
Value at address 0x705001E0 (0xb6ffa1e0): 0x10 (pes_coount)

Thus, this makes me think that definitively the problem is related to the sthorm run-time which, at least the version delivered with the 2013.1 SDK, does not properly initialize the decriptor. For the rest, BBQ is correctly running and the bbque-testapp is also working, but we know that this application is running on the host side ;-)

This is just a set of input to trigger a discussion... let me know if we have done something in a not proper way.

Hope we can have a telco beginning next week!

Have a nice week-end,

Patrick

--
#include <best/regards.h>

Patrick Bellasi
Post-Doc at Politecnico di Milano
http://home.dei.polimi.it/bellasi

Germain HAUGOU

unread,

Mar 4, 2013, 5:08:01 AM3/4/13

to bosp-...@googlegroups.com, Patrick Bellasi (derkling@gmail.com)

Hi Patrick,

From: bosp-...@googlegroups.com [mailto:bosp-...@googlegroups.com] On Behalf Of Patrick Bellasi
Sent: Friday, March 01, 2013 7:24 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: [STHORM] Integration issue - SDK v2013.1 - p12Runtime not properly initializing the platform descriptor

Hi Germain!

Finally we got the SThorm HW here in our office.

Now we are trying to get a working setup with BarbequeRTRM which is able to talk with the accelerator firmware. So far, when we run barbeque, wither:

1. it stops waiting for platform data loading

or

2. is load a wrong set of platform data (e.g. 8 cluster descriptors instead of the expected 4)

This is how we configured the current setup, please check each point and let us know if we have to do something in a different way.

.:: SDK

We are using SDK 2013.1 which provides a new sthormStart script, this is the initialization we are doing in the shell used thereafter:

// First define some required env variables

$> export ANDROID_SDK_ROOT=/opt/android-sdk-linux
$> export ANDROID_NDK_ROOT=/opt/android-ndk-r7
$> export ANDROID_TOOLSET_ROOT=$ANDROID_SDK_ROOT/tools
$> export SX=/opt/SDK-release-2013.1/tools/STxP70

You should remove the last one (SX), it is only needed for the partial SDKs I’ve sent you in the past. Anyway, I think the toolset is still the same in 2013.1, this won’t have any impact.

Note that I will be sending you regular SDK now, the toolset is now always included, thus you won’t need anymore this SX variable.

// Enter the SDK root
$> cd /top/SDK-release-2013.1
$> source env/sdk_setup.sh

// Add some missing definitions (should these be defined by the sdk_setup.sh?!?)
$> export STHORM_SDK_OCL_HOME=$STHORM_SDK_HOME
$> export P2012_STHORM_IP_ADDR=192.168.1.10

In fact the sdk_setup.sh was used in the previous development SDKs. For official SDK, you should source the file setup.sh in the root directory. This explains why you are missing the first variable. Note than for future intermediate SDKs, you can also source the same file than for official SDKs.

The procedure for using the board is not yet well documented and it is still evolving. I will document it soon. For now I think it is better that you use the new SDK I sent today. The command for uploading the new design and software is the following:

p12run --platform=sthorm --sthorm-steps="design sw config"

Then you have to reset the board.

The OCL daemon is always running but can receive requests for taking or releasing clusters. This is the functionality we discussed some time ago and which is available through the Android binder. You have to interact with this daemon in order to manage the device.

I think something may have been broken recently on these aspects as they not yet automatically tested. Could you check with the new SDK and procedure if you still have the issue ? If yes, I will have to debug that, something must be wrong with the runtime. Could you sent me a binary package with BBQ that allows me to reproduce and see the issue ?

Ciao,

Germain

Have a nice week-end,

Patrick

--
#include <best/regards.h>

Patrick Bellasi
Post-Doc at Politecnico di Milano
http://home.dei.polimi.it/bellasi

--
You received this message because you are subscribed to the Google Groups "BOSP Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bosp-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Patrick Bellasi

unread,

Mar 4, 2013, 12:20:39 PM3/4/13

to Germain HAUGOU, bosp-...@googlegroups.com

On Mon, Mar 4, 2013 at 11:08 AM, Germain HAUGOU <germain...@st.com> wrote:

Hi Patrick,

Hi Germain!

.:: SDK
We are using SDK 2013.1 which provides a new sthormStart script, this is the initialization we are doing in the shell used thereafter:

// First define some required env variables

$> export ANDROID_SDK_ROOT=/opt/android-sdk-linux
$> export ANDROID_NDK_ROOT=/opt/android-ndk-r7
$> export ANDROID_TOOLSET_ROOT=$ANDROID_SDK_ROOT/tools
$> export SX=/opt/SDK-release-2013.1/tools/STxP70

You should remove the last one (SX), it is only needed for the partial SDKs I’ve sent you in the past. Anyway, I think the toolset is still the same in 2013.1, this won’t have any impact.

Note that I will be sending you regular SDK now, the toolset is now always included, thus you won’t need anymore this SX variable.

Ok, I've updated my init_env script. Now I init my shell with these commands:

// First define some required env variables
$> export ANDROID_SDK_ROOT=/opt/android-sdk-linux
$> export ANDROID_NDK_ROOT=/opt/android-ndk-r7

// Enter the SDK root

$> cd /opt/sthorm_sdk
$> source setup.sh
// Add some missing definitions (should these be defined by the setup.sh?!?)
$> export P2012_STHORM_IP_ADDR=192.168.1.10

The procedure for using the board is not yet well documented and it is still evolving. I will document it soon. For now I think it is better that you use the new SDK I sent today. The command for uploading the new design and software is the following:

p12run --platform=sthorm --sthorm-steps="design sw config"

Then you have to reset the board.

Ok, this worked.

Before issuing this command I've also updated the SDCard to start with a fresh image of the CES demo. I've recovered this image from the link reported by Manuele Lupo on this webpage http://goo.gl/HeSNC

After that update I've uploaded the BBQ installation (update.zip) you could download from this link http://goo.gl/xKgfW

You could download a convenient updater shell script from: http://goo.gl/mwzbq

Than:

// Deploy BBQ on the target SThorm device
$> ./apply_update 20130304_update.zip

It is worth to notice that both the P2012 daemon (p2012d_dbg) and the OpenCL daemon (oclDaemon) are running.
Germain: correct me if I'm wrong, but I expect at least the P2012 daemon not running if the accelerator if managed by BBQ. Is that correct? Otherwise, could this daemon interfere somehow with BBQ?

The OCL daemon is always running but can receive requests for taking or releasing clusters. This is the functionality we discussed some time ago and which is available through the Android binder. You have to interact with this daemon in order to manage the device.

Ok, I see. However, we are still missing a Binder access from the native layer of BBQ.

We should implement an ad-hoc Binder integration with the STHORM Platform Integration Layer... to be discussed better.

By the way: do you have an AIDL already defined for this Binder interface? Could you share it with us?

Now, if we start the BarbequeRTRM daemon, the platform initialization is completed but the enumeration we get is wrong.

Unfortunately still we get a wrong enumeration:

V/bq.pp ( 1171): PLAT P2012: ... Loading platform data ...

I//vendor/modules/p2012d_dbg( 1018): p2012d_pipe.c main(305) P2012d: waiting for client (opening pipes) ... V/bq.pp ( 1171): PLAT P2012: Message queues initialized V/bq.pp ( 1171): PLAT P2012: Start notification sent V/bq.pp ( 1171): PLAT P2012: Driver initialized V/bq.pp ( 1171): PLAT P2012: Device descriptor mapped in [b6769000] V/bq.pp ( 1171): PLAT P2012: Platform initialization performed V/bq.pp ( 1171): PLAT P2012: Platform is ready I/bq.pp ( 1171): PLAT PRX: Platform [com.st.sthorm] initialization COMPLETED V/bq.ra ( 1171): Report on state view: 0 I/bq.ra ( 1171): ========================================================================= I/bq.ra ( 1171): | RESOURCES | USED | UNRESERVED | TOTAL | I/bq.ra ( 1171): |-------------------------------+-------------+---------------------------| I/bq.ra ( 1171): | sys0.acc0.grp0.io0 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp0.io1 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp0.mem0 I : 0.000e+0 | 1535.500e+9 | 1535.500e+9 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe0 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe1 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe10 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe11 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe12 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe13 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe14 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe15 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe2 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe3 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe4 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe5 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe6 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe7 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe8 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe9 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | [... entries removed for brevity ...] I/bq.ra ( 1171): | sys0.acc0.grp7.io0 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp7.io1 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp7.mem0 I : 0.000e+0 | 0.000e+0 | 0.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe0 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe1 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe10 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe11 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe12 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe13 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe14 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe15 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe2 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe3 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe4 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe5 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe6 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe7 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe8 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe9 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): ========================================================================= V/bq.pp ( 1171): Worker[bq.pp]: Registered V/bq.pp ( 1171): PLAT PRX: Monitoring thread STARTED

And this is the new kernel logile we get:

[ 207.410000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1593) : case P2012_P2012D_OPEN

[ 207.440000] DD[kernel-1040] p2012_ld.c, allocP2012Priv(583) : [ 207.460000] DD[kernel-1040] p2012_ld.c, p2012_initHandles(569) : [ 207.490000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1610) : p2012Priv = d8284c00 [ 207.530000] DD[kernel-1040] p2012_ld.c, p2012_allocSysQueuesPrivateHandle(1100) : p2012Priv = d8284c00 [ 207.560000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1303) : case P2012_CREATE_QUEUE from(5) to (4) [ 207.600000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(65) : sizeof(P2012_message_t)=256 [ 207.630000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(66) : nr_elem=8 [ 207.660000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(73) : msg_host_virt_address=ffda2000 [ 207.690000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(80) : msg_fabric_phys_address=983c7000 [ 207.730000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1339) : data.back_link= (null) [ 207.760000] DD[kernel-1040] p2012_ld.c, p2012_setProcess(489) : backlink= (null) [ 207.790000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1351) : Queue has been allocated: [ 207.820000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1352) : - usrHandle: 118 [ 207.860000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1353) : - realHandle: 21 [ 207.890000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1354) : - :queue->id 21 [ 207.920000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1355) : - process: 0xd8284c00 [ 207.950000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1303) : case P2012_CREATE_QUEUE from(4) to (5) [ 207.990000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(65) : sizeof(P2012_message_t)=256 [ 208.020000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(66) : nr_elem=8 [ 208.050000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(73) : msg_host_virt_address=ffda1000 [ 208.080000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(80) : msg_fabric_phys_address=983fd000 [ 208.120000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1339) : data.back_link= (null) [ 208.150000] DD[kernel-1040] p2012_ld.c, p2012_setProcess(489) : backlink= (null) [ 208.180000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1351) : Queue has been allocated: [ 208.210000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1352) : - usrHandle: 117 [ 208.250000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1353) : - realHandle: 22 [ 208.280000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1354) : - :queue->id 22 [ 208.310000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1355) : - process: 0xd8284c00 [ 208.330000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2033) : case P2012_SEND_MSG [ 208.360000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2054) : queue_ptr=ffdc0670, from5 to 4 [ 208.390000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2055) : posIn=0, posOut=0 [ 208.420000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2077) : callback= (null) [ 208.460000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1439) : case P2012_BBQ_INIT [ 208.490000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1444) : case P2012_BBQ_INIT handle = 70500000 [ 208.530000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1445) : case P2012_BBQ_INIT size = 524288, 0x80000 [ 208.550000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2289) : vm_pgoff=460032=0x70500 [ 208.580000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2290) : offset=1884291072=0x70500000 [ 208.610000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2291) : vma_size=524288=0x80000 [ 208.640000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2323) : curr->busAddr=0x70500000 [ 208.670000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2324) : curr->userLogicalAddr=0x (null) [ 208.710000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2326) : curr->busAddr=0x70500000 [ 208.740000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2327) : curr->userLogicalAddr=0x (null) [ 208.770000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2377) : userLogicalAddr=b6714000 [ 208.800000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2378) : busAddr=0x70500000 [ 208.830000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2379) : kernelLogicalAddr=e1500000

./dumpDescriptor.sh 0x70500000 0x1DC 2

Value at address 0x705001DC (0xb6fbf1dc): 0x8 (clusters_count)
Value at address 0x705001E0 (0xb6ffa1e0): 0x10 (pes_coount)

These are still the value I can read from the device descriptor.

This, yes... the firmware has some issue with respect to BBQ integration.

I think something may have been broken recently on these aspects as they not yet automatically tested. Could you check with the new SDK and procedure if you still have the issue ? If yes, I will have to debug that, something must be wrong with the runtime. Could you sent me a binary package with BBQ that allows me to reproduce and see the issue ?

Ok, thansk!

All the required SW and tools are linked in the previous text. Hope they could be useful.

Meanwhile, I would like to ask you if you could give us access to the p12Runtime source code, so that we could possibly support you better on investigating these integration issues.

Ciao,
Germain

Ciao Patrick

Germain HAUGOU

unread,

Mar 5, 2013, 3:32:34 AM3/5/13

to Patrick Bellasi, bosp-...@googlegroups.com

Hi Patrick,

From: Patrick Bellasi [mailto:derk...@gmail.com]

Sent: Monday, March 04, 2013 6:21 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com

I’ve attached the AIDL.

Now, if we start the BarbequeRTRM daemon, the platform initialization is completed but the enumeration we get is wrong.

Unfortunately still we get a wrong enumeration:

V/bq.pp ( 1171): PLAT P2012: ... Loading platform data ...

I//vendor/modules/p2012d_dbg( 1018): p2012d_pipe.c main(305) P2012d: waiting for client (opening pipes) ... V/bq.pp ( 1171): PLAT P2012: Message queues initialized V/bq.pp ( 1171): PLAT P2012: Start notification sent V/bq.pp ( 1171): PLAT P2012: Driver initialized V/bq.pp ( 1171): PLAT P2012: Device descriptor mapped in [b6769000] V/bq.pp ( 1171): PLAT P2012: Platform initialization performed V/bq.pp ( 1171): PLAT P2012: Platform is ready I/bq.pp ( 1171): PLAT PRX: Platform [com.st.sthorm] initialization COMPLETED V/bq.ra ( 1171): Report on state view: 0 I/bq.ra ( 1171): ========================================================================= I/bq.ra ( 1171): | RESOURCES | USED | UNRESERVED | TOTAL | I/bq.ra ( 1171): |-------------------------------+-------------+---------------------------| I/bq.ra ( 1171): | sys0.acc0.grp0.io0 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp0.io1 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp0.mem0 I : 0.000e+0 | 1535.500e+9 | 1535.500e+9 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe0 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe1 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe10 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe11 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe12 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe13 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe14 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe15 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe2 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe3 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe4 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe5 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe6 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe7 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe8 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp0.pe9 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | [... entries removed for brevity ...] I/bq.ra ( 1171): | sys0.acc0.grp7.io0 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp7.io1 I : 0.000e+0 | 1849937024. | 1849937024. | I/bq.ra ( 1171): | sys0.acc0.grp7.mem0 I : 0.000e+0 | 0.000e+0 | 0.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe0 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe1 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe10 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe11 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe12 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe13 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe14 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe15 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe2 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe3 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe4 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe5 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe6 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe7 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe8 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): | sys0.acc0.grp7.pe9 I : 0.000e+0 | 100.000e+0 | 100.000e+0 | I/bq.ra ( 1171): ========================================================================= V/bq.pp ( 1171): Worker[bq.pp]: Registered V/bq.pp ( 1171): PLAT PRX: Monitoring thread STARTED

And this is the new kernel logile we get:

[ 207.410000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1593) : case P2012_P2012D_OPEN

[ 207.440000] DD[kernel-1040] p2012_ld.c, allocP2012Priv(583) : [ 207.460000] DD[kernel-1040] p2012_ld.c, p2012_initHandles(569) : [ 207.490000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1610) : p2012Priv = d8284c00 [ 207.530000] DD[kernel-1040] p2012_ld.c, p2012_allocSysQueuesPrivateHandle(1100) : p2012Priv = d8284c00 [ 207.560000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1303) : case P2012_CREATE_QUEUE from(5) to (4) [ 207.600000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(65) : sizeof(P2012_message_t)=256 [ 207.630000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(66) : nr_elem=8 [ 207.660000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(73) : msg_host_virt_address=ffda2000 [ 207.690000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(80) : msg_fabric_phys_address=983c7000 [ 207.730000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1339) : data.back_link= (null) [ 207.760000] DD[kernel-1040] p2012_ld.c, p2012_setProcess(489) : backlink= (null) [ 207.790000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1351) : Queue has been allocated: [ 207.820000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1352) : - usrHandle: 118 [ 207.860000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1353) : - realHandle: 21 [ 207.890000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1354) : - :queue->id 21 [ 207.920000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1355) : - process: 0xd8284c00 [ 207.950000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1303) : case P2012_CREATE_QUEUE from(4) to (5) [ 207.990000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(65) : sizeof(P2012_message_t)=256 [ 208.020000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(66) : nr_elem=8 [ 208.050000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(73) : msg_host_virt_address=ffda1000 [ 208.080000] DD[kernel-1040] p2012_queue_mgmt.c, allocMsgQueue(80) : msg_fabric_phys_address=983fd000 [ 208.120000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1339) : data.back_link= (null) [ 208.150000] DD[kernel-1040] p2012_ld.c, p2012_setProcess(489) : backlink= (null) [ 208.180000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1351) : Queue has been allocated: [ 208.210000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1352) : - usrHandle: 117 [ 208.250000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1353) : - realHandle: 22 [ 208.280000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1354) : - :queue->id 22 [ 208.310000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1355) : - process: 0xd8284c00 [ 208.330000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2033) : case P2012_SEND_MSG [ 208.360000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2054) : queue_ptr=ffdc0670, from5 to 4 [ 208.390000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2055) : posIn=0, posOut=0 [ 208.420000] DD[kernel-1083] p2012_ld.c, usr_ioctl(2077) : callback= (null) [ 208.460000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1439) : case P2012_BBQ_INIT [ 208.490000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1444) : case P2012_BBQ_INIT handle = 70500000 [ 208.530000] DD[kernel-1040] p2012_ld.c, p2012_daemon_ioctl(1445) : case P2012_BBQ_INIT size = 524288, 0x80000 [ 208.550000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2289) : vm_pgoff=460032=0x70500 [ 208.580000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2290) : offset=1884291072=0x70500000 [ 208.610000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2291) : vma_size=524288=0x80000 [ 208.640000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2323) : curr->busAddr=0x70500000 [ 208.670000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2324) : curr->userLogicalAddr=0x (null) [ 208.710000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2326) : curr->busAddr=0x70500000 [ 208.740000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2327) : curr->userLogicalAddr=0x (null) [ 208.770000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2377) : userLogicalAddr=b6714000 [ 208.800000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2378) : busAddr=0x70500000 [ 208.830000] DD[kernel-1083] p2012_ld.c, p2012_ld_mmap(2379) : kernelLogicalAddr=e1500000

./dumpDescriptor.sh 0x70500000 0x1DC 2

Value at address 0x705001DC (0xb6fbf1dc): 0x8 (clusters_count)
Value at address 0x705001E0 (0xb6ffa1e0): 0x10 (pes_coount)

These are still the value I can read from the device descriptor.

This, yes... the firmware has some issue with respect to BBQ integration.

I think something may have been broken recently on these aspects as they not yet automatically tested. Could you check with the new SDK and procedure if you still have the issue ? If yes, I will have to debug that, something must be wrong with the runtime. Could you sent me a binary package with BBQ that allows me to reproduce and see the issue ?

Ok, thansk!

All the required SW and tools are linked in the previous text. Hope they could be useful.

Meanwhile, I would like to ask you if you could give us access to the p12Runtime source code, so that we could possibly support you better on investigating these integration issues.

You can find the runtime sources in the SDK, in src/p12Runtime. In order to compile you can configure the SDK and execute:

make clean build package FABRIC_TYPE=xp70

Meanwhile I will also try to find the issue.

Ciao,

Germain

Ciao,
Germain

Ciao Patrick

IOcld_admin.hpp

Germain HAUGOU

unread,

Mar 5, 2013, 4:34:29 AM3/5/13

to Patrick Bellasi, bosp-...@googlegroups.com

Hi Patrick,

indeed I’ve fixed a bug in the PIL that has been recently introduced. I’ll send you a new SDK today. Meanwhile you can modify and recompile the runtime :

--- a/src/p2012/main.c

+++ b/src/p2012/main.c

@@ -569,7 +569,7 @@ int main()

// Platform descriptor

int i;

- dev->pdesc.clusters_count = p_cc->runtimeConf.rtConf.nbCluster;

+ dev->pdesc.clusters_count = 0;

dev->pdesc.pes_count = p_cc->runtimeConf.rtConf.nbPe;

for (i=0; i<P2012_MAX_FABRIC_CLUSTER_COUNT; i++) {

if (p_cc->runtimeConf.rtConf.clusterMask & (1<<i)) {

Ciao,

Germain

From: Patrick Bellasi [mailto:derk...@gmail.com]

Sent: Monday, March 04, 2013 6:21 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com

Patrick Bellasi

unread,

Mar 5, 2013, 4:55:22 AM3/5/13

to Germain HAUGOU, bosp-...@googlegroups.com

On Tue, Mar 5, 2013 at 9:32 AM, Germain HAUGOU <germain...@st.com> wrote:

Hi Germain!

By the way: do you have an AIDL already defined for this Binder interface? Could you share it with us?

I’ve attached the AIDL.

Thanks, I'll have a look on how to integrate Binder with the STHORM PIL.

AFAIK, this is a sort of "native layer" Binder interface... cool, no need to compile the high-level AIDL the way you do for android apps. Perhaps, have you already some example of a client using this interface? In case, could you share this code?

You can find the runtime sources in the SDK, in src/p12Runtime. In order to compile you can configure the SDK and execute:

make clean build package FABRIC_TYPE=xp70

Another cool news! Thanks!

Meanwhile I will also try to find the issue.

Ok thanks!

Ciao,

Germain

Ciao Patrick

Patrick Bellasi

unread,

Mar 5, 2013, 4:56:59 AM3/5/13

to Germain HAUGOU, bosp-...@googlegroups.com

On Tue, Mar 5, 2013 at 10:34 AM, Germain HAUGOU <germain...@st.com> wrote:

Hi Patrick,

Hi!

indeed I’ve fixed a bug in the PIL that has been recently introduced. I’ll send you a new SDK today.

Cool, thanks! ;-)

Meanwhile you can modify and recompile the runtime :

--- a/src/p2012/main.c
+++ b/src/p2012/main.c

@@ -569,7 +569,7 @@ int main()

     // Platform descriptor
     int i;

-    dev->pdesc.clusters_count = p_cc->runtimeConf.rtConf.nbCluster;

+    dev->pdesc.clusters_count = 0;
     dev->pdesc.pes_count = p_cc->runtimeConf.rtConf.nbPe;

     for (i=0; i<P2012_MAX_FABRIC_CLUSTER_COUNT; i++) {
       if (p_cc->runtimeConf.rtConf.clusterMask & (1<<i)) {

Sure... I'll try to deply this new runtime and check if it solves ;-)

Ciao,
Germain

Thanks again for the support!

Ciao Patrick

Patrick Bellasi

unread,

Mar 5, 2013, 5:28:22 AM3/5/13

to Germain HAUGOU, bosp-...@googlegroups.com

On Tue, Mar 5, 2013 at 10:56 AM, Patrick Bellasi <derk...@gmail.com> wrote:

--- a/src/p2012/main.c

+++ b/src/p2012/main.c

@@ -569,7 +569,7 @@ int main()

     // Platform descriptor
     int i;

-    dev->pdesc.clusters_count = p_cc->runtimeConf.rtConf.nbCluster;

+    dev->pdesc.clusters_count = 0;
     dev->pdesc.pes_count = p_cc->runtimeConf.rtConf.nbPe;

     for (i=0; i<P2012_MAX_FABRIC_CLUSTER_COUNT; i++) {
       if (p_cc->runtimeConf.rtConf.clusterMask & (1<<i)) {

Sure... I'll try to deply this new runtime and check if it solves ;-)

Cool! Finally we got BBQ talking with SThorm! ;-)

Thanks Germain: now we have all the setup ready to start to play!

Edoardo: are you ready for a MultiView test on real HW?!?

Ciao Patrick

Germain HAUGOU

unread,

Mar 5, 2013, 5:47:54 AM3/5/13

to Patrick Bellasi, bosp-...@googlegroups.com

I must admit this was quite painful to handle this binder part in the native part because this functionality is not visible in the Android NDK (on purpose). As this should be used only by the framework, this mean that you need the Android sources in order to compile the part that will interact with the OpenCL daemon. Is it an issue for you ?

If yes, what I can do is to hide the binder stuff behind a C api within a classic shared library, that you can call from BBQ. This is already what I did for OpenCL applications that want to connect to the OCL runtime. The binder stuff is hidden within the OpenCL library.

Bye,

Germain

From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Tuesday, March 05, 2013 10:55 AM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Integration issue - SDK v2013.1 - p12Runtime not properly initializing the platform descriptor

On Tue, Mar 5, 2013 at 9:32 AM, Germain HAUGOU <germain...@st.com> wrote:

Patrick Bellasi

unread,

Mar 5, 2013, 6:16:13 AM3/5/13

to Germain HAUGOU, bosp-...@googlegroups.com

On Tue, Mar 5, 2013 at 11:47 AM, Germain HAUGOU <germain...@st.com> wrote:

I must admit this was quite painful to handle this binder part in the native part because this functionality is not visible in the Android NDK (on purpose).

I know, indeed Binder is considered an "internal" API in Android... not exposed to developers since it could be subject to internal modifications which are always masked to applications thanks to the Java API.

As this should be used only by the framework, this mean that you need the Android sources in order to compile the part that will interact with the OpenCL daemon. Is it an issue for you ?

Well, let say that we aims to have all BBQ compilation dependencies tracked by the BOSP building system. Thus, to interact with Binder we have two possibilities:

1. reference a local installation of the Android sources, something similar to what we already do with the STHORM SDK

2. keep track of the Binder sources on a BOSP tracked "external" repository, something similar to what we do for other dependencies, e.g. Boost libs, etc.

Daniele Rogora, the student that worked previously on Binder integration, adopter the second option.

This allows to keep track of just the sources needed to access Binder. You could see an example in this patch:

https://bitbucket.org/dodoeg/barbeque-binder/commits/4b6915d74902869fc3a15df590657dda7c9b47ae

Probably, this is a quite boring approach... we have to maintain the local sources aligned with every and each new version of Android being released.

Thus, probably solution 1 is the best one... perhaps we just need to check if it is possible to clone not all the Android sources bu just the Binder related code... maybe it is possible, I'll check for that and let you know! ;-)

If yes, what I can do is to hide the binder stuff behind a C api within a classic shared library, that you can call from BBQ.

That's good as well... however, still we (especially you) have the problem to always track all the Android source tree just to build the STHORM software.

This is already what I did for OpenCL applications that want to connect to the OCL runtime. The binder stuff is hidden within the OpenCL library.

I see, of course this is a solution to be evaluated...

However, since this will require to develop some wrapping code I'm wondering if it is not worth to have a plain FIFO interface. We should consider that Binder, yes it is designed to be more efficient, but it is also targeting quite complex communication scenarios. If we just need to send simple messages between a couple of process... probably a FIFO based implementation has a much lower run-time overhead and it is even more efficient.

To be verified, but I remember that when I was reviewing the work done by Daniel, I had the impression to end with a quite wired solution without any real benefit.

Binder is ok for Android internal code, i.e. code mainlined into the Android source tree, but until we are developing an aside project, is much more a pain than a benefit.

What do you think?

Bye,

Germain

Ciao Patrick

Germain HAUGOU

unread,

Mar 5, 2013, 7:28:23 AM3/5/13

to Patrick Bellasi, bosp-...@googlegroups.com

I think we should go for a C wrapper, I already have the shared library, it should take one hour to add the call to the binder for the daemon config. Tell me if it is fine so that I add it.

Ciao,

Germain

From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Tuesday, March 05, 2013 12:16 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Integration issue - SDK v2013.1 - p12Runtime not properly initializing the platform descriptor

On Tue, Mar 5, 2013 at 11:47 AM, Germain HAUGOU <germain...@st.com> wrote:

Patrick Bellasi

unread,

Mar 5, 2013, 8:14:38 AM3/5/13

to Germain HAUGOU, bosp-...@googlegroups.com

On Tue, Mar 5, 2013 at 1:28 PM, Germain HAUGOU <germain...@st.com> wrote:

I think we should go for a C wrapper, I already have the shared library, it should take one hour to add the call to the binder for the daemon config. Tell me if it is fine so that I add it.

Ok, if it is really so simple, let go for this solution. At least for the time being, it is for sure the straightway to have a complete functional demo.

We are already linking the p2012.so, do you think it could be convenient to expose this wrapper by this library, or do you prefer to have a second shared object?

Ciao,
Germain

Thanks,

Patrick

Reply all

Reply to author

Forward