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: 268 seconds]
bonda_000 has joined ##raspberrypi-internals
Stromeko has quit [Ping timeout: 252 seconds]
Stromeko has joined ##raspberrypi-internals
f_ has joined ##raspberrypi-internals
f_ has quit [Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.]
<bonda_000> any idea what this does? local_c._0_3_ = CONCAT12(*(undefined *)(param_1 + 0x198),*(undefined2 *)(param_1 + 0x19c));
<clever> bonda_000: feels like a 64bit load
<clever> double-check what the asm is doing in that area
<bonda_000> CONCAT12
<bonda_000> I'm not sure whether they left out functions that are not being used
<bonda_000> or they are called in some weird way from a function table and Ghidra doesn't see it as it doesn't seem to go deep into recursion
<bonda_000> isp_open seems to be an important one yet has no XREF
<bonda_000> only from debug
<clever> try searching for the addr with s, rather then relying on xref's
<bonda_000> I tried
<bonda_000> it may just be a debug function
<clever> with that, i found a big fat function table with isp_open in it
<clever> the label is isp_module
<bonda_000> the address where the function starts?
<clever> yes
<clever> make sure to search both forwards and backwards
<bonda_000> maybe that's what I didn't do
<bonda_000> I'm trying to find where isp_globals is being set
<bonda_000> or allocated
<bonda_000> it seems to be an array of 72Kb large entries, seemingly one per frame
<clever> i also see a get_isp_module, that returns gp + 0x26f68
<clever> and isp_module (the function table) is at ef2ed68
<clever> youll notice, half the digits match
<clever> so get_isp_module is returning the function table
<bonda_000> give me a sec
jcea has joined ##raspberrypi-internals
<bonda_000> I've been saving this huge struct of 0x119ac bytes that I'm editing for isp_globals
<bonda_000> Search for address tables?
<clever> ah, but get_isp_module might not be the right thing
<clever> yeah, search for the entry-point of isp_open
<bonda_000> search for a scalar then?
<bonda_000> Search for address tables gives me only three options as tick-boxes
<clever> bonda_000: https://imgur.com/a/aY9kzZP
<bonda_000> oh, I see
<bonda_000> it says Painting Field
<bonda_000> in red
<bonda_000> Error Painting Field
<clever> that sounds like an internal error in ghidra
<bonda_000> yeah
<bonda_000> it blinks for a split second I see there is some Elf table
<bonda_000> but when I try to scroll over it it's showing me this
<clever> try using `g` for goto, and `isp_module`
<clever> try restarting ghidra
<bonda_000> yeah I have that
<bonda_000> ok
<bonda_000> one sec
<bonda_000> same thing
<clever> not sure what is going on then
<bonda_000> but I can see isp_module
<bonda_000> that one is ok
<bonda_000> it's only blanking for isp_open
<clever> isp_module is a function table
<bonda_000> and there is a reference to ed72264
<bonda_000> within isp_module table
<clever> yep
<bonda_000> is that the reason I don't see any xrefs?
<clever> the reason is that ghidra mis-labeled isp_module as a byte array
<clever> when its a function pointer array
<bonda_000> so the isp_open may also be something other than just plain bytes?
<clever> its a function
<bonda_000> so that entry in the .symtab that doesn't paint in my window is just the .text of that function?
<clever> .symtab is the symbol table for the elf file
<clever> thats what gives a name to every address
<bonda_000> memset(param_1,0,0x11aa0);
<bonda_000> see that it zeroes out that huge struct that I was editing the last few days
<bonda_000> it contains parameters that it then writes to hardware regs, among other things that I haven't figured out yet
<clever> yeah, thats a major hint about the size of a struct, and i use that a lot
<bonda_000> most of the isp_ functions and especially isp_plat_ functions seem to take pointer to that struct as param_1
<bonda_000> pardon, isp_plat_ add an offset to the beginning of that struct
<clever> that sounds like a struct within the struct
<bonda_000> wish I knew where isp_open is getting called from
<bonda_000> oh yeah
<clever> something likely uses the isp_module table to call isp_open
<clever> the question then, is how did isp_module get referenced
<bonda_000> I dont get any references to that function table
<bonda_000> only 1
<clever> yeah, thats what i havent figured out
<bonda_000> that's some entry in the Elf header at .symtab + 0x1d480h
<bonda_000> well if it's refernced via gp
<bonda_000> then probably gotta look for certain operands
<bonda_000> whatever is with gp ghidra doesn't go deep at all
<bonda_000> that's why I'm doing this 0x119ac byte struct by hand
<bonda_000> 0ef2ed68 (func.table) - 0ef07e00 (gp) = 26f68
<bonda_000> In fact, I had to increase my search limit to 50000 entries to get all gp references throughout the code
<clever> ah, if i search for that offset, i get the `get_isp_module()` function i mentioned earlier
<bonda_000> mine isn't this fast, I'm searching Program text for operands "gp,26f68"
<bonda_000> I'll look at that in the meanwhile
<clever> i did a byte search, same as my last screenshot
<bonda_000> what's get_isp_pass
<bonda_000> lol
<bonda_000> I will open as soon as its done it tends to crash when I use both firefox and ghidra
<bonda_000> but
<bonda_000> isp_globals the undefined8 entry in .sbss
<bonda_000> seems to have an address of that 0x11a9c byte struct in its high 4 bytes
<bonda_000> and then it iterates over by adding 0x11a9c to the iterator untill it equals a 0x0
<bonda_000> linked list I guess?
<bonda_000> of frames or more likely tile batches as each of these the isp_task runs through Isp_tiles_ready function
<bonda_000> more like an array as it's just adding a constant offset on each iteration of the loop
<bonda_000> first loop, it iterates over the whole array
<bonda_000> second major loop, it stops at whichever isp_tiles_ready returns a '1'
<bonda_000> isp_schedule() is the one I'm talking about
<clever> i still havent been able to make sense of all of that code
<bonda_000> get_isp_tuner_ov5647
<bonda_000> isn't ov5647 one of the cameras that raspberry pi supports?
<clever> yes
<clever> the isp has some tuning profiles, to adjust for how sensitive the sensor is
<bonda_000> the one that I got doesn't have any of those supported ones
<bonda_000> sony icx415aq
<bonda_000> compare the data sheet to that Sony one raspberry pi supports lol
<bonda_000> imx219 or something
<bonda_000> there's like a whole messaging systems over i2c and half the tuning is done on the camera side of hardware
<bonda_000> I'm making a raw sensor
<bonda_000> pure ADC input
<clever> there is also both analog and digital gain
<clever> the ISP will apply digital gain to the pixels, to fix the brightness
<bonda_000> on the software side?
<clever> but there is a limit to how much it can do, so the ISP is also outputting stats on the average pre-gain brightness levels
<clever> and the software stack then sends i2c commands to the sensor, to adjust the analog gain
<bonda_000> yeah
<clever> those i2c commands also have a lag on them
<clever> so the digital gain in the ISP can adjust every frame directly
<clever> while the analog gain has to take the stats from 1 frame, then change the sensor, then wait a few frames for the response
<bonda_000> yeah in the datasheet I think they mean analog gain
<bonda_000> but they also weirdly have dual adc
<bonda_000> one adc channel to capture RgRb
<bonda_000> the other adc channel for R/B
<bonda_000> I don't know what's the benefit of that
<bonda_000> presumably all effort to minimize noise on hardware so there is less to do in software
<bonda_000> but that follows the C.D.S. block
<bonda_000> so same C.D.S. block for R,B,Gr,Gb, but split ADCx
<bonda_000> ADCs*
<bonda_000> that's in the measurement section too, so it may just be the setup for measuring low/high levels
<bonda_000> Plus I thought there was supposed to be a CDS per each column other than one CDS per frame
<bonda_000> others say you don't need a CDS with CCD as it flushes the charge better than CMOS
<bonda_000> I'm also searching in the Program text search for (gp+0x26f68) for loads/stores of isp function table
<bonda_000> as an operand
<bonda_000> and for gp,-195b9c and (gp-0x195b9c) for movs and loads/stores of isp_open respectively
dolphinana has joined ##raspberrypi-internals
dolphinana has quit [Ping timeout: 256 seconds]
f_ has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 260 seconds]
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Client Quit]
f_ is now known as f_|afk
f_|afk is now known as f_
bonda_000 has joined ##raspberrypi-internals
<bonda_000> do you know what's wrong with this one: https://imgur.com/KRR4vOD
<bonda_000> :clever
<clever> bonda_000: never seen that one before
<bonda_000> it's saying something's wrong with r9 that keeps ping ponging a FILE *
<clever> that function disassembles just fine for me
<bonda_000> also syntax's weird, mov param1, r9 as in mov r0, r9?
<clever> what addr is that opcode at?
<clever> 49bc?
<bonda_000> 0eea49ae 09 40 mov r9,param_1
<bonda_000> 0eea49bc 90 40 mov param_1,r9
<clever> thats just ghidra trying to help some, inserting the names from the decompile
<bonda_000> o
<bonda_000> oh
<bonda_000> that whole section of write_isp_ is broken for me
<bonda_000> or most of it
<bonda_000> so I realize the isp block probably doesn't run by itself
<bonda_000> it is probably instantiated only when a program is run such as camplus_setup_isp
<clever> yeah, it seems to be heavily command driven, and software has to tell it what to do at every step
<bonda_000> were you able to fix this
<bonda_000> 0eca4e56 87 90 8a fb bl logging_message undefined logging_message(uint p
<bonda_000> -- Flow Override: CALL_RETURN (CALL_TERMINATOR)
<bonda_000> it doesn't matter what return type it's always like this
<clever> what are the attributes on loggin_message?
<bonda_000> just fixed it with un-ticking the "No return"
<bonda_000> other places it's not behaving as good
<bonda_000> but anyway
<clever> no return is only for very special functions like exit()
<clever> normally it should never be checked
<bonda_000> now that there's no more "Flow override" two bytes after bl logging message are not interpreted
<bonda_000> 0eca4d3a 84 ?? 84h
<bonda_000> 0eca4d3b e6 ?? E6h
<clever> select the first byte and hit d
<bonda_000> its very common in my decompile
<bonda_000> nothing happens
<clever> right click the first byte, select decompile
<bonda_000> "Disassemble" is what I have
<clever> yes that
<bonda_000> still
<bonda_000> E6 84 doesnt look like a valid two byte opcode anyway
<clever> screenshot?
<bonda_000> I mean it somehow gets the rest of it sort of logically sound still
<clever> you need to clear the opcodes after it
<clever> that rsub is wrong
<bonda_000> oh that fixed it
<clever> the opcode at 0eca4d3a is likely over 16 bits in size
<clever> and because the rsub is in the way, it cant fit the proper one
<clever> it should even tell you so in the status bar
<bonda_000> yeah there was some sort of red banner
<bonda_000> stuff like undefined4 extraout_r4_00;
<bonda_000> still extraout r1, r2, r3, r4, r5 mean it depends on values of these regs set before we entered this function
<bonda_000> right?
<bonda_000> this one also has no xref so another dead end
<clever> extraout mean something didnt decompile properly
<bonda_000> I don't know it keeps graying it out for me
<clever> because ghidra got confused about where the function ends
<clever> select the first opcode in the function, hit the delete key once, and it will un-function it, then hit f
<clever> this happens a lot
<clever> due to the no-return, ghidra thinks the function ends at that logging_message, and only recreating the function will fix it
<clever> ah, there is also a re-create function option, in the right click menu
<bonda_000> there is this $t as well as camplus_setup_isp
<clever> yeah, delete the function on that
<bonda_000> so when I hit delete it removes the camplus_ but not the $t
<clever> it will cause the same problem
<clever> $t, $S, and $c are never functions, delete the function on sight
<bonda_000> so
<bonda_000> what Delete does is just remove the function name
<clever> what it does varies heavily, based on context
<clever> in this case, it removes just the function tag, on the first hit
<clever> if you hit it again, it will remove the label, undo that
<bonda_000> it deletes camplus_setup_isp, then deletes $t, then I'm left with FUN_0eca4cf0
<clever> you hit it too many times, undo that
<bonda_000> delete or C?
<clever> just use the undo button in the toolbar
<bonda_000> oh i see
<bonda_000> it depends on where you hover over
<clever> yeah
<bonda_000> it can delete params, or the function
<bonda_000> yeah I recreated, still with all the extraout_rN
<clever> if you right click, youll see the delete hotkey is on different things, depending on where you clicked
<bonda_000> although its not grayed out anymore which is better
<clever> where do you see the extraout?
<bonda_000> opcode at 0eca4cf0
<bonda_000> camplus_setup_isp() do you also have all the extraout?
<clever> none at all
<clever> screenshot?
f_ has quit [Quit: To contact me, send a memo using MemoServ, PM f_[xmpp], or send an email. See https://vitali64.duckdns.org/.]
<clever> the arguments to logging_message are messed up
<clever> screenshot the edit function on that one
<clever> thats not the right window
<bonda_000> I know I was doing that one before I read your message
<clever> yeah, you have too many arguments on there
<clever> it should look like my screenshot
<bonda_000> that made it slighly better but still a lot of extraouts, 3 local_
<bonda_000> undefined4 camplus_setup_isp(int param_1,int param_2)
<clever> now that i look, i notice i do have 3 extraout's
<bonda_000> I wonder why it puts those as extraouts and not input arguments
<clever> because one of the functions that got called, has an extra output
<clever> and the decompiler cant figure out which one
<bonda_000> extra output
<bonda_000> what does that mean
<bonda_000> isn't output just an r0?
<clever> an extra output, is when its more then just r0
<clever> thats what the extra means
<bonda_000> huh
<bonda_000> what would that look like
<clever> a function that set both r0 and r1
<bonda_000> a function with multiple outputs
<clever> and then whatever called it, used r1
<bonda_000> oh
<bonda_000> and that function didnt stash r1?
<clever> the ABI says that a function is free to destroy the data in r0 thru r5
<clever> only r6 and above have to be stashed
<bonda_000> so r1 was just a scratch variable then? how does the decompiler guesses that r1 has anything valuable
<bonda_000> guess*
<clever> because something used r1, after it should have been clobbered
<clever> you will have to read the assembly, and figure out what is going on
<clever> just before a call to camplus_stabilise_compensate, i can see it mov'd into r2, r0, and r1
<clever> setting up 3 arguments
<clever> then it `bl camplus_stabilise_compensate`
<clever> afterwards, it loads r4 from ram, because r4 was clobbered
<clever> and it OR's that new r4, with r0, the return value
<clever> then stores that back to the same place r4 came from
<clever> which is basically just `foo |= r0`
<clever> and now i see, where the problem is
<clever> Ivar4 = extraout_r1_01;
<clever> (*pcVar5)(iVar9+offset, iVar4, pcVar5);
<clever> its calling a function pointer, and ghidra guessed wrong on how many args the function pointer wanted
<clever> ghidra assumed the function pointer takes 3 args
<clever> and nothing set r1 and r2
<clever> so ghidra imagined up an extra output, that never existed
<clever> so, on that function pointer line, right click, override signature, and type in something that only accepts 1 argument
<bonda_000> pcVar5 = *(code **)(*(int *)(param_1 + 0x64fc) + 0xd4);
<bonda_000> at the very beginning
<clever> yeah, so the problem is, you need to figure out what pcVar5 is pointing to
<clever> and then fix the args on that function
<bonda_000> pcVar5 = *(code **)(*(int *)(param_1 + 0x64fc) + 0x24);
<clever> something wrote to offset 64fc
<bonda_000> (*pcVar5)(iVar10 + 0x28594,iVar4,pcVar5);
<bonda_000> yeah
<bonda_000> code pointers
<bonda_000> is why most important stuff has no xrefs, I guess
<clever> yep
<clever> (*(code *)param_1->fun_table[9])(&pcVar10[5].field_0x5594,iVar4,param_1->fun_table[9]);
<clever> if i change `param_1` into a struct that is big enough (i just went 0x7000 bytes)
<clever> and then change the field at 64fc into a `void**`
<clever> then it becomes this
<clever> now you can clearly see, that param_1 is being passed to the function
<clever> param_2 is what ghidra just imagined out of nowhere
<clever> and param_3 is the function pointer itself, the reason ghidra imagined param_2
<clever> ghidra saw something set r0 and r2, so clearly its a function that takes 3 args, r0/r1/r2
<clever> and nothing set r1, so it must have been an extra output!
<clever> so if you just reduce the function at [5] to taking 1 arg, the imaginary extraout will vanish
<clever> bonda_000: and there it is, camplus_open, uses vclib_memset (vectorized memset) to zero out a 0x70810 byte struct, the camplus_state
<clever> bonda_000: oh, wow, it calls dlshared_get_vll_symbol!!
<clever> ive heard that the firmware still has dynamic module loading in place
<clever> and yep, i thought so!
<clever> that string is next to a reference of get_isp_module from hours ago!
<clever> which means, the fun_table above, is the isp_module
<clever> bingo, all of your xref questions are solved
<bonda_000> no references to isp_open?
<clever> one refernece, in camplus_isp_open
<clever> first, look in camplus_open, you will see a call to rtos_malloc_priority, and vclib_memset, to create a "camplus ctrl object" that is 0x70810 bytes in size
<clever> create a struct for that, and re-type the pointer
<clever> next, in camplus_setup_isp, param_1 is a pointer of that type
<bonda_000> I got this
<bonda_000> (**(code **)(param_1 + 0x54))(param_1,0xfffffffe,0,*(undefined4 *)(param_1 + 0x58));
<clever> in which function?
<bonda_000> in camplus_setup_isp()
<bonda_000> right after camplus_unlock() call
<clever> i dont see that one
<clever> do you have the 0x70810 byte `struct camplus_state` yet?
<bonda_000> I create this manually?
<clever> yes
<bonda_000> done
<clever> now create another struct, called isp_function_table, it is 388 bytes in size
<clever> and every word in there, is a function from the isp_module table
<clever> https://i.imgur.com/ylurfGQ.png then at offset 64fc of camplus_state, you create a isp_function_table*
<clever> https://imgur.com/a/JgaHwq8 now it clearly says that its calling isp_mark_schedulable
<clever> but ghidra is still wrong on the arg count, and imagined up the 2nd and 3rd param
<bonda_000> done as well
<clever> but i can just go to that function, and see that its a uint foo(uint)
<bonda_000> so param1 is camplus_ctrl_object?
<clever> yep
<clever> so down in the data type manager, i can create a new function definition, i'll call it uint oneone(uint)
<clever> then in the `struct isp_function_table`, i change isp_mark_schedulable to be a `oneone*`
<bonda_000> undefined4 camplus_setup_isp(camplus_ctrl_object *param_1,int param_2)
<bonda_000> is what the signature is now
<clever> and now ghidra has stopped dreaming up args that dont exist
<bonda_000> param2 must be deleted?
<clever> not on camplus_setup_isp
<clever> here, on line 153
<bonda_000> so param1 at some offset has that second struct within it?
<clever> yes
<clever> 2024-05-08 18:01:01 < clever> https://i.imgur.com/ylurfGQ.png then at offset 64fc of camplus_state, you create a isp_function_table*
<clever> and did you fill that struct with the names i showed?
<bonda_000> no but there seems to be another function table there
<bonda_000> (**(code **)&param_1->field_0x54)(param_1,0xfffffffe,0,*(undefined4 *)&param_1->field_0x58);
<bonda_000> thats line 96 in my decompile window
<bonda_000> gonna do it right now
<clever> if you right click on 54, and search for references (after tagging the camplus_ctrl_object * in all related functions)
<clever> youll find its set in camplus_error
<bonda_000> okay
<bonda_000> so just copy all the names from that function table we spoke earlier today?
<clever> yep
<clever> and for bonus points, create a function type for each
<clever> 2024-05-08 18:03:38 < clever> so down in the data type manager, i can create a new function definition, i'll call it uint oneone(uint)
<bonda_000> at 0ef2ed68
<clever> 2024-05-08 18:04:07 < clever> then in the `struct isp_function_table`, i change isp_mark_schedulable to be a `oneone*`
<clever> thats the one
<bonda_000> isp_module to be exact
<bonda_000> why such special attention to isp_mark_schedulable?
<bonda_000> I see
<bonda_000> let me do this and see how that goes
<clever> because isp_mark_schedulable is being called, and ghidra imagined it took 3 args
<clever> and thats what caused the extraout
<clever> but if you correctly label it as taking 1 arg, the extraout vanishes
<clever> also, doing all of this, solves the question of where isp_open gets called
<bonda_000> right here?
<bonda_000> undefined4 __stdcall isp_mark_schedulable(int param_1)
<bonda_000> mine takes only 1 arg
<clever> 2024-05-08 17:48:01 < clever> bingo, all of your xref questions are solved
<clever> 2024-05-08 17:52:12 < bonda_000> no references to isp_open?
<clever> 2024-05-08 17:52:56 < clever> one refernece, in camplus_isp_open
<clever> bonda_000: yep, but after going thru a dozen pointers and function tables, ghidra lost track of that
<bonda_000> I'm not done with the struct yet
<clever> and with the xref broken, ghidra is assuming it takes 3 args when it gets called
<bonda_000> well it doesn't know what is getting called
<clever> yeah, you need to do everything i said above, then it will have the right type again
<clever> thats not right
<clever> you want to create a function in the data type manager, and then make it a pointer to a function
<clever> also, you have the offset entirely wrong
<clever> init is at 0, not 0x120
<bonda_000> doh
<clever> https://imgur.com/a/cXqadXF here it is with the type set right
<bonda_000> isn't there a better way to do it
<clever> i dont know of any better way
<bonda_000> like map that isp_module array into this struct
<clever> you can change the type of isp_module to isp_function_table
<bonda_000> so that the function names appear properly?
<clever> but you still need to create all of the fields
<clever> yep, looks good
<clever> now if you look back in the function where you saw the extraout's, they should be fixed
<clever> and if you label everything as using that camplus ctrl struct properly, you can right click on isp_open in the struct, and find all references
<clever> and it will lead you to the missing isp_open xref you couldnt find yesterday
<bonda_000> i counted 14 extraouts before now 11
<bonda_000> code * callouts now look like this
<bonda_000> pcVar10 = (code *)param_1->field25852_0x64fc->isp_set_hresize;
<bonda_000> well it's not yet pointing at the actual function
<clever> now if you goto isp_set_hresize, youll see its an uint isp_set_hresize(uint, void*)
<clever> create another function definition in the data manager, maybe `uint uint_ptr(uint, void*)`
<clever> and then fix the type in the function table struct
<bonda_000> void isp_set_hresize(int param_1,void *param_2)
<bonda_000> the actual function
<clever> yep
<clever> mine returns uint
<clever> but always returns 0
<bonda_000> undefined4 isp_set_hresize(int param_1,void *param_2)
<bonda_000> memcpy was off
<bonda_000> it doesn't know whether its signed or unsigned so it puts undefined4?
<clever> yeah
<clever> i generally use uint
<clever> but if it looks negative, i use int
<clever> also, looking at the call-site, where setup_isp calls set_hresize, i can see both args, are iVar10 plus an offset
<clever> so its actually 2 pointers
<bonda_000> yeah it sometimes does that but arithmetic is corresponding to it
<clever> and then back in isp_set_hresize, the 2nd pointer is clearly a struct
<bonda_000> yeah
<clever> so fixing the function definition (once we have that struct) would enable labeling things back in setup_isp
<bonda_000> so
<bonda_000> how adding another placeholder function definition
<bonda_000> is going to help seeing the actual function at physical address 0ed74958
<bonda_000> <clever> create another function definition in the data manager, maybe `uint uint_ptr(uint, void*)`
<clever> ive since changed that one, to `uint set_hresize(void*,void*)`
<bonda_000> I guess it doesn't accept const
<bonda_000> fixing that function table address in one of the structs
<bonda_000> because you said the way you altered it made it see arguments correctly
<bonda_000> oh right
<bonda_000> void * is not giving it any hints
<bonda_000> so right
<clever> but at least the number of arguments is set
<bonda_000> that's why we need <clever> create another function definition in the data manager, maybe `uint uint_ptr(uint, void*)`
<clever> and that stops ghidra from dreaming up extraout's
<clever> if (*(char *)(iVar10 + 0x3b196) != '\0') {
<bonda_000> so now go over that list and add correct function signatures
<clever> (*param_1->isp_module->set_hresize)((void *)(iVar10 + 0x28594),(void *)(iVar10 + 0x3a044));
<clever> and now that things are labeled better
<clever> i can clearly see, this is an if statement, that is checking if resizing is needed
<clever> and only if resizing is needed, does it set the resize params
<clever> iVar10 = &param_1->field_0x0 + param_2 * 0x35110;
<clever> i can also see, that the main camplus state contains an array at offset 0
<clever> each array element, is 0x35110 bytes long
<clever> i'll name that camera_channel in the structs
<bonda_000> do I need to make a function placeholder each time or is there a more generic way
<clever> thats why i was using names like uint_ptr
<clever> for something that takes an uint and a pointer
<clever> then i can reuse that for every function taking an uint and a ptr
<bonda_000> (uint *)(uint arg1, uint arg2) should work?
<clever> yeah
<bonda_000> undefined is just a byte correct?
<clever> yeah
<bonda_000> Unrecognized data type of (undefined*)(void)
<clever> you need to create it in the data type manager first
jcea has quit [Remote host closed the connection]
<bonda_000> are "local_" variables also some sort of non-optimal decompilation?
<clever> just another name the decompiler seems to pick
<bonda_000> it seems to put intermediate results of the "CONCAT" operations in "local_" variables
<clever> CONCAT is usually a sign that its decompiled things wrong
<bonda_000> many of those isp_plat_write_ functions use CONCAT12, CONCAT13, CONCAT22 to assemble bit fields to write into peripheral registers
<bonda_000> undefined4 isp_plat_write_defective_pixel_auto(int param_1)
<bonda_000> undefined4 isp_plat_write_distortion(byte *param_1) this one has CONCAT22
<bonda_000> undefined4 isp_plat_write_fringing(undefined2 *param_1) all CONCAT22
<bonda_000> its using CONCAT22 to put together FFFF and FFFF bit fields
<bonda_000> like in the FG_GR_POS register of an ISP block
<bonda_000> as in, upper 16 bits and lower 16 bits of a 32 bit peripheral register
<bonda_000> void * memcpy(void *__dest,void *__src,size_t __n)
<bonda_000> is this the same as you have?
<bonda_000> no return un-ticked
<clever> the conat22's in isp_plat_write_fringing, do look valid, but i would have just written that as a bunch of `foo || foo[8]<<16`
<clever> i'm not sure why it went with the concat instead, but it is valid
<clever> my memcpy does look the same
<bonda_000> it's just the 22
<bonda_000> it's concatenating 16 bits and 16bits so concat22 sounds like it's concatenating on a 22-bit boundary
<clever> you would need to check the ghidra docs to see what that means