f_ changed the topic of ##raspberrypi-internals to: The inner workings of the Raspberry Pi (Low level VPU/HW) -- for general queries please visit #raspberrypi -- open firmware: https://librerpi.github.io/ -- VC4 VPU Programmers Manual: https://github.com/hermanhermitage/videocoreiv/wiki -- chat logs: https://libera.irclog.whitequark.org/~h~raspberrypi-internals -- bridged to matrix and discord
jcea has quit [Ping timeout: 256 seconds]
_whitelogger has quit [Ping timeout: 260 seconds]
_whitelogger has joined ##raspberrypi-internals
bonda_000 has joined ##raspberrypi-internals
<bonda_000> clever: hello
<bonda_000> do you know if
<bonda_000> in int ov5647_open(void *param_1,uint **param_2)
<bonda_000> this line
<bonda_000> line 16-17
<bonda_000> if ((param_1 == (void *)0x0) ||
<bonda_000> (puVar1 = (uint *)rtos_malloc_priority(0x28c,4,1,0), puVar1 == (uint *)0x0))
<bonda_000> is it going to evaluate the second part if param_1 happens to be equal to zero?
<bonda_000> ah nvm assembly says it does call rtos_malloc_priority no matter what
jcea has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 264 seconds]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> clever: have you managed to fix your cdi_camera_change_state?
<bonda_000> I feel like this function is broken in the decompile window
<bonda_000> I have these weird extraouts that are never being used
<bonda_000> it's messing up because of this instruction
<bonda_000> 0eca91d6 00 9e 2b 02 b FUN_0eca962c undefined FUN_0eca962c(void)
<bonda_000> -- Flow Override: CALL_RETURN (CALL_TERMINATOR)
<bonda_000> which does pop lr
Ad0 has quit [Ping timeout: 260 seconds]
bonda_000 has quit [Ping timeout: 264 seconds]
Ad0 has joined ##raspberrypi-internals
bonda_000 has joined ##raspberrypi-internals
<bonda_000> :clever what I'm wondering about is
<bonda_000> cdi_camera_task_func() that we spoke about yesterday that references the cdi_struct + 0xDC entry
<bonda_000> I just noticed something interesting
<bonda_000> it starts with
<bonda_000> undefined4 cdi_camera_task_func(cdi_camera_ctrl_struct *param_1)
<bonda_000> puVar13 = param_1 + 0x18
<bonda_000> at line 64 it goes:
<bonda_000> bVar3 = param_1->field_0x7844;
<bonda_000> ...
<bonda_000> if (bVar3 != 0) {
<bonda_000> bVar2 = *(byte *)((uint *)puVar13[0x31] + 0xd);
<bonda_000> so it doesn't check whether puVar[0x31] has been initialized
<bonda_000> which is dangerous first and foremost
<bonda_000> or
<bonda_000> bVar3 = param_1->field_0x7844 is an indicator whether puVar13[0x31] has anything in it
<bonda_000> ah, no
bonda_000 has quit [Ping timeout: 268 seconds]
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 268 seconds]
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 264 seconds]
bonda_000 has joined ##raspberrypi-internals
dolphinana has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 252 seconds]
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 260 seconds]
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Remote host closed the connection]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> do you know how I can see logging messages such as this on rpi? :clever
<bonda_000> logging_message(0x400,"cdi_camera_request_mode [%d]: enter: want mode %s %d,%d,%d",param_2,
<bonda_000> *param_3,(uint)*(ushort *)(param_3 + 2),(uint)*(ushort *)((int)param_3 + 10),
<bonda_000> param_3[4]);
<bonda_000> I did the enable_2ndstage_uart thing last time but It practically didn't print anything of this kind
<clever> bonda_000: you can also check out vcdbg
<clever> line 4
<bonda_000> yeah I am having trouble finding what is at 0xDC of cdi struct that holds the CAM0 regs to write into unicam
<bonda_000> if I knew that I could try to put the same configs from a userland program on ARM side and try to hook up a scope to those AVE pins
<bonda_000> there are still a bunch more cdi calls from ca_process_thread that I just found
<bonda_000> I would suppose it is a unicam_state struct
<bonda_000> which is in the bss segment
<clever> bonda_000: sometimes it can help to ignore the decompile, and read the asm opcode by opcode
<clever> the disassembly can sometimes be misleading
<bonda_000> it normally does match
<bonda_000> clever: but I do read both