I start this again if a cooker wanna test the new values
Sorry for the title I just love Chopin
Sick of contacting the I-mate support team with no help, and no reply from HTC and Samsung, Microsoft is telling me to contact HTC, so again to the same circle.
I want to share my last idea about prophet before I do the last decision I made.
I always thought that is the low frame rate in prophet camera is because the DMA so if someone help me in this please.
I think the functions related to this issue are (aCamreaDMA and CameraInterface) and it could be fixed or at least improved debugging the file s5k3bafx.dll that contains the functions for the Samsung chip.
Code:
.text:10002018 ; ---------------------------------------------------------------------------
.text:10002018 CMP R4, #1
.text:1000201C BNE loc_100020C0
.text:10002020 LDR R3, =aCameradma
.text:10002024 MOV R2, #0
.text:10002028 MOV R1, #0
.text:1000202C MOV R0, #0
.text:10002030 BL CreateEventW
.text:10002034 ; ---------------------------------------------------------------------------
.text:10002034 CMP R0, #0
.text:10002038 STR R0, [R5,#0x10]
.text:1000203C BEQ loc_10002070
.text:10002040 MOV R1, #2
.text:10002044 BL EventModify
.text:10002048 ; ---------------------------------------------------------------------------
.text:10002048 LDR R1, [R5,#0x10]
.text:1000204C MOV R3, #0
.text:10002050 MOV R2, #0
.text:10002054 MOV R0, #0x1F
.text:10002058 BL InterruptInitialize
.text:1000205C ; ---------------------------------------------------------------------------
.text:1000205C CMP R0, #1
.text:10002060 BNE loc_10002070
.text:10002064 MOV R0, #0x1F
.text:10002068 BL InterruptDone
.text:1000206C ; ---------------------------------------------------------------------------
.text:1000206C MOV R6, #1
.text:10002070
.text:10002070 loc_10002070 ; CODE XREF: .text:1000203Cj
.text:10002070 ; .text:10002060j
.text:10002070 LDR R3, =aCamerainterfac
.text:10002074 MOV R2, #0
.text:10002078 MOV R1, #0
.text:1000207C MOV R0, #0
.text:10002080 BL CreateEventW
.text:10002084 ; ---------------------------------------------------------------------------
.text:10002084 CMP R0, #0
.text:10002088 STR R0, [R5,#0x50]
.text:1000208C BEQ loc_10002108
.text:10002090 MOV R1, #2
.text:10002094 BL EventModify
.text:10002098 ; ---------------------------------------------------------------------------
.text:10002098 LDR R1, [R5,#0x50]
.text:1000209C MOV R3, #0
.text:100020A0 MOV R2, #0
.text:100020A4 MOV R0, #0x2B
.text:100020A8 BL InterruptInitialize
.text:100020AC ; ---------------------------------------------------------------------------
.text:100020AC CMP R0, #1
.text:100020B0 BNE loc_10002108
.text:100020B4 MOV R0, #0x2B
.text:100020B8 BL InterruptDone
.text:100020BC ; ---------------------------------------------------------------------------
.text:100020BC B loc_10002104
.text:100020C0 ; ---------------------------------------------------------------------------
.text:100020C0
.text:100020C0 loc_100020C0 ; CODE XREF: .text:1000201Cj
.text:100020C0 LDR R3, [R5,#0x10]
.text:100020C4 MOV R4, #0
.text:100020C8 CMP R3, #0
.text:100020CC BEQ loc_100020DC
.text:100020D0 MOV R0, R3
.text:100020D4 BL CloseHandle
.text:100020D8 ; ---------------------------------------------------------------------------
.text:100020D8 STR R4, [R5,#0x10]
.text:100020DC
.text:100020DC loc_100020DC ; CODE XREF: .text:100020CCj
.text:100020DC MOV R0, #0x1F
.text:100020E0 BL InterruptDisable
.text:100020E4 ; ---------------------------------------------------------------------------
.text:100020E4 LDR R3, [R5,#0x50]
.text:100020E8 CMP R3, #0
.text:100020EC BEQ loc_100020FC
.text:100020F0 MOV R0, R3
.text:100020F4 BL CloseHandle
.text:100020F8 ; ---------------------------------------------------------------------------
.text:100020F8 STR R4, [R5,#0x50]
.text:100020FC
.text:100020FC loc_100020FC ; CODE XREF: .text:100020ECj
.text:100020FC MOV R0, #0x2B
.text:10002100 BL InterruptDisable
.text:10002104 ; ---------------------------------------------------------------------------
.text:10002104
.text:10002104 loc_10002104 ; CODE XREF: .text:100020BCj
.text:10002104 MOV R6, #1
.text:10002108
.text:10002108 loc_10002108 ; CODE XREF: .text:1000208Cj
.text:10002108 ; .text:100020B0j
.text:10002108 MOV R0, #0
.text:1000210C BL SetKMode
.text:10002110 ; ---------------------------------------------------------------------------
.text:10002110 MOV R0, R6
.text:10002114 LDMFD SP!, {R4-R6,LR}
.text:10002118 BX LR
.text:10002118 ; ---------------------------------------------------------------------------
.text:1000211C off_1000211C DCD aCamerainterfac ; DATA XREF: .text:loc_10002070r
.text:1000211C ; "CameraInterface"
.text:10002120 off_10002120 DCD aCameradma ; DATA XREF: .text:10002020r
.text:10002120 ; "CameraDMA"
I think if we change the constant value at loc text:10002038 and text:10002088 and all related values (0x10, 0x50 to R5; register will be load to memory) will improve the DMA transfer from the camera chip to the device RAM, and will load less CPU make it faster.
Please help in this, how to improve the S5K3BAFX.dll driver and DMA compatibility with HTC prophet.
For ROM cookers:
The hex values need to be changed from (10 to 2C, 50 to 88) in the module S5K3BAFX.dll.
Version 2.15, the file need to be modify S000 the offsets are: 1050, 1060, 10A0, 10B0, 10D8, 10F0, 10FC, 1110.
Version 2.20 (the module in the AKU2.2 I'll attach it as it provide better picture but can't over clock the CPU) the offsets in S000 are: 1038, 1048, 1088, 1098, 10C0, 10D8, 10E4, 10F8.
I'm not sure about the 2C and 88 values, if someone can help to improve the camera DMA.
is there anything i can try to modify?
Some fixes:
- dmesg
Code:
<6>[ 1.044134] pmem_camera: 1 init
- mem
Code:
static struct android_pmem_platform_data pmem_camera_pdata = {
.name = "pmem_camera",
.no_allocator = 0,
//cardsharing
// .cached = 0,
.cached = 1,
};
no more physical address error, but somethink is not ok with jpegtask
Code:
<6>[ 194.591656] pmem: successful request for physical address of pmem region id 1, offset 650190848, len 524288
<6>[ 194.591716] pmem: successful request for physical address of pmem region id 2, offset 661762048, len 6721536
<6>[ 194.612419] adsp_open() name = 'JPEGTASK'
<6>[ 194.612514] adsp: opening module JPEGTASK
<6>[ 194.613648] adsp: module JPEGTASK has been registered
<6>[ 194.613674] adsp_open() module 'JPEGTASK' adev e4978e84
<6>[ 194.613708] msm_adsp_enable() 'JPEGTASK'state[0] id[42]
<6>[ 194.614464] adsp: rpc event=0, proc_id=2, module=42, image=0
<6>[ 194.614748] adsp: module JPEGTASK: READY
<6>[ 194.615379] pmem: successful request for physical address of pmem region id 1, offset 649142272, len 4096
<6>[ 194.615554] pmem: successful request for physical address of pmem region id 1, offset 649146368, len 4096
<6>[ 194.615603] adsp_pmem_add module JPEGTASK vaddr:0x41168000 paddr:0x26b12000 len:4096
<6>[ 194.615633] adsp_pmem_add module JPEGTASK vaddr:0x4116c000 paddr:0x26b13000 len:4096
<6>[ 194.615801] adsp_pmem_add module JPEGTASK vaddr:0x41ffc000 paddr:0x26c12000 len:524288
<3>[ 194.615836] module JPEGTASK: verify failed.
maybe you have idea!
I think problem with: camera (jpeg), youtube (high def video) , but all working (output way), but not working (input way), is becouse we have something wrong with user space (maybe problem with permisions!), or maybe need corection for memory mapping!
I've tried to fix cammera, and I know bug is inside when camera catcing picture from jpeg task (input way not working, but output way working). Also, I know when youtube catching "high def video" (input way), something is not ok with "codecs" or "user space" or "memmory map"... maybe you have idea?
I think fixing cam bug will fix all (youtube...etc)
EDIT:
See this:
Code:
<6>[ 194.615801] adsp_pmem_add module JPEGTASK vaddr:0x41ffc000 paddr:0x26c12000 len:524288
Why len is 524288? Picture have size > 3-4M, maybe it cause problem with jpegtask verify??
about video and youtube problem in codecs
about camera problem in memory map
I think problem is in msm_adsp.h, adsp.c, adsp.h and adsp_photon.c
something is not ok there (I think wrong in adsp_photon.c != msm_adsp.h!) becouse I see in dmesg from int adsp_video_verify_cmd() warning about "unknown video queue"... from code:
Code:
int adsp_video_verify_cmd(struct msm_adsp_module *module,
unsigned int queue_id, void *cmd_data,
size_t cmd_size)
{
switch (queue_id) {
case QDSP_mpuVDecPktQueue:
DLOG("\n");
return verify_vdec_pkt_cmd(module, cmd_data, cmd_size);
default:
printk(KERN_INFO "unknown video queue %u\n", queue_id);
return 0;
}
}
and from it I know QDSP_mpuVDecPktQueue is not used, so I think we have problem in adsp_photon.c and need to realign it like defined in msm_adsp.h!!!
I dumped something, maybe help here:
Code:
<4>[ 0.972350] adsp: module name=AUDPLAY0TASK, module id=2, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDPLAY0TASK, pdev id=-1, id_to_module=e4979000
<4>[ 0.972588] adsp: module name=AUDPPTASK, module id=7, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDPPTASK, pdev id=-1, id_to_module=e4979148
<4>[ 0.972741] adsp: module name=AUDRECTASK, module id=19, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDRECTASK, pdev id=-1, id_to_module=e4979290
<4>[ 0.972886] adsp: module name=AUDPREPROCTASK, module id=20, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_AUDPREPROCTASK, pdev id=-1, id_to_module=e49793d8
<4>[ 0.973040] adsp: module name=VFETASK, module id=31, mod clk=vfe_clk, verify cmd=c0143330, patch event=c01437f4, pdev name=adsp_VFETASK, pdev id=-1, id_to_module=e4979520
<4>[ 0.973183] adsp: module name=QCAMTASK, module id=43, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_QCAMTASK, pdev id=-1, id_to_module=e4979668
<4>[ 0.973330] adsp: module name=JPEGTASK, module id=42, mod clk=vdc_clk, verify cmd=c0142f0c, patch event=c01432d4, pdev name=adsp_JPEGTASK, pdev id=-1, id_to_module=e49797b0
<4>[ 0.973568] adsp: module name=VIDEOTASK, module id=9, mod clk=vdc_clk, verify cmd=c01429c0, patch event=0, pdev name=adsp_VIDEOTASK, pdev id=-1, id_to_module=e49798f8
<4>[ 0.973713] adsp: module name=VDEC_LP_MODE, module id=48, mod clk=<NULL>, verify cmd=0, patch event=0, pdev name=adsp_VDEC_LP_MODE, pdev id=-1, id_to_module=e4979a40
<4>[ 0.973901] adsp: module name=VIDEOENCTASK, module id=30, mod clk=vdc_clk, verify cmd=c0142bd8, patch event=0, pdev name=adsp_VIDEOENCTASK, pdev id=-1, id_to_module=e4979b88
And yes, cammera jpegtask have problem with memory map, but video have problem in adsp!
may be ,video with another player with codecs work good
http://gitorious.org/linux-on-qualcomm-s-msm/linux-msm/blobs/htc-msm-2.6.27/arch/arm/mach-msm/pmem.c
this file had camera pmem calc
i think this is help with with
NOTE: need edits in devices_htc.c/.h
NOTE2: Camera Snapshot work only in Fast Burst Camera
Ok I will try! Please see this -> http://forum.xda-developers.com/showpost.php?p=16448252&postcount=4
camera
Hi !
sorry for my English, but someone has a solution for a problem with camera in hd mini ? I try the android r134 FANTASTIC, but no photos some one can help me?
tanks
No reason do make doubbleposts.
As you can see in this thread, they are working on it.
Its still "under construction"
something interesting from strace
Code:
writev(3, [{"\4", 1}, {"GPhoto\0", 7}, {"Sd-card availableSize = 5673\0", 29}], 3) = 37
syscall_983042(0x43904738, 0x4390473c, 0, 0x4390473c, 0xaca8c3f4, 0x438f70cf, 0x434, 0xf0002, 0, 0x40041858, 0xcd80, 0xbe9e4700, 0, 0xbe9e43f0, 0xaca64fc7, 0xafd0ec8c, 0x8000010, 0x43904738, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) = 0
Code:
recv(52740, 0x80, 4294966774, MSG_WAITALL|MSG_TRUNC|MSG_DONTWAIT|MSG_PROBE|MSG_FIN|MSG_NOSIGNAL|0xbe9e0000) = -1 ETIMEDOUT (Connection timed out)
TIMEDOUT !! I don't know where is timedout, hmmm FUTEX??? Also I seen in dmesg always diferent size in bank_1 but it's defined static !!
this adress 0xbe9e0000 don't responding
I found something! Curently error come from msm_camera.c (see dmesg.log) "msm_put_stats_buffer: NULL physical address"!!!
Two functions:
first:
Code:
static int msm_put_stats_buffer(struct msm_sync *sync, void __user *arg)
{
int rc = -EIO;
struct msm_stats_buf buf;
unsigned long pphy;
struct msm_vfe_cfg_cmd cfgcmd;
if (copy_from_user(&buf, arg,
sizeof(struct msm_stats_buf))) {
ERR_COPY_FROM_USER();
return -EFAULT;
}
CDBG("%s\n", __func__);
pphy = msm_pmem_stats_vtop_lookup(sync, buf.buffer, buf.fd);
if (pphy != 0) {
if (buf.type == STAT_AEAW)
cfgcmd.cmd_type = CMD_STATS_BUF_RELEASE;
else if (buf.type == STAT_AF)
cfgcmd.cmd_type = CMD_STATS_AF_BUF_RELEASE;
else {
pr_err("%s: invalid buf type %d\n",
__func__,
buf.type);
rc = -EINVAL;
goto put_done;
}
cfgcmd.value = (void *)&buf;
if (sync->vfefn.vfe_config) {
rc = sync->vfefn.vfe_config(&cfgcmd, &pphy);
if (rc < 0)
pr_err("%s: vfe_config error %d\n",
__func__, rc);
} else
pr_err("%s: vfe_config is NULL\n", __func__);
} else {
pr_err("%s: NULL physical address\n", __func__);
rc = -EINVAL;
}
put_done:
return rc;
}
In second function I added (see dmesg.log!) printk, and I see vaddr and buffer addr sometimes is ===, sometimes !== so it need to be fixed but hmmm where??? I not have idea , maybe you have idea:
Code:
static unsigned long msm_pmem_stats_vtop_lookup(
struct msm_sync *sync,
unsigned long buffer,
int fd)
{
struct msm_pmem_region *region;
struct hlist_node *node, *n;
hlist_for_each_entry_safe(region, node, n, &sync->pmem_stats, list) {
printk("ADSP TEST: region->info.vaddr(0x%08lx)==(0x%08lx)buffer, region->info.fd(%d)==(%d)fd, region->info.vfe_can_write(%d)==0\n",
((unsigned long)(region->info.vaddr)), buffer, region->info.fd, fd, region->info.vfe_can_write);
if (((unsigned long)(region->info.vaddr) == buffer) &&
(region->info.fd == fd) &&
region->info.vfe_can_write == 0) {
region->info.vfe_can_write = 1;
return region->paddr;
}
}
return 0;
}
As you see some memory regions is not writeable becouse region->info.vaddr !== buffer
i don't think so
i think problem in s5k4e1gx.c
Code:
{ /*Snapshot*/
0x06, /* pre_pll_clk_div REG=0x0305 */
0x00, /* pll_multiplier_msb REG=0x0306 */
0x50, /* pll_multiplier_lsb REG=0x0307 */
0x00, /* vt_sys_clk_div REG=0x30B5 */
0xB0, /* DPHY_bandctrl REG=0x30F1 */
0x00, /* read_mode REG=0x0101 */
0x0A, /* x_output_size_msb REG=0x034C */
0x30, /* x_output_size_lsb REG=0x034D */
0x07, /* y_output_size_msb REG=0x034E */
0xA8, /* y_output_size_lsb REG=0x034F */
0x01, /* x_even_inc REG=0x0381 */
0x01, /* x_odd_inc REG=0x0383 */
0x01, /* y_even_inc REG=0x0385 */
0x01, /* y_odd_inc REG=0x0387 */
0x03, /* h_binning REG=0x30A9 */
0xE8, /* v_binning REG=0x300E */
0x07, /* frame_length_lines_msb REG=0x0340 */
0xB4, /* frame_length_lines_lsb REG=0x0341 */
0x0A, /* line_length_pck_msb REG=0x0342 */
0xB2, /* line_length_pck_lsb REG=0x0343 */
0x10, /* pclk_inv; REG=0x3110 */
0x0C, /* pclk_delay; REG=0x3117 */
0x0A, /* v_h_strength; REG=0x3119 */
0xAA, /* data_pclk_strength; REG=0x311A */
0x82, /* cds_test REG=0x300F */
0xC0, /* rst_offset1 REG=0x3013 */
0xA4, /* rmp_init REG=0x3017 */ /*0x94*/
0x88, /* comp_bias REG=0x301B */ /*0x71*/
0x00, /* analogue_gain_code_global_msb REG=0x0204 */
0x80, /* analogue_gain_code_global_lsb REG=0x0205 */
0x07, /* coarse_integration_time_msb REG=0x0202 */
0xA8, /* coarse_intergation_time_lsb REG=0x0203 */
1960, /* size_h */
12, /* blk_l*/
2608, /* size_w*/
130 /* blk_p*/
}
};
or may be
static int msm_divert_snapshot(struct msm_sync *sync,
in msm_camera
Ok maybe! But as you see region->info.vaddr !== buffer ...some offsets differs there and I don't know what cause it or where I need to search Maybe haret not cleaned completely some memory regions?
i try to research diffs in leo kernel
only find time fix
Maked some tests and I confirm we have problem in queue_id and it need to be fixed in photon_adsp.c or msm_adsp.h... see dmesg with latest kernel from munjeni release thread... I tried video and camera and got "adsp_video_verify_cmd: unknown video queue 4" and in jpeg_verify "-1" !!! So one queue step fail or maybe array of the queues (or array of the module offsets) in adsp_photon.c or msm_adsp.h need to be realigned! I think it cause audio loop and video freze in youtube becouse wrong queue (wrong module used), allso cause problem in video capture! With new memory map I got youtube to "not freze" but could not stop audio and no high def video... please see commit http://gitorious.org/2-6-32-photon/testing/commit/e3121b4083068760fc33a277e10c049a4054840d you will see QDSP_uPJpegActionCmdQueue is not used!
i think value for camera 22 - 23
because logcat have error with 22 ioctl
QDSP_uPJpegActionCmdQueue with 22 value you can find in leo source msm_adsp
Maybe asking help from Cianogen to support our phone becouse it's related to rpc and we not have that knownledge, it is hard to fix without .pdf specification for our phone!
problem with resolution, in fast burst camera with large buffer and 1280x760 all good in android camera problem with buffer ,
the first what can be a problem : auto-focus wrong offset
the second : buffer with very high resolution too large and pmem don't have needed size
the third : problem with ioctl
I'm having problems debugging libstagefright.
Code:
#6 0xe6c9c740 in vpx_codec_decode () from target:/system/lib/libstagefright_soft_vpxdec.so
#7 0xe6c98f74 in android::SoftVPX::onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
#8 0xe88570f2 in android::SimpleSoftOMXComponent::onMessageReceived(android::sp<android::AMessage> const&) () from target:/system/lib/libstagefright_omx.so
#9 0xe885813e in android::AHandlerReflector<android::SimpleSoftOMXComponent>::onMessageReceived(android::sp<android::AMessage> const&) ()
from target:/system/lib/libstagefright_omx.so
#10 0xe8d24556 in android::AHandler::deliverMessage(android::sp<android::AMessage> const&) () from target:/system/lib/libstagefright_foundation.so
#11 0xe8d26a6a in android::AMessage::deliver() () from target:/system/lib/libstagefright_foundation.so
#12 0xe8d251d2 in android::ALooper::loop() () from target:/system/lib/libstagefright_foundation.so
#13 0xe83592b4 in android::Thread::_threadLoop(void*) () from target:/system/lib/libutils.so
#14 0xe8694812 in __pthread_start(void*) () from target:/system/lib/libc.so
#15 0xe866736a in __start_thread () from target:/system/lib/libc.so
#16 0x00000000 in ?? () from target:/system/vendor/bin/hw/[email protected]
I can debug code up until I get to android::SoftVPX:: onQueueFilled, once the call to vpx_codec_decode() is made, and I step, I get this error:
Thread 12 received signal SIGSYS, Bad system call.
It would appear to be due to this syscall made inside of __pthread_cond_timedwait():
Code:
Thread 13 (Thread 2656.12953):
#0 0xe8664e50 in syscall () from target:/system/lib/libc.so
#1 0xe86941a6 in __pthread_cond_timedwait(pthread_cond_internal_t*, pthread_mutex_t*, bool, timespec const*) () from target:/system/lib/libc.so
#2 0xe884cc58 in android::eek:MXNodeInstance::CallbackDispatcher::loop() () from target:/system/lib/libstagefright_omx.so
#3 0xe884cd04 in android::eek:MXNodeInstance::CallbackDispatcherThread::threadLoop() () from target:/system/lib/libstagefright_omx.so
#4 0xe8359236 in android::Thread::_threadLoop(void*) () from target:/system/lib/libutils.so
#5 0xe8694812 in __pthread_start(void*) () from target:/system/lib/libc.so
#6 0xe866736a in __start_thread () from target:/system/lib/libc.so
#7 0x00000000 in ?? () from target:/system/vendor/bin/hw/[email protected]
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Code:
(gdb) disas __pthread_cond_timedwait
...........
0xe86941a0 <+100>: movs r0, #240 ; 0xf0
0xe86941a2 <+102>: blx 0xe8661478 <[email protected]>
Syscall #240 appears to be the futex syscall (correct me if I'm wrong)...I added that to the media.codec seccomp profile file on the file system, along with a load of other syscalls, but it still doesn't work and I'm stuck, I don't know what to do as I need to be able to step through the code and it just errors out.
Any ideas on how to disable minijail/seccomp or add the correct syscall number so it doesn't bale once it enters vpx_codec_decode() from android::SoftVPX:: onQueueFilled?
Sorry to bump this, but here's some more output:
Code:
Thread 11 hit Breakpoint 1, 0xf1298e3e in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) c
Continuing.
Thread 11 hit Breakpoint 2, 0xf1298f6c in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) si
0xf1298f70 in android::SoftVPX::onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) disas
0xf1298f6c <+320>: add.w r1, r12, lr
=> 0xf1298f70 <+324>: blx 0xf1297614 <[email protected]>
0xf1298f74 <+328>: mov r3, r0
0xf1298f76 <+330>: cmp r3, #0
0xf1298f78 <+332>: bne.n 0xf1298ffc <_ZN7android7SoftVPX13onQueueFilledEj+464>
0xf1298f7a <+334>: strb.w r11, [r10, #4]
(gdb) si
Thread 11 received signal SIGSYS, Bad system call.
0xf1297618 in [email protected] () from target:/system/lib/libstagefright_soft_vpxdec.so
As soon as I step into [email protected] I get that bad syscall error. I just don't really understand what the hell is going on.
int80 said:
Sorry to bump this, but here's some more output:
Code:
Thread 11 hit Breakpoint 1, 0xf1298e3e in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) c
Continuing.
Thread 11 hit Breakpoint 2, 0xf1298f6c in android::SoftVPX:: onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) si
0xf1298f70 in android::SoftVPX::onQueueFilled(unsigned int) () from target:/system/lib/libstagefright_soft_vpxdec.so
(gdb) disas
0xf1298f6c <+320>: add.w r1, r12, lr
=> 0xf1298f70 <+324>: blx 0xf1297614 <[email protected]>
0xf1298f74 <+328>: mov r3, r0
0xf1298f76 <+330>: cmp r3, #0
0xf1298f78 <+332>: bne.n 0xf1298ffc <_ZN7android7SoftVPX13onQueueFilledEj+464>
0xf1298f7a <+334>: strb.w r11, [r10, #4]
(gdb) si
Thread 11 received signal SIGSYS, Bad system call.
0xf1297618 in [email protected] () from target:/system/lib/libstagefright_soft_vpxdec.so
As soon as I step into [email protected] I get that bad syscall error. I just don't really understand what the hell is going on.
Click to expand...
Click to collapse
gdb set force-mode thumb?
gellmar said:
gdb set force-mode thumb?
Click to expand...
Click to collapse
Thanks for the reply, but unfortunately not. I think it's something to do with threading and minijail/SECCOMP.
Code:
(gdb) set arm force-mode thumb
(gdb) si
[New Thread 2652.11026]
Thread 9 received signal SIGSYS, Bad system call.
0xe8a16618 in [email protected] () from target:/system/lib/libstagefright_soft_vpxdec.so