<clever>
and i recently discovered that this unrelated chip, is using the same usb core, and has actually bothered to document it
<clever>
samueldr: in theory, if i figure out some basic host-mode stuff, and get keyboard working, i could add generation stuff to my bootloader in the open firmware
<clever>
though, i could also just use the existing arm baremetal libraries as well
<samueldr>
but where's the fun in that?
<clever>
samueldr: exactly, and 2 other points as well
<clever>
none of the baremetal libs handle gadget/device mode!
cript0nauta has quit [Ping timeout: 256 seconds]
<clever>
and they all assume arm, and use FIQ, so i cant easily port them to VPU
<clever>
samueldr: look at the diagram on page 234 of the above pdf!!
<samueldr>
I like those kind of diagrams
<clever>
257, device mode
cript0nauta has joined #nixos-aarch64
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 256 seconds]
<angerman>
the ubuntu image they had did boot, the sd-image-aarch64.nix doesn't seem to boot up :-/
<clever>
skimming over the wiki i linked, i believe the mask rom will just load sector 64 into cache, and execute it, if some header is valid
<clever>
and that will then init ram, and load sector 16384 (uboot) and execute it
<clever>
so you just need to put some binaries at the right offsets, naked, within the disk
<angerman>
yea, I wrote the u-boot into 16384, but it still doesn't come up.
<clever>
and the idbloader at 64?
<angerman>
yep
quinn has quit [Ping timeout: 256 seconds]
<clever>
not sure then
<angerman>
I'll try the ubuntu one again.
orivej has joined #nixos-aarch64
quinn has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
quinn has quit [Ping timeout: 246 seconds]
cole-h has joined #nixos-aarch64
quinn has joined #nixos-aarch64
veleiro has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
quinn has quit [Ping timeout: 272 seconds]
quinn has joined #nixos-aarch64
quinn has quit [Ping timeout: 240 seconds]
quinn has joined #nixos-aarch64
quinn has quit [Ping timeout: 256 seconds]
quinn has joined #nixos-aarch64
quinn_ has joined #nixos-aarch64
quinn has quit [Read error: Connection reset by peer]
dongcarl has quit [Read error: Connection reset by peer]
Thra11 has joined #nixos-aarch64
quinn_ has quit [Read error: Connection reset by peer]
quinn has joined #nixos-aarch64
<colemickens>
hm, even after bumping raspberrypi-firmware I can't get usb boot to work with my nixos install
<clever>
colemickens: do you have an hdmi display connected?
<clever>
colemickens: did you reflash the SPI chip?
<colemickens>
I reflashed the eeprom bin, even tried yesterdays.
<colemickens>
It checksums the start4.elf and complains, I can send the pic of the hdmi output
<colemickens>
(not sure if eeprom == spi, hence why I answered that way)
<clever>
colemickens: was both start4.elf and fixup4.dat updated together?
<colemickens>
I updated the entire raspberrypi-firmware package and convinced myself that it was hwat the raspberry-bi boot nix/sh generator was using.
<clever>
colemickens: try mounting the boot fs, and just `ls -ltrh` the dir
<clever>
when where start4.elf and fixup4.dat last modified?
<colemickens>
I spot checked the sha256sum of one of the random ELF binaries to make sure the dropped copy in /boot matched the latest bin from their GH drop.
<colemickens>
I can do that too.
dongcarl has joined #nixos-aarch64
<colemickens>
on the rpi, those files get copied, so I feel like the timestamp might be when they were copied
<colemickens>
-rwxr-xr-x 1 root root 2.7M May 27 09:46 start4.elf
<clever>
that should still be useful info
<clever>
colemickens: what about fixup4.dat ?
<colemickens>
-rwxr-xr-x 1 root root 6.6K May 27 09:46 fixup.dat
<clever>
looks good
<clever>
what was the error on the hdmi?
<colemickens>
the time from `ls -ltrh` from all contents of /boot are that timestamp
<colemickens>
Hm, the sha256sum of start4.elf doesn't match the sha256sum if I curl the bin from that tag on GH.
<colemickens>
I might have a mistake somewhere still.
<clever>
try doing a `hexdump -C` on both files, then `diff -u` the 2 hexdumps
<clever>
do they differ slightly or massively?
<samueldr>
clever: holey is used to punch a hole in the GPT tables to make place for the initial bootloaders of some boards
<clever>
samueldr: yeah
<samueldr>
clever: so you can then use a full UEFI setup
<clever>
samueldr: but while looking into rockpi4 stuff with angerman , i found something more fancy and nicer
<clever>
samueldr: it has 3 partitions, at the correct offsets, so you dont need holes
<colemickens>
the diff is still pretty large. I need to recheck my work, maybe I missed a sha256 hash update
<clever>
colemickens: yeah, sounds like your just not using the start4.elf you think your using
cole-h has quit [Quit: Goodbye]
<clever>
samueldr: which would you prefer, holey, or proper partitions for each blob?
<samueldr>
proper partition, and especially, loaded by partition UUIDs
<clever>
in this case, the positions are hard set (somewhere)
<samueldr>
but in a pinch, partitions at specific offset can work
<clever>
yeah
<samueldr>
though annoying on MBR due to the limits of 4 physical partitions and such
<samueldr>
with GPT you can add a partlabel and partuuid so it's obvious what those things are
<clever>
GPT saves the day there
alp has quit [Ping timeout: 272 seconds]
<colemickens>
I wonder if I just didn't have /boot mounted when I nixos-install'd after updating the firmware. The sha256sum is right, and it even matches what I see when the rpi boots up, but it still complains.
<colemickens>
now I'm wondering if I need a non-tagged firmware releases?
<colemickens>
"start4.elf is not compatible" "USB-MSD boot requires newer software"
<colemickens>
actually, I have two rpi4s and this is still running the first usb release, not yesterdays which included some relevant-looking fixes.
<colemickens>
Seems like a newer set of firmware elfs is needed but I don't see it actually documented anywhere which commit is currently considered beta.
<colemickens>
sometimes I'm a bit surprised at the ad-hoc nature of some of the rpi stuff
<clever>
this nixos module, will add support for the open firmware
<clever>
it includes building the cross compilers, building the firmware, and copying the firmware to /boot/ along with configuring it to boot nixos
<colemickens>
is this primarily a passion/curiosity project? if you don't mind me asking? or is the hw ubiquitous enough that you see a big return on having it around as a freer platform?
<clever>
colemickens: a mix of things, partially to make it more open, partially to allow using the hw more fully
<clever>
colemickens: for example, every model of rpi has a dual-core VPU running at ~500mhz, that is capable of doing vector math and real-time things
<clever>
colemickens: i see way too many people trying to just ban linux from touching an arm core, to try and get more real-timey action out of a userland process, and fighting context switching the whole way
quinn has quit [Ping timeout: 256 seconds]
<clever>
colemickens: theres also just the matter of delays getting basic features implemented, because there is a limited number of engineers that have access to the source, and they are already busy
<colemickens>
by that you mean the foundation only has so many engineers that have the NDA'd source. presumably?
<clever>
yeah
<clever>
if i had the source, i could add basic features myself, and submit a pr
<clever>
but i dont, so i have to re-implement EVERYTHING from scratch first
<clever>
i just barely have linux booting, and the hdmi isnt working at all
<colemickens>
I would be curious to know what the process of working on this looks like for you. I wouldn't have the faintest idea where to begin, though I guess you packaged some tools to try to start decoding the gpu blob to RE it I guess?
<colemickens>
well not just re-implement but you don't even have the same internal HW knowledge that those with NDA do, so presumably you have to understand it, RE it, then implement it?
<{^_^}>
NationalSecurityAgency/ghidra#1147 (by paolovagnero, 32 weeks ago, open): Initial support of Broadcom VideoCore IV
<clever>
colemickens: this PR includes the ability to decompile VPU binaries
<clever>
colemickens: yeah
<colemickens>
cool. maybe time to see if I can find a ghidra tutorial to throw on, just for curiosity's sake
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<clever>
as for testing things
<clever>
the rpi3 is able to load bootcode.bin while network booting
<clever>
and rpi-open-firmware skips the start.elf stage, and can boot directly from bootcode.bin
<clever>
so i intentionally leave bootcode.bin out of my /boot/, and then i just build and scp it to the router
<clever>
then i can reboot the pi, and see if it works or not
<clever>
the problem, is that i lack the ability to do network in the firmware
<clever>
so zImage and initrd, must be on the SD card
<clever>
and if i break booting, i cant update it remotely
<clever>
so i have to swap the card between the laptop&pi, to unbrick things
<clever>
colemickens: i also have this, which shows how each component leads to the next
<colemickens>
ah this is so weird to me
<colemickens>
the idea that you can have networking working in a lower layer and then later it's not available to you
<clever>
colemickens: yeah
<colemickens>
I guess it's not weird, it's just something that just clicked as I grok'd the diagram and understood your problem, and something I take very for granted to not think about
<clever>
for the rpi3, the mask rom supports loading bootcode.bin over usb-msd or tftp via the lan95xx
<colemickens>
so the bootmask on the rpi3 is rather sophisticated itself it seems?
<clever>
but the bootcode.bin itself must then still support network, to load further files
<clever>
yep
<colemickens>
and that is completely RO? ( barring more extreme HW I assume?)
<clever>
i believe so
<clever>
the rpi4 entirely redid both the network and usb interfaces
<colemickens>
so once you get bootcode.bin to be able to load start.elf, will you have the same problem again?
<clever>
and rather then force users to buy a new board when the feature gets implemented
<clever>
they moved things to the SPI/eeprom
<clever>
the rpi4 holds bootcode.bin in the SPI eeprom chip
<clever>
and by reflashing it, you can then load start4.elf from usb, without needing to update the maskrom or jam bootcode.bin onto an SD card
<clever>
colemickens: in theory, once i have an open soure vpu usb driver, i can use that in both bootcode.bin and start.elf, and the problem wont exist
<colemickens>
hm, if you have to put start4.elf on there anyway, why do I care if I have to carry bootcode.bin too?
<colemickens>
is it conceptually cleaner or is there another advantage?
<clever>
more, that start4.elf is needed, to hold the "bloated" firmware, that does a crap-ton of things
<clever>
hw video accel (encode and decode), camera control, 3d libraries, and more
<clever>
if you put all of that into linux, then the firmware can be a lot smaller
<clever>
possibly enough to skip a start4.elf stage entirely
<colemickens>
okay, I see
<clever>
on the rpi 1-3, the mask rom loads bootcode.bin to addr 0x8000_0000, then jumps to 0x8000_0200
<clever>
the rpi3 can do that over usb mass-storage and tftp
orivej has quit [Ping timeout: 260 seconds]
<clever>
the official bootcode.bin then brings dram online, and loads start.elf
orivej has joined #nixos-aarch64
<clever>
and then start.elf loads kernel.img, and enables the arm
<clever>
and start.elf and kernel.img then co-operate over control of things, and talk over a mailbox
<clever>
colemickens: all make sense?
<colemickens>
sort of
<clever>
the open firmware jams everything into a single bootcode.bin
<clever>
on the rpi4, things are a bit different
<clever>
under normal conditions, bootcode.bin lives in the SPI chip, along with several other firmware files (ddr4 firmware, usb firmware, graphics, fonts)
<clever>
and once the dram is online, it will load start4.elf into ram
<colemickens>
hm I was surprised to see firmware/startelf.{c,S} in the open firmware repo then ?
<clever>
colemickens: those where more of experiments, to confirm how it works
<colemickens>
aha
<clever>
but ive moved that experimenting to the LK repo
<clever>
the .elf stages currently rely in the closed bootcode.bin to load
<colemickens>
so how much of what you're doing would have to be redone to target rpi4 then?
<clever>
main problem right now is the ddr4 controller
<clever>
but i could ignore that, and go right to try to boot the arm
<clever>
and use the closed bootcode.bin
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
quinn has quit [Ping timeout: 265 seconds]
quinn has joined #nixos-aarch64
alp has joined #nixos-aarch64
quinn has quit [Ping timeout: 240 seconds]
quinn has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
Thra11 has quit [Quit: WeeChat 2.8]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
veleiro`` has joined #nixos-aarch64
veleiro` has quit [Ping timeout: 246 seconds]
comrandroxaos[m] has joined #nixos-aarch64
Darkmatter66_ has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
<comrandroxaos[m]>
hi o/
<comrandroxaos[m]>
are there any nixos images for rpi4?
<samueldr>
yes
<samueldr>
with minor caveats
<samueldr>
this thread has some details, though I don't think it has the link to the build
<{^_^}>
#63720 (by majewsky, 48 weeks ago, open): Raspberry Pi 4 support
* samueldr
digs up the link to the image
<samueldr>
the main caveat to know of is that the current image is built on a weird way, doing only the minimum required to work on top of the usual sd image
<samueldr>
it doesn't use u-boot, so by default some expected configurations will not work, mainly /boot will need to be mounting the "FIRMWARE" partition