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 has quit [Quit: Leaving]
jcea has quit [Ping timeout: 240 seconds]
Stromeko has quit [Ping timeout: 255 seconds]
Stromeko has joined ##raspberrypi-internals
bonda_000 has joined ##raspberrypi-internals
f_ has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 246 seconds]
bonda_000 has joined ##raspberrypi-internals
<bonda_000> Happy Orthodox Easter to everyone celebrating
<bonda_000> :clever using your linker script bootcode.ld to compile my own little bootcode program
<bonda_000> bimbom@max:~/Desktop/armtimer/minix$ vc4-elf-ld -o prog sdram udelay -T bootcode.ld -lgcc
<bonda_000> vc4-elf-ld: cannot find -lgcc
<bonda_000> I guess it needs the vc4-toolchain/gcc-vc4/libgcc but doesn't know where to look for it
dolphinana has joined ##raspberrypi-internals
<clever> bonda_000: when you built gcc, it should have produced a libgcc.a
<clever> do `find / -name libgcc.a` to find it
<clever> you need to tell the linker where to look with a `-L/path/to/that/dir/`
<clever> that is better solved when you build binutils, you can set the default search path somehow
<bonda_000> how di I distinguish between amd64 and the vc4 libgcc ?
<bonda_000> do*
<bonda_000> it shows a crap ton of libgcc's
<clever> the vc4 gcc will be in whatever directory you installed the vc4 gcc to
<clever> lib/gcc/vc4-elf/6.2.1/libgcc.a
<clever> it will be a path like that
<bonda_000> some are pointing to /nix/ dir
<bonda_000> which we used to compile lk-overlay only right?
<bonda_000> /nix/store/cwpy4q0qvdwdif1zfwnfg5gi50c6j9w8-vc4-elf-stage-final-gcc-debug-6.5.0/lib/gcc/vc4-elf/6.2.1/libgcc.a
<bonda_000> /nix/store/v36hzrcnzprcxnrwsd3apkhy2j0if3n4-vc4-elf-stage-static-gcc-debug-6.5.0/lib/gcc/vc4-elf/6.2.1/libgcc.a
<bonda_000> this looks ok: /home/bimbom/Desktop/vc4-toolchain/gcc-build/gcc/libgcc.a
<bonda_000> actually here is the full list
<clever> yeah, if your using the copy you built yourself, then you want the one in Desktop/vc4-toolchain
<clever> /home/bimbom/Desktop/vc4-toolchain/prefix/lib/gcc/vc4-elf/6.2.1/libgcc.a
<clever> this is the one you want
<clever> 2024-05-05 10:05:34 < clever> lib/gcc/vc4-elf/6.2.1/libgcc.a
<clever> 2024-05-05 10:05:39 < clever> it will be a path like that
<bonda_000> I haven't really installed vc4-elf toolchain I guess, since every time I open terminal I have to go to vc4-toolchain/ dir and type "export "PATH=$PWD/prefix/bin:$PATH"
<clever> you did install it, to /home/bimbom/Desktop/vc4-toolchain/prefix
<bonda_000> well it always disappears from my PATH
<clever> because PATH is just an env variable
<clever> and its lost when you close that shell
<clever> either modify your .bashrc to add it to PATH automatically, or install it again to /usr/local
<bonda_000> so I need to explicitly tell the linker path to libgcc
<clever> 2024-05-05 10:04:02 < clever> that is better solved when you build binutils, you can set the default search path somehow
<bonda_000> I thought I built all
<bonda_000> follow the guideline
<clever> but you didnt configure it correctly
<bonda_000> oh
<bonda_000> ./build-all.sh 2>&1 | tee build.log
<bonda_000> is how I built it
<clever> then that script didnt configure it correctly
<bonda_000> did you build it differently?
<clever> i built it with nix
<bonda_000> with what command
<clever> just run `nix-shell` in the `lk-overlay` directory
<bonda_000> oh yep that's what I did
<bonda_000> let's try again
<bonda_000> I thought I had it
<bonda_000> says sudo: nix-shell: command not found
<clever> dont run it with sudo
<bonda_000> ok now it's hanging thinking
<bonda_000> I'm in
<bonda_000> [nix-shell:~/Desktop/vc4-toolchain]$
<clever> now you can build things normally
<bonda_000> like 'make' or use one of their scripts?
<clever> just normal vc4-elf-ld and vc4-elf-gcc will work there
<bonda_000> or 'build'
<clever> `make PROJECT=vc4-stage1` if you want the stage1 bootlodader from LK
<bonda_000> no I was trying to use the toolchain to build a simple binary
<clever> 2024-05-05 10:18:54 < clever> just normal vc4-elf-ld and vc4-elf-gcc will work there
<bonda_000> like enable uart, sdram, and test If I can write to C0000000 - FFFFFFFC
<bonda_000> well they worked before also
<bonda_000> I guess I didn't link properly
<bonda_000> what's the benefit of using nix shell in this case?
<clever> it builds the binutils and gcc for you
<bonda_000> as I write make Project vc4 stage1?
<clever> when you run `nix-shell`
<bonda_000> it built vc4-binutils and vc4-gcc while it was starting up?
<clever> it was probably already built, given you had things in /nix/store/
<clever> so it just setup $PATH for you
<bonda_000> yeah
<bonda_000> oh yeah now my PATH looks way bigger
<bonda_000> [nix-shell:~/Desktop/armtimer/minix]$ vc4-elf-ld -o prog udelay sdram -T bootcode.ld -lgcc
<bonda_000> /nix/store/02j1692sjdp5pgzazqn98swgz115byds-vc4-elf-binutils-2.31.1/bin/vc4-elf-ld: cannot find -lgcc
<bonda_000> why did you need GROUP(-lgcc) in your .ld anyway?
<bonda_000> what's in that library that lk uses?
<bonda_000> the .gnu.warning?
<clever> i dont remember what those do
<clever> arch/vpu/rules.mk:ARCH_LDFLAGS += -L/nix/store/cwpy4q0qvdwdif1zfwnfg5gi50c6j9w8-vc4-elf-stage-final-gcc-debug-6.5.0/lib/gcc/vc4-elf/6.2.1/
<clever> i also suspect my binutils isnt configured right either
<clever> i need that -L flag for it to work
<bonda_000> well I'm currently filling up my Ghidra with peripheral structs
<bonda_000> this already looks much better
<bonda_000> I allocated volatile memory, then defined a struct with all regs and defined that memory as a struct. the clock manager stuff
<bonda_000> hopefully I can import that to other .elfs that I have without issue
<clever> how did you import the struct?
<bonda_000> I haven't I'm writing them manually like this
<clever> that could definitely save me some time
<clever> ah
<clever> my problem is that i have to re-label every peripheral register, every time i import a new elf
<bonda_000> I'm sure I saw the import button somewhere in the Data Type Manager just recently
<bonda_000> commit data types to generic.clib?
<bonda_000> that should be a shared one
<clever> where are you seeing that option?
<clever> oh, thats new
<clever> new to me at least
<bonda_000> brb
<clever> bbl
<bonda_000> any idea what extraout_var is?
<clever> that tends to happen when ghidra doesnt get the return values right during decompile
<clever> look at the asm, which register is it?
<bonda_000> in that same function 5b8 is declared then "if (CONCAT31(extraout_var,bVar2) != 0) {"
<clever> i dont see that
<clever> is it the first if, that decides between 52 and 37?
<clever> `beq r0, 0, ...5d6` ?
<bonda_000> just something that came in in r0
<bonda_000> although it thinks the function takes no arguments
<clever> the problem is that ghidra doesnt understand that the function call returns a uint
<clever> you need to edit the function it just called, and set a return type
<bonda_000> undefined __stdcall FUN_600005b8(void)
<clever> not that function
<bonda_000> which one?
<clever> the one that calls, down around line 10
<clever> it only calls a single function
<bonda_000> bVar2 = FUN_60000470();?
<clever> yes
<clever> this is what mind looks like
<bonda_000> yeah that returned bool
<clever> it should be returning a uint
<clever> i see the problem now, bVar2 is a bool, but the compare is checking all 32 bits
<clever> so ghidra has to pull an extra 31 bits out of its hat, to make the compare happy
<clever> and that is what the extraout_var is, 31 bits that came out of nowhere
<bonda_000> yeah right
<bonda_000> it's not doing bittest its comparing with beq
<clever> which is a valid way to test for false and not false
<bonda_000> and that FUN_60000470 took something from sram
<bonda_000> since my bootrom is 64KB, 0x0 to 0x10000 I captured some of the sram
<bonda_000> what I probably want to do is zero it out
<bonda_000> and just make a sram struct
<clever> i dont think it needs to be a struct
<bonda_000> like you did before with gp_area
<clever> or rather, yeah, for gp yes
<clever> then you can just hit find references, and find the code i just linked
<bonda_000> does start_x.elf refer to that sram memory?
<bonda_000> let me see
<bonda_000> when I fixed gp at 60008000 there it showed me all the global variables
<clever> did you have to fix gp for every function?
<bonda_000> yeah I've been doing it manually Set register value
<clever> ah, so same as my struct hack
<bonda_000> but that elf has the defs for 60008000
<clever> does it show XREF's ?
<clever> as i expected, start_x.elf references the SRAM in 3 areas, otp, sdram, and aes/hdcp
<bonda_000> *(unaff_gp+0xsomething) became isp_initialised = 1;
<bonda_000> once I put a hard value for that entire function
<clever> sdram copies some code to sram, because you cant use dram when changing dram config
<bonda_000> sorry my bad
<bonda_000> **************************************************************
<bonda_000> * FUNCTION *
<bonda_000> **************************************************************
<bonda_000> undefined __stdcall isp_init(void)
<bonda_000> assume gp = 0xef07e00
<bonda_000> undefined r0:1 <RETURN>
<bonda_000> $t XREF[2]: Entry Point(*),
<bonda_000> isp_init .debug_frame::0001d0a4(*)
<bonda_000> 0ed71d5c a3 03 stm r6-r9, lr,(--sp)
<bonda_000> crap
<clever> otp uses sram because keys are sensitive, and you could sniff the dram bus
<clever> and aes/hdcp, same reason
<bonda_000> your struct hack wasn't showing global variables names
<clever> if you want to see them at 0x6000_8000, then you need to re-type that to the struct as well
<bonda_000> it does some copying at cec00bbe
<bonda_000> then does this
<bonda_000> cec00be8 10 cc 01 00 mov p16,r1
<bonda_000> thats a mutex
<clever> thats the suspend2ram code
<clever> its saving some things to sram, so it can turn the dram controller off
<bonda_000> do I declare sram 60008000 of length C000 as volatile, non-initialized?
<clever> not volatile, i prefer initialized to 0
<bonda_000> I have 20+ xrefs to SRAM
<bonda_000> in the unstripped start_x.elf
<clever> 2024-05-05 11:36:37 < clever> as i expected, start_x.elf references the SRAM in 3 areas, otp, sdram, and aes/hdcp
<bonda_000> yeah
Stromeko has quit [Ping timeout: 272 seconds]
Stromeko has joined ##raspberrypi-internals
bonda_000 has quit [Ping timeout: 256 seconds]
f_ has quit [Ping timeout: 260 seconds]
dolphinana has quit [Quit: Leaving]
bonda_000 has joined ##raspberrypi-internals
dolphinana has joined ##raspberrypi-internals
<bonda_000> do you know what's going on in the usb.h?
<bonda_000> :clever
<bonda_000> many registers redefined
<clever> for example?
<bonda_000> #define USB_DPTXFSIZ1 HW_REGISTER_RW(0x7e980108)
<bonda_000> #define USB_DIEPTXF2 HW_REGISTER_RW(0x7e980108)
<bonda_000> in the same header
<clever> just 2 different names for the same register
<clever> Device IN Endpoint Transmit Fifo Size Register: (DIEPTXFn)
<clever> Offset: 104h + (FIFO_number – 1) * 04h
<clever> that register only matters when the dwc2 controller is acting as a usb device
bonda_000 has quit [Ping timeout: 256 seconds]
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Quit: Leaving]
dolphinana has quit [Quit: Leaving]