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
t0mm13b_ has quit [Quit: ZNC - https://znc.in]
t0mm13b has joined ##raspberrypi-internals
hackkitten has quit [Ping timeout: 268 seconds]
hackkitten has joined ##raspberrypi-internals
hackkitten has quit [Ping timeout: 268 seconds]
jn has quit [Ping timeout: 272 seconds]
jn has joined ##raspberrypi-internals
jn has joined ##raspberrypi-internals
jn has quit [Changing host]
hackkitten has joined ##raspberrypi-internals
hackkitten has quit [Ping timeout: 264 seconds]
hackkitten has joined ##raspberrypi-internals
f__ has joined ##raspberrypi-internals
f_ has quit [Ping timeout: 260 seconds]
f__ is now known as f_
ryao has quit [Ping timeout: 252 seconds]
jcea has quit [Ping timeout: 256 seconds]
vriska has quit [Read error: Connection reset by peer]
vriska has joined ##raspberrypi-internals
Siecje has joined ##raspberrypi-internals
jcea has joined ##raspberrypi-internals
dolphinana has joined ##raspberrypi-internals
<dolphinana> hi! o/
<clever> dolphinana: *waves*
<dolphinana> good to see you again clever! ^^
<f_ridge> <f​_[mtrx]/M> hi
<f_> hi
<dolphinana> hi f_
<f_> ^^
<f_> Long time no see :P
<dolphinana> indeed :P
<dolphinana> great to see y'all again! ^^
<f_[xmpp]> Wanting to hack on RPi again?
<dolphinana> yes ^^
<f_[xmpp]> nice :)
<dolphinana> I've been pretty busy in the last few months, so I didn't really have time to hack on RPi
<dolphinana> but now I'm a bit more free ^^
<clever> dolphinana: most recently, ive been hacking on the RP1 and got some things like PIO working
<dolphinana> RP1? Is that the new in-house chip by Raspberry Pi? Used in Raspberry Pi 5?
<clever> yep
<dolphinana> ooooh,
<dolphinana> I see ^^
<dolphinana> what does PIO mean?
<clever> the RP1 has 2 csi, 2 dsi, gpio, dual, cortex-m3, usb3, ethernet, and pio
<clever> the same PIO as the rp2040
<dolphinana> aaah, oki ^^
<clever> also, the rp2040 is the 2nd chip in the family
<clever> the RP1 came first
<clever> but the rp2040 was released to the public first
<dolphinana> I see
<dolphinana> I never knew that o.o
<clever> damn near all of the IO on the pi5, goes thru the RP1 chip
<clever> the hdmi, wifi, uSD, and pcie, are the only things still on the SoC
<dolphinana> aaah
<dolphinana> what is uSD?
<clever> micro sd card
<dolphinana> oooh, why call it uSD? It makes me confused xD
<clever> because i dont have the μ on my keyboard to call it μSD
<dolphinana> oh, okay :P
<dolphinana> clever: having a good day?
<clever> yep
<dolphinana> great to hear
<dolphinana> I'm also having a good day ^^
<clever> the pi4 and pi5 are fairly similar in design, in terms of firmware and dram
<dolphinana> mhm
<clever> they use the identical spi flash filesystem
<clever> and both use the memsysxx.bin files for dram init
<clever> for the pi4, bootmain.elf is just another stage in the loader, and it loads start4.elf from the boot media
<clever> for the pi4, bootmain.elf is the final stage, and it implements all of the runtime services (mailbox stuff)
<clever> oops, pi5 on the 2nd one!
<dolphinana> ah, I understand
<clever> in both cases, bootmain.elf is just a file in the SPI flash
<clever> but pi5 signs things differently
<clever> and its much better sealed up, so i have yet to get a rom dump
<dolphinana> oh, so it's more difficult to get a rom dump?
<clever> yeah
<dolphinana> damn..
<clever> for the pi0-pi3, bootcode.bin isnt verified, so a custom bootcode.bin can just read the rom and dump it to uart
<clever> for the pi4, recovery.bin is verified, but start4.elf isnt, so a custom start4.elf can just dump it
<dolphinana> good luck on getting a rom dump from pi5
<dolphinana> btw, how do I get the rom dump from pi1?
<clever> `make PROJECT=rpi3-bootcode` will generate a lk.bin file
<clever> rename it to bootcode.bin, and it will run on anything in the pi0-pi3 family
<clever> once booted, it will give a shell on the serial port, gpio 14/15, 115200 baud
<dolphinana> (I will not do it now, but I'll do it later ^^)
<clever> and there is a command to dump bytes
<clever> at 0x60000000 is the boot rom
<clever> ] db 0x60000000 0x5000
<clever> 0x60000000: 00 b0 00 01 f0 81 00 c0 e0 00 00 6d 82 18 0d 1f
<clever> 0x60000010: 1d c0 41 07 18 e8 00 80 00 60 19 e8 47 80 00 60
<clever> an example of running the dump bytes command, and the first 32 bytes it gave
<clever> then you just capture the uart traffic, and convert it to a .bin
<clever> one problem, is that something in the official start(4).elf turns the rom off
<clever> so you cant read the rom once linux has booted
<clever> so you need to hijack the boot before that stage
<dolphinana> thank you so much for the info ^^
<clever> and with the pi5, there are no unverified stages you can hijack....
<clever> there was also this fun mailbox property
<clever> it lets you execute arbitrary VPU assembly
<clever> its missing on the pi5
<dolphinana> oooooh
<clever> an example of using that mailbox call
<dolphinana> I see
<dolphinana> btw, is the size of the bootROM 0x5000 large?
<clever> [clever@amd-nixos:~/apps/rpi/roms]$ hexdump -C rpi1-230aad04.bin | tail
<clever> 000047c0 02 3d 00 60 32 3e 00 60 40 00 00 00 05 00 00 00 |.=.`2>.`@.......|
<clever> 000047d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
<clever> *
<clever> looks to be about 0x47c0 bytes
<dolphinana> ah, okay ^^
<clever> ive got dumps for the roms from the pi1, pi2, pi3, pi4, and pi400
<clever> pi1 and pi2 are nearly identical
<dolphinana> (I'll be away now, see y'all later, perhaps later today?)
<dolphinana> (I will stay in the IRC chat tho... will just be inactive)
<Siecje> How does the Pi5 prevent you from reading the ROM?
<clever> Siecje: the main way, is that the VPU just doesnt allow running unsigned code
<clever> so you just cant run code to read the ROM
<Siecje> Why does Raspberry Pi the company care?
<Siecje> Security through obsecurity? So people can't learn how it works?
<clever> i dont really know
<Siecje> Or so you can't create a clone board?
<clever> you cant buy the SoC, so you cant produce a clone
<clever> and even if you could buy the SoC, you dont need the rom to make clones
<clever> assuming you could flash the OTP to enable booting from spi
<clever> but, i would assume a brand new SoC, might have verification disabled
<Siecje> I remember working somewhere in 2013 and someone was complaining about NDAs with Raspberry Pi. They ended up going with Beagle Bone black, not sure if it was any better.
<Siecje> "the USB host controller is under NDA"
<Siecje> Any idea why that is important? Or if it is still the case?
<clever> Siecje: the docs for the dwc2 controller are behind NDA (but have leaked, google can give you them)
<clever> they only matter if you want to use the dwc2 outside of linux
<clever> or improve the linux drivers
<clever> Siecje: also, the EZR32WG chip from silicon labs has a dwc2, and they did release docs
<clever> so if you just read the EZR32WG docs, youll get 90% of what you need
<Siecje> This was an embedded linux software company. They were looking for a device for training. They even thought touch screens were cheap enough that students could keep the hardware after the training.
<clever> depends on what exactly your training for
<Siecje> There were all kinds. Anything with encryption for the USA had restrictions.
<clever> i believe the entire pi0-pi4 lineup lacks hardware crypto extensions
<clever> only with the pi5 did they add arm hw crypto extensions
<Siecje> Even if the training was about how RSA worked there were import/export restrictions.
<Siecje> Does Pi5 have a TPM?
<clever> no proper hw TPM on the pi5
<Siecje> What did they add? Hardware to do crypto operations faster?
<clever> yeah
<clever> standard arm crypto extensions
<f_> clever: yyyyeeeahhhh good luck with dumping the bootROM on that Pi5..
<clever> ive got 2 plans currently, for gaining execute on the VPU, but both involve booting linux first
<clever> at which point, the rom will have dropped off the bus
<clever> so, how do i bring the rom back onto the bus?
<clever> is it even possible? the gameboy didnt allow it
Siecje has quit [Quit: Leaving...]
dolphinana has left ##raspberrypi-internals [##raspberrypi-internals]