<samueldr> archseer: yes, I could have been more specific, the updated PR not pushed to that branch yet
<samueldr> I made the `f` commits to fixup later, and didn't want to add way more noise than needed :)
bennofs__ has joined #nixos-aarch64
<samueldr> ugh, I wrote it wrong... should have said: "the updated branch, not pushed to that PR yet"
bennofs_ has quit [Ping timeout: 264 seconds]
rajivr has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
cole-h has quit [Ping timeout: 256 seconds]
h0m1 has quit [Ping timeout: 258 seconds]
h0m1 has joined #nixos-aarch64
ajs124 has quit [Quit: Bridge terminating on SIGTERM]
ajs124 has joined #nixos-aarch64
<angerman> how do I completely disable GC in nix?
<angerman> the segfaults i get on aarch64, all happen in GC_...
<angerman> export GC_DONT_GC=1, doesn't seem to prevent this.
<samueldr> hmmmmmmmmmmmmmmmmmmmmm https://review.tizen.org/git/?p=adaptation/ap_samsung/xserver-xorg-misc-exynos.git;a=blob;f=debian/control;h=a8823fb2d9c80c380b828408a4c2858aedbdf53b;hb=HEAD
<samueldr> and similarly hmmm https://review.tizen.org/git/?a=project_list;pf=adaptation/ap_samsung
<samueldr> I hadn't thought about looking at tizen things
<samueldr> wonder how usable standalone the EFL bits are
<samueldr> might be quite variable
<samueldr> looking at the clock app... maybe
<samueldr> hmm, on a second look, probably not
<colemickens> interesting that this seems to use the qemu-static method well enough to get a raspi3 image: https://www.reddit.com/r/NixOS/comments/l54do3/build_your_nixos_raspberry_pi_image_using_github/
<samueldr> for aarch64 you end up mostly assembling things
<samueldr> since a lot is already cached
<samueldr> the real test would be doing a full stdenv rebuild
lopsided98 has quit [Ping timeout: 240 seconds]
<colemickens> oh, my bad, I didn't realize rpi3 was aarch64. Huh.
<samueldr> haha
lopsided98 has joined #nixos-aarch64
<archseer> samueldr: attribute 'currentSystem' missing in eval-config
<samueldr> I think you already hit that in the past
<archseer> the way I worked around it is import the pkgs first
<archseer> I think you could just specify a system when you call evalConfig
<samueldr> I?
<samueldr> the evalConfig from composeConfig should inherit whatever the general config has
<samueldr> so wouldn't it be needed only in your usage of evalConfig?
<archseer> I'm not sure but I needed to do that workaround with the original version of the PR
<samueldr> hmm
<samueldr> maybe I don't see the issue
<samueldr> or something was done differently
<archseer> I don't think it just inherits the system correctly
<archseer> I'm calling it the same way you would through lib/configuration.nix: https://github.com/archseer/mobile-nixos/blob/flake/flake.nix#L15-L19
<archseer> just generating the modules to import
<samueldr> where is the `currentSystem` it errors on found?
orivej has joined #nixos-aarch64
<archseer> try running my flake, might be easier to diagnose
<archseer> I had a similar issue with the version we had a few days ago, then I started passing that dummy system value and it worked
<archseer> maybe these imports happen too soon and don't inherit the value? https://github.com/archseer/mobile-nixos/blob/flake/flake.nix#L15-L19
<archseer> if I wrapped them in a closure maybe
<samueldr> there's not much Mobile NixOS can do here I think
<samueldr> uh
<samueldr> let me verify
<samueldr> hm
<samueldr> maybe composeConfig doesn't play well with that
<samueldr> but that should be easy to fix
<elvishjerricco> `No partition table` also `card did not respond to voltage select`
<elvishjerricco> There most certainly is a partition table
<elvishjerricco> Is my card borked or something?
<samueldr> "card did not respond to voltage select" means that the board does not see the card
<elvishjerricco> oh
<elvishjerricco> wut
<samueldr> like, it tried to pass electricity to it and it was an open circuit
<elvishjerricco> Well it was certainly in there
<samueldr> it might be a bad contact
<samueldr> sometimes some boards don't like being rebooted
<elvishjerricco> I took it out and put it back at least once
<samueldr> and only power off / on cycle works
<samueldr> elvishjerricco: try rubbing the contacts on the card
<elvishjerricco> samueldr: This was after a power off / on
<samueldr> just with your clean finger, not too strongly, but not weakly
<elvishjerricco> samueldr: Well I can plug it into a usb adapter and read that from the very same pi
<elvishjerricco> using another card with an image that does boot
<samueldr> yeah
<samueldr> but try it anyway
<elvishjerricco> sure. I'm flashing ubuntu on this card now, then I'll be able to try
<samueldr> might be that there's just enough light corrosion or something at just the right location for _that_ reader (the built-in reader of the board)
<samueldr> not all readers are equal after all
<elvishjerricco> samueldr: Well the Ubuntu image booted on this card
<elvishjerricco> Let's try putting the NixOS image on it again...
<samueldr> but that's the only location `eval-config.nix` would be used by Mobile NixOS from your usage
<samueldr> since you're not using release-tools.nix
<archseer> yes! that fixes it!
<samueldr> great, thanks for your patience
<elvishjerricco> samueldr: Yea, so the card will boot with ubuntu on it but not my image :/
<samueldr> elvishjerricco: hmm, ah, CM4?
<elvishjerricco> yea
<samueldr> here be dragons!
<archseer> I'll send in a PR with the flake definition once 238 is merged
<samueldr> elvishjerricco: I think what is happening is that the u-boot on that sd image doesn't know about the sd setup of the CM4
<samueldr> since obviously u-boot booted from the sd image
<samueldr> otherwise u-boot couldn't complain about the missing sd image
<elvishjerricco> samueldr: I would think the u-boot patches you helped me find for the cm4 would have fixed anything like that
<samueldr> I assume it's a _patched_ u-boot with CM4 patchset, right?
<elvishjerricco> yea
<samueldr> is the .dtb file for the CM4 present at the root?
<elvishjerricco> I believe so... I'll check
<samueldr> I don't know if u-boot would boot in that case
<samueldr> (if it wasn't there)
<samueldr> so maybe it is already there and proven by it booting
<samueldr> I guess read more in the mailing list thread, maybe there's info?
<samueldr> I also guess ubuntu doesn't use u-boot, and directly boots the kernel
<elvishjerricco> I believe that is the case, yea
<elvishjerricco> dunno about raspbian though
<elvishjerricco> Yea, bcm2711-rpi-cm4.dtb is there
<samueldr> raspbian _definitely_ doesn't use u-boot
<samueldr> well, raspio's
<samueldr> part of a healthy and balanced breakfast
<elvishjerricco> samueldr: How do I find any other messages in the mailing list thread? I don't see a link to any other messages here: https://patchwork.ozlabs.org/project/uboot/cover/20210112125531.26547-1-nsaenzjulienne@suse.de/
<samueldr> hm, patchwork isn't great for mailing lists view
<samueldr> per patch the replies will be shown
<samueldr> I guess no one replied to the cover letter
<samueldr> in these situations you need to find a mailing list interface for it
<samueldr> good thing u-boot has one official such interface
<samueldr> the kernel has a couple, all bad for different reasons
<samueldr> in pipermail, when on a message, the "Thread" link at the bottom links you to here
<samueldr> which shows you all the zero replies to the v6 patch set
<samueldr> in the v5 series
<samueldr> > I am seeing an error which I need to test a bit more around mmc
<samueldr> > voltage select which I didn't see previously:
<{^_^}> undefined variable 'I' at (string):471:1
<{^_^}> error: syntax error, unexpected ':', expecting ')', at (string):471:45
<samueldr> thanks bot
<samueldr> so it may be that the patch set doesn't work right now with SD
<elvishjerricco> samueldr: Will it boot off the usb adapter?
<samueldr> good question!
<samueldr> if it's like the pi 4, it will require configuration of the eeprom firmware
<elvishjerricco> Let's give it a shot...
<elvishjerricco> how would I configure that?
<samueldr> the latter link only deals with usb boot
<samueldr> also update the eeprom, maybe?
<samueldr> that's a whole source of uncertainty with the 4 series of pi hardware
<samueldr> no way to know how the built-in eeprom firmware will affect the boot
<samueldr> so all guesses are good and bad
cole-h has joined #nixos-aarch64
<elvishjerricco> Ugh... I have to get raspberry pi os to update the eeprom to get usb boot support...
cptrbn has quit [Quit: Textual IRC Client: www.textualapp.com]
orivej has quit [Ping timeout: 272 seconds]
<elvishjerricco> Huh... I updated the eeprom for usb boot support. It boots but then kernel panics on "Attempted to kill init"
<samueldr> good news it can boot from usb
<samueldr> but uh, a bit concerning I guess :)
<samueldr> since you played in a custom stage-1 a bit, you must know what that means
<elvishjerricco> Going back to the sd slot, works fine
<samueldr> so the eeprom firmware update _may_ have changed something that helped with the sd slot and u-boot?
<elvishjerricco> samueldr: Oh, no I'm starting with the raspios image just to see if I have usb boot
<samueldr> ah
<samueldr> good idea though
<samueldr> start from expected good values
<samueldr> start from expected good values
<samueldr> start from expected good valuesd
<samueldr> oops
<samueldr> that explains why the terminal wasn't updating
<elvishjerricco> Lol
<samueldr> I assumed it was laggy because it often is with that device
<elvishjerricco> It boots the kernel, the kernel spits out a bunch of stuff about usb, seemingly normal, and then barfs a bunch of `CPU1: stopping` and whatnot preventing me from seeing any messages for more than a fraction of a second before it stops.
alpernebbi has joined #nixos-aarch64
<samueldr> raspios or nixos?
<elvishjerricco> raspios
<samueldr> fresh image from them? that would be odd that it fails on the CM4
<elvishjerricco> Oh wait. Saw something about a read error
<elvishjerricco> It works in the sd card slot, just not in a USB adapter
<samueldr> oh, not all usb card readers will work exactly as a usb flash drive
<samueldr> you're better off with a classic usb drive
<samueldr> I'm not sure why, and I know it's not universal
<elvishjerricco> Ah. Well I have none of those...
<elvishjerricco> Is there any way to see the kernel messages before the panic?
<sphalerite> serial
<elvishjerricco> Oh gosh. I have no idea how to access serial on this thing
<samueldr> I would assume the same GPIO pinout, but maybe check
<elvishjerricco> It is the same gpio pin out but that does not mean I know how to use that for serial :P
<LinuxHackerman> do you have a USB-UART adapter?
<samueldr> the topic should contain "have your serial adapter at the ready!"
<LinuxHackerman> yes
<elvishjerricco> Lol well I guess I'm going back to the sd slot...
<samueldr> since peter robinson had the same issue (seemingly) as you did with sd
<samueldr> I'm thinking u-boot won't work just now
<samueldr> you could look at the raspberry pi 4 sd image builder derivation, and (locally) revert the update that changed it to use u-boot
<samueldr> note that there are a few caveats, like bad mount point configuration in such a built system
<samueldr> but it would boot using the kernel directly
<elvishjerricco> samueldr: Peter Robinson? Did he write down the things he tried anywhere?
<samueldr> not as far as I can tell
<samueldr> it was the reply I linked to earlier
<elvishjerricco> Ah
<samueldr> the name is well-known, IIRC at fedora, paid to work on ARM boards
<elvishjerricco> I have a feeling that I'm going to get some variation of this problem when linux tries to read the sd card as well
<samueldr> I don't really think so
<elvishjerricco> Should that happen, I'll see if a newer rpi kernel fixes it
<samueldr> because it's the vendor kernel
<samueldr> vs. a mainline not-vendor u-boot
<samueldr> but yeah, you might need an updated kernel
<samueldr> in fact
<elvishjerricco> samueldr: Right, but is the vendor kernel in nixpkgs up to date?
<samueldr> maybe
<samueldr> something quicker to try first
<samueldr> update the raspberry pi firmware package
<samueldr> which contains the .dtb file
<elvishjerricco> Ah, that's interesting
<samueldr> maybe that's an important difference
<samueldr> since .dtb describes hardware
<samueldr> u-boot uses that to know about the hardware
<elvishjerricco> yea
<elvishjerricco> I'll probably update the kernel too just in case
<samueldr> not a bad idea either, but it would be quicker to just update the raspberrypifw package and build an image :)
<samueldr> you'll see quickly if u-boot fails or not
<samueldr> afterwards, yes please feel free to update the kernel package :)
<elvishjerricco> Oh, I'm guessing the kernel package is actually built from source, isn't it?...
<elvishjerricco> Not looking forward to building a kernel on this thing
<samueldr> exactly
<elvishjerricco> What would be faster, 32 threads of qemu emulation, or 4 threads of rpi cpu?
<samueldr> true qemu emulation, slow
<samueldr> qemu-user, probably faster
<samueldr> but really
<elvishjerricco> qemu-user?
<samueldr> sd card = deadly slow
<samueldr> binfmt thing
<elvishjerricco> samueldr: Oh, yea I have the binfmt thing
<samueldr> that's qemu-user[space] emulation
<elvishjerricco> yep
<samueldr> while qemu-system would be a full system and yes be slow
<samueldr> but really where the rubber meets the road, SD cards are terrible
<elvishjerricco> but with qemu-user, 32x emulated (threadripper 1950X), or 4x rpi?
<samueldr> most likely qemu-user would end up faster due to more parallelization
<samueldr> on an RK3399 device I compared SD card perfs vs. NVMe and it caused literally the system to go from unresponsive while building to still be usable
<elvishjerricco> Yea building the kernel pushes my cpu to 100 for like 95% of the build
<samueldr> and not only that, but builds were multiple times faster
<elvishjerricco> oh that's cool
<elvishjerricco> Yea I guess it would spend a very nonnegligible amount of time just waiting on the sd
<samueldr> yes, SD cards destroy the iowait
<elvishjerricco> Alright. Now to rebuild my sd image...
zupo has joined #nixos-aarch64
<elvishjerricco> Well... did not know that raspios was built for arm7l... Thought it was aarch64. Now I gotta image ubuntu again
<samueldr> heh
<samueldr> vendors!
<elvishjerricco> Wonder why they use armv7l
<samueldr> raspberry pi 2
<samueldr> *and* lots of non-free bits and bobs other vendors shipped for the pi ecosystem
<elvishjerricco> hmph well I'm gonna pout about it
<samueldr> yeah, raspberry pi, strictly my opinion here, are not good vendors for aarch64 and arm
<samueldr> (talking SBCs, don't really know about their new silicon)
<elvishjerricco> I'm glad they exist though. I'm guessing they're a major reason other vendors decided to start making similar SBCs.
<samueldr> they helped
<elvishjerricco> God dammit. Every time I image this card I forget that the CM4 has this very annoying quirk where you have to add a line to config.txt or else the usb ports are disabled
<samueldr> oh
<elvishjerricco> I don't think that's why usb boot didn't work; iirc I had made that change already
Darkmatter66 has joined #nixos-aarch64
cole-h has quit [Ping timeout: 264 seconds]
<elvishjerricco> Darn. Updating the firmware didn't help
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 258 seconds]
lopsided98 has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 272 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<patagonicus> Oh, I totally missed that nixpkgs has ghc for armv7l now (and I say now, my nixpkgs is still on December 1st). On the other hand my machine has been stripping the lib and bin dirs of that for more than an hour now.
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…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
v0|d has joined #nixos-aarch64
misuzu has joined #nixos-aarch64
alpernebbi has quit [Quit: alpernebbi]
cole-h has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
dev_mohe has joined #nixos-aarch64
julm has joined #nixos-aarch64
v0|d has quit [Ping timeout: 258 seconds]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
<samueldr> news from elsewhere: first audio call with the liberated modem firmware on the pinephone!
<samueldr> (by the author)
<ryantrinkle> samueldr: wow, that's awesome!
<samueldr> note: still contains qualcomm proprietary bits, it's liberated from the additional vendor layers
<samueldr> I don't know for sure, but I wouldn't expect any of the qualcomm bits to be replaced
<samueldr> probably well secured, and anyway known to conform to the regulations and laws
<samueldr> welp
<samueldr> this explains why things started failing with modules
<{^_^}> #78430 (by puckipedia, 1 year ago, merged): nixos/stage-1: Do not allow missing kernel modules in initrd
<samueldr> tagged release (not for general consumption) https://github.com/Biktorgj/pinephone_modem_sdk/releases/tag/0.1.1
dev_mohe has quit [Quit: dev_mohe]
<yorick> colemickens: as it turns out, I did have that netboot/nfs lying around somewhere https://gist.github.com/yorickvP/55910c5372cfb050f02a688bd867ca8e
<yorick> but this is targeted to the rpi3
<yorick> I'm very interested in getting it working on the 4
<colemickens> Does this include laying out the rootfs in the nfs export?
<samueldr> ARMv5TEJ to be exact
<samueldr> really, NixOS is not a good fit... but a Nix-built OS will
<samueldr> details about the CPU https://linux-sunxi.org/F1C100s
<samueldr> the wi-fi microSD card is adorable!
<colemickens> yorick: that's cool, if you have the other side of it (laying out the nfs export) I'd be curious to see it too!
<yorick> colemickens: I seem to have lost that, but it's just services.nfs.server with a read-only /nix bind-mounted into it
<yorick> (and special care to translate the 'root' user)
<matthewcroughan> samueldr: I couldn't get any further with the Opi3.
<matthewcroughan> Any instantaneous wisdom you can bestow?
<samueldr> none at all
<matthewcroughan> Bah, time to give up and use Armbian :P
<matthewcroughan> It's in the u-boot master isn't this?
<matthewcroughan> Well crap
<matthewcroughan> what now needs to happen to get it into nixos?
<matthewcroughan> the same change I made to add it manually?
<samueldr> uh?
<samueldr> I don't follow
<matthewcroughan> this
<matthewcroughan> with the exception of L22-26 of pkgs/misc/uboot/default.nix, is this all that's required
<samueldr> yeah
<matthewcroughan> so I should submit a PR?
<samueldr> if it was in 2021.01
<samueldr> if it works
<samueldr> (u-boot that is, if the kernel needs other things, that's another issue)
<matthewcroughan> samueldr: It is in v2021.01
<matthewcroughan> so I should build it, test it, and then submit a PR?
<samueldr> yes
<matthewcroughan> if I get to the SPL, does that qualify as good enough?
<samueldr> it needs to get into u-boot proper
<matthewcroughan> Ah, ok.
orivej has quit [Ping timeout: 246 seconds]