<samueldr> bennofs: I figure from the wiki edit that this helped?
<bennofs> yeah. I just noticed now that usb does not work with 5.3 :(
<flokli> samueldr: so I took a look at building barebox, which seems to be uboot 2.0, and realized the buildUBoot function doesn't really compose well: https://pastebin.aquilenet.fr/?2b0cb6cc75fc9102#8BgkD7ssWfPHTpjssX6hpMjWBMsydJtk2gi5xq197YW1
<flokli> I now need to pass additional nativeBuildInputs, which also isn't supported
<samueldr> when I had to futz around u-boot's builder I usually resorted to overrideAttrs
<flokli> and it seems people just don't use the function arguments, but rather just set everything they want manually
<flokli> the shebang patch is already sent to the upstream ML btw ;-)
<samueldr> might be better to forget about buildUboot, and figure out how such a builder should look like to you...
<samueldr> ... then apply the same to u-boot
<flokli> yeah, seems like
<samueldr> I'm not even sure they really should share code through composition
<samueldr> while true, barebox is a u-boot fork, I think they diverged greatly, no?
<flokli> yes. I just thought the buildUBoot function was quite handy to do the defconfig and copying files over part
<samueldr> hmmm... that makes me think about the EDK2 stuff I haven't had the time to re-check again
<flokli> turns out, it isn't really…
<flokli> I'm not sure if we have functions/tooling for software that has some common "build code in a make-file-like project with some conventions" except uboot and the kernel ;-)
<clever> builder for '/nix/store/jsk70860cczc4f5ccvx69xf0y210b0pr-perl5.30.0-XML-Parser-2.46-aarch64-unknown-linux-gnu.drv' failed with exit code 2
<clever> builder for '/nix/store/sfrcvxpwr937hqsjv94banyvnnlwj1ra-libstartup-notification-0.12-aarch64-unknown-linux-gnu.drv' failed with exit code 1
<clever> builder for '/nix/store/cmyfxa8256rhr5icikc8b7wl6n3y2hng-atk-2.34.1-aarch64-unknown-linux-gnu.drv' failed with exit code 1
<clever> builder for '/nix/store/28lwk8lva2jkza8mdwrp62cygwjz0h75-libXres-1.2.0-aarch64-unknown-linux-gnu.drv' failed with exit code 1
<clever> builder for '/nix/store/va1kd8sirzh648v4ngz67jhkfnyj1db7-gdk-pixbuf-2.40.0-aarch64-unknown-linux-gnu.drv' failed with exit code 1
<clever> builder for '/nix/store/p7ffycn5xy5d6aql2fld05zqx006p0bc-valgrind-3.15.0-aarch64-unknown-linux-gnu.drv' failed with exit code 2
<clever> builder for '/nix/store/fswhcwyy9pzl9221xv6ax8c93xm6k2ij-llvm-9.0.0-aarch64-unknown-linux-gnu.drv' failed with exit code 2
<clever> samueldr: all current failures, for xfwm4
<clever> the valgrind one is the most fishy to me
<samueldr> it's already fixed
<clever> ah yeah
<samueldr> but the PR has not been merged yet
<clever> i'm more curious why it even needed valgrind at build time
<samueldr> I seem to recall being about putting valgrind helper bits in there
<samueldr> it's legit
<samueldr> not an error
<clever> libva -> libdrm -> valgrind
* samueldr downloads
<clever> samueldr: oh, something else ive heard about, is that the gpu stuff changed roles massively in the rpi4
<clever> i think the linux side is more in control of some display duties now, via regular kms
<clever> armstub=RPI_EFI.fd
<clever> samueldr: ah, ive not seen many things using the armstub before
<clever> -rw-r--r-- 1 clever users 2.0M Nov 27 2019 RPI_EFI.fd
<clever> disable_commandline_tags=1
<clever> looks like they are entirely skipping the linux kernel loading phase
<samueldr> makes sense
<clever> so start.elf will drop RPI_EFI.fd at physical addr 0, and then release the reset on the arm
<clever> the very first opcode arm runs will be from RPI_EFI.fd, i believe
<clever> thats going to be fairly close to normal arm system bootup
<clever> so the only real complication is getting graphics/usb/ethernet
<samueldr> usb works
<clever> the readme says graphics also work
<samueldr> not sure about ethernet
<samueldr> yes
<samueldr> I booted it
<samueldr> now need to make a UEFI iso with the rpi kernel
<samueldr> since it's not mainline yet
<clever> do you have a serial adapter for your rpi uart?
<samueldr> yes
<samueldr> but no need for it :D
<clever> sed -i -e "s/BOOT_UART=0/BOOT_UART=1/" bootcode.bin
<clever> if you run that, bootcode.bin will print debug out the uart, at 115200 baud
<clever> and if you add `uart_2ndstage=1` to `config.txt`, then `start.elf` will also print more debug
<clever> `dtdebug=1` will also include debug about device tree loading
<clever> MESS:00:00:04.672274:0: brfs: File read: /mfs/sd/kernel7.img
<clever> interestingly, it claims that there is an sd card mounted to /mfs/sd/
<clever> that makes me wonder, does the spi chip and its files also appear there
<clever> oh!
<clever> samueldr: you have an rpi4 right? if you patch the bootcode.bin, what does it say?
<samueldr> haven't done it
<samueldr> so I don't know
<clever> under the "recovery image" they point to a zip, that contains `recovery.bin` and 2 other files, one is the bootcode.bin, the other is a plain old sha hash of it
<clever> so you could run the same sed as before, then use recovery to flash the spi chip
<clever> and then it will always print that debug on powerup
<clever> if you get filenames like memsys07.bin or mcb.bin, that will be a strong sign that we could patch things without the foundations help
<clever> although, i only see mfs in the debug from start.elf, not bootcode.bin...
<clever> back to the disassembly i go!
<samueldr> not sure it will/can help, but have you used ghidra?
<clever> nope
<clever> ive used idapro before (in trial mode)
<clever> and ive seen some people on youtube using radare, but havent figured it out yet myself
<clever> radare does have vc4 support, but its an optional plugin, and the entire plugin system is just a wrapper around git clone;./configure;make, which wont play nicely with nixos
<clever> currently, i'm just doing objdump -d, and reading it by hand
<samueldr> tried ghidra to reverse engineer the xiaomi-lavender bootloader when I suspected it was buggy
<samueldr> didn't figure out anything, and in the meantime figuerd out the real solution to my issue
<clever> SD HOST: %u CTL0: 0x%08x BUS: %u Hz actual: %d HZ div: %u (%u) status: 0x%08x delay: %u
<samueldr> but it at least made some sense of some stuff
<clever> Bad partition: %d sectors: %d type: %d
<clever> some of the strings within bootcode.bin, for the rpi4
<clever> Partition: %d
<clever> Failed partition %d after %d retries
<clever> MEMSYS INIT failed: %d
<clever> MEMSYS DPFE failed: %d
<clever> there are 8 memsys files in the spi...
<clever> Failed to open device: '%s' %d
<clever> what strings could go into the %s here, that could be of use...
<clever> Bad EEPROM capacity: 0x%x
<clever> samueldr: ehhhh, this one might be bad?
<clever> Initialising SDRAM '%s' %dGb x%d total-size: %d Gbit %u
<clever> bootconf.txt
<clever> the name of its own config file is present, so i may find file opening routines near that string
<clever> arasan-emmc0
<clever> fixup4x.dat
<clever> memsys00.bin
<clever> and there is a full list of filenames in one block
<clever> uart_2ndstage
<clever> including debug flags i mentioned previously
<clever> 00005100 16 7d 60 40 20 03 01 00 42 61 64 20 45 45 50 52 |.}`@ ...Bad EEPR|
<clever> 00005110 4f 4d 20 63 61 70 61 63 69 74 79 3a 20 30 78 25 |OM capacity: 0x%|
<clever> 0x5108 is the address of the error msg...
<clever> 50f4: e0 bf 14 00 lea r0,0x5108
<clever> yep, and there is a function using it
<clever> 50f0 will test if r1 == 0x13? and then maybe jump to 5102, causing it to skip the `printf("Bad EEPROM capacity: 0x%x",?)`
<clever> not sure yet what the rest does, lol
<samueldr> booting from empty SPI to SPI with bootrom?
<clever> the code i'm disassembling lives in the SPI
<clever> so the bootrom has already read the SPI into L2, and is executing it
<samueldr> it's supposed to be able to boot if the SPI is emptied
<samueldr> (or bad flash)
<clever> under "recovery image"
<clever> its just a zip file with: recovery.bin, pieeprom.bin, pieeprom.sig, vl805.bin, and vl805.sig
<clever> the sig files files are just sha256's of the matching bin files
<clever> samueldr: and if an SD card with recover.bin is present, it has priority over the SPI flash, and will boot recovery.bin instead
<samueldr> I'm thinking that there must be a built-in bootloader *somehwere*, that is used if the SPI is unreadable
<clever> there is definitely still a boot rom, in the cpu
<clever> that is likely mask rom
<samueldr> hmmm
<samueldr> can you put pieeprom.bin as recovery.bin?
<samueldr> and simply not use the SPI flash?
<clever> pieeprom.bin contains the bootcode.bin, and all of the memsys01.bin files
<clever> so that wont really work
<clever> its like trying to shove an ext4 disk image into the kernel field of grub
<samueldr> my thinking is that the boot rom would have done the same exact thing with wither of [spi flash, recovery.bin], and "jupmed" into it
<clever> for the rpi 1 to 3, the bootcode.bin would follow the above procedure
orivej has joined #nixos-aarch64
<samueldr> with either of*
<clever> which included checking for firmware on the sd card, nand flash, spi flash, usb, both device, then as a host to msd or ethernet
<clever> but there was no official support for nand/spi flash on the 1/2/3
<clever> with the rpi4, the boot rom now does...
<clever> a check for recovery.bin, then it executes the bootcode.bin held in SPI
<clever> and bootcode.bin will respect bootconf.txt, within the SPI
<clever> the supplied recovery.bin will re-flash both spi chips, then rename itself and reboot
<clever> and due to recovery.bin commiting suicide, the SPI will take over
<samueldr> welp, grub failed
<clever> so the new boot rom seems to be far simpler then the old one
<clever> samueldr: oh, lol, all the code starting at 50c4 in the pastebin, is just ascii, lol
<clever> 50e2: 78 00 bl gp
<clever> thats the terminating null
<clever> 50e4 is the entry-point
<clever> gist updated
<clever> of note, i think all of the functions start with an opcode like `stm r6,lr,(--sp)`
<clever> likely to make room on the stack for local variables
<clever> 17295 c3c6: 60 10 lea r0,(sp+0xc)
<clever> 17296 c3c8: e1 bf 6c 00 lea r1,0xc434 # "bootcode.bin"
<clever> 17297 c3cc: 02 61 mov r2,0x10
<clever> 17298 c3ce: 80 90 6f 01 bl 0xc6ac
<clever> samueldr: thats interesting, it loads something from the stack, the string "bootcode.bin", the number 16, and then calls a function..
<clever> what libc functions could this be? :D
<clever> void *memcpy(void *dest, const void *src, size_t n);
<clever> the order fits...
<clever> int memcmp(const void *s1, const void *s2, size_t n);
<clever> but so does this
<clever> though, the size is off
<clever> its a 12 byte string, and the size param is 16
<clever> char *strncpy(char *dest, const char *src, size_t n);
<clever> 17284 c398: 44 e9 0f f0 aa 55 cmp r4,0x55aaf00f
<clever> samueldr: oooo!, thats a magic number from the spi firmare image!!
* craige sings o/~ three, that's the magic number o/~
ryantrinkle has joined #nixos-aarch64
<clever> craige: the weird part, is that this is bootcode.bin itself, detecting its own blob in the spi image
<clever> my guess, is that its assigning a name to the blob, so future code can parse it
<clever> but why does it even need to name itself? when itself is already in ram
<craige> It's self aware?
<clever> lol
<clever> it only has 128kb of ram at this point
<craige> More than some recent politicians.
<clever> i doubt anything that limited could become self-aware!
<clever> lol
<clever> you heard about the coppa stuff on youtube?
<craige> All their thoughts are fed entirely from external sources :-)
<craige> No, I'm only on IRC / Matrix - I find commericla social media to be a particularly toxic space.
<clever> basically, you must flag your youtube channel (or on a per-video basis) as being for adults or kids
<clever> if you flag it as for kids, your basically crippling your entire channel
<clever> no comments, no notifications, far fewer ad's, your videos wont even show up in a search
<samueldr> that's "not new", COPPA, that is... what's new is how youtube forced the FTC in agreeing that YouTube isn't at fault for targeting kids, and that creators are, somehow
<clever> if you flag it for adults, and the FTC thinks your video is appealing to kids, like using words such as "yeah", then you get a $42k fine, per video
<clever> samueldr: some of the videos ive watched mention that the FTC has a 3rd option, flagging the videos as for a "general audience"
<clever> and youtube opted to omit that checkbox, because it would reduce their ad revenue
<samueldr> about 99.9% of the information you can find right now about that is hearsay and probably misleading
<clever> 2 of the videos mention a youtube insider that is leaking details
<samueldr> unless you got in touch with a lawyer about that, I wouldn't trust most
<craige> I've puased this video at 0:32 where he says "Hey creator" - not sure I can watch any further.
<clever> one is from a lawyer that has read the law
<samueldr> video creators are definitely biased in this
<samueldr> and it's definitely a hard topic
<clever> one video mentioned that some creators are going to fill the first 30 seconds of every video with curse words
<clever> so its obviously not for kids, lol
<clever> one person i talked to said that youtube is making it so much worse, to force people into complaining, to get the law changed
<clever> i'm thinking that the FTC isnt going to bother going after every single creator
ryantrinkle has quit [Ping timeout: 265 seconds]
h0m1 has quit [Ping timeout: 252 seconds]
h0m1 has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 276 seconds]
<lopsided98> I'm testing blob free mainline U-Boot on the Rock64.
<lopsided98> It boots, but I'm running into what seems to be random memory corruption
<lopsided98> I saw something similar when I tried using the U-Boot TPL from the downstream U-Boot a while ago, but that wouldn't even finishing booting
<samueldr> lopsided98: saw my ping earlier?
<samueldr> also, how are you observing the memory corruption?
<lopsided98> Random kernel oops and lots of memtester failures
<lopsided98> I missed that ping, I will try to submit that patch upstream
<samueldr> great!
<samueldr> (about the patch)
<samueldr> about failures, it was more about learning how to check, wondering if it'll affect rk3399 stuff
<lopsided98> Using the rkbin TPL with mainline U-Boot seems to be working so far
grw has quit [*.net *.split]
samueldr has quit [*.net *.split]
Aleksejs has quit [*.net *.split]
Aleksejs has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
grw has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 276 seconds]
zupo has joined #nixos-aarch64
andi- has quit [Ping timeout: 245 seconds]
andi- 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 [Client Quit]
zupo has joined #nixos-aarch64
craige has quit [Ping timeout: 246 seconds]
craige has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bennofs> lopsided98: have you managed to get USB working with a recent mainline kernel on Rock64?
lordcirth__ has quit [Remote host closed the connection]
lordcirth__ has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 276 seconds]
h0m1 has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 250 seconds]
h0m1 has joined #nixos-aarch64
marijan[m] has quit [Read error: Connection reset by peer]
cornu has quit [Write error: Connection reset by peer]
NickHu has quit [Write error: Connection reset by peer]
atopuzov[m] has quit [Read error: Connection reset by peer]
codyopel has quit [Read error: Connection reset by peer]
balsoft has quit [Read error: Connection reset by peer]
Ox4A6F has quit [Read error: Connection reset by peer]
craige[m] has quit [Read error: Connection reset by peer]
thequux[m] has quit [Read error: Connection reset by peer]
thefloweringash has quit [Read error: Connection reset by peer]
timokau[m] has quit [Write error: Connection reset by peer]
danielrf[m] has quit [Write error: Connection reset by peer]
contrun[m] has quit [Write error: Connection reset by peer]
worldofpeace has quit [Read error: Connection reset by peer]
dtz has quit [Read error: Connection reset by peer]
marius851000[m] has quit [Write error: Connection reset by peer]
alienpirate5 has quit [Write error: Connection reset by peer]
bennofs[m] has quit [Write error: Connection reset by peer]
Ericson2314 has quit [Write error: Connection reset by peer]
insep[m]1 has quit [Write error: Connection reset by peer]
zupo has joined #nixos-aarch64
<clever> samueldr: https://github.com/NixOS/nixops/issues/1189 your screenshot is 404'ing now
<{^_^}> nixops#1189 (by cleverca22, 15 weeks ago, open): plan for supporting custom partition layouts and custom FS's on any backend
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
marijan[m] has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
insep[m]1 has joined #nixos-aarch64
dtz has joined #nixos-aarch64
craige[m] has joined #nixos-aarch64
timokau[m] has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
alienpirate5 has joined #nixos-aarch64
atopuzov[m] has joined #nixos-aarch64
thequux[m] has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
contrun[m] has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
NickHu has joined #nixos-aarch64
balsoft has joined #nixos-aarch64
cornu has joined #nixos-aarch64
worldofpeace has joined #nixos-aarch64
danielrf[m] has joined #nixos-aarch64
codyopel has joined #nixos-aarch64
marius851000[m] has joined #nixos-aarch64
<samueldr> clever: look into mobile-nixos, it's image-builder
codyopel has quit [Quit: User has been idle for 30+ days.]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<lopsided98> bennofs: It works with ayufan's 4.19 (because of ZFS) kernel. I haven't tested mainline since I got the board, and I don't think it worked then
<bennofs> ah, I am currently on 4.4
<bennofs> maybe I should try 4.19
<lopsided98> You should probably try ayufan's 5.4 instead: https://github.com/ayufan-rock64/linux-mainline-kernel
<lopsided98> I normally rebase that repo against the latest stable release, but I've also been maintaining a 4.19 branch so I don't have to worry about ZFS incompatibilities
Thra11 has joined #nixos-aarch64
<clever> samueldr: ah
<samueldr> :/
<simpson> That's hilarious.
<samueldr> what is not is the fact that this is a known thing that needs to be designd for or against :(
<samueldr> that the issue is there is sad
<clever> ouch
<simpson> Also par for the course, though. Original RPis had SD card bandwidth issues. The original PogoPlug's WiFi only worked when it wasn't overheating, and its cooling issues meant that it was always overheating.
<samueldr> pogo plugs were made by the same peeps as the raspberry pi?
<samueldr> (otherwise I guess it's not that relevant, other than "hardware is hard")
<simpson> "ARM hardware is hard", really.
<samueldr> pretty sure x86_64 is, too, but has a thicker layer of warding from the years of experience, and mostly, accretion
<simpson> Also, I don't know which regulatory domain you're in, but in the USA, they sell cordless landline phones that also can cut into WiFi. And RC cars that can cut into WiFi.
<simpson> Lots of things cut into WiFi. It's *really* funny that "my own GPU" is one of them.
<samueldr> wi-fi is, by design, in the public use spectrum
<samueldr> microwaves also are in that spectrum
<samueldr> like, microwave ovens
<samueldr> pretty much anything wireless for 3~5 meters is 2.4GHz, especially when not expensive
<clever> samueldr: i kept my wifi router under the microwave for years, and never had any problems
<clever> and my microwave is just a few months older then i am, lol
<samueldr> do you live in a crowded area?
<samueldr> if not, it's likely able to cope
<clever> very sparse area
<samueldr> it becomes more of an issue when the channels are crowded, and then there's additional noise thrown in
<samueldr> here it's terrible
<clever> i just expected the router being under the microwave to cause more issues
<samueldr> there's more than 25 2.4GHz wi-fi routers advertising as measured in this corner of my appartment, going closer to the core of the block it spikes up
<clever> i believe i'm on a fixed channel
<samueldr> and the fun thing is some are on fixed channels *between* the recommended free channels
<samueldr> so there's interference on 100% of the spectrum
<clever> *looks*
<clever> i see 6 networks in the 2.4ghz band
<clever> on 1, 4, 7, and 11
<clever> and depending on how i lean over the phone, it drops as low as 3, lol
<clever> the only 3 surviving ones, are all within my property
<bennofs> lopsided98: I tied ayufan 5.3 and 5.4 (on the linux-build images from ayufan), 5.4 doesn't even boot due to some system issue (API mount fails, system enters freezing), neither detects my USB devices
<bennofs> I also tried ayufan 5.3 on NixOS, no USB :(
<samueldr> hmmmmm
<samueldr> the no USB thing might be a bigger issue than ayufan's
<bennofs> I've read somewhere that people started having problems since 4.20 or so
<samueldr> libre.computer's RK3399 board didn't work with USB last time I tried
<samueldr> ah, it worked beforehand... I see
<bennofs> 4.4 works fine
<samueldr> here I was thinking maybe there's a kernel module missing
<bennofs> but is also ancient
<samueldr> though, maybe there is a kernel module missing
<samueldr> that in 4.4 it got enabled through defaults, but gets disabled in newer versions
<bennofs> " tmpfs: Unknown parameter 'mode'" on linux 5.4, wat?
<clever> samueldr: lol
<clever> samueldr: and we just stuck firmware gold! lol
<clever> samueldr: i believe this is a chunk of c code, for a function in start.elf!!
<clever> that could be a cheat-sheet to decompiling things
<samueldr> cool
<clever> samueldr: ive also figured out my netboot issues, and i suspect its related to my linux driver issues, in a weird way
<clever> Nov 28 19:33:54 router kernel: e1000 0000:04:02.1 enp4s2f1: Detected Tx Unit Hang
<clever> samueldr: randomly, the NIC in my router craps out
<clever> and within 20-ish seconds, the driver notices, and does a hard-reset
<clever> Nov 28 19:33:54 router kernel: e1000 0000:04:02.1 enp4s2f1: Reset adapter
<clever> this leads to total packet loss for random periods of time
<clever> the problem tends to happen in bursts, and has actually been rather bad the last 2 days
<clever> but once the storm clears, its perfectly stable for weeks
<clever> i suspect, that a tftp packet is being lost, and the rpi firmware treats that as "file not found"
<clever> and if kernel7.img doesnt exist, then i obviously want kernel.img!
<clever> (which is for the wrong model, and hangs)
<clever> and if start.elf "doesnt exist", then it just fails to boot
h0m1 has quit [Quit: WeeChat 2.6]
h0m1 has joined #nixos-aarch64
h0m1 has quit [Client Quit]
h0m1 has joined #nixos-aarch64
<bennofs> did anyone encounter an "invalid argument" error when trying to mount tmpfs before?
<bennofs> mount -t tmpfs -o "noexec,nosuid" tmpfs /run is the command I triewd
<clever> that works fine on 4.19 x86
<bennofs> oh, my kernel has CONFIG_TMPFS unset. unlucky
<clever> bennofs: `cat /proc/filesystems` can quickly confirm that in the future, without access to the .config
<bennofs> it did have config.gz :)
<bennofs> but nice to know
zupo has joined #nixos-aarch64
<lopsided98> bennofs: USB works for me on ayufan's 5.4
<lopsided98> I rebased ayufan's repo against 5.4.0 and tested it with ZFS on an USB3 hard drive
<lopsided98> I haven't tested hotplugging, which didn't work last time I tried it
<lopsided98> USB 2 works, including hotplugging
<clever> lopsided98: semi related, if a block device behind zfs vanishes, it will freeze all io, and wait for you to call `zpool online` on the device, to un-freeze things
<clever> but, it only works if the device re-appears at the same path
<clever> you may need to rename nodes in /dev/ to make the tooling happy
<bennofs> hotplugging doesn't work = you need to have it connected at boot?
<bennofs> or is there something else?
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
zupo_ has quit [Read error: Connection reset by peer]
<lopsided98> bennofs: Yes, but I just tested it and it looks like it works now
<lopsided98> clever: That's cool - I just tried it while testing hotplugging
<bennofs[m]> Oh hmm. Then maybe I should try 5.4. This is on rock64 (not pro) right?
<lopsided98> yes
<bennofs[m]> Cool, thank you!
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 252 seconds]
zupo_ has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
zupo has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Read error: Connection reset by peer]
lordcirth__ has quit [Remote host closed the connection]
lordcirth__ has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
zupo_ has quit [Read error: Connection reset by peer]
fooker has quit [Remote host closed the connection]
<bennofs> lopsided98: kernel is building. what uboot/idbloader setup are you using? the one from nixpkgs?