bennofs_ has joined #nixos-aarch64
bennofs__ has quit [Ping timeout: 265 seconds]
<samueldr> got it with the sd card... now will it work on the iso? :)
<samueldr> totally looks like somethin in the UEFI boot flow breaks something with rockchipdrm here
h0m1 has quit [Ping timeout: 276 seconds]
h0m1 has joined #nixos-aarch64
<samueldr> anyone with a "free" RK3399 + HDMI that would know how, and have the time to test an sd image vs. iso image build of the same Nixpkgs (with the same kernel) to see if it's a pinebook pro issue, or RK3399 issue?
<zhaofeng> samueldr: On an unrelated note, I assume you've tried the patched ATF in https://github.com/samueldr/wip-pinebook-pro/issues/3 - Does it work, and are you still using it?
<{^_^}> samueldr/wip-pinebook-pro#3 (by samueldr, 1 year ago, open): Suspend to RAM with tsys' kernel tracking issue
<samueldr> not yet tried it
<samueldr> I tried to try it
<samueldr> but I've been having issuees with UEFI boot on the pinebook pro!
<samueldr> just today tracked it to UEFI issues
<samueldr> also booting from UEFI seems to break poweroff
<samueldr> that's awfully inconvenient
<zhaofeng> Oh nice, never tried UEFI and would be really great if it worked
<samueldr> been trying to fix the iso image build so it works A+++ on many aarch64 systems
<samueldr> (those I have around)
<samueldr> I guess I'll "volunteer" my builder again
<samueldr> zhaofeng: you should try it for yourself, as I won't be able to try it properly for a while still
<samueldr> considering I really wanted to re-setup my PBP with UEFI before doing anything new with it
<samueldr> so glad, though, that I can continue with the actual important part of my work whether or not UEFI on RK3399 works
<zhaofeng> Cool, gonna try in a bit
<zhaofeng> Not sure how legit it is, but looks very interesting
<samueldr> it's probably "legit"
<samueldr> but probably not something I'd look into
<samueldr> looks like at first glance they might not be complying with licenses correctly
<samueldr> they've been spamming some subreddits for the past few months
<samueldr> about how they're the only and first linux tablet
<samueldr> and things like that
rajivr has joined #nixos-aarch64
<samueldr> not sure if they finally unveiled what the hardware actually will be
<samueldr> it's a toss-up whether it'll be an overall good thing for the whole community or just a quick buck for them
<samueldr> apparently mediatek helio p90
<samueldr> I wouldn't trust any kernel tree to come out
<samueldr> or maybe even worse
<samueldr> Unisoc Tiger T7510
<zhaofeng> Hmm, neither seem to cite their sources. What are their *actual* specs? 🤔
<samueldr> zhaofeng: I don't want to imply anything... but your name sounds more chinese than mine, maybe you'd have better luck digging for info?
<samueldr> (yes, I'm assuming a whole ton here)
<samueldr> (and I could be wrong, if so, sorry!)
<zhaofeng> Yeah, guess I need to dig more. Just watched their teaser video and I'm excited and skeptical at the same time
<zhaofeng> (especially with no actual prototype - just renders)
<samueldr> the hardware side of thing does not follow suit
<samueldr> and most likely this is an ODM design, which is not an issue in itself... it just means it's not something they designed
<samueldr> and probably also means it's going to be built on whatever BSP they get
<samueldr> also quotes Unisoc T7510
<samueldr> though that site also looks like a scraper/aggregator
<samueldr> but the "the domestic Ziguang Zhanrui Tiger Card T7510" sounds like translation
<samueldr> "card" is something I've often seen used in less good translations for CPU
<zhaofeng> Ew, this machine translated article is so hard to read: https://daydaynews.cc/en/digitals/a-small-step-for-the-tiger-a-big-step-for-domestic-chips.html
<zhaofeng> But it seems to be the most likely candidate with built-in 5G baseband
<samueldr> given the lack of transparence they've exhibited previously, I don't have any hopes to see the kernel
<samueldr> and it won't be mainline-based I bet on it
<zhaofeng> Guess I'll hold off until I see an actual prototype :/ There doesn't seem to be much information out there even in Chinese
* zhaofeng prays it won't be some 3.x BSP kernel
<samueldr> probably not because of android requirements
<samueldr> but probably some really bad "whatever minimum is required by android" based tree
<samueldr> what I'm actually more curious is
<samueldr> how long until the sam ODM design is linked from alibaba or aliexpress
<samueldr> same*
<samueldr> in itself it's not necessarily an issue
<zhaofeng> There are probably just using Anbox as the apps run in JingOS, not via dual-boot
<samueldr> oh, probably
<samueldr> or maybe using one of those proprietary products
<samueldr> there are "anbox-like" products for android
orivej has quit [Ping timeout: 240 seconds]
<samueldr> great! finally I can tie a bow around my changes
<samueldr> since I have now basically shown that the issue lies with something in the UEFI boot chain
<samueldr> hmph... a bit frustrating, but nothin I can't deal with... I guess for now I'll re-setup it in preparation for future UEFI setup, prep an ESP partition and not use it
<samueldr> I kind of confirmed that with extlinux.conf booting poweroff works fine
figgyc has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
orivej has joined #nixos-aarch64
srk has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-aarch64
<sphalerite> samueldr: as in it will just configure a new output automatically?
orivej has quit [Ping timeout: 240 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
dev_mohe has quit [Client Quit]
<dupon1> Hi, I'm following the wiki guide to build my own ARM image but can't figure out how to cross compile the image
bennofs has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
<samueldr> sphalerite: (pinephone DP output) IIRC I needed to go to the displays panel
<samueldr> and uh, needed the "prefer modesetting" PR to be applied
<sphalerite> hm, difficulty with that was (for me at least) that it doesn't fit on the screen…
<samueldr> yeah, I tested before the xfce bump that broke the interfaces somewhat :(
<samueldr> "broke"...
<samueldr> get in a shell, export DISPLAY=:0 and use xrandr?
Mindavi has quit [Quit: leaving]
<dxb[m]> is fetchgit broken in nixos-unstable? it looks like it's trying to fetch the nixos branch instead of the branch i'm telling it to fetch
<dxb[m]> `Unable to checkout refs/tags/21.05pre-git from https://git.sr.ht/~mil/sxmo-svkbd`
<dxb[m]> i guess that's more of a general nix question
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<dxb[m]> oh lol, i guess i was missing a `rec` in there... not sure how it was building before then
Mirrexagon has quit [Ping timeout: 268 seconds]
<samueldr> #121720 should make the UEFI installer work better on rockchip, allwinner and amlogic hardware
<{^_^}> https://github.com/NixOS/nixpkgs/pull/121720 (by samueldr, 31 seconds ago, open): installer images: Add available modules to stage-1
<samueldr> oh, raspberry pi too, but IIRC it was working out of the box
<samueldr> "work better" means here that it also enables early display init in stage-1
<dxb[m]> samueldr: when i build and run mobile-nixos in a vm, is there a way to emulate hardware button presses like power and volume?
<samueldr> volume: use a volume key on your keyboard
<samueldr> like, on my physical keyboard I have media keys
<samueldr> power... not really
<samueldr> for the stage-1 interfaces "LVGUI" stuff, ENTER and TAB can be used as alternatives
<samueldr> (since it's also meant to work well enough for a touchscreen-less laptop
<samueldr> ah!
<samueldr> I connected the dots
<samueldr> sxmo
<samueldr> ¯\_(ツ)_/¯
<samueldr> though you can rest assured that the volume and power keys on the phone literally are just like the volume and power keys otherwise
Mirrexagon has joined #nixos-aarch64
<dxb[m]> ah ok...
<dxb[m]> i guess i can just use whatever key combos they're sending after interpreting the volume and power keys
<dxb[m]> vol up and down on my laptop didn't work in the vm
<dxb[m]> but that's fine, i'll have to dig a bit more
<samueldr> at the very least for LVGUI I can use the volume keys from my keyboard on the vm
<dxb[m]> the way this builds and runs a vm so easily is pretty damn cool
<samueldr> (though down is up, and up is down)
<samueldr> yeah, I had to make the VM trivial to use *for my own damn self* :)
<samueldr> that's how I test many things that are not hardware-specific
<dxb[m]> yeah this is gonna make it super nice to try to update this sxmo stuff
monk has left #nixos-aarch64 ["Error from remote client"]
justanotheruser has quit [Ping timeout: 250 seconds]
justanotheruser has joined #nixos-aarch64
s1341_ has quit [Ping timeout: 268 seconds]
sorear has joined #nixos-aarch64
s1341_ has joined #nixos-aarch64
<samueldr> hm!
<samueldr> tried the fedora image (for reasons) and it might be *only* the text console that is broken
<samueldr> the gdm (wayland AFAICT) display manager and gnome session works
<samueldr> at least, I'm glad to see that's not an issue with my builds!
orivej has quit [Ping timeout: 268 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
Andoriyu has quit [Quit: ZNC - https://znc.in]
Andoriyu has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 250 seconds]
raspi4 has joined #nixos-aarch64
<raspi4> hi guys, does the gui stuff (x11, mesa, gpu) work on latest raspberry 4 build?
<samueldr> that's a trick question
<raspi4> hehe
<samueldr> IIRC some combination of vendor kernel + vendor boot chain may work
<dupon1> I tried to generate an SD-image with Qemu but it takes ages and can't find how to cross-compile but saw people saying on samueldr's logs it's working
<samueldr> not sure if mainline linux has it working with acceleration
<raspi4> i had it working a year ago but lately i crashed it (my fault) so i rebuilt fresh version
<samueldr> it's possible that if U-Boot is involved, even with the vendor kernel, there will be uh... things... to do
<samueldr> things that I'm not really sure what though
<raspi4> well you got the hardware? then i suggest you just copy the image onto an sd
<raspi4> i got the problem with the device-tree-overlays
<raspi4> when i try to get the graphic with acceleration to work
<samueldr> [08:28:01] <dupon1> Hi, I'm following the wiki guide to build my own ARM image but can't figure out how to cross compile the image
<samueldr> (that was their earlier message, since raspi4 might not have seen it)
<samueldr> ARM is vague :) armv6, armv7 or aarch64?
<raspi4> no idea how to help with cross compiling, didnt manage to get it working last time i tried
<dupon1> samueldr: oops, forgot to say which ^^' it's aarch64
<samueldr> it's not exactly working out of the box still
<samueldr> for the time being there are issues that needs Nixpkgs patches still
<raspi4> hmm
<samueldr> and then some workarounds can be done strictly in NixOS options
<samueldr> raspi4: which board?
<samueldr> oops
<samueldr> dupon1: which board?
<dupon1> I yet have the board but target is Pine64 (normal, not the pro)
<samueldr> if it's well supported by the mainline kernel, you shouldn't need to build anything
<samueldr> dupon1: a big vague, unqualified "Pine64" is their allwinner offer
<samueldr> but since you said pro
<samueldr> might be rock64 from pine64 ?
* dupon1 is tired
<samueldr> a bit*
<dupon1> the Rock64
<samueldr> no worries :)
<samueldr> right
<samueldr> I don't remember if that's well supported by mainline
<dupon1> it's "community supported"
<dupon1> according to wiki
<samueldr> yeah, I mean by the "mainline" linux kernel
<samueldr> which means the kernel from kernel.org, without additional patches
<samueldr> which is what we build in the aarch64 images
<samueldr> and those notes are a bit older, so it might be better now
<dupon1> (even though it'd like to have USB3)
<dupon1> samueldr: thanks, hydra cross compiles or it's native compilation?
<samueldr> native
<samueldr> and that's for the u-boot
<dupon1> hum
<samueldr> the "TLDT" is that most SBCs don't come with an "initial boot firmware" installed already
<samueldr> the TLDR*
<samueldr> "initial boot firmware" is analogous to the BIOS or UEFI of your usual x86_64 machines
<samueldr> most SoCs in SBCs can and will load that firmware from the same storage as the system
<samueldr> (in addition to other sources)
<dupon1> The reason I want to compile my own image is to have a plug 'n play image I can bootstrap for pseudo automatic deployments
<samueldr> you probably want to make yourself an hand-crafted image so you can have a builder to bootstrap yourself with native builds :)
<dupon1> yes but I don't have a 256 cores 512G aarch64 board next to me ^^
<samueldr> you're most likely going to be able to build on the rock64, since a good chunk of it will be cached
<dupon1> that's why I'm trying to cross compile (and I notice a `CROSS_COMPILE=` flag during the nix-build)
<samueldr> I recently updated this repo, https://github.com/samueldr/cross-system
<samueldr> but even with the tip of master, won't cross-compile an sd image or iso image
<samueldr> though AFAIK everything is available either in PRs or on its way through staging
justanotheruser has joined #nixos-aarch64
<dupon1> hum okay
<zhaofeng> Or spend $800 on an M1 Mac :) This thing's performance is unreal, I must say
<dupon1> so you advise me to native build it? (because cross-compile is likely impossible?)
<dupon1> zhaofeng: haha
<samueldr> no, don't buy M1 for linux, unless you research and understand what you get yourself into
<samueldr> dupon1: cross-compiling with NixOS is going to make things harder on you
<samueldr> so I advise it only if you're really confident with everything else in your project
<samueldr> e.g. I was fixing up some issues with the sd image and iso images for arm, I am really confident in everything Nixpkgs/NixOS with those builds, so adding the cross-compilation issues means I'm 99.9% sure that the issues I face are caused by cross-compilation
<dupon1> if it don't requires me to be confident in my lif- I see, NinjaTrappeur told me he had terrible failure with cross-compiling
<samueldr> if I wasn't already confident in the results, then I couldn't really "get" what the root causes of the issues are :)
<dupon1> I get it
figgyc has joined #nixos-aarch64
<samueldr> it's not "don't cross-compile"... but... "cross-compilation is another layer of issues you might want to avoid until you know everything else is supposed to work"
<samueldr> "so that when you hit issues, you're not left scratching your head wondering why"
<dupon1> I understand, I'll get two boards, one to compile and the other to test builds
<samueldr> though you probably can start with one board, as long as you have a way to switch the storage out :)
<samueldr> (assuming you already have one board)
<raspi4> you could use an usb card reader
<samueldr> uuh... to write the sd image from linux, yeah... to boot... YMMV
<dupon1> I yet have a board and I'll wait next month to order one or more, it will give me time to think about :)
zupo has joined #nixos-aarch64
<raspi4> Error at 'compatible': FDT_ERR_NOTFOUND
<raspi4> builder for '/nix/store/30ljrfbjawpfw1cmd83cn90f3m4h347l-device-tree-overlays.drv' failed with exit code 1
<raspi4> cannot build derivation '/nix/store/a2k0r076g0ja4pzpg078jizwpcsl8q9v-nixos-system-raspi-21.05pre286880.7cb76200088.drv': 1 dependencies couldn't be built
<raspi4> error: build of '/nix/store/a2k0r076g0ja4pzpg078jizwpcsl8q9v-nixos-system-raspi-21.05pre286880.7cb76200088.drv' failed
<raspi4> any idea?
<samueldr> FDT_ERR_NOTFOUND is most likely what happens when applying an overlay to a dtb file that either doesn't have labels enabled, or doesn't have the node the overlay is looking for
<samueldr> with the pi4, probably trying to apply an overlay for the vendor kernel on top of mainline
<raspi4> hmm ok... thanks...
<samueldr> >> boot.kernelPackages = pkgs.linuxPackages_rpi4;
<samueldr> that is the configuration that will allow you to use the vendor kernel
<raspi4> got that line
<samueldr> then it's odd
<samueldr> I'm really not familiar with the overlays stuff in NixOS
<raspi4> me neither :/
raspi4 has quit [Quit: Connection closed]
<dxb[m]> is there something i can put in my config to hide the mouse?
<dxb[m]> like to just have it always hidden
<samueldr> dxb[m]: unclutter maybe
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<CRTified[m]> So, I've been redirected here (again): Does anyone has a config for the rpi3b+ at hand where wifi works? According to ip a and the wpa_supplicant log, there is a connection, but the RPi is not reachable over wifi and wpa_supplicant also complains about "RRM: Ignoring radio measurement request: Not RRM network". I'm on nixos-21.05pre286925.3e62e383f4b, the RPi is set up with nixops and using linuxPackages_latest
<CRTified[m]> (_rpi3 won't build on my x86 host). Here's my config right now: https://gist.github.com/CRTified/1c35fd357e6bf08da029860698862f67
* colemickens is tempted to get a rpi3b+ just to help out sometimes, I didnt know it was so popular
<CRTified[m]> I might have one spare 3b+ right now, as I want to move away from them :D
<CRTified[m]> Originally used one for my 3D printer with octoprint (I'm migrating that right now to using nixops, as seen above), and already replaced one for running home assistant with a RockPi 4C (I'm having wifi problems on that one, too... Somehow I'm always fighting with wifi on these things)
<colemickens> oh plus there's a cute little flirc case for it even
apache8080 has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 240 seconds]
apache8080 has joined #nixos-aarch64
<apache8080> Has anyone setup full disk encryption on a raspberry pi with nixos?
<samueldr> yes
<apache8080> do you have a link to an example?
<samueldr> no
<samueldr> anyway it wouldn't help much for the config
<samueldr> since the config is basically the same as on any other NixOS system
<samueldr> what differs is how it was installed
<apache8080> oh, did you have to modify the sd-image.nix script in any way?
<samueldr> encryption through a nix-build is probably a big no no :)
<apache8080> oh ok
<samueldr> sd-image should be seen as a shortcut to an end-result
<samueldr> it's a ready-to-run system
<samueldr> but you can `nixos-install` to another media!
<samueldr> either from the sd-image build, or from alternative ways to boot
<samueldr> the main issue there is how to get the "initial boot firmware" parts set up properly
<apache8080> hmm ok, so during that install step then I would setup the other media for encryption
<samueldr> yeah
<samueldr> you have to be aware of the boot scheme you want to use
<samueldr> whether it's through the raspberry pi "config.txt" scheme which directly loads a kernel, through some other U-Boot based boot schemes, or UEFI through tianocore
<samueldr> sadly I don't really have (yet) documentation for that part
<apache8080> so right now we have just been building sd-images for the various arm boards we are using and booting and running off of that, thats why I was looking at encryption at nix-build time
<samueldr> know that this means the secret (the passphrase) will be part of the build
<apache8080> ah ok
<samueldr> (or you need to work a lot more to not have it part of the build)
<samueldr> and the image builder is currently strongly railroaded into its use case
<apache8080> that makes sense
<samueldr> so even if you had a method to do so, it would be hard to integrate with the current setup
<samueldr> (not impossible!)
<apache8080> ok, thanks for the help
<samueldr> sorry there was no all-in-one answer, but that's the gist of it
<samueldr> oh, and really, being aware of your boot chain here is probably the most helpful "first step" for further customizations of the installation