<patagonicus>
Hmm, re kernel config: as far as I can tell it doesn't complain if crosscompiling on x86_64, but it does fail on a native aarch64 build.
<patagonicus>
Also, my pinephone locked up twice while I was trying to build the image natively. As far as I can tell the MicroSD card becomes totally unresponsive, the system itself on the eMMC was still working fine. But 32GB isn't really enough for Manjaro + building a full mobile-nixos image, I think. Doesn't help that /tmp is a tmpfs by default.
srk has quit [Remote host closed the connection]
srk has joined #nixos-aarch64
<patagonicus>
It boots! I have a shell. :D
<patagonicus>
So, is there a DE in nixos that's reasonably usable on a touchscreen? xfce with an onscreen keyboard, maybe?
<patagonicus>
I've seen a PR for packaging Phosh, but that seems a bit stale.
dstzd has joined #nixos-aarch64
<srk>
gnome :)
<patagonicus>
Any specific things I should enable for that?
<patagonicus>
Hmm, it doesn't seem to detect the USB-C hub's ethernet, which is annoying.
<patagonicus>
Oh, and no iwconfig preinstalled. That makes installing it a bit of a challenge.
monk has left #nixos-aarch64 ["Error from remote client"]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<LinuxHackerman>
oh yeah that will make it difficult :>
<patagonicus>
I'm rebuilding with iwconfig + a few other tools now, but quite a few things fail to build. Probably due to cross-compiling.
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<patagonicus>
Yay, I have internet on the phone now. :)
<patagonicus>
Huh. nix-channel --update fails with an exec format error for bash.
zupo has joined #nixos-aarch64
<Ke>
my guess: interpreter wrong
<Ke>
for a dynamic executable
<Ke>
strings /run/current-system/sw/bin/bash | head
<Ke>
and check whether the first line item exists
<Ke>
like /nix/store/33idnvrkvfgd5lsx2pwgwwi955adl6sk-glibc-2.31/lib/ld-linux-x86-64.so.2
zupo has quit [Ping timeout: 260 seconds]
<Ke>
at this stage maybe look at kernel logs for some dead giveaways
<Ke>
like stack traces and such
<Ke>
io errors
<patagonicus>
Ke: I'm guessing something went wrong with cross-building it. After I did a nixos-rebuild switch with a nixpkgs snapshot I had manually downloaded it worked fine.
<sphalerite>
angerman: yeah I'm using that, just wondering if you've had a look at how much effort it would be to get a nixos kernel running on it
<sphalerite>
Ke: still waiting for it to ship
<angerman>
sphalerite: you could start dropping patches for other boards.
<angerman>
sphalerite: I tried to get the stock kernel working and eventually gave up.
<angerman>
I was adding the patches from Armbian bit by bit, and then just decided to go all in. Time was just too short :/
<sphalerite>
Ke: though red[evilred] was told that theirs would ship at the end of December, and we ordered around the same time, so I'm guessing mine will too
<sphalerite>
angerman: fair enough
<angerman>
sphalerite: bisecting the kernel confit was also something toot time consuming.
<angerman>
sphalerite: if you have a quick way that doesn’t take 1h round trips it might be feasible.
<sphalerite>
the thunderx I used for the thunderx debugging was able to build a nixos kernel in ~15min so that's already a fair bit faster, but still not really ideal…
<sphalerite>
I suppose starting from a localyesconfig from the armbian kernel might be more fruitful
<sphalerite>
since it's just a lot less to build
<srk>
angerman: kconfig-diff from kconfig-frontends might help
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite>
srk: won't get kernels building faster.
<sphalerite>
angerman: did you use "recovery mode" at all?
zupo has joined #nixos-aarch64
<angerman>
sphalerite: that was too awkward to get working and I had the USB’s post blocked for console use already
<srk>
sphalerite: no, for that I tend to disable bunch of drivers, especially GPU stuff
<sphalerite>
huh, isn't it the same port?
<angerman>
sphalerite: yea it is
<sphalerite>
and were there any tricks for getting the console working? I'm not getting any output…
<angerman>
sphalerite: should be on 115200
<sphalerite>
yep, that's what I'm using
<sphalerite>
oh wait there's probably just no u-boot there ^^
<sphalerite>
I'm guessing the eMMC is blank from factory
<angerman>
At least with my builds. I can never get that 1500000 working with rockchips, so I keep patching it down to 115200 all the time :-/
<sphalerite>
and I haven't flashed an sd card yet because I haven't finished building the image x)
<angerman>
sphalerite: yea, it’s all blank.
<sphalerite>
the spi too?
<angerman>
sphalerite: also the build in emmc has precedence. So if you burn something broken on it, you’ll need to erase it from uboot :-)
<sphalerite>
or jumper it :D
<angerman>
Or mess with the jumpers.
<angerman>
But then it’s not visible... or I’m blind.
<angerman>
I think the jumper just outright disabled it
<sphalerite>
oh, good to know
<sphalerite>
I still don't quite get why you weren't able to use recovery mode though?
<angerman>
sphalerite: if you use my Makefile, you’ll need to put the populateRootDs back in. See the guy history for the configuration.nix. I seem to have dropped that by mistake.
<sphalerite>
is it not usable at the same time as the serial?
<angerman>
sphalerite: I think you need to jumper it and use that recovery image on an sd. I might have goofed.
<angerman>
And the build image - burn sd card - reboot - watch console, just worked.
<angerman>
sphalerite: if you make it work, do let me know.
<sphalerite>
will do. First things first, I need to wait for the image to finish building ^^
FRidh has quit [Ping timeout: 256 seconds]
<angerman>
I got jophish a working image a few hours ago.
FRidh has joined #nixos-aarch64
<angerman>
sphalerite: had I known you’d be building one as well, I had pushed the changes for the rootCmds
<angerman>
sphalerite: will definitely push in ~10hs after the kids are at school though :-/
<sphalerite>
well I reversed the hunk so all good :)
<angerman>
Let me know if you end up finding the fans loud as well. I ended up replacing them with a pair of Arctic’s I had lying around.
<sphalerite>
right now they're very quiet :p
<sphalerite>
were they just spun up too aggressively, or loud at low speeds too?
<angerman>
Spun up.
<angerman>
You hear it when it reboots.
<angerman>
Fans go full throttle during shutdown;)
<sphalerite>
oh fun
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<sphalerite>
angerman: oh and on what level were your problems with nixos's stock kernel? No boot, or peripherals not working?
ashkitten has quit [Ping timeout: 260 seconds]
ashkitten has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
<sphalerite>
I've gone and built an image for my helios64 on the community box #yolowon'tuseitasmyrealnasanyway
<sphalerite>
went a lot faster than on the nanopi m4 :D
<sphalerite>
well actually it's not _completely_ done. But the kernel finished a lot quicker.
zupo has joined #nixos-aarch64
<samueldr>
at least a good way to check that the actual build you'll use will work
<samueldr>
it's what, 2-3 hours for the pinebook pro kernel (unoptimized, the default nixos config + needed options)
<samueldr>
when buiding on an RK3399
<sphalerite>
at what clock speed? ;)
<sphalerite>
since my gru-bob has a higher clock speed than my nanopi m4
<samueldr>
whatever the ROC-PC from libre.computer shipped in their DTB, which means the default
<samueldr>
yeah, OP1 are a bit special
<samueldr>
IIRC they are higher binned
<samueldr>
in addition to having a different boot rom
<sphalerite>
aah ok
<sphalerite>
yeah just saw it's overwritten in rk3399-op1-opp.dtsi
<sphalerite>
can non-OP1 rk3399s just be overclocked by adding OPPs or does it depend on boot rom / hardware / other?
<samueldr>
IIRC it can all be done through the device tree
<samueldr>
but IIRC it's also dangerous
<samueldr>
there are "known safe" values but going higher could be harmful
<samueldr>
it's something I need to investigate still
<samueldr>
the ROC-PC has enough thermal headroom with its ginormous heatsink
<samueldr>
and I'd like to know how to do it so I can add a downclocking configuration example for the pinebook pro
<samueldr>
as fully clocked it might not be able to rebuild itself
<sphalerite>
yeah, that's the thing — I have lots of cooling capacity in my devices, so I'm fairly comfortable overclocking as far as the thermals are concerned
<samueldr>
but yeah, you need to be aware that you can give too much voltage
<sphalerite>
well you can limit the level by writing to /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
<samueldr>
now, why the heck isn't CONFIG_KEXEC available in my phone's kernel config??
<sphalerite>
or is that not what you mean?
<samueldr>
sphalerite: that's up to the max configured in the device tree
<samueldr>
but you can change the max voltage given in the device tree (IIRC)
<samueldr>
and you can give it too much
<samueldr>
and bzzt
<sphalerite>
yeah but I mean for the downclocking
<samueldr>
ah
<samueldr>
that's probably another option
<sphalerite>
that way you don't have to mess with the device tree and can set/remove the limit at runtime
<samueldr>
just need something to test and check at some point in the future, which given the current state of things, is far
<sphalerite>
of course that doesn't help if it's clocked too high to boot stably :D
Darkmatter66 has quit [Ping timeout: 240 seconds]
<sphalerite>
angerman: hm, I've got an SD card with the necessary image now, and it's clearly doing more (it spins up the HDDs), but I'm still getting nothing on the serial…
<sphalerite>
if the jumper were set wrong, the FTDI wouldn't show up on the USB connection, right?
Darkmatter66 has joined #nixos-aarch64
<samueldr>
sphalerite: their wiki has good schematics IIRC
<samueldr>
like, updated in the last few weeks
<samueldr>
and are you using the right baudrate?
<samueldr>
I think angerman changed the defaults?
<sphalerite>
samueldr: yeah, it does, but I'm not 100% sure of my interpretation that the serial should only show up to the host if the jumper is set appropriately
<samueldr>
probably can't tell either
<samueldr>
but try setting it on the other setting
<sphalerite>
samueldr: and yeah I've tried both angerman's baud rate and the rockchip standard. Even if it were wrong, I'd expect junk. But I get nothing at all.
<samueldr>
I never got junk for wrong baud rate
<samueldr>
in my personal experience :)
<sphalerite>
really? huh
<samueldr>
at least, those two
<samueldr>
probably the timing is way out of whack that it doesn't match anything
<sphalerite>
aaaaaaaaaaaaah
<sphalerite>
115200 works. I was using 1152000
<samueldr>
see?? :)
<samueldr>
I would only _expect_ junk for wrong parity bits and similar settings
<samueldr>
for wrong clock rate, I don't _expect_ it
<sphalerite>
That's my first time not getting junk for the wrong baud rates
<sphalerite>
ah well
<sphalerite>
yay kernel panic
<sphalerite>
just initramfs issues though, nothing hardwarey. So that's good.
<samueldr>
that's progress
<samueldr>
I'm pleased enough with a kernel panic I can actually see
<sphalerite>
:D
<sphalerite>
same
<samueldr>
uh
<samueldr>
arm64 didn't have KEXEC support when other platforms did
<samueldr>
that's... really not great
<samueldr>
found in Linux kernels: 4.8–4.20, 5.0–5.10, 5.10+HEAD
<samueldr>
whew... that's really putting a damper on things
Darkmatter66 has quit [Ping timeout: 246 seconds]
<samueldr>
what's worse is that for arm (kernel nomenclature) it was available for a good while
<samueldr>
found in Linux kernels: 2.6.21–2.6.39, 3.0–3.19, 4.0–4.20, 5.0–5.10, 5.10+HEAD
<sphalerite>
damn
* samueldr
checks for backporting
<samueldr>
that basically means only SDM845+ or similarly fresh enough kernels will be able to do it
<samueldr>
(for vendor kernels)
<samueldr>
interestingly, the patches seem to have had a rough time
<samueldr>
and are you sure it's not being loaded?
<samueldr>
right, "what could go wrong"? using features not yet in the kernel :)
<sphalerite>
u-boot says Retrieving file: /boot/extlinux/../nixos/rm0q04isa6y8cvk0s8bdkk67n7bjnysh-initrd-linux-5.9.14-initrd and Loading Ramdisk to f55b4000, end f5ee56fd ... OK
<sphalerite>
oh, but good point! It's failing to start init, doesn't complain about failing to mount the rootfs
<samueldr>
*which* init? :)
<samueldr>
:( even the oldest kexec patch uses features not in 3.10
<sphalerite>
angerman: the kernel is failing to run the init script, with ENOEXEC.
<angerman>
Reproducibly at the same point? That’s odd.
<sphalerite>
reproducibly with completely different initramfses
<sphalerite>
the latter of which worked on the thunderx machines when I was fiddling with those
<angerman>
hmm, did you modify my image much?
<sphalerite>
nope, just using my own key really.
<angerman>
sphalerite: I’m just curious because it worked out of the box for jophish as well.
<sphalerite>
yeah… well clearly the universe doesn't like me :p
<sphalerite>
if you could make your actual image available to me somehow I'd be happy to try that
<angerman>
sphalerite: if you give me your secrets.nix, I can build one in ~2hs
<sphalerite>
I mean it could also maybe have something to do with some non-redroducibility caused by aarch64.nixos.community vs whatever you're building on
<angerman>
Need to drop the kids off at school first.
<angerman>
sphalerite: that’s the one I use.
<sphalerite>
ok in that case wtf x)
<angerman>
sphalerite: let me know if that image works