<pie_> clever: possible version mismatch between server and client. i was running an unstable daemon but loaded the 19.09 client in the other shell
<pie_> doesnt seem to hang anymore
<pie_> version your protocols kids
<clever> that would explain things
<pie_> do i get to blame both parties here?
<clever> they are in the same package i believe
<clever> and they kind of assume you cant mix versions, because who would be crazy enough to install multiple copies to a different --prefix each
* clever eyes nix
<pie_> c:
<pie_> https://superuser.com/questions/1436995/iscsiadm-hangs-and-tcpdump-shows-nothing might not be the same thing but it got me thinking
<samueldr> but
<samueldr> your server might not update as quickly as your clients!
<clever> samueldr: its IPC over a unix socket, both must be on the same machine
<pie_> yes but the daemon and the daemon-client are usually on the same machine :p
<samueldr> oh
<pie_> ok clevers explanation was much better XD
<samueldr> I assumed it was over network
<pie_> well you *could* route a socket over the network :p
<clever> samueldr: iscsiadm talks to iscsid over unix, then iscsid talks to tgtd over tcp
<samueldr> oooh, the tool to control the daemon, I see
<samueldr> like systemctl to systemd
<clever> yep
<clever> and tgtadm to tgtd
<clever> tgt-admin is a lie, its a perl wrapper over tgtadm, lol
<clever> technically, the c++ parts of tgt (tgtd and tgtadm) dont even support their own config files
<clever> tgt-admin parses the config in perl, then runs tgtadm to create the proper state in tgtd
stiell has joined #nixos-aarch64
<pie_> soudns fun
<pie_> any easy way to get the commit id of channel:nixos-unstable?
<clever> pie_: i decided to skip that, and create systemd services to run tgtadm directly
<clever> and thats where things got complex and buggy
<pie_> yeesh :D
<pie_> might as well rewrite it all in rust
<colemickens> pie_: `git ls-remote https://github.com/nixos/nixpkgs nixos-unstable`
<colemickens> `| cut -d ' ' -f 1` I guess
<colemickens> or maybe there's another flag you can pass it
stiell has quit [Ping timeout: 244 seconds]
<pie_> clever: samueldr: well, i opened a pretty meh issue description https://github.com/NixOS/nixpkgs/issues/97875
<{^_^}> #97875 (by deliciouslytyped, 32 seconds ago, open): Mixing versions of openiscsi daemon and clients for the daemon results in the clients hanging (and otherwise broken behaviour)
<pie_> not really sure what could be done about this
<clever> 2020-09-12 21:06:25 < pie_> version your protocols kids
<samueldr> I'd like a "2.status: will be stale"
<samueldr> ;)
<pie_> :ppp
<samueldr> it's not something we can really do anything about
<clever> id open it against upstream
<samueldr> so please nudge upstream yeah
<samueldr> and link back the discussion
<samueldr> hopefully an issue tracker and not a dreaded mailing list
<pie_> doesnt let you do anything retroactively but at least maybe fixes the future
<pie_> looks to be in luck https://github.com/open-iscsi/open-iscsi
<{^_^}> open-iscsi/open-iscsi#222 (by deliciouslytyped, 31 seconds ago, open): MIxing versions leads to subtle breakage, please version your protocol
* clever cheers
<pie_> now with that yak shave aside lets see if i can actually get somewhere
<pie_> (which should be bed but no :P)
<pie_> clever: so what do i do after iscsistart? no matter what i do it seems to complain about the session already existing, but it does seem to log in
<clever> pie_: does a blockdev magically appear in /dev/? check dmesg?
<pie_> ive been checking /by-path/ and not there
<pie_> clever: im guessing the disk creation section is failing?
<clever> possibly
<pie_> that seems to be separate from login
stiell has joined #nixos-aarch64
<pie_> clever: well, at the least, doing it with -m node from https://wiki.archlinux.org/index.php/ISCSI/Boot seems to have worked
<pie_> dunno why iscsistart is failing :/
<pie_> clever: also with iscsistart, the login is done but --logout doesnt work until i restart the daemon and it recovers something
<pie_> though that might just be because the daemon isnt informed
<pie_> oh maybe i should stop the daemon
<clever> yeah
<clever> iscsistart is meant to be ran without the daemon
<pie_> man i dont like this stateful stuff
<pie_> i need to get the containers figured out
<pie_> i would really like not having to wait for squashfs :p
<pie_> assuming the image generation is faster withut it
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 240 seconds]
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
mvnetbiz_6 has joined #nixos-aarch64
mvnetbiz_ has quit [Ping timeout: 264 seconds]
mvnetbiz_6 is now known as mvnetbiz_
<samueldr> neat, just took my old work for u-boot on rpi4 and it seems to work now
<samueldr> maybe the updated packages since that time
knerten2 has joined #nixos-aarch64
<clever> after countless hours, i finally have the ability to send a 132 byte packet to the VPU firmware, lol
<clever> the biggest mistake, was just blindly turning interrupts off, then back on, when you register an interrupt handler
<clever> that turned them on, when they should have been off
<clever> and then, i forgot to change the clock source, so it was still running at 19.2mhz, and the code couldnt keep up with the uart
knerten1 has quit [Ping timeout: 240 seconds]
<samueldr> if my intuition is right, we can start shipping u-boot for pi4 with the mainline image, and whenever mainline works on pi4 the image will just work
<samueldr> (assuming all kernel options are accounted for)
<clever> ACK 4544 / 4519
<clever> Segmentation fault (core dumped)
<clever> woops, need EOF detection! lol
orivej has joined #nixos-aarch64
makefu has quit [Ping timeout: 240 seconds]
makefu has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 244 seconds]
andi- has quit [Ping timeout: 258 seconds]
<samueldr> #97883 is pretty much ready
<{^_^}> https://github.com/NixOS/nixpkgs/pull/97883 (by samueldr, 1 minute ago, open): Use U-Boot for the Raspberry Pi 4-specific image
<clever> samueldr: it should also be possible to boot aarch64 on both pi3 and pi4 with the same image
<samueldr> clever: "failed with exit code 135" with nix, what could cause that?
<samueldr> clever: yes, when the kernel supports it, as I stated
<clever> you may need 2 uboots simetimes, but thats easily delt with
<samueldr> clever: with this change it's in fact ready to go, if mainline boots in rpi4, the aarch64 defconfig image will work
<samueldr> so it's not "it should be possible"... it is, and this change does it
<clever> ah, already got the conditionals, perfect
<samueldr> yeah, one U-Boot to do both would have been hell :)
<samueldr> so the raspbery pi 4 images are on their last hour
<clever> thats pretty much what ive been doing in the open firmware
<clever> one arm blob, that runs on pi1, pi2 and pi3
<samueldr> it'll last for however much time it'll take for mainline to work fine
<samueldr> which... maybe I should try?
<clever> bio_read:357: dev 'sdhostp0', buf 0xc1522934, offset 2199023384576, len 2048
<clever> also, that offset aint right
<samueldr> so yeah, having an issue with nix builds right now
<clever> i need to figure out what happened to it
<samueldr> builder for '/nix/store/0890c93kp9rmw4i36qj656f2jmy6kgyb-source.drv' failed with exit code 135
<clever> does dmesg say anything?
<samueldr> it seems nix doesn't want to fetch from github anymore on my machine
<clever> what was the proc within?
<clever> is it curl based?
<samueldr> nope
<samueldr> the proc within?
<samueldr> fetchFromGitHub
<clever> ah, curl based then
<samueldr> the "nope" was about dmesg :)
<clever> any other logs?
cole-h has joined #nixos-aarch64
<samueldr> I couldn't find anything
<clever> try just `nix-store -r /nix/store/0890c93kp9rmw4i36qj656f2jmy6kgyb-source.drv`
<samueldr> that's why I'm confused
<clever> to re-run it
<samueldr> same exact result
<samueldr> building '/nix/store/0890c93kp9rmw4i36qj656f2jmy6kgyb-source.drv'...
<samueldr> builder for '/nix/store/0890c93kp9rmw4i36qj656f2jmy6kgyb-source.drv' failed with exit code 135
<clever> and still the same when ran as root?
<samueldr> yep
<clever> NIX_REMOTE=local strace -ff -o logfiles nix-store -r /nix/store/0890c93kp9rmw4i36qj656f2jmy6kgyb-source.drv
<samueldr> earlier I restarted nix-daemon and it didn't change anything
<clever> and since your root, it wont go via the daemon, so you can strace the builder
<clever> check the tail end of each file, one of them should have an exit code of 135
<samueldr> wait4(-1, 0x7fffffffca10, WNOHANG, NULL) = -1 ECHILD (No child processes)
* samueldr looks more closely at this file
<clever> that sounds like one of the parent procs
<samueldr> though that's the one that exit_group(135)
<clever> can you gist that whole file?
<samueldr> oh
<samueldr> +++ killed by SIGBUS (core dumped) +++
<samueldr> could that be what makes the parent quit?
<clever> that was my first guess, but i dismissed it
<samueldr> (most likely yes)
<clever> > 135 - 128
<clever> 7
<{^_^}> 7
<clever> c2d ~ # kill -l
<clever> if its killed by a signal, it returns with 128+signal
<samueldr> yeah
<clever> SIGBUS typically happens if your reading/writing to an mmap'd file, and it changes size
<clever> `coredumpctl | tail` ?
<samueldr> Sun 2020-09-13 00:50:13 EDT 30273 30001 30000 7 none /nix/store/yrss5dxlcbshrx3a1ib2bqyb5xj5gpci-curl-7.72.0-bin/bin/curl
<clever> so curl exited with SIGBUS, but we didnt get a coredump
<clever> can you pastebin more of the strace?
<clever> execve("/nix/store/yrss5dxlcbshrx3a1ib2bqyb5xj5gpci-curl-7.72.0-bin/bin/curl", ["curl", "-V"], 0x4ec008 /* 110 vars */) = 0
<clever> all it did was run `curl -V`
<samueldr> @DUFFMAN ~/tmp/cross-system 135 $ /nix/store/yrss5dxlcbshrx3a1ib2bqyb5xj5gpci-curl-7.72.0-bin/bin/curl -V
<samueldr> Bus error (core dumped)
<clever> samueldr: `nix-store --verify --check-contents` ?
<samueldr> that'll take a hot... minute or ten or more
<samueldr> but that's what I guess too
<clever> you can also do a smaller closure
<clever> ` nix-store --verify-path paths...
<clever> and nix-store -qR on the curl
<samueldr> error: reading from file: Input/output error
<samueldr> that doesn't sound fun
<clever> what did you run?
<samueldr> nix-store --verify-path $( nix-store -qR /nix/store/yrss5dxlcbshrx3a1ib2bqyb5xj5gpci-curl-7.72.0-bin )
<clever> and does dmesg say anything new?
<samueldr> dmesg is completely serene
<samueldr> and I know which store path
<samueldr> /nix/store/l9dq6m41myj0fblh7a352jm66akihilw-libkrb5-1.18/
<samueldr> cat: /nix/store/l9dq6m41myj0fblh7a352jm66akihilw-libkrb5-1.18/lib/libkdb5.so: Input/output error
<samueldr> yay?
<clever> sounds like your fs is corrupt
<samueldr> yeah
<clever> `nix-store --repair-path` ?
<samueldr> already ahead of you
<samueldr> didn't help
<clever> what fs is the store on?
<samueldr> ext4
<clever> oh, do you have auto-optimize on?
<samueldr> auto-optimise-store = true
<clever> yeah, thats it
<clever> after fixing it, it hashed the good copy, and discovered it was a dup
<clever> so it deleted the good copy, and hard-linked it to the bad copy~
<samueldr> so how do I... unbreak this?
<clever> `nix-store --repair-path --option auto-optimise-store false ...`
<clever> to repair it without redoing the link
<clever> then youll need to find, and repair every other duplicate
<clever> and `nix-collect-garbage --max-freed 1` once thats done, to GC the dangling hardlink in /nix/store/.links/
<samueldr> that didn't help it seems
<clever> once all corrupt copies are gone, you can redo optimize
<samueldr> oh, wait, repaired the wrong path
<samueldr> it's fixed for now
<samueldr> clever++ thanks
<{^_^}> clever's karma got increased to 506
orivej_ has quit [Ping timeout: 240 seconds]
<betrion[m]> <pinage404[m] "betrion: https://gitlab.com/pina"> Thank for the reply.
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has quit [Ping timeout: 244 seconds]
cole-h has quit [Quit: Goodbye]
orivej has joined #nixos-aarch64
colemickens has quit [*.net *.split]
chessai has quit [*.net *.split]
feepo has quit [*.net *.split]
betrion[m] has quit [*.net *.split]
AmandaC has quit [*.net *.split]
leonardp has quit [*.net *.split]
cornu has quit [*.net *.split]
bbigras has quit [*.net *.split]
flokli has quit [*.net *.split]
andi- has joined #nixos-aarch64
ninjin_ has quit [*.net *.split]
colemickens has joined #nixos-aarch64
andi- has quit [Ping timeout: 244 seconds]
justanotheruser has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
alp has joined #nixos-aarch64
feepo has joined #nixos-aarch64
bbigras has joined #nixos-aarch64
cornu has joined #nixos-aarch64
leonardp has joined #nixos-aarch64
AmandaC has joined #nixos-aarch64
chessai has joined #nixos-aarch64
flokli has joined #nixos-aarch64
betrion[m] has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ninjin_ has joined #nixos-aarch64
stiell has quit [Ping timeout: 265 seconds]
alp has quit [Ping timeout: 240 seconds]
andi- has joined #nixos-aarch64
<colemickens> btw, do yalls Pine phones have coil whine?
stiell has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
stiell has quit [Ping timeout: 240 seconds]
stiell has joined #nixos-aarch64
patagonicus3 is now known as patagonicus
zupo has joined #nixos-aarch64
patagonicus is now known as patagonicus3
patagonicus3 has quit [Quit: The Lounge - https://thelounge.chat]
patagonicus3 has joined #nixos-aarch64
patagonicus3 is now known as patagonicus
patagonicus has quit [Client Quit]
patagonicus3 has joined #nixos-aarch64
patagonicus3 is now known as patagonicus
zupo has quit [Ping timeout: 244 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
<sphalerite> colemickens: nope, neither on battery nor when connected to power
zupo has quit [Ping timeout: 244 seconds]
mvnetbiz_9 has joined #nixos-aarch64
mvnetbiz_ has quit [Ping timeout: 244 seconds]
mvnetbiz_9 is now known as mvnetbiz_
codyopel has quit [Quit: Idle for 30+ days]
mvnetbiz_ has joined #nixos-aarch64
mvnetbiz_ has quit [Changing host]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 244 seconds]
prusnak_ is now known as prusnak
prusnak has joined #nixos-aarch64
prusnak has joined #nixos-aarch64
prusnak has quit [Changing host]
<pinage404[m]> betrion: i clone it anywhere (usually, in my `/home`) because i do a symlink `sudo ln -sr nixos_config /etc/nixos` to put it in the right path
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 264 seconds]
Darkmatter66 has joined #nixos-aarch64
<betrion[m]> <pinage404[m] "betrion: i clone it anywhere (u"> ok thank you
alp has joined #nixos-aarch64
orivej has quit [Ping timeout: 264 seconds]
<pinage404[m]> i'm trying to add this `boot.kernelPackages = pkgs.linuxPackages_rpi3;` in my Raspberry Pi 3 B config (just because the name seems to suit to the machine) but `nixos-rebuild switch` fail, it says there is no space left, it fills the `/tmp` directory with this big directory `nix-build-cpupower-4.19.75-1.20190925.drv-0` ; what can i do ?
alp has quit [Ping timeout: 246 seconds]
andi- has quit [Ping timeout: 244 seconds]
andi- has joined #nixos-aarch64
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
pbb has quit [Ping timeout: 246 seconds]
kloenk has quit [Ping timeout: 244 seconds]
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
<Mic92> Meh. I should have go for rpi rather than a rock64
<Mic92> Still no upstream support for hdmi sound
t184256 has left #nixos-aarch64 ["Error from remote client"]
kloenk has joined #nixos-aarch64
t184256 has joined #nixos-aarch64
juliosueiras has quit [Ping timeout: 260 seconds]
<pinage404[m]> `nix search 'linuxPackages.*rpi'` take MANY memory and doesn't respond after too much times, what happend ?
<pinage404[m]> if anyone has the same issues for the no space left for `boot.kernelPackages = pkgs.linuxPackages_rpi3;` i have solved with `TMPDIR=/media/data_hdd/tmp nixos-rebuild switch`
orivej has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
juliosueiras has joined #nixos-aarch64
pbb has joined #nixos-aarch64
alp has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
zupo has joined #nixos-aarch64
bennofs__ has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 260 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 246 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
alp has quit [Ping timeout: 244 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 244 seconds]
<samueldr> Mic92: not like usptream support for the pi is better really
<samueldr> you would have had to go for a previous model
<Mic92> Yeah, my rock64 is as old as the previous model
<samueldr> the only thing the raspberry pi family of products has that is truly different from other devices, is the size of the community
<samueldr> but the foundation acts just as badly (if not worse) than other vendors regarding their "BSP"
<Mic92> I can get a up-to-date kernel for the raspiberry pi that fully supports the hardware.
<samueldr> with a forked-off kernel with enough differences that it causes issues
<Mic92> The rock64 will never it stuff upstream
<samueldr> it uses rockchip hardware, once another board has that supported, generally all other boards improve at the same time
<samueldr> and I'd say that mainline support is as community-supported for other SoCs and SBCs than raspberry pi is
<samueldr> not entirely sure, I don't think they have people from the foundation working on mainline
<samueldr> working here meaning the main focus
<Mic92> Well, I also get the intention that the graphics driver quality is low.
<samueldr> I assume here rockchip and raspberry pi at the same time
<Mic92> I just get kernel oops
Darkmatter66 has joined #nixos-aarch64
<samueldr> though right that panfrost is a bit newer than the vc4 driver
<Mic92> Maybe I should just go back to x86.
<samueldr> basically, what I'm saying is that the raspberry pi is not a panacea when thinking mainline, compared to other SBCs
<samueldr> it's a bit oversold that they're "open source friendly" and "just linux"
<samueldr> oversold? overblown? anyway, not as true as it is :(
<Mic92> At least their devices feel more stable
<samueldr> I'd wager than only a single-digit percentage of users in their community is using mainline
<samueldr> (there is a wild amount of raspberry pi users! the mainline users are probably, in absolute numbers, much bigger than I'd think anyway, but comparatively it's probably small)
<Mic92> Yeah. Even more a reason to not go for the niche boards.
<aminechikhaoui> Hello, is there a usable rpi4 image from hydra by any chance ?
<aminechikhaoui> trying to resurrect mine :D
<aminechikhaoui> I tried one of https://hydra.nixos.org/job/nixos/trunk-combined/nixos.sd_image_raspberrypi4.aarch64-linux but it didn't even show the colors screen or any boot log
<samueldr> aminechikhaoui: do you want to help out with a fresh PR?
<aminechikhaoui> I don't know where to start hehe
<samueldr> uh weird, it should have shown colours at boot... except if the display is somehow problematic
<aminechikhaoui> what's the current status
<samueldr> is your rpi4 working with that display and raspberry pi os?
<aminechikhaoui> yeah I think I used that before
<samueldr> the current status is: different enough to matter compared to the mainline image; should support everything the foundation supports
<aminechikhaoui> I actually had an old image in the sdcard from 20.03 maybe and it was showing the colors screen
<aminechikhaoui> without booting
<aminechikhaoui> but I was trying to get the latest and try again
<samueldr> weird, since this happens before the actual linux boot process, using binaries from the foundation
<samueldr> if that doesn't work, it points to the firmware not being happy with the hdmi setup and not starting it
<aminechikhaoui> let me just start over to make sure
<samueldr> just checking
<samueldr> you did uncompress the image when burning, right?
<samueldr> and burn to the device?
<samueldr> never assume an experienced user can't accidentally do something wrong :)
<aminechikhaoui> hehe I just did that few seconds ago and then realized it but the one that didn't boot I'm pretty sure I did zstd -d before :)
<samueldr> I pipe the decompression into dd (shouldn't matter)
<samueldr> well, truly I also don't directly do it and use a stupid wrapper that does it for me
<aminechikhaoui> yeah safer than manually typing it each time :)
<samueldr> it detects the compression algorithm and uses the right uncompression thing
<samueldr> I wouldn't really recommend relying on it, but it's there anyway https://github.com/samueldr/burninate
<aminechikhaoui> 👍
<aminechikhaoui> heh this build did bring some logs at least https://hydra.nixos.org/build/126688209
<samueldr> I don't think the eeprom bits should matter really, but I'm not positive
<samueldr> ugh, they _had_ to make the boot process harder to grok
<aminechikhaoui> tho' the error now is that it's complaining about the fs in the sd card
<aminechikhaoui> something like NIXOS_SD inode <number> has an invalid extent node
<samueldr> a possible explanation is a bad burn or bad sd card
<samueldr> though tbf I didn't actually try the image you're using, so there's still a possibility of the image somehow being bad
<aminechikhaoui> yeah I have a flaky adapter which might cause issues
<samueldr> I'll download, burn and boot to check
<aminechikhaoui> I might try their distro just to double check
<samueldr> it could end up accidentally resilient to your issue though
<Mic92> what does iflag=fullblock ?
<samueldr> >> accumulate full blocks of input
<samueldr> dd otherwise nags you that it's going to write less for the first block when you pipe into it
<samueldr> AFAIK it structurally changes nothing
<Mic92> Is the default blocksize not a bit in-efficient?
<samueldr> to my understanding it's mostly a micro-optimization about micro-managing when things get written, when thinking about "burning" sd or usb
<samueldr> Mic92: default for which?
<Mic92> hang on
<Mic92> I did not saw you overwriting it
<samueldr> for my tool? I found that on usb and sd, 8M was the "best", since anything above 8M would end up with ~9MiB/s speeds anyway
<samueldr> dd defaults to 512 bytes and that's sloooooow
<Mic92> yes, especially with direct io
<Mic92> since this does not accumlate in the page cache
alp has joined #nixos-aarch64
<Mic92> I also do direct io for input assuming the user does not need the image in memory afterwards: https://github.com/Mic92/nixos-aarch64-images/blob/main/pkgs/build-image/build-image.py#L66
<samueldr> Mic92: isn't that only for when if= is a file?
<Mic92> Yes. In your case it is a pipe
<samueldr> uh, turns out I never pushed my changes
<samueldr> oh, seek_bytes and skip_bytes could be useful
<samueldr> I'll try to remember next time I have to make gnarly dd chains
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Thra11> samueldr: btw, I've started packaging up the plasma-mobile stuff (the mobile frameworks bits + the apps in https://invent.kde.org/plasma-mobile)
<samueldr> there was a previous (or was it you?) effort IIRC
<samueldr> just in case you hadn't seen it
<samueldr> aminechikhaoui: that specific image worked for me
<Thra11> samueldr: I've seen an old PR just for the plasma-phone-components package. Was there more than that?
<samueldr> I don't know for sure
<samueldr> but you made due diligence in checking I assume then :)
<samueldr> it's such a bummer when you spend some time doing something, only to find a PR with the same exact changes
<Thra11> True
<Thra11> When I want something which isn't packaged yet, I usually start with a nixpkgs PR / issue search.
<Thra11> Probably my number one way of discovering interesting PRs to review
<samueldr> good, I still forget sometimes to check, for fixing bugs it's kind of worse since it's more likely someone has done the change already!
orivej has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-aarch64
<aminechikhaoui> samueldr oh then it might be my sdcard or the adapter having problems
<aminechikhaoui> thanks for checking !
<samueldr> I guess there could still be the issue of the eeprom content misbehaving with the firmware partition content
<samueldr> which is... not something I know how to debug really
cole-h has quit [Quit: Goodbye]
<samueldr> heh, our "all =m" thing for kernel configuration can produce weird results
<samueldr> like CONFIG_CMDLINE="m"
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<Mic92> thefloweringash: do you know where rockchip's mpp went?
orivej has quit [Ping timeout: 244 seconds]
<Mic92> I see mpv now supports rkmpp directly
<aminechikhaoui> samueldr hm raspios did boot fine though
<samueldr> aminechikhaoui: you did re-dd the nixos image too, right? how did you get the image? maybe you had an incomplete download through the browser?
<samueldr> I used nix-store --realise
<aminechikhaoui> I did curl -O of the url of the hydra build product
<aminechikhaoui> but I can try nix-store -r as well
<samueldr> the only difference I can see is that nix-store -r would check the outputs
<samueldr> one thing I wanted to add to burninate was a verification on-device
<samueldr> aminechikhaoui: your SD card is big enough, right? I think 4GB+ is required
<samueldr> 2GB won't cut it
<aminechikhaoui> yeah I have 32Gb
<aminechikhaoui> samueldr magic ! it's now working
<aminechikhaoui> so it's all stupid issues preventing me from experimenting with it all this time :p
<aminechikhaoui> it's a bit odd I get something corrupt from curl
<aminechikhaoui> I meant wouldn't zstd -d fail as well
<samueldr> I don't know how it acts on a truncated input
<samueldr> it *is* a stream compression/decompression scheme after all
<samueldr> you might want to sha256sum the two different files to compare
<samueldr> if they're the same, then *something else* changed, maybe that `dd` invocation ended up syncing before you removed the device
<samueldr> you did sync and/or eject, did you?
<aminechikhaoui> oh it might be a sync problem, tho since I'm not mounting a filesystem I though dd operations don't need sync
<samueldr> unless you do direct I/O, which I don't know if it'd do by default without being told to, might not
<samueldr> oflag=direct,sync is what I usually end up using
<samueldr> which AFAIUI that sync is now redundant
<samueldr> but eh, better be safe than sorry
<aminechikhaoui> this might be why I always have problems with dd for burning images :D
<aminechikhaoui> I sometimes switch to unetbootin just for that, which I guess makes sure to handle syncing
justanotheruser has quit [Ping timeout: 244 seconds]
quinn has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Smith[m] has joined #nixos-aarch64
<samueldr> clever: you're quite Raspberry Pi-adjacent, do you have any clues to look into for #97732
<{^_^}> https://github.com/NixOS/nixpkgs/pull/97732 (by matthewbauer, 2 days ago, open): linux-rpi: 4.19.118 -> 5.4.61
<samueldr> it seems that using the Raspberry Pi Foundation's own 5.4 kernel fails to boot with U-Boot
<samueldr> that same exact kernel boots fine directly from the firmware, and the foundation's 4.9 kernel boots fine both with U-Boot and the firmware
<samueldr> "fails to boot" here means that during stage-1 mmc0 (the sd card) never shows up
<clever> samueldr: pi3 or pi4?
<samueldr> pi 4
<samueldr> on the pi 3 the same exact kernel is fine
<samueldr> (using bcm2711_defconfig, so the pi4's defconfig AFAIK)
<clever> the 4 has a 3rd SD controller, is uboot saying to use the right one?
<samueldr> hm?
<clever> try building an initrd that includes a shell and the dtc binary
<clever> then run `dtc /proc/device-tree` with and without uboot
<clever> and see what the difference is
t184256 has left #nixos-aarch64 ["Error from remote client"]
<samueldr> U-Boot itself does not ship a device tree for the rpi4, so this uses a raspberry pi foundation's FDT, which both the pre-built and the kernel-built fail
<clever> the firmware also patches the dtb after loading it
<clever> and uboot may undo that patching
<samueldr> just stating again that with rpi-4.9 all is fine
<clever> ah, same firmware in both cases?
<samueldr> yes, only diff is linux_rpi's version
<samueldr> and using the same prebuilt raspberrypifw FDT
<samueldr> so it truly is the only difference
<samueldr> one thing I haven't tried is shoving the prebuilt FDT on top of the kernel-built FDT
<samueldr> brb
<thefloweringash> Mic92: your comment made me go look, and it sure looks like the main rockchip-linux/mpp repo his disappeared.
<clever> samueldr: does the error say which mmc controller is failing?
<samueldr> there is no error AFAICT with mmc or sd greppable terms
<samueldr> it's as if mmc0 wasn't even looked at or tried
<clever> it may help to get a shell inside the initrd, and then poke at /proc/device-tree and /sys, to see what mmc0 is tied to
<samueldr> will look after trying shoving the prebuilt FDT
<clever> i think /sys/class/block/mmc0/ will reveal the MMIO base addr
<samueldr> nothing under block
<samueldr> no mmc* under /sys/class/block
* samueldr preps image with dtc
<samueldr> though one issue is saving that output
<samueldr> I guess usb
<clever> samueldr: serial console? network?
<clever> dropbear should work, if you include the drivers in the initrd
<samueldr> let's not push our luck with untested network :)
<samueldr> serial is tricky because of how badly setup I am right now
<samueldr> I would have to move my whole setup on that other desk
<samueldr> and it's a real rat's nest right now
<samueldr> (and serial doesn't really allow saving the file outright)
<clever> i think the pi4 network is relatively simple, when compared to usb
<clever> at a hw level
<samueldr> I know usb works
andi- has quit [Quit: WeeChat 2.8]
<clever> things like minicom can log to a file as well
<samueldr> yeah, but that gets messy :)
<samueldr> picocom can too
<samueldr> it's actually easier to dig up a usb drive right now
<samueldr> just verified to be working
andi- has joined #nixos-aarch64
<clever> [ 1.894141] mmc-bcm2835 fe300000.mmcnr: could not get clk, deferring probe
<clever> that looks like SDHCI, what was the main controller on VC4
<clever> it may not be muxed to any pins, causing issues
superherointj has joined #nixos-aarch64
<superherointj> Hello.
<clever> oh wait, correction, SDHCI was for wifi
<clever> [ 3.862219] mmc1: new high speed SDIO card at address 0001
<samueldr> clever: that deferring probe is present too on the non-u-boot image
<clever> samueldr: so mmc1 is the old SDHCI
<clever> and it manages wifi
<samueldr> quite possibly, emmc2 is the name in the DT for mmc0
<clever> mmc0 then is the uSD slot, but i dont see that in dmesg
<samueldr> yeah, that's a "failed" boot :)
bennofs__ has quit [Remote host closed the connection]
bennofs has joined #nixos-aarch64
<clever> samueldr: if you `find /sys
<clever> samueldr: if you `find /sys | grep mmc` do you see a second instance, that isnt mmc1
<superherointj> I think the PR is now acceptable: https://github.com/NixOS/nixpkgs/pull/97764 ... with backports 20.09 / 20.03 ready too. It just has to be reviewed and accepted. But I don't want to bother. But I am a bit anxious in seeing it working. Hope you understand. Humans. :D
<{^_^}> #97764 (by superherointj, 2 days ago, open): [20.09] nixos/dmidecode: added recommended patches
<samueldr> clever: some for mmc0 led
<samueldr> clever: some for /sys/devices/platform/emmc2bus which is more likely relevant
<clever> samueldr: is that a symlink, to what?
<samueldr> itself a folder
t184256 has joined #nixos-aarch64
<clever> samueldr: is there a device symlink within it?
<samueldr> with fe340000.emmc2 file
<clever> yeah, thats what i was looking for
<lovesegfault> samueldr: Seems like the wiki's info on RPI4 are no longer working
<clever> arch/arm/boot/dts/bcm2838.dtsi: emmc2: emmc2@7e340000 {
<clever> samueldr: yep, thats EMMC2
<lovesegfault> > The option definition `hardware.deviceTree.base' in `/home/bemeurer/src/nix-config/hardware/rpi4.nix' no longer has any effect; please remove it.
<{^_^}> error: syntax error, unexpected $undefined, expecting ')', at (string):323:23
<samueldr> lovesegfault: possible, there are recent PRs changing behaviour
<lovesegfault> Trying to figure out how it should be now
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
<samueldr> clever: the .dts don't really seem to have consequential differences
<clever> yeah, the diff is pretty minor
<clever> more pins for the uart, framebuffer missing, revision missing
<clever> the pcie change is the most drastic, but it wouldnt interact with mmc
<samueldr> that was what my intution told me
<samueldr> I could build that working dts into a dtb and try u-boot with it still
<samueldr> otherwise
<samueldr> raspberrypi-firmware soc:firmware: Request 0x00048010 returned status 0x00000000
<samueldr> a bunch of similar stuff in the failing boot
<samueldr> not present in the okay boot
<samueldr> raspberrypi-firmware soc:firmware: Attached to firmware from 2020-08-19 17:38, variant start
<samueldr> at the location of the first failing request
<samueldr> clever: does that sound relevant?
<clever> samueldr: thats just the date from the git commit of the firmware source, and that its start.elf, not start_x.elf
<samueldr> I mean, it looks like with u-boot it can't "talk" to the firmware
<samueldr> while without it can
<clever> ahh
<clever> that relies on a firmware node in the dts
<samueldr> raspberrypi-firmware soc:firmware: Request 0x00000001 returned status 0x00000000
<samueldr> raspberrypi-firmware soc:firmware: Request 0x00000003 returned status 0x00000000
<samueldr> those are the first two commands
<samueldr> failing
<samueldr> and on the other dmesg they are what I'd call "hello" responses
<samueldr> raspberrypi-firmware soc:firmware: Attached to firmware from 2020-08-19 17:38, variant start
* clever looks
<samueldr> raspberrypi-firmware soc:firmware: Firmware hash is e90cba19a98a0d1f2ef086b9cafcbca00778f094
<samueldr> it seems to also cause
<samueldr> raspberrypi-exp-gpio soc:firmware:gpio: Failed to get GPIO 0 config (-22 80)
<clever> thats the gpio expander
<samueldr> from raspberrypi-firmware soc:firmware: Request 0x00030043 returned status 0x00000000
<clever> oh, *looks more*
<samueldr> so to me this really sounds relevant
<samueldr> I don't know on 4.9 how that compare
<clever> column J row 71, bingo
<clever> the gpio expander, pin 4, controls the voltage to the uSD slot
t184256 has left #nixos-aarch64 ["Error from remote client"]
<clever> and the only way to control it, is to talk to the firmware
<samueldr> oh, so to enable MMC it needs to somehow be able to talk to the firmware to somehow be able to do GPIO stuff
<samueldr> is that it?
<samueldr> yeah
<samueldr> neat
<samueldr> I don't have a clue what to do next but I should eat first
<samueldr> I probably should have ate ~1h30 ago
<clever> they ran out of gpio pins, so they stuck an 8 pin i2c expander on the i2c bus
<clever> and they cant take pins away from the gpio header, the horror!!
<clever> checking kernel source...
<clever> drivers/firmware/raspberrypi.c: dev_err(fw->cl.dev, "Request 0x%08x returned status 0x%08x\n",
<clever> 373 { .compatible = "raspberrypi,bcm2835-firmware", },
<clever> it wants a dts entry with that compatible
<clever> compatible = "raspberrypi,bcm2835-firmware\0simple-bus";
<clever> which you do have