tilpner_ has joined #nixos-aarch64
dan_b` has quit [Read error: Connection reset by peer]
dan_b` has joined #nixos-aarch64
tilpner has quit [Ping timeout: 265 seconds]
tilpner_ is now known as tilpner
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
<samueldr> oh, regarding an issue I had with udevd settle taking a long time
<samueldr> I just saw in that example system that I was disabling it outright
<samueldr> so *that*'s why it wasn't causing any issue with that system
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
pat_h has joined #nixos-aarch64
pat_h has quit [Quit: Connection closed]
alp has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.8]
lovesegfault has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
quinn has quit [Quit: ZNC 1.7.5 - https://znc.in]
FRidh has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-aarch64
leonardp has quit [Quit: Idle for 30+ days]
thequux[m] has quit [Quit: Idle for 30+ days]
alp has quit [Remote host closed the connection]
alp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<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> Someone else tried to upstream a blob here: https://lkml.org/lkml/2019/4/5/863
<angerman> W.T.F.? Is this really what I am supposed to expect from firmware blobs?
<srk> /o\
<clever> welcome to closed source, lll
<clever> lol*
<srk> this, I haven't even tried wifi or bluetooth on pi due to this
<srk> the "reason" for this is that wifi is just a SDR so if they would open firmware you could like hack for real
<clever> srk: for the rockpi4? the rpi has a very similar wifi name....
<clever> [ 6.380926] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
<clever> [ 6.403570] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2
<clever> srk: thats my current rpi4
<srk> clever: in general, haven't played with rockpi
<clever> and the rockpi is brcmfmac43456 i think, just one model# away
<srk> I see
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
<angerman> yea. That's why wifi doesn't work on mine. I'll build a package.
<angerman> the majaro-arm one seem to be the most recent firmwares, and it includes probably the kr00k fix.
<angerman> srk, clever apparently the same chip is in the pinebook
<angerman> err pine64.pinebook-pro
alp has quit [Ping timeout: 265 seconds]
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
<angerman> srk: so wait, are you saying these are binary blobs due to regulatory restrictions of turning any chip into a SDR?
<clever> angerman: i think part of why the source isnt out, is FCC regulations
<clever> angerman: you can just break the law (either on purpose, or by bug) and broadcast on freqs you shouldnt
<clever> so they want the firmware to go thru certification, i htink
<clever> i have seen a guy on youtube, that messed with the PLL divisors in an esp86 chip, so it wasnt broadcasting wifi on 2.4ghz anymore
<clever> only another esp86 that was similarly misconfigured could respond to things
<angerman> ouch
<clever> but it wasnt by accident, but on purpose, just to push the hardware to do things it wasnt meant to
<angerman> Hmm... [ 14.712752] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
<angerman> guess I should stick that module in there as well.
<angerman> wlan works.
<angerman> lol, gitlab "Deploy in progress"
<angerman> clever: btw can I update the rpi's usb powerdraw from nixos, or do I need to use one of the official distributions for the flashing tool?
<clever> angerman: power draw?
<clever> angerman: a few pages down is the firmware timeline
<clever> angerman: the VLI firmware, is for the vl805 usb controller
<clever> angerman: the vl805 file in here, is a static arm32-elf binary, that can reflash the vl805 firmware
<angerman> clever: so just download and run? Cool.
<clever> angerman: and the vl805*.bin files, are firmware for it, higher numbers are newer
<angerman> thanks.
<clever> it has a working --help and is pretty simpke
<clever> further down in the timeline, you have SDRAM firmware
<clever> that is held within the pieeprom*.bin images, and you have 2 ways of updating it
<clever> this is a shell script that manages both ways
<clever> by default, it copies recovery.bin and a pieeprom to /boot/
<clever> and recovery.bin will do the flashing for you
<clever> but you can also set `USE_FLASHROM=1` in `/etc/default/rpi-eeprom-update`, to make it use flashrom directly from linux
<clever> the other 2 bullet points, are likely in `start4.elf`, which is in the fat32 "/boot" filesystem (nixos may call it /firmware)
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-aarch64
<clever> if you want to do an impure update (ignoring nix's attempts to manage things), you would just copy the latest files
<clever> start4.elf and fixup4.dat are a matched pair, and both must come from the same version
<angerman> alright, something to try tomorrow.
<angerman> Thanks.
<clever> the beta pieeprom also offers usb mass-storage booting, and hdmi diagnostics
<angerman> yep. Maybe I should get me some additional usb sticks :D
<clever> the beta is the eeprom image also includes a selfupdate feature
<clever> so it can fetch further updates from usb or tftp
<clever> but if anything goes wrong while flashing, it will brick itself
<clever> and only recovery.bin on an SD can fix it
<clever> s/an/can/
<clever> wait, that wasnt a typo, lol
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
<angerman> lol. Yea I've got only my rockpi's sd port busted. The pis have proper cases.
<clever> technically, the rpi4 can also boot over usb-c in a DFU mode
orivej has joined #nixos-aarch64
<clever> but, it will only do so if the eeprom fails the hmac check, or you have previously burnt a fuse to allow disabling SPI temporarily
<clever> and the supplied recovery.bin doesnt allow reflashing over usb, so thats not of use
<angerman> you seem to like the pi a lot. my friend from arm doens't like it at all for it's pathetic chip.
<angerman> that rockpi4 boot process appears a *lot* faster once you got the wireless module loaded.
<clever> angerman: partially its because i'm already familiar with it, and partially due to the size of the community
<clever> and cheapness of the hw
<angerman> bluetooth still fails, but I don't use that anyway...
<clever> how expensive is a rock pi 4?
<angerman> clever: yea the size of the community is pretty great!
<angerman> clever: $75 for the 4GB version.
<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
* lovesegfault googled
<lovesegfault> *s
<lovesegfault> https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fflashing.html%23wwpID0E0OH0HA
<lovesegfault> maybe this
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
<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
<samueldr> there are links to download an sd card imae
<samueldr> image*
<samueldr> I can't follow them due to lacking an account
* lovesegfault looks
<samueldr> not sure that the sd image will be useful, but my main guess is that it will have a kernel and kernel-dtb partition
<lovesegfault> samueldr: that's only for Xavier NX and Jetson Nano, sadly :(
<lovesegfault> The AGX doesn't support this
<lovesegfault> for whatever reason
<samueldr> oops, I misread AGX
<lovesegfault> or, rather, there are no provided sd images
<lovesegfault> I ordered an sd card from amazon
<lovesegfault> should be here sunday
<lovesegfault> I'll try the script method the
<lovesegfault> *then
<samueldr> looks like you can run the script without an SD image
<samueldr> it will build a .img file, maybe
<samueldr> so you could mount that and inspect it
* lovesegfault tries
alp has quit [Read error: Connection reset by peer]
alp has joined #nixos-aarch64
<lovesegfault> samueldr: applies to Jetson nano only
lopsided98 has quit [Remote host closed the connection]
<lovesegfault> see the small note below the header
<samueldr> from some sleuthing, it looks like it relies on "jetpack"
<samueldr> to do anything software-wise
<lovesegfault> Yeah, jetpack is cursed
<samueldr> tbf, it looks a bit confusing
<lovesegfault> it _only_ runs on Ubuntu
<lovesegfault> guess I gotta setup a VM
<samueldr> pretty much no information online on it, and definitely no disk image
<samueldr> it looks like it really likes to rely on a custom ecosystem to flash and manipulate what's on the device
lopsided98 has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
<lovesegfault> Yeah, it's a bit cursed :/;
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
bdju has quit [Read error: Connection reset by peer]
bdju has joined #nixos-aarch64
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
quinn has quit [Quit: ZNC 1.7.5 - https://znc.in]
quinn has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
sphalerite has quit [Quit: WeeChat 2.6]
sphalerite has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
zupo has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64