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]
fxsheep has joined ##raspberrypi-internals
fxsheep has quit [Client Quit]
fxsheep has joined ##raspberrypi-internals
fxsheep has quit [Ping timeout: 250 seconds]
bonda_000 has joined ##raspberrypi-internals
f_ has joined ##raspberrypi-internals
bonda_000 has quit [Remote host closed the connection]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> clever: I see why most FidDB functions don't match
<bonda_000> my old elf had issues with logging_message, memcpy, memset and past those I had to decompile by hand
<bonda_000> so it seems like those functions that had these didn't get accounted for properly
<clever> ah
<bonda_000> but I also noticed in different places it complains at some FLOW
<bonda_000> so if I put memset as "No return" it would stop complaining
<bonda_000> but in some other place a different function now complains that memset is "No return" and wants it the other way
<bonda_000> maybe I should configure those properly, run decompile again
<bonda_000> pretty much the whole "arm" block is new here though
<bonda_000> half the function I wasn't able to identify
Stromeko has quit [Ping timeout: 268 seconds]
Stromeko has joined ##raspberrypi-internals
<clever> bonda_000: memset should never be no return
<bonda_000> No return is like a trap function that has an infinite loop right?
<bonda_000> or just a void
<bonda_000> void foo()
<clever> bonda_000: no return is things like exit()
<bonda_000> clever: it keeps doing this https://imgur.com/VeLnpqZ automatically on a decompile
<bonda_000> and then populate fiddb with garbage half of it
<bonda_000> before I decompiled I fixed these functions
<bonda_000> I guess because it just does "b memset_asm"
<bonda_000> not sure what "thunked function" means, but it apparently doesn't bother to go into memset_asm and see that it does do an "rts"
<bonda_000> weird, I don't have this issue on a new elf
<bonda_000> I'll probably shut off the Non-returning functions options in the Analysis menu
<bonda_000> see if it does any better
<bonda_000> I usually enable all options
<clever> 2024-05-12 12:21:51 < bonda_000> I guess because it just does "b memset_asm"
<clever> bonda_000: that can be called either tail calling or a thunk function
<clever> bonda_000: it says nothing about if it returns or not
<clever> so you need to check memset_asm next
<bonda_000> memset_asm does return
<clever> then memset also returns
<bonda_000> but Ghidra doesn't bother to go and see that
<bonda_000> obviously, "memset" is a not a real, function, just a label of a branch to the assembly routine
<clever> yeah
<bonda_000> I get it with memset, but I don't quite get why it marked logging_message and memcpy as No return if both clearly end with an "rts"
<bonda_000> yeah it's all good with Non-returning options disabled
<bonda_000> Had to start fresh
bonda_000 has quit [Ping timeout: 260 seconds]
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 has joined ##raspberrypi-internals
<bonda_000> oh yeah now most of the stuff
<bonda_000> clever: now most of the stuff transferred over that I fixed memcpy, memset, and logging_message
<bonda_000> and luckily I was manually doing alphabetically so mostly labelled all of the new arm_ stuff
<bonda_000> that wouldn't be in the library any way
<bonda_000> clever: now I can just finish it off with remaining unresolved XREFs
<bonda_000> clever: I was wrong actually, I was on the path of manually labelling 60000 functions
<bonda_000> not 10000
bonda_000 has quit [Ping timeout: 268 seconds]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> clever: do you know why in the __os_main_hook() each core disables interrupts after doing rtos_start()?
<bonda_000> and then does "bkpt" aka "swi"?
<bonda_000> and then falls into an infite loop it never gets out of
<bonda_000> if it disabled interrupts how the rtos is going to work?
<clever> bonda_000: that sounds like what happens when you return from main()
<clever> its never supposed to reach that code
<bonda_000> no that's prior to main
<bonda_000> let me check
<bonda_000> in the unstripped elf
<bonda_000> 0ec31060 is where core1 jumps
<bonda_000> and the first thing it does is __os_main_hook()
<clever> checking
<clever> thats refernece by _start and it isnt decompiling well, let me read the asm line by line
<bonda_000> label 0ec30fc8 and 0ec31060 as functions
<clever> yeah, that fits
<bonda_000> there isn't an explicit function call, but rather it sneaks one of those values into lr based on version()
<clever> i labeled them core0_start and core1_start
<clever> core0_start will run various startup hooks, run main(), and then run `exit()`
<clever> core1_start just runs 2 hooks, main, and exit
<bonda_000> yeah but look at __os_main_hook()
<bonda_000> that's where both cores end up trapped
<bonda_000> in that infinite loop with disabled interrupts
<clever> but it runs rtos_start first
<clever> which likely starts the rtos
<clever> that likely doesnt return
<clever> so it never reaches main() ?
<bonda_000> ulonglong rtos_start(undefined4 param_1,undefined4 param_2)
<bonda_000> checks cpu number
<bonda_000> core 0 goes into main
<bonda_000> core 1 goes into _tx_initialize_low_level()
<clever> ah
<clever> so the other main() call we saw, never gets ran
<clever> and __os_main_hook is a no-return
<bonda_000> right
<clever> looks like somebody jammed an rtos into a weird place
<clever> "it works, ship it"
<bonda_000> so for core0, main starts _tx_thread_start_scheduler() and then returns
<clever> so both cores will ultimately land in _tx_thread_start_scheduler
<clever> and then the scheduler decides what they are doing
<bonda_000> yeah _tx_thread_schedule has an infinite loop with one break condition
<bonda_000> and that is
<bonda_000> something based on the thread struct that is pointed at by r29
<bonda_000> which is updated to ST_7e003000.CLO each loop iteration
<clever> i think its taking the current time (ST_CLO) and storing it in the current thread, and going to sleep
<clever> what you cant see in the disassembly, is that it ran the `sleep` opcode
<clever> `sleep` will process interrupts, even if they are disabled
<clever> so the field in gp can then change, and it will check it again
<bonda_000> ah yeah sleep doesn't show up in the pseudocode
<clever> so i think this is the cpu_idle() loop
<bonda_000> so if it woke up, it does what?
<clever> when there is no runnable thread, the scheduler will go to sleep here
<clever> after it wakes up, it checks gp+0xf9c again
<clever> and once f9c has something, it will call _tx_thread_schedule
<clever> and it will then change to another thread
<bonda_000> it saves the timer value several times into that thread struct
<clever> likely for cpu usage tracking, when a thread started and stopped
<bonda_000> so it is saying
<bonda_000> if something started the system timer
<bonda_000> I am free to go?
<bonda_000> if (uVar3 != 0) break;
<bonda_000> nevermind the decompile window is broken
<bonda_000> it doesn't even show that it can branch to __tx_thread_schedule it
<bonda_000> no, it's actually lying
<bonda_000> it should be
<bonda_000> if (uVar3 != 0) __tx_thread_schedule_it();
<bonda_000> clever: and that's on core1 initially, while core1 is doing that core0 is in the main probably scheduling some task
<bonda_000> core0 is scheduling vmcs task
<bonda_000> and that's gonna literally do everything
<bonda_000> look at 0ee8e7d2 and around it
<clever> busy with a few things now
<bonda_000> no problem
jcea has joined ##raspberrypi-internals
bonda_000 has quit [Quit: Leaving]