<angerman>
Hmm... I guess my image just misses the /firmware files, as I don't have a dedicated boot partition, only a fake one where I write the uboot into directly.
orivej has joined #nixos-aarch64
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has joined #nixos-aarch64
<angerman>
ok, got further, what's this mess with firmwares? Seriously everyone is dropping random blobs all over the internet? hardly any versioning done?
<srk>
:D
<srk>
which component needs fw?
<srk>
wifi?
<angerman>
yea.
<angerman>
armbian has it. But it has the fw_bcm43456c5_ag.bin files *and* it has the brcmfmac43456-sdio.bin. However the brcmfmac43456-sdio.bin is just a link to brcmfmac4356-sdio.bin, which is the same as other brcmfmac43456-sdio.bin or fw_bcm43456c5_ag.bin that can be found in other repos.
<angerman>
At the same time fw_bcm43456c5_ag.bin is the most recent drop in armbian, mentioning the fix for the Kr00k fix; it's droppen into two folders. What's up with the rkwifi folder? But the brcmfmac43456-sdio.bin is not updated? I'm absolutely confused...
<angerman>
v1.3 will have no soldered on SPI, v1.4 should have one.
<clever>
angerman: $78 for an rpi4 with 4gig, pretty equal
<angerman>
you *do* probably want to get the $8 big heatsink though and maybe.
<clever>
just glancing at the photos, the main difference i can see is that the rpi4 has 2 hdmi out
<clever>
while the rockpi4 has 1 hdmi
<angerman>
the rk3399 is a pretty decent chip. It's of similar performance to the S922X that's in the N2, even though that should have a newer generation on the big cores.
<angerman>
The rk3399 will run a bit hotter, *but* it does support nvme booting and stuff.
<angerman>
also the rk3399 seems to have quite decent open source support, being a popular board. Compared to the S922X which seems to mostly end up in Android TV boxes.
<clever>
in theory, the rpi4 chip could support nvme booting
<clever>
but you would have to redo the board layout to allow it
<srk>
lol I didn't notice there are two hdmis on pi4.. gotta try using that as a desktop with two monitors :D
<clever>
srk: i believe it also supports dual 4k output
<srk>
... wow
<angerman>
clever: yea I think so too.
<angerman>
But then I could never get youtube to not stutter on a rpi4, lol.
<clever>
angerman: from what ive heard, chromium has all of the hw video accel properly setup
<angerman>
clever: the cardano-on-the-rocks guy was using a rockpi4 with an ssd mounted for nvme.
<srk>
angerman: not even with mpv? :)
<angerman>
if you remember that from the last summit.
<clever>
yeah, i do remember that
<clever>
i think half the reason they went with rockpi, was ram
<clever>
but now there is an 8gig rpi4
<angerman>
srk: dunno, tried to set one up for my father in law. He'd be using it for browsing the web on his 1080p tv anyway...
<angerman>
but it ended up being too slow and most videos stuttering, which was confusing to me...
<srk>
I see
<clever>
as for processing power on the rpi4
<srk>
I'm yet to fix video playback with etnaviv and imx6..
<clever>
you have 4 arm cores, running at 1.5ghz
<clever>
2 VPU cores, running at 500mhz (capable of doing vector math, 16 mults in 2 clocks for example)
<clever>
128 (i think?) QPU cores, running at somewhere around 500mhz, for running GL shaders, each one computes the color of a single pixel
<clever>
then you have h264 encode/decode blocks (1080 and below i believe)
<clever>
and a h265 decode block (for stuff above 1080)
<clever>
thats most of the compute in the rpi4
<angerman>
now that I have rpi4s and rockpi4s with nixos setup, I could try to do some performance benchmarking (though disk IO might be an issue...)
<angerman>
see how long it takes to sync mainnet, or compile ghc or some other realworld task :D I don't care much about synthetic benchmarks.
<clever>
for the rpi4, you can also bypass the SD a bit, by putting your working directory onto a usb3 disk
<clever>
it doesnt have to boot from usb3, just mount and cd over
<srk>
I hope rpi5 gonna have nvme slot :D
<srk>
m2..
<clever>
srk: that would require either more pcie lanes (somewhat simple) or a pcie port multipler, both though would add to the costs
<clever>
and then a pcie slot of some form, which adds to the cost
<srk>
well they can just add another version :)
<srk>
(variant)
<nbp>
I am just starting with my first RPI (a RPI 3B+). I started with the nixos-generate tool, generating an sd-aarch64 image. However, doing so produces 2 partition, but this partition does not take into account any of the `boot.loade.firmware.config` parameters and also uses extlinux-compatible boot-loader. The firmware content is dumped into a FIRMWARE partition, but this one is never updated later on
<nbp>
when using nixos-rebuild on the RPI. Removing the extlinux-compatible boot loader does write the updated config.txt file in the /boot, but it still seems to be booting out of the extlinux-compatible entries.
<nbp>
I am wondering how can I tell the RPI to ignore the extlinux boot file and take the image in /boot instead.
alp has quit [Remote host closed the connection]
<nbp>
or how to have the /boot/config.txt be updated, and as well update the extlinux entries?
<clever>
nbp: depends on if your using uboot or raw firmware as the "bootloader"
<nbp>
I disabled uboot from the beginning, should I enable it?
<nbp>
I want to add a camera to the PI, which implies adding a few lines to the config.txt, as I read on our wiki
<clever>
nixos on the rpi3 typically uses uboot
<clever>
and i think the camera will still work when you add `start_x=1` to config.txt
<clever>
with uboot
* nbp
read the code …
<clever>
nbp: for nixos on the rpi3, the firmware and uboot blobs are typically on a /firmware partition, and then /boot is just a normal dir on the / (ext4) fs
<clever>
and nixos basically ignores /firmware
<nbp>
I see uboot actually relies on extbuilder to setup the boot properly and write the config.txt files, when the boot.loader.raspberryPi.enable flag is set.
alp has joined #nixos-aarch64
<nbp>
I presume we should add a warning/error when this option is set with extbuilder boot loader.
<nbp>
(or I am missing perspective of the configuration space)
<nbp>
clever: Thanks, I will try uboot.
<nbp>
clever: ok, I understand my initial error, I had set boot.loader.generic-extlinux-compatible.enable instead of boot.loader.raspberryPi.uboot.enable
<nbp>
however files are still being generated in /boot/config.txt and /firmware files remain unchanged … which makes me wonder whether I should remove the /firmware partition.
<nbp>
is there a way to know which config.txt file is being loaded?
<nbp>
ok, adding a boot_delay=60 in the /firmware/config.txt file highlighted that /boot/config.txt was ignored, while being the updated location.
<clever>
nbp: the firmware always loads the config.txt on a fat32 partition
<clever>
nbp: if its on ext4, then the firmware cant see it
<nbp>
oh … so I would have to add commends to copy all of these files to the firmware partition?
<nbp>
^ commands
<nbp>
I see that these scripts have a target, but they always set it to /boot and never /firmware, and there does not seems to be a way to add a target (AFAIK)
<lopsided98>
nbp: boot.loader.raspberryPi.uboot.enable doesn't work all that well with the way the image is setup now
<{^_^}>
#67902 (by lopsided98, 38 weeks ago, open): raspberrypi-bootloader: support new firmware partition concept
<lopsided98>
Most people just use boot.loader.generic-extlinux-compatible.enable and treat the firmware, U-Boot and config.txt as a black box not managed by NixOS.
<nbp>
lopsided98: Thanks for the explanation!
<lopsided98>
There is some danger in managing the firmware through NixOS, in that if it breaks you can't just select an older generation like you can with NixOS configurations.
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
<nbp>
Thanks I can now see the /dev/video0 device , next step … taking a picture of my ceiling!
alp has quit [Ping timeout: 272 seconds]
artemist has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has joined #nixos-aarch64
<lovesegfault>
samueldr: mine and andi-'s attempts at booting NixOS on the Nvidia AGX are a disaster
<lovesegfault>
nothing works 🤣
<samueldr>
how come
<samueldr>
what seems to be the issue?
<lovesegfault>
So, first we tried booting an image off of USB
artemist has left #nixos-aarch64 ["= """]
<lovesegfault>
We flashed a USB drive with the rpi4 sd card image
<samueldr>
was it verified that a vendor-made image works on usb?
<samueldr>
oh, that sounds like a bad start
<samueldr>
I mean, the very first thing to do is verify usb booting with the hardware you have, works with vendor provided assets :)
<lovesegfault>
No, and it doesn't work because apparently USB isn't supported (you can boot off of a USB drive, but the devkit only exposes USB ports through a hub and hubs aren't supported)
<samueldr>
oh
<lovesegfault>
I mean we can try the nvidia one but I don't even know where to get an image
<samueldr>
I mean, in my opinion, probably factually, it's better to have a known working example of what you want to compare against... and more importantly, validate the assumption that it should be working
quinn has joined #nixos-aarch64
<lovesegfault>
I agree
<lovesegfault>
We're trying to flash an USB stick with the normal nvidia ubuntu
<lovesegfault>
but it's also _not_ trivial
<lovesegfault>
They reference a bunch of files you need but don't say where they can be found
<samueldr>
doesn't look too bad
<samueldr>
oh, that part is bad though
<samueldr>
not having the files, I mean
<samueldr>
but the instructions to me sounds like it uses GPT partition labels to identify partitions
<samueldr>
>> 10. Print the start, end, and size in sectors of the partitions:
<samueldr>
WHY?
<lovesegfault>
Yeah, that part is simple
<samueldr>
you just made partitions, dd to the dang partitions!!
<lovesegfault>
yeah but dd what :P
<lovesegfault>
that is the issue
<samueldr>
yeah :)
<samueldr>
looking at the following section, it looks like there is a script for jetson
<samueldr>
not sure if it fetches the data
<samueldr>
and if there is one for AGX
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<lovesegfault>
maybe I need to use the script they reference in the sd card portion