<bonda_000>
mkswap: ./foo.img: warning: wiping old swap signature.
<bonda_000>
Setting up swapspace version 1, size = 10 GiB (10737414144 bytes)
<bonda_000>
no label, UUID=e4ade729-9136-49be-baf5-c64171383c16
<clever>
you dont need to mkswap again
<clever>
it was already made
<bonda_000>
total used free shared buff/cache available
<bonda_000>
Mem: 3783 2071 122 21 1889 1712
<bonda_000>
Swap: 10239 0 10239
<clever>
now you can try the build again
<bonda_000>
hopefully it doesn't complain at me just pulling the vc4 folder from Windows version that I was using
<bonda_000>
there was Ghidra/Processors/VC4 which I made and then there was another 'VideoCore' folder which I guess it made by itself, I had Eclipse with plugins hooked up to it
<bonda_000>
I mean Ghidra/Processors/VC4 I dragged and dropped in there
<clever>
gonna head upstairs for a bit
<bonda_000>
ok
<bonda_000>
huh I didn't even need to build anything everything from that Windows works on Linux
<bonda_000>
just have to decompile it all over again
<clever>
thats kinda the point of java
<bonda_000>
I hope its not laggy
<bonda_000>
idk its a bit laggy but its doing something atm
<bonda_000>
I guess I need to build if I want to write my own tools for it
<bonda_000>
i really wanna see what's in that Gp area
<bonda_000>
of bootrom
<bonda_000>
that it always refers to
<bonda_000>
I think it points at 60008000 when it steps into bootcode
<clever>
thats sram
<bonda_000>
like a bunch of constants maybe
<clever>
and something i forgot to explain, is the .bss and .data handling
<bonda_000>
from .elf?
<clever>
for things like the rom, and that run directly from flash, .data is a bit weird
<clever>
there is a read-only copy of .data in the rom/flash
<clever>
but you need to get it into ram somehow
<clever>
if you search the rom for INI case sensitive, youll find a `INI\2` string at around 7220 into the binary
<clever>
do you see that?
<bonda_000>
the bootrom?
<clever>
yes
<bonda_000>
Im currently decompiling start_elf_unstripped
<bonda_000>
I haven't got to bootrom yet
<bonda_000>
literally just launched
<bonda_000>
plus I haven't figured out how you feed it binaries without wrapping them into .elf
<bonda_000>
I have an elf I tweaked still
<bonda_000>
bootrom.elf
<clever>
when you import the .bin file, you have to select vc4 and then hit advanced and set the base addr
<bonda_000>
ok
<bonda_000>
once its done with start_x_unstripped.elf I will do that
<bonda_000>
by the way
<bonda_000>
about generating that patterns directory
<bonda_000>
how do you do that?
<clever>
tools, function id
<bonda_000>
is it somewhere by default? I see ARM has it and pretty much all of the default languages have the "Patterns" folder
<bonda_000>
do I do that before I decompile or after?
<clever>
ah, no idea what that is
<bonda_000>
I guess after
<bonda_000>
well it should collect and better recognize assembly patterns
<bonda_000>
not sure what that does, it already does a great job
<clever>
this is the INI\2 region i was refering to
<clever>
first, you have an unsigned 32bit int, the destination addr
<clever>
then you have a signed int (right click, convert, if its not showing negatives right)
<clever>
a positive number like 50h (50 hex), means copy the next 0x50 bytes to the destination
<clever>
its then followed by another destination, size, and 0x15a bytes
<clever>
then 2 nulls (padding, i guess it wants 32bit alignment)
<clever>
then a destination, and a NEGATIVE size of -36, this means to just zero out 36 bytes at the specified addr
<clever>
the best way to handle this, is to generate more LOAD sections in the elf header
<clever>
then ghidra will just do everything correctly
<bonda_000>
elf header for the bootrom?
<clever>
yep
<clever>
https://i.imgur.com/nBsUI2z.png but i didnt have an elf, so i just manually went into the memory window, and filled in the right numbers, using the initialized thing, you can take a chunk of the original file
<clever>
the bootcode.bin files use the same INI\2 scheme, so youll get more then 4 uses out of this tool
<clever>
let me have a look at creating such a tool, ive been wanting one for a while...
<bonda_000>
before RAM is on, the VPU executes the bootrom code from L2 cache and it starts at 60000000
<bonda_000>
it then loads the bootcode.bin also into L2 cache and branches there with r24=60008000
<clever>
the L2 cache is also not usable at reset
<clever>
the rom has to turn the L2 cache on first
<clever>
60000000 is rom, and 60008000 is sram
<bonda_000>
so 60000000 - 60010000 is a bootrom
<bonda_000>
and you say its RAM
<clever>
the rom sets up L2 cache-as-ram, loads bootcode.bin to 0x80000000, and then jumps so it
<bonda_000>
60000000 - 60010000 is ROM*
<clever>
60008000 is sram
<bonda_000>
oh yeah you told me
<bonda_000>
where it ends
<bonda_000>
where all the zeros start
<clever>
when bootcode.bin is passing control off to start.elf, it will copy a small chunk of assembly from L2 cache to sram(60008000)
<clever>
and then bootcode.bin jumps back to the code in sram
<clever>
and that code changes L2 config settings, and then jumps to start.elf
<clever>
its not safe to be using the L2 when changing L2 settings
<bonda_000>
so then rom is somewhere starting at 6000000 and how big is it?
<bonda_000>
like last time you pointed me that zeros start somewhere around 60003700h or so but is that an indicator that its the end of physical ROM?
<clever>
that looks like a normal function, hit f to tag it as one
<bonda_000>
at 6000b12e there is a string u"Broadcom"
<bonda_000>
I'm referring to the BCM2837 document which says 40000000-80000000 alias '4' is L2 cache coherent(non-allocating) and it's split in four parts
<clever>
the rom at 0x6000_0000 and the sram at 0x6000_8000 arent covered in the docs
<clever>
and they shadow the normal 4 alias
<bonda_000>
SDRAM beginning at 40000000 then some blue rectangle unnamed, then I/O periph which may be the ROM
<bonda_000>
then a thin slice before 80000000 also unnamed
<clever>
those thin slices used to be nothing
<clever>
back when there was only 256mb of ram
<clever>
then the ram kept growing, and growing
<bonda_000>
so bootrom brings up the L2 cache and loads bootcode.bin in there correct?
<bonda_000>
RAM is still disabled
<bonda_000>
until bootcode.bin turns on RAM controller
<clever>
yeah
<bonda_000>
so then how in my dumpbootrom I read address 6000b12e and its a unicode string u"Broadcom" how did that get into L2 cache?
<bonda_000>
if you are saying ROM ends at 60004700 and its way past that
<clever>
my only guess, is that some bits of the address bus are ignored
<clever>
so the data is just repeating at regular intervals
<clever>
that b in the addr, is 1011 binary
<bonda_000>
at 6000b874 string "bootcode.bin"
<clever>
bootcode.bin loads to 0x8000_0000
<clever>
if your seeing a 6, you set the base addr wrong
<clever>
ah wait, you mean the bootcode.bin filename, appears in the rom
<bonda_000>
it does kind of
<clever>
thats within the INI\2 regions i just explained
<bonda_000>
at 6000a074 also string "bootcode.bin"
<clever>
it gets copied during bootup
<clever>
re-read what i said about INI\2
<bonda_000>
then its no worries
<bonda_000>
so the first thing bootROM does is enable L2 cache that gives it 128KB of memory right?
<clever>
the boot rom only uses that as a buffer, to hold the bootcode.bin
<clever>
the bulk of its variables go into sram at 0x6000_8000
<clever>
same reason elf has a random 7f in the start
<clever>
somebody flipped a coin and decided so
<clever>
so that first int32 is the destination, and the 2nd int32 is the size
<clever>
the next $size bytes, need to be copied to destination
<clever>
you can either do that with a LOAD header in the elf, or by creating a new region in the memory window, and setting the initialize params right
<clever>
after $size bytes (rounded up to a multiple of 4), you have another addr/size pair, repeat, until the addr is 0
<bonda_000>
so db[80] is which part of this INI/2 protocol
<bonda_000>
data bytes?
<clever>
yeah
<clever>
i just hit t, and then set the type to `byte[0x50]`
<bonda_000>
yeah 50h is 80 decimal
<clever>
and ghidra then turned it into 80 on me
<bonda_000>
nice
<bonda_000>
yeah then go all the strings
<bonda_000>
"bootcode.bin" "bootsig.bin"
<bonda_000>
repeated twice
<bonda_000>
when I try to put these strings as an array of bytes it says "Data applied from 60007284 to 600073dd conflicts with existing defined data!"
<clever>
ghidra auto-detected something in that range, and tagged it as something
<clever>
youll have to scroll down, find that thing, and use c to clear it
<bonda_000>
well there are strings "bootcode.bin" "bootsig.bin" "bootcode.bin" "bootsig.bin" then a bunch of data 79000000 54130060 etc
<clever>
yeah, thats all data that will be copied elsewhere
<bonda_000>
I think its warning that I'm gonna pack these strings into a byte array and asking if I want to do that
<clever>
so you can just clear it, and hide it behind the array
<bonda_000>
oh okay so its the format
<bonda_000>
Dest_Address Length Bytes
<clever>
yes
<bonda_000>
so the program that runs in the ROM is going to look up this area at 60007220 for data and instructions where to write that data
<clever>
yes
f_ has quit [Remote host closed the connection]
<bonda_000>
brb I'm gonna cook food
<clever>
and this will initialize a bunch of variables in 0x6000_8000
f_ has joined ##raspberrypi-internals
<bonda_000>
hold on
<bonda_000>
wasnt there supposed to be an XREF if the program that successfully decompiled acceses this data?
<bonda_000>
or rather, wrote data to this location I'm still processing this
<clever>
its a gp relative reference
<clever>
the function at 0x6000_1472, is taking gp, and subtracting a huge number from it
<clever>
then checking for the INI\2 magic
<clever>
ghidra isnt aware of what gp is, so it cant make an XREF
<clever>
but youll always find it setting gp within the first few opcodes of the entry-point
<bonda_000>
yeah right away at 60000014 does mov gp, 0x60008000
<bonda_000>
so then why is the rest of the code not acknowledging it knows whats in gp
<clever>
because ghidra doesnt understand that
<clever>
ghidra assumes that r0-r5 are arguments, and everything else is local to the function
<bonda_000>
if (unaff_gp != 0xc08) {
<bonda_000>
also whats unaff_gp stand for
<clever>
un-affliated
<bonda_000>
unaffected?
<clever>
ghidra is complaining that something used gp, and gp was never set
<clever>
so it has no clue what it is
<clever>
ive already told you how to deal with that
<clever>
2024-04-28 11:44:20< clever> down in the data type manager, under your elf file, create a new struct, call it gp_area, and make the size at least 0x2000
<clever>
2024-04-28 11:44:24< clever> and hit save
<clever>
2024-04-28 11:44:42< clever> then select that `unaff_gp`, hit ctrl+l, and set it to `gp_area*`
<clever>
2024-04-28 11:45:20< clever> and then select the new variable, and use `l` to rename it to `gp`
<clever>
2024-04-28 11:45:26< clever> it will turn into things like `*(uint*)&gp->field_0x1234`
<bonda_000>
yeah but it should be around the 60008000 it can't start at 60008000 because there is clearly subtraction
<clever>
ignore the subtraction stuff
<clever>
thats rarely done, and the struct hack wont handle it
<bonda_000>
so starts at 60008000, 0x2000 bytes long, volatile
<bonda_000>
not zero initialized
<bonda_000>
won't let me do it says Block Address conflict [60008000, 60009fff
<bonda_000>
it has a book for it by Andrew Tanenbaum Operating Systems Minix book since I'm a noob in it and that's what they use in Universities to teach OS class these days
<bonda_000>
so
<bonda_000>
if its a GNU toolchain it should have everything needed right?
<clever>
you would still need to implement a userland, library loading, context switching, irq handling
<bonda_000>
it's all in there it just need a hardware layer
<clever>
context switching is part of the hardware layer
<clever>
as is irq handling
<bonda_000>
yup
<bonda_000>
I just want to check first if vc4-toolchain compiles with itself
<clever>
that wont work until you have a libc for vc4 and your kernel
<clever>
so you need to build your libc first
<bonda_000>
hold on there are a lot of libs being built in the vc4-toolchain
<bonda_000>
binutils/libvc4
<bonda_000>
thats like assembly stuff there
<bonda_000>
binutils/libiberty
<bonda_000>
gcc-vc4/libcc1
<bonda_000>
gcc-vc4/libcpp
<bonda_000>
gcc-vc4/libobjc
<bonda_000>
no libc that I see but cpp should be similar
<clever>
libc isnt part of the vc4-toolchain
<clever>
the libc needs to support the kernel you want to use
<bonda_000>
and thats like memset
<clever>
yeah
<bonda_000>
how did they not put libc in here or it doesnt come with gcc?
<bonda_000>
oh I see I need to interface libc with system calls in Minix
<bonda_000>
oh thats everything that I use daily like printf and so on
<bonda_000>
stdio.h, stdlib.h, to name the few
<bonda_000>
do you wanna team up on that?
<bonda_000>
I'm gonna use this as a reference on what function to build
<bonda_000>
All the machine-dependent and operating system-dependent files in the library are in the subdirectory sysdeps under the top-level library source directory. This directory contains a hierarchy of subdirectories (see Layout of the sysdeps Directory Hierarchy).