<bonda_000>
now it didn't kill the link but it says speed on the cable is cut down tenfold
<bonda_000>
May 11 03:24:52 max kernel: r8169 0000:02:00.0 enp2s0: Link is Down
<bonda_000>
don't see anything on the journal about bootcode.bin though
<bonda_000>
May 11 03:26:19 max dhcpd[2535]: DHCPOFFER on 10.0.0.106 to b8:27:eb:47:c3:04 via enp2s0
<bonda_000>
and nothing else
<bonda_000>
this cable is a bit worn
<bonda_000>
Gonna look at the wireshark
<clever>
having some damages wires in the ethernet cable can mess with 1gbit a lot
jn has quit [Ping timeout: 260 seconds]
jn has joined ##raspberrypi-internals
jn has quit [Changing host]
jn has joined ##raspberrypi-internals
<bonda_000>
okay got a not damaged one
<bonda_000>
May 11 03:48:29 max kernel: Generic FE-GE Realtek PHY r8169-0-200:00: Downshift occurred from negotiated speed 100Mbps to actual speed 10Mbps, check cabling!
<bonda_000>
but that didn't stop it from
<bonda_000>
May 11 03:48:29 max dhcpd[2535]: DHCPDISCOVER from b8:27:eb:47:c3:04 via enp2s0
<bonda_000>
May 11 03:48:30 max dhcpd[2535]: DHCPOFFER on 10.0.0.107 to b8:27:eb:47:c3:04 via enp2s0
<bonda_000>
and then silence on the UART also
<bonda_000>
1211082.29843113010.0.0.110.0.0.107TFTP61Error Code, Code: File not found, Message: File not found
<bonda_000>
1201082.29465589810.0.0.10710.0.0.1TFTP62Read Request, File: bootsig.bin, Transfer type: octet
<bonda_000>
I think we had that before
<bonda_000>
it sent 34 packets of 512 bytes
<bonda_000>
and the 35th one had 428
<clever>
bonda_000: and which file did it ask for?
<bonda_000>
it's the one from the 10 year old repo ?
<clever>
oh, the 10 year old one likely doesnt support network booting
<clever>
so that would explain why it doesnt work
<clever>
grab the latest bootcode.bin and mix that in
<bonda_000>
oh
<bonda_000>
alright
<clever>
but then the same problem will just happen at the next step, the old start_x.elf doesnt support netboot, so it will expect to find everything on the SD card
<bonda_000>
what is it going to look for over the link?
<bonda_000>
Even if it loads is fine
<clever>
after start_x.elf and fixup_x.dat load, it will just go silent
<clever>
and your only feedback will be the status LED, and maybe the uart
<bonda_000>
If it can log itself booting is still ok
<bonda_000>
should I use the newer fixup file also?
<clever>
no
<clever>
the fixup must always come from the exact same version as the elf
<clever>
never mix the fixup files up
<bonda_000>
that's what I thought too just hopefully the 2019 bootcode works with the 2012 elf
<bonda_000>
I'm using the one from
<bonda_000>
2020-02-13-raspbian-buster
<bonda_000>
release
<bonda_000>
May 11 04:04:53 max kernel: r8169 0000:02:00.0 enp2s0: Link is Down
<bonda_000>
killed the link again
<bonda_000>
well this time there's a lot on wireshark
<bonda_000>
so after the last block of fixup_x.dat the link went down
<bonda_000>
and it printed these four lines over the UART
<bonda_000>
I'm not sure who does this
<bonda_000>
Pi or PC
<bonda_000>
and there is no palette on the TV screen that my HDMI is hooked to
<clever>
that was bootcode.bin printing those lines
<clever>
afterwards, bootcode.bin shuts the ethernet off
<clever>
and its the .elf's job to turn ethernet back on, if it supports it
<bonda_000>
well its kind of a hard reset as I have to go to network manager and activate it manually again
<bonda_000>
maybe there was no palette in 2012
<bonda_000>
or 2014
<clever>
is the hdmi connected?
<bonda_000>
wait
<bonda_000>
yes
<clever>
no signal?
<bonda_000>
stage 2 is bootcode no?
<bonda_000>
Yeah no signal
<clever>
stage 2 is the elf
<clever>
stage 1 is the bin
<bonda_000>
stage 1 bootrom?
<bonda_000>
stage 2 bootcode
<clever>
what is the status LED doing?
<clever>
stage 0 is the rom
<bonda_000>
stage 3 elf?
<bonda_000>
oh
<bonda_000>
I see
<bonda_000>
its just enabled green
<bonda_000>
both red and green enabled
<clever>
not sure what its doing then
<clever>
is this the original unmodified start_x.elf from the unstripped build?
<bonda_000>
unless Ghidra messed with it
<bonda_000>
I think I used the same file I imported to Ghidra
<clever>
i assume that is fine
<clever>
maybe try the old bootcode.bin and elf, on an SD card?
<clever>
oh, and which pi model is that elf even for!
<bonda_000>
3B
<clever>
Date: Thu Jun 26 17:57:25 2014 +0100
<bonda_000>
Yeah Pi 3B was already in the making
<bonda_000>
not on the market
<clever>
the pi2 came out in 2015
<bonda_000>
On mine it says
<clever>
so a 2014 elf, will only work on the pi1
<bonda_000>
Raspberry Pi 3 model B v1.2 (c) Raspberry Pi 2015
<clever>
wikipedia says it was released feb 2016
<clever>
so thats right on the edge
<clever>
so your elf doesnt support the pi3
<clever>
either use an older pi, or a newer elf
<bonda_000>
well since I've been decompiling this Pi for some time now
<bonda_000>
this elf*
<bonda_000>
and that's the only Raspberry Pi board that I have
<bonda_000>
what's the problem here
<clever>
the unstripped start_x.elf doesnt support the pi3 board
<bonda_000>
the SDRAM size that it doesn't know exist or what
<clever>
could be anything
<clever>
youll need to go thru the process of re-discovering those functions in a modern .elf file, and then carry over the knowedge you got from the unstripped one
<bonda_000>
or some otp value that's not hard coded in some switch statement
<bonda_000>
I can see what it looks like
<bonda_000>
I haven't really looked at it as you told me this one has all the metadata
<bonda_000>
does elf try read anything from the config.txt?
<clever>
yes
<clever>
bootcode.bin has a rather dumb config.txt parser, and lacks support for include statements
<clever>
while the modern start.elf has a complex config.txt parser and supports include statements
<clever>
so the file gets read 2 or even 3 times during boot
<bonda_000>
surprisingly start_x.elf of 2019 is 3.8MB
<bonda_000>
and start_x.elf of 2014 is 5MB
<clever>
the 2014 one is huge, because it has debug info
<clever>
somebody complained about the size, and RPF fixed the leak
<bonda_000>
and not a single one ever since then had metadata in it?
<clever>
correct
<bonda_000>
I mean it's already gold to have something like this
<clever>
yep
<bonda_000>
I wonder if Ghidra can automate that
<bonda_000>
labelling functions in a similar binary
<clever>
thats what the function id is for
<clever>
create a FID database, and add the unstripped binary to it
<bonda_000>
so open the unstripped one?
<clever>
yeah, and then add the symbols to the FID file
<bonda_000>
The 2019 one is currently open and decompiling
<bonda_000>
that's also curious
<bonda_000>
They say the VC4 can contain up to 16 QPU slices
<bonda_000>
but available are only 12
<bonda_000>
and at the same time, it's said the ISP block "may" use QPU slices for processing
<bonda_000>
so it makes me think - maybe there are, in fact, 16 slices, only 4 of them are locked for the ISP?
<clever>
i still think the isp and qpu are entirely unrelated hw blocks
<clever>
and they dont share anything
<bonda_000>
the very intro into VideoCore IV official document says
<bonda_000>
the QPU may be used for Image Processing
<bonda_000>
at the very bottom
<bonda_000>
still a black box mystery to us
<bonda_000>
the whole ISP thing
<bonda_000>
to be fair, I think to those firmware engineers that wrote the vpu firmware it may be as well
<bonda_000>
some data is labeled like L232 that seems like the patent entries
<bonda_000>
camera_ril_create is a page of magic values, that look like someone handed those out to the programmer
<bonda_000>
I may be wrong though, if we don't see the #defines in the stripped elf
<bonda_000>
What's a Common Symbols File?
<clever>
not sure, i dont have ghidra open currently, busy with another task
<bonda_000>
well, just populating FidDb with function didn't change anything in the newer .elf
<bonda_000>
I populated it in a stripped .elf but can't find an option how to apply it
<bonda_000>
the new one that I made, VC4FUNTAB.fidb is selected as Active
<clever>
one of the auto-analyze steps, is to apply the FidDb
<bonda_000>
I am decompiling second time after I populated the FidDb
<bonda_000>
Everything is still named FUN_ although right at the CAMERA_POOL_END the diff shows they are identical
jcea has quit [Ping timeout: 246 seconds]
<bonda_000>
on the good side, the 2019 firmware did boot properly from Ethernet
<fxsheep>
is it true that the only unstripped build of firmware are commit affe5cd9d3e1e8dcc29509f12fc3ed5153f3fb67 and 4f63c3bdd4d9ca4f308e683fe7e70501b4ac3232
fxsheep has quit [Quit: Client closed]
f_ has joined ##raspberrypi-internals
Stromeko has quit [Ping timeout: 264 seconds]
Stromeko has joined ##raspberrypi-internals
f_ridge has quit [Remote host closed the connection]
f_ridge has joined ##raspberrypi-internals
bonda_000 has joined ##raspberrypi-internals
bonda_000 has quit [Read error: Connection reset by peer]
bonda_000 has joined ##raspberrypi-internals
<bonda_000>
Ha it does work
<bonda_000>
the fiddb
<bonda_000>
I had to put a tick "Always apply FID labels" or something
<clever>
bonda_000: yeah, conflicts will happen, you need to read the given function in both elfs and fix it yourself
<bonda_000>
so it's saying these 5+ functions had the same hash?
<bonda_000>
and it can't tell which one of them this particular instance is?
<clever>
yeah
<bonda_000>
seems like quite many top-level functions have changed
<bonda_000>
camera_ril_create wasn't identified
<bonda_000>
low-level stuff like helper functions were recognized
<bonda_000>
surprisingly, all of the mmal hasn't changed and was recognized
<clever>
youll need to use xref's to find nearby functions that have changed too much and label them manually
<bonda_000>
but what I noticed is their compiler puts these functions in an alphabetical order
<bonda_000>
so, clearly, from the boot sequence I wrote about yesterday, exit() wasn't recognized. but I see it is preceded by an "exfat" function and superceded by "exp" function and structurally looks like an exit() function
<bonda_000>
yeah xrefs is a very good point. I will have to cross-reference the old and new files
<clever>
oh, if you go back to the initial ghidra window, and i think double click on an elf, it will open a new window
<clever>
then you can put the old&new elf's on different monitors
<bonda_000>
there's a diff that I ran yesterday
<bonda_000>
although it was scrolling both elfs simultaneously
<bonda_000>
so after the first mismatch it was all different