[STHORM] Updates on new SDK
Patrick Bellasi
#include <best/regards.h>
Patrick Bellasi
Post-Doc at Politecnico di Milano
http://home.dei.polimi.it/bellasi
Germain HAUGOU
Hi Patrick,
sorry to answer now, I was sick today.
Could you send me the multiview binary, I will try on my side ?
For the second problem, maybe we have broken something, we have made some clean-up recently in the driver. I will add a test for that in our testsuite to check what’s wrong and make sure this does not happen anymore.
Ciao,
Germain
Patrick Bellasi
sorry to answer now, I was sick today.
Could you send me the multiview binary, I will try on my side ?
For the second problem, maybe we have broken something, we have made some clean-up recently in the driver. I will add a test for that in our testsuite to check what’s wrong and make sure this does not happen anymore.
Ciao,
Germain
Germain HAUGOU
Sent: Wednesday, March 27, 2013 8:30 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Wed, Mar 27, 2013 at 7:36 PM, Germain HAUGOU <germain...@st.com> wrote:
Hi Patrick,
Hi Germain!
sorry to answer now, I was sick today.
No problems... we have some many open branches right now that we can easily switch from one bug to another without risk to became bored ;-)
Rather, best wishes for your health... hope it's not Italy side-effects :-]
In fact I came back to France for 1 week, maybe I’m missing Italy !
Could you send me the multiview binary, I will try on my side ?
You could download from this link:
an archive which, once decompressed, contains a "bosp" folder to be pushed under the "/data" folder of your device.
This bosp folder contains both BBQ and MView, ready to run.
You could run BBQ the usual way:
$ adb shell /data/bosp/sbin/barbeque
while, to run MView, you could use this command:
$ adb shell \
LD_PRELOAD=/data/bosp/lib/bbque/libbbque_rtlib.so \
OCL_KERNELS_PATH=/data/bosp/mview0/ \
/data/bosp/mview0/mview_ahead \
--max_hypo_value=18 --num_cycles=10
PLEASE NOTICE:
1. the ending "/" in the definition of the OCL_KERNELS_PATH... this probably should be fixed in SThorm OCL runtime?
I think this variable is used by liboclUtils.so which is not really maintained. Edoardo should based multiview directly on top the OCL runtime to avoid this environment variable.
2. if you run BBQ... the board craches... however, you could still run the MView application until the point it stucks waiting for the OCL deamon
It seems to work, here what I get:
/mview_ahead --max_hypo_value=18 --num_cycles=10
connect: Connection refused
Executing StereoMatch Kernel on P2012 with configuration:
- MAX_HYPO_VALUE 18
- HYPO_STEP 2
- MAX_ARM_LENGTH 16
- CONFIDENCE_COLOR_SIM 30
- MATCH_COST_TRUNC_LIMIT 60
- GRAY_SCALE 16
- NB_WI_PER_WG 16
- NB_HYPO_PER_WG 4
- NB_WTA_WORKGROUPS 4
- WG_COL_PIXEL_WIDTH 80
Acquisition image size (HxW) from file /data/bosp/mview/tsukuba/i_right.bmp
Successfully opened /data/bosp/mview/tsukuba/i_right.bmp, [12, 40], 288 x 384
Acquisition of right image from file /data/bosp/mview/tsukuba/i_right.bmp
Successfully opened /data/bosp/mview/tsukuba/i_right.bmp, [12, 40], 288 x 384
Acquisition of left image from file /data/bosp/mview/tsukuba/i_left.bmp
Successfully opened /data/bosp/mview/tsukuba/i_left.bmp, [12, 40], 288 x 384
Acquisition of reference disparity map from file /data/bosp/mview/tsukuba/i_truth.bmp
Successfully opened /data/bosp/mview/tsukuba/i_truth.bmp, [12, 40], 288 x 384
>> OpenCL stereo-matching initialization
Unable to open file: /data/test/clProf.csv: No such file or directory
>> OpenCL stereo-matching configuration
- Allocated 36864 bytes local memory to WinBuild kernel
- Allocated 36864 bytes local memory to WinBuild kernel
- Allocated 178944 bytes local memory to CostAggreg kernel
- Allocated 51200 bytes local memory to FinalDecision kernel
- Allocated 70144 bytes local memory to Refinement kernel
>> OpenCL stereo-matching execution (frame 0)
>> OpenCL stereo-matching execution (frame 1)
>> OpenCL stereo-matching execution (frame 2)
>> OpenCL stereo-matching execution (frame 3)
>> OpenCL stereo-matching execution (frame 4)
>> OpenCL stereo-matching execution (frame 5)
>> OpenCL stereo-matching execution (frame 6)
>> OpenCL stereo-matching execution (frame 7)
>> OpenCL stereo-matching execution (frame 8)
>> OpenCL stereo-matching execution (frame 9)
Metric disper : 1.013410
Metric pixels : 110592.000000
Writing result: /data/bosp/mview/tsukuba/images/i_0.bmp
Failed to store RGB image to file /data/bosp/mview/tsukuba/images/i_0.bmp
>> OpenCL stereo-matching release
Although I get this message from BBQ:
***** - INFO bq : Starting BBQ (ver. 2PARMA_UC6_v0.2.2-148-g866fa72)...
***** - INFO bq : BarbequeRTRM build time: Mar 4 2013 11:56:30
***** - INFO bq : flavor: Android-Linux (32bit - Release)
***** - INFO bq : compiler: gcc v.
***** - INFO bq : Loading plugins from dir [/data/bosp/lib/bbque/plugins]...
***** - ERROR bq.dl : FAILED loading [/data/bosp/lib/bbque/plugins/libbbque_schedpol_random.so], Error:
Cannot load library: reloc_library[1285]: 1334 cannot locate '_ZN5boost15program_options19options_descriptionC1ERKSsjj'...
***** - ERROR bq.pm : [libbbque_schedpol_random.so] library load ERROR:
Cannot load library: reloc_library[1285]: 1334 cannot locate '_ZN5boost15program_options19options_descriptionC1ERKSsjj'...
***** - ERROR bq.pm : Plugin [libbbque_schedpol_random.so] is not a valid dynamic library
***** - INFO bq.rm : Registering Worker[bq.df.am.cln]...
***** - INFO bq.ps : Loading configuration for system service [bq.rl.xml]...
***** - INFO bq.rl.xml : Using XMLRecipeLoader recipe folder [/data/bosp/etc/bbque/recipes]
***** - INFO bq.cm : CMD MNGR: using dir [/data/bosp/var]
***** - INFO bq.rm : Registering Worker[bq.cm]...
***** - INFO bq.ps : Loading configuration for system service [bq.rpc.fif]...
***** - INFO bq.rpc.fif : FIFO RPC: using dir [/data/bosp/var]
***** - INFO bq.rm : Registering Worker[bq.rpc]...
***** - INFO bq.rm : Registering Worker[bq.ap]...
***** - INFO bq.rm : Registering Worker[bq.df.rm.opt]...
***** - INFO bq.rm : Registering Worker[bq.pp]...
For the second problem, maybe we have broken something, we have made some clean-up recently in the driver. I will add a test for that in our testsuite to check what’s wrong and make sure this does not happen anymore.
Good to know, thanks! ;-)
I wrote this test, this is also working on my side. I think there was something wrong with the procedure for formatting the SDCARD. The fact BBQ is stuck getting the page seems to indicate the Linux driver is not in a good state. Could you send me the result of the “dmesg” command. Meanwhile you can try a different procedure for uploading the SDK:
p12run --platform=sthorm --sthorm-steps=”stop sw run”
This will stop the runtime, upload the one from the SDK and restart things.
Meanwhile, I've noticed that in the really last SDK and SDCard image, you mount "/data" under tmpfs... we use this folder to deploy BBQ, thus now we are forced to re-deploy it everything with power-on the board. Maybe we should target a different and more stable deployment path, any suggestion?
Indeed I think it is better if you deploy it inside /vendor. You should also put your library under /vendor/lib, so that you don’t need to define LD_PRELOAD. For that you will have to remount / writable with these commands:
adb shell mount -o remount,rw /
adb push bosp /vendor/bosp
adb shell sync
adb shell mount -o remount,ro /
If it can simplify things, we can modify p12run to include these kind of features.
I don’t remember why Manuele has decided to put /data under tmpfs, I will check with him.
Finally, if you need to run a pre-compiled version of BBQ the fast way possible, have a look at this:
and let me know you feedbacks ;-)
Ciao,
Germain
Ciao Patrick
Patrick Bellasi
I wrote this test, this is also working on my side.
I think there was something wrong with the procedure for formatting the SDCARD. The fact BBQ is stuck getting the page seems to indicate the Linux driver is not in a good state. Could you send me the result of the “dmesg” command. Meanwhile you can try a different procedure for uploading the SDK:
p12run --platform=sthorm --sthorm-steps=”stop sw run”
This will stop the runtime, upload the one from the SDK and restart things.
Meanwhile, I've noticed that in the really last SDK and SDCard image, you mount "/data" under tmpfs... we use this folder to deploy BBQ, thus now we are forced to re-deploy it everything with power-on the board. Maybe we should target a different and more stable deployment path, any suggestion?
Indeed I think it is better if you deploy it inside /vendor. You should also put your library under /vendor/lib, so that you don’t need to define LD_PRELOAD. For that you will have to remount / writable with these commands:
adb shell mount -o remount,rw /
adb push bosp /vendor/bosp
adb shell sync
adb shell mount -o remount,ro /
If it can simplify things, we can modify p12run to include these kind of features.
I don’t remember why Manuele has decided to put /data under tmpfs, I will check with him.
By the way, I report that I'm experiencing continuously a minor but annoying problem: if the Ethernet cable is not already connected when you boot the board, the ADB connect alwasy fails. I've to reboot the board with the cable plugged in... in that case ADB connect, almost always, succeed...
Germain HAUGOU
Hi Patrick,
I attached the test I used to check the page is accessible. You can run it with:
make clean all run PLT_TYPE=sthorm
I will send you a new SDK that allows dumping runtime traces, I hope we will identify something’s wrong with these traces. You have to install the SDK and activate runtime traces with this command:
p12run --platform=sthorm --sthorm-steps=”stop sw run” --rt-trace=1000
The best is that you connect a terminal to the UART so that we see the very last traces just before it crashes.
Then also try with driver traces:
p12run --platform=sthorm --sthorm-steps=”stop sw run” --dd-trace=10
Can you try and send me the output ?
By the way, can we meet next week for a debug session ? The best for me is Wednesday, I can come early in the morning so that we all the day to debug your issues.
For the network, we have lot of issues with it, I’m not surprised about your issue, but there is nothing to do I think.
Bye,
Germain
From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Thursday, March 28, 2013 11:25 AM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Wed, Mar 27, 2013 at 9:34 PM, Germain HAUGOU <germain...@st.com> wrote:
Patrick Bellasi
I attached the test I used to check the page is accessible. You can run it with:
make clean all run PLT_TYPE=sthorm
I will send you a new SDK that allows dumping runtime traces, I hope we will identify something’s wrong with these traces. You have to install the SDK and activate runtime traces with this command:
p12run --platform=sthorm --sthorm-steps=”stop sw run” --rt-trace=1000
The best is that you connect a terminal to the UART so that we see the very last traces just before it crashes.
Then also try with driver traces:
p12run --platform=sthorm --sthorm-steps=”stop sw run” --dd-trace=10
Can you try and send me the output ?
By the way, can we meet next week for a debug session ? The best for me is Wednesday, I can come early in the morning so that we all the day to debug your issues.
For the network, we have lot of issues with it, I’m not surprised about your issue, but there is nothing to do I think.
Bye,
Germain
Germain HAUGOU
Hi Patrick,
indeed in case the board become totally inaccessible, the best is that you format again the SDCARD. Meanwhile I will try to improve this issue, I think this is coming from the fact that OpenCL runtime and Linux drivers are automatically started.
Ciao,
Germain
From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Friday, March 29, 2013 10:09 AM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Thu, Mar 28, 2013 at 5:20 PM, Germain HAUGOU <germain...@st.com> wrote:
Germain HAUGOU
Hi Patrick,
I’ve sent you a new SDK with a few improvments, we’ll use It on Wednesday. Meanwhile, if you want to try you can reformat the sdcard by hands with the image that I’ve sent you a few days ago using this command:
dd if=<path to image> of=<sdcard dev>
The SDCARD must not be mounted.
Then you can boot the board and check that the system is working well. At this point there should not be any P2012 soft running. Then you can execute the following command to upload the SDK while the system is running:
p12run --platform=sthorm --sthorm-steps="stop sw run"
Ciao,
Germain
From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Friday, March 29, 2013 10:09 AM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Thu, Mar 28, 2013 at 5:20 PM, Germain HAUGOU <germain...@st.com> wrote:
Patrick Bellasi
I’ve sent you a new SDK with a few improvments, we’ll use It on Wednesday. Meanwhile, if you want to try you can reformat the sdcard by hands with the image that I’ve sent you a few days ago using this command:
dd if=<path to image> of=<sdcard dev>
The SDCARD must not be mounted.
Then you can boot the board and check that the system is working well. At this point there should not be any P2012 soft running.
Then you can execute the following command to upload the SDK while the system is running:
p12run --platform=sthorm --sthorm-steps="stop sw run"
Ciao,
Germain
Germain HAUGOU
From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Tuesday, April 02, 2013 10:44 AM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Mon, Apr 1, 2013 at 11:00 PM, Germain HAUGOU <germain...@st.com> wrote:
Something was wrong with the packaging, I will fix that. Meanwhile you can edit env/setup.sh and put the following line:
#!/bin/bash
# Assume base package dir is one level up from this script
scriptDir="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"
export STHORM_SDK_HOME="$(dirname $scriptDir)"
You will still get an error but this should work.
Ciao,
Germain
Ciao Patrick
Patrick Bellasi
#!/bin/bash
# Assume base package dir is one level up from this script
scriptDir="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"
export STHORM_SDK_HOME="$(dirname $scriptDir)"
You will still get an error but this should work.
Germain HAUGOU
You’re right let’s see that tomorrow. For tomorrow, I can arrive between 9 and 9.30am, is it fine ? Could you tell me where we meet ?
Ciao,
Germain
From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Tuesday, April 02, 2013 12:55 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Tue, Apr 2, 2013 at 11:53 AM, Germain HAUGOU <germain...@st.com> wrote:
Patrick Bellasi
You’re right let’s see that tomorrow. For tomorrow, I can arrive between 9 and 9.30am, is it fine ? Could you tell me where we meet ?
Ciao,
Germain
Germain HAUGOU
Thanks see you tomorrow !
Germain
From: Patrick Bellasi [mailto:derk...@gmail.com]
Sent: Tuesday, April 02, 2013 2:10 PM
To: Germain HAUGOU
Cc: bosp-...@googlegroups.com
Subject: Re: [STHORM] Updates on new SDK
On Tue, Apr 2, 2013 at 12:56 PM, Germain HAUGOU <germain...@st.com> wrote: