<samueldr>
AFAIUI this is a rebase of the changes needed on top of the CAF (qualcomm's) tree
<samueldr>
>> All these libraries and binaries have been compiled with an older GLIBC and all of them have been patched to not complain with glibc 2.37, as bundled with Yocto 3.1 release with patchelf.
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cfinch has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 265 seconds]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
alp has joined #nixos-aarch64
zupo has quit [Ping timeout: 260 seconds]
cole-h has quit [Ping timeout: 256 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cfinch has quit [Read error: Connection reset by peer]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<das_j>
Does anyone know how the rpi firmware update works exactly? Is it enough to boot my pi with a pieeprom.upd in /boot?
<das_j>
Asking because I need to update 60 pis to the latest firmware and it's kind of tedious
<das_j>
Probably a question for clever
<das_j>
Hmm, looks like I just need a FAT32 partition with recovery.bin, pieeprom.bin, pieeprom.sig?
orivej has joined #nixos-aarch64
Darkmatter66 has quit [Quit: ZNC 1.7.5 - https://znc.in]
Darkmatter66 has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
alp has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
zarel has joined #nixos-aarch64
monk has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
zarel_ has joined #nixos-aarch64
zarel has quit [Ping timeout: 265 seconds]
<patagonicus>
My current cooling "solution" for my Odroid HC2s includes a book as an integral component. A stress test suggests it works, but maybe I'll need to think about some of my life choices.
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…]
hmpffff has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hmpffff has joined #nixos-aarch64
zupo has joined #nixos-aarch64
hmpffff has quit [Ping timeout: 260 seconds]
<patagonicus>
Huh. Turns out it's the board that's bad, not my cooling. Stacking them in reverse still has that board go >110°C. Guess I'll order a replacement and keep that as a backup or something.
<patagonicus>
Weird thing is that I can't trigger it with `stress` or reading from the HDD/SD card. Apparently the synthetic load doesn't manage to make it get that hot.
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<clever>
samueldr: CM4 is out!
<clever>
das_j: pieeprom.sig must contain the sha256 of the pieeprom file
<clever>
das_j: pieeprom.bin will update and then freeze, so you have to remove it yourself, pieeprom.upd causes recovery.bin to rename itself then reboot, so it can be integrated into a systemd service
<das_j>
yay, I'll try it once my HDMI adapter gets delivered
<das_j>
thanks, maybe that'll do the trick
<clever>
das_j: recovery.bin is also optional
<clever>
if the eeprom is still working (and new enough), it can do a self-update
<clever>
it will diff the pieeprom, flash itself, and reboot
<clever>
and if there is no difference, it will just continue the boot
<das_j>
I'll probably keep it since this is going to be a generic sd image that should run on any pi
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hmpffff has joined #nixos-aarch64
<Mic92>
clever: does uboot on pi4 also expose serial console over its gpios?
<clever>
Mic92: i think it forces serial on gpio 14/15, even if you didnt try to enable it
<clever>
which can cause some conflicts with things
hmpffff has quit [Ping timeout: 272 seconds]
<Mic92>
clever: ok. are these the same pins that the kernel uses for its ttyS0? My pi is currently several hundrets KM away overseas, so I cannot check.
<clever>
by default, yes
<clever>
depending on config.txt entries, 14/15 might be ttyAMA0 instead
<Mic92>
Interesting. Maybe I need to poke harder next time. I saw the last few lines of the boot screen and than the login prompt but not uboot
<Mic92>
clever: just saw that our rpi4 images don't install uboot at all. Hence no serial console support
<clever>
Mic92: you can still add enable_uart=1 to config.txt, to get a serial console after linux boots
<das_j>
Mic92: You can also console=ttyAMA0,115200
<das_j>
in your cmdline.txt
<clever>
das_j: ttyAMA0 might be bluetooth, causing conflicts, serial0 is the magic alias to avoid the problem
<das_j>
TIL… I usually boot without bluetooth so that's not an issue
<clever>
its all in the uart.md i linked above
<Mic92>
das_j: yeah that works for getting some kernel output but no boot-loader output. But since right now it only seems to install one kernel at the time, I don't get rollback support this way anyway.
<clever>
Mic92: for bootloader output, uart_2ndstage=1 in config.txt
<das_j>
Mic92: You need to set BOOT_UART=1 in your eeprom image
<das_j>
clever: Are we talking about the same thing?
<clever>
das_j: BOOT_UART is for stage1(the eeprom), uart_2ndstage=1 is for stage2 (start4.elf)
<Mic92>
clever: do I need dtoverlay=disable-bt for uart_2ndstage=1 ?
<das_j>
ohh. So I will have to set both, nice to know that
<Mic92>
das_j: how do I set BOOT_UART=1 in my eeprom image?