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
<bonda_000> undefined8 isp_abort_frame(int param_1,undefined4 param_2)
<bonda_000> is the same for you?
<bonda_000> good night, finished the isp_func_table struct
<bonda_000> hopefully thats good enough for a hint for those (code *) entries
bonda_000 has quit [Quit: Leaving]
Stromeko has quit [Ping timeout: 256 seconds]
Stromeko has joined ##raspberrypi-internals
_whitelogger has joined ##raspberrypi-internals
_whitelogger has joined ##raspberrypi-internals
angerisagift has quit [Ping timeout: 268 seconds]
angerisagift has joined ##raspberrypi-internals
bonda_000 has joined ##raspberrypi-internals
<bonda_000> (*pcVar12)(*(undefined4 *)(&param_1->field_0x6500 + param_2 * 4),
<bonda_000> *(undefined4 *)(&param_1->field_0x6604 + iVar7 + -0x65d8),0,bVar2,&local_39,pcVar12);
<bonda_000> that should have been replaced
<bonda_000> was this supposed to be a function call
<bonda_000> iVar10 = *(int *)(&param_1->field_0x65fc + iVar7 + -0x65d8);
<bonda_000> but yeah now I do find
<bonda_000> line 48 call to isp_set_hresize, line 172 isp_mark_schedulable, line 190 isp_start_yuv_frame
<bonda_000> line 207 something interesting
<bonda_000> pwVar14 = (wordiiiiii *)param_1->field25852_0x64fc->isp_start_raw_frame;
<bonda_000> it's applying one of my types lol to change it a bit
<bonda_000> and see it casted it to a type with 6 params
<bonda_000> it doesn't want to obey data types I put into the table https://imgur.com/qlWK8c0
<bonda_000> <clever> because isp_mark_schedulable is being called, and ghidra imagined it took 3 args
<bonda_000> <clever> and thats what caused the extraout
<bonda_000> :clever that's not what's happening in my case
<bonda_000> I have 11 extraouts declared, only 8 of them are being used
<bonda_000> all 8 in this section, where well-defined function are being called
<bonda_000> so, for instance logging_message, sets extraout_r1, extraout_r2, extraout_r5
<bonda_000> logging_message(0x800,
<bonda_000> "camplus_setup_isp [%d]: new isp frame, isp_frames_done=%d, prep_frames_done=%d",
<bonda_000> param_2,*(undefined4 *)&param_1->field_0x646c,
<bonda_000> *(undefined4 *)&param_1->field_0x64d8);
<bonda_000> this is wrong
<bonda_000> ah no nwm it has the right argument count
f_ has joined ##raspberrypi-internals
<clever> bonda_000: from what i learned yesterday, you want to see what consumes the extraouts, not what seems to produce them
<clever> so when you see an ivar4=extraout, search to see where ivar4 is used, and if its even used at all
<bonda_000> local_40 = camplus_set_multichannel_isp_buffers
<bonda_000> (param_1,uVar5,uVar6,*(uint *)&param_1->field_0x4,
<bonda_000> (uint)(byte)param_1->field_0x65bb,uVar11);
<bonda_000> this one takes all extraouts set by logging message, camplus_set_isp_lresize
<bonda_000> uvar5, uvar6, uvar11
<bonda_000> ah I see
<bonda_000> that function is messed up
<bonda_000> undefined4 *
<bonda_000> camplus_open(undefined4 param_1,undefined4 *param_2,undefined4 *param_3,code **param_4,int *param_5,
<bonda_000> int param_6)
<bonda_000> this one seems to be big as well
<bonda_000> It seems to be right though
<bonda_000> 0eca4d1a it overwrites r1 with lea param_2, $S
<bonda_000> that's the string argument to logging message
<bonda_000> this could be the issue
<bonda_000> I dont know where 800h comes from here and why it points to some macro
<bonda_000> oh okay
<bonda_000> :clever bingo
<bonda_000> that's how Ghidra decompiled camplus_set_multichannel_isp_buffers()
<bonda_000> for whatever reason with 6 parameters of which 5 latter never get used
<bonda_000> deleting and making it a function again cleared all extraouts
<bonda_000> I feel like all the extraouts due to this function not explicitly being called anywhere so it writes some "one-size-fits-all" as it has no use cases
<bonda_000> oh s**t dude
<bonda_000> look at 0ef22ee8
<bonda_000> that's another function table
<bonda_000> there's also a camera_info_table at 0ef22d34 that's probably within that huge struct we are passing around
<bonda_000> according to the logic of things that's also being passed around somewhere in upper layers of the OS
jcea has joined ##raspberrypi-internals
<bonda_000> there are
<bonda_000> get_X_func_table strings
<bonda_000> 0ef19666 67 65 74 ds "get_isp_func_table"
<bonda_000> 5f 69 73
<bonda_000> 70 5f 66
<bonda_000> but such function is not in the symbol tree
<bonda_000> my bad, it is
<bonda_000> it has two names
<bonda_000> get_isp_module and get_isp_func_table
<bonda_000> get_isp_module appears in the symbol tree. but no xrefs
f_ is now known as f_`
f_` is now known as f_
<bonda_000> logging_message(unaff_r6,
<bonda_000> "cameraRIL:try_update_and_start_capture:AWAIT_CAPTURE_END. stop parallel cam plus to resume viewfinder/encode"
<bonda_000> logging_message(unaff_r6,
<bonda_000> "cameraRIL:try_update_and_start_capture:VIEWFINDER. stop parallel camplus to r esume viewfinder/encode"
<bonda_000> this is a function void FUN_0ee2cf76(void) at 0ee2cf76 for some reason without any name given to it
bonda_000 has quit [Remote host closed the connection]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> logging_message(0x40,"cameraRIL: starting camplus after either RECV_SINGLE or memory compaction"
<bonda_000> );
<bonda_000> void try_frame_start(int param_1,int param_2)
<bonda_000> 0ee2c484 ff 9f d2 8f bl start_camplus undefined4 start_camplus(int par
<bonda_000> pcVar2 = *(code **)(*(int *)(param_1 + 0x1b6c) + 0x14); so start_camplus also picks up some function pointer from a struct at that offset param_1 + 0x1b6c
<bonda_000> let's see
<bonda_000> yeah at offset +0x14 within camplus module sits the camplus_start
<bonda_000> so param_1 + 0x1b6c is the camplus_func_table
<bonda_000> undefined4 ca_process_thread(uint *param_1) this seems to be the camera thread
<bonda_000> :clever yeah FUN_0ee2d0fc() and FUN_0ee2cf76() seem to be camera module functions that for some reason don't have a name in my decompile
<bonda_000> undefined4 __stdcall open_camplus(int param_1) that's also a big one right here at 0eddaa7c
<bonda_000> same calls to (**(code **)(*(int *)(param_1 + 0x1b6c) + 0x3c)) camplus_func table
<bonda_000> but how you caught the exact size of the struct yesterday I'm still oblivious, I haven't seen such a memset yet
<bonda_000> so as of right now: ? -> camera(cameraRIL)->camplus->isp and we need to work our way up
<bonda_000> oh man
<bonda_000> look at camplus_open
<bonda_000> pcVar3 = (code *)dlshared_get_vll_symbol(iVar2,"get_isp_func_table");
<bonda_000> that's where it gets the function table from
<bonda_000> camplus_setup_isp that I was looking at yesterday is a baby child compared to this beast camplus_open
<bonda_000> I kind of worked backwards but now seem to get at the results you got yesterday
<clever> bonda_000: yep, i found vll yesterday, ive heard mention of it years ago
<clever> basically think of it like dll's on windows
<clever> originally, there was a way to pass a vll file to the firmware, after booting, to add features to it
bonda_000 has quit [Ping timeout: 260 seconds]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> but do you have those two functions also without a proper name tag? :clever
<bonda_000> FUN_0ee2d0fc() and FUN_0ee2cf76()
<bonda_000> I only hope that the camera interface and some way up is not discriminating against particular camera attachment
<bonda_000> and doesn't cling way too much to CAM0/CAM1 peripheral which seems to be tied to the CSI interface
<bonda_000> and I am not able to find a function table with these start_camplus() and try_frame_start() functions
<bonda_000> 0eeaf7b0 67 65 74 ds "get_camera_func_table"
<bonda_000> 5f 63 61
<bonda_000> 6d 65 72
<bonda_000> there is a "camera_subsystem_func_table" but it is the unicam CAM0/CAM1 stuff
<bonda_000> I suspect this one is a part of the "camera" block and could be within some function table
<bonda_000> the (code *) pointer is calling the top "camplus" function
<bonda_000> almost as in some kind of creepy videogame
<bonda_000> it all tracks down to these two nameless FUN's
<bonda_000> FUN_0ee2d0fc() and FUN_0ee2cf76()
<bonda_000> tracks up* to be precise
<bonda_000> and I think it's just a hickup on my side
<bonda_000> because of the switch that precedes
<bonda_000> it all seems to be a part of a very big function called
<bonda_000> int try_update_and_start_capture(int param_1)
bonda_000 has quit [Read error: Connection reset by peer]
bonda_000 has joined ##raspberrypi-internals
f_ has quit [Ping timeout: 260 seconds]
<bonda_000> found this just as a string
<bonda_000> 0ef191a1 63 61 6d ds "camera_ilc.vll"
<bonda_000> 65 72 61
<bonda_000> 5f 69 6c
<bonda_000> 0ef191bb 63 61 6d ds "camplus.vll"
<bonda_000> 70 6c 75
<bonda_000> 73 2e 76
<bonda_000> is that the .dll you mentioned?
<bonda_000> it does seem to do some vll loading:
<bonda_000> undefined4 mmal_vll_load(uint *param_1,char *param_2,int param_3,uint **param_4)
<bonda_000> pcVar5 = (code *)dlsym(puVar12[1],&$S,uVar7,uVar8,uVar10,uVar11); in mmal_vll_load
<bonda_000> int sym_lookup_value(int param_1,byte *param_2) this hashes the elf for a vll string
<clever> bonda_000: yeah thats it
<clever> because this was originally its own os with apps and drivers, it has the ability to load modules from the disk
<bonda_000> I don't think there is any VC4 on the raspberry pi linux side
<bonda_000> like load a binary to run as program?
<bonda_000> it's just strange that I can't find a function table for the cameraRIL stuff
<bonda_000> elf weighs 5 MB though
<bonda_000> this is a neat looking one
<bonda_000> void compact_timeout_task(void)
<bonda_000> finally something that I can understand how it works in this code
<bonda_000> this is the biggest one I've seen so far
<bonda_000> int compact_internal(uint param_1,uint param_2,int param_3)
<bonda_000> its doing some memory operations for the RTOS
<bonda_000> else {
<bonda_000> pcVar5 = "get_record_buffer_driver_func_table";
<bonda_000> }
<bonda_000> pcVar7 = (code *)dlsym(iVar4,(byte *)pcVar5,extraout_r2,extraout_r3,extraout_r4,extraout_r5);
<bonda_000> this one is causing a lot of extraouts and it seems to just put all the regs on the stack
<bonda_000> undefined8
<bonda_000> logging_assert_dump(undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
<bonda_000> undefined4 param_5,undefined4 param_6)
<bonda_000> and then it just puts all the params and r6 through r31 on the stack and it doesn't seem to use these params in any other way
<bonda_000> probably going to override the signature and make it zero args
bonda_000 has quit [Quit: Leaving]
inara has quit [Quit: Leaving]
inara has joined ##raspberrypi-internals