justan0theruser has quit [Ping timeout: 260 seconds]
justanotheruser has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 252 seconds]
ryantrinkle has joined #nixos-aarch64
orivej has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
dev_mohe has quit [Ping timeout: 250 seconds]
<ar>
that's a weird definition of success, but if you like it, sure
<Ke>
man true
<ar>
hexa-: >release year 2023
<Ke>
so what about rk3588
<Ke>
they were supposed to buy cheap extra fab, but none available
<Ke>
and can't run on 28nm
<Ke>
?
orivej has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Ping timeout: 258 seconds]
lopsided98 has joined #nixos-aarch64
srk has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo has joined #nixos-aarch64
<anton[m]>
samueldr: your PR101454 branch looks cool. Do you think it is possible to add an ubootOdroidHC1 "alias" to ubootOdroidC4? I'm not that familiar with nix syntax and not sure it is even possible to make a real alias, without defining new derivation based on other... I built the C2 and C4 images, will test them later this week and leave these working for a longer time.
cole-h has quit [Ping timeout: 252 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
h0m1 has quit [Quit: WeeChat 3.1]
h0m1 has joined #nixos-aarch64
heywoodlh has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 3.1]
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
orivej has joined #nixos-aarch64
justanotheruser has quit [Quit: WeeChat 2.9]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
noonien has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
<evils>
anyone know if mobile nixos is usable as one's only phone?
noonien has quit [Ping timeout: 240 seconds]
noonien has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<davidak[m]>
evils: the short answer is: no
<davidak[m]>
a longer answer: it depends...
<davidak[m]>
maybe come back in some months and follow the updates in the blog
<simpson>
A longer answer: Don't experiment with your only phone.
<gchristensen>
canit make phone calls?
nicoo has quit [Ping timeout: 240 seconds]
* evils
considers refurbishing 2 xiaomi A1's putting lineageos and nixos on them
nicoo has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Error from remote client"]
<LinuxHackerman>
evils: do you already have them lying around? Cause I have two A1s with broken screens… :p
<LinuxHackerman>
I'm also not sure if anyone other than me has ever experimented with mobile-nixos on them, and basic stuff like wifi isn't working yet
<evils>
LinuxHackerman: you're not in ghent belgium are you?
<LinuxHackerman>
evils: no
<evils>
there's a pair of them with broken screens available here xD
<evils>
LinuxHackerman: thanks for the info though, "currently no wifi" is a fair reason to just repair my current phone and wait to see what happens with mobile nixos
cole-h has joined #nixos-aarch64
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
<Ke>
well theoretically you can use networkmanager, if you have the drivers
<Ke>
but I think the bottom line is that the out of the box experience is missing
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<samueldr>
that's...
<samueldr>
that's obviously why there is no wifi, not because there is no frontend to configure it
<samueldr>
and yes, it's still all work-in-progress
<LinuxHackerman>
Emil Karlson: it's not a networkmanager problem in the case of the A1, it's the driver not being set up correctly
<LinuxHackerman>
Well maybe samueldr has fixed it and I haven't kept on the ball, but I don't think it's ever been tested
<samueldr>
LinuxHackerman: pretty sure it's wcnss daemon or qcacld-2.0, both are well understood enough for usage in Mobile NixOS now :)
<samueldr>
but still far from daily driver usage
<LinuxHackerman>
yep wcnss sounds right, that's good to hear! iirc there was an issue of missing firmware still though
<samueldr>
oh, right
<samueldr>
"just" get the firmware
<LinuxHackerman>
but if that's well-understood I guess that's a minor obstacle
<samueldr>
haha!
<samueldr>
yeah, wcnss (and qcacld-2.0) just need the firmware to be in a loadable path, and a specific device node to be poked
<samueldr>
the latter is done through the quirks
<samueldr>
getting the firmware is the hard part
<samueldr>
ideally it'd be taken from a factory image from the OEM
<samueldr>
(please save the zip on archive.org and link to it!)
<samueldr>
(too!)
<samueldr>
on one of my devices with qcacld-2.0, it takes about a full minute before wifi works... don't know why, but the other it just works
<samueldr>
anton[m]: if there is absolutely no differences, there is no benefit into providing an alias, instead documentation [where?] should state it uses the OdroidC4 build
<anton[m]>
samueldr: works for me :)
<samueldr>
btw, if with my changes there are issues, it really should be specific to the firmware blobs only
<Ke>
oh right, missed that we were talking about one specific device
<samueldr>
as before changing to the blobs, the builds were identical enough
<samueldr>
uh, before changing which blobs were used*
<Ke>
the original question was quite generic
<samueldr>
yeah
justan0theruser has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 250 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
mi.com is official
<samueldr>
and yeah
<samueldr>
the main thing to know is that the phone wouldn't boot an wrongly signed image
<samueldr>
if the bootloader is locked
<sphalerite>
hm, so I've downloaded one of these zips and it contains a payload.bin and I extracted that using some dodgy python script
<sphalerite>
but… I'm not sure which of the resulting files might contain the firmware. There's no vendor.img.
<sphalerite>
ah but there is a vendor directory in system.img :)
<samueldr>
it can be modem.img
<samueldr>
or non-hlos
<sphalerite>
hmmm modem.img is weird. `file` recognises it as an MBR partition table, but fdisk -l outputs some "interesting" partition information on it
<sphalerite>
I have found WCNSS_cfg.dat and WCNSS_qcom_cfg.ini, I'm guessing wlan_mac.bin is important too though
<samueldr>
probably won't apply outright, but trivial enough to apply manually against a kernel
<samueldr>
I use such a patched kernel when looking for firmware files
<samueldr>
since too often it happens that vendor kernels silently fail
<sphalerite>
nice, thanks
<sphalerite>
oh wow.
<sphalerite>
wlan_mac.bin is literally just the MAC address…
<sphalerite>
wait not quite.
<sphalerite>
But it's only 24 bytes.
rajivr has quit [Quit: Connection closed for inactivity]
<sphalerite>
hah. It's multiple mac addresses.
<sphalerite>
well, I'll give it a try $soon
<sphalerite>
for now, I'm updating my pinephone :)
<sphalerite>
would the right way to update stage1 be to build build.boot-partition and just write that over /dev/disk/by-label/mobile-nixos-boot?
<sphalerite>
(well, what I really want to update is the kernel)
<sphalerite>
(but also stage1 I guess since that's pretty old)
<samueldr>
sphalerite: wlan_mac.bin may be a mask that is used with things like predictable mac address generation from CPU serial and such
<samueldr>
and yes, overwriting the partition is one of the methods I expect to support
<sphalerite>
Is that what I should use currently?
<samueldr>
I left a lot of room to allow a "safer" alternative method, but I'm not sure it's worth it
<samueldr>
yes
<samueldr>
the "safer" alternative will only update boot.img from the boot partition
<samueldr>
(or maybe it uses another name?)
<samueldr>
leaving recovery.img for a not-implemented "hold volume down for alternate boot image"
<samueldr>
but since there's no automated way to update stage-1 yet, there's no need to
<samueldr>
(yet)
<sphalerite>
ah but that's for android devices, right?
<sphalerite>
or is that a thing on the pinephone as well?
<samueldr>
I was thinking about the pinephone here
<samueldr>
I assume the user will be in a situation where they can rescue their pinephone with an SD card
<samueldr>
for the moment
<sphalerite>
right
<sphalerite>
makes sense
<sphalerite>
also, I don't think this is actually ~supported~, but I'm running on a btrfs root on my pinephone :D
<samueldr>
btw, if you update stage-1 for pinephone, it will now be stage-0, and will use the kernel+initrd from the generation
<sphalerite>
sweet
<samueldr>
no worries, "supported" is not a word yet for any setup
<sphalerite>
using kexec?
<samueldr>
yes
<sphalerite>
fair enough
<samueldr>
but I don't want to be too opinionated for the chosen filesystem
<samueldr>
I'm thinking more and more, as the task approaches, about the actual initial setup
<sphalerite>
is the March round-up still in the works?
<samueldr>
will be part of april's
<sphalerite>
ah ok
<samueldr>
not enough completed work
<samueldr>
and among the steps, you should be free to choose the filesystem your rootfs lives on
<samueldr>
because, anyway, LUKS kind of needs it already
<samueldr>
I'm thinking the setup will use a tethered approach using rndis
<sphalerite>
makes sense
<sphalerite>
hm, why that? To avoid having to implement all the UI bits and pieces for configuring it on-device?
<sphalerite>
I imagined setup being "write your nixos config, build an image from it, install that using adb or by writing it to an SD card"
<sphalerite>
oh no, kernel hang :(
<samueldr>
sphalerite: "writing it on an sd card" won't help on android-based devices
<sphalerite>
hence using adb :D
<samueldr>
and "building an image from it" will be hard with LVM to join partitions
<samueldr>
can't just "fastboot flash" it
<sphalerite>
aah I see
<samueldr>
it could be adb
<samueldr>
but adb *as it stands* has issues still
<samueldr>
while rndis+openssh is just networking
<sphalerite>
so you use fastboot to boot an installer system analogous to desktop nixos, and then do the setup from there by sshing in via rndis?
<samueldr>
kind of
<samueldr>
I'm thinking about the possibility of having a "tool" that does the steps for you
<samueldr>
but through rndis+ssh
<samueldr>
or maybe at least an automated enough "happy path" installation
<sphalerite>
we could use that for desktop nixos too :p I recently discovered the alpine installer, and thought nixos could do with something similar (and that that could be done with a reasonably small amount of effort)
<gchristensen>
speaking of which it'd be rockin' if nixos-generate-config detected you were on wifi and turned on wireless support lol
<samueldr>
sphalerite: links to the alpine installer?
<sphalerite>
now I want a car so I can do that but with nixos
<samueldr>
I was looking through image search
<sphalerite>
hahaha
<samueldr>
yeah, something like that is an option
<samueldr>
and probably a good starting point
<samueldr>
I had the bad idea of using the "simulator" for the GUI framework I'm using in stage-0/1 on desktop to have a GUI
<samueldr>
though that's probably a bad idea because keyboard input probably is wrong
<samueldr>
rndis+ssh, assuming the proper bits are fiddled with to share the host's internet connection, is probably going to be more reliable than wifi, too
<sphalerite>
sharing the host's internet connection is likely to be a lot of fiddling though…
<samueldr>
I'm bad at networking
<samueldr>
so I don't know what can and cannot really be done
<sphalerite>
It would almost certainly require configuring stuff on the host
<samueldr>
yeah
<samueldr>
that I assumed
<sphalerite>
I think using wifi as the default option would be a lot friendlier
<samueldr>
the wifi on the pinephone is way too terrible for that
<samueldr>
at least where I'm at
<sphalerite>
oh?
<samueldr>
too much interference
<samueldr>
though maybe we can do it in a "simple" and "involved" method
<sphalerite>
kernel_comp_addr_r or kernel_comp_size is not provided!
<samueldr>
your setup is from before I switched to GPT
<sphalerite>
huh
<samueldr>
hm, too bad there's no SLA :(
<sphalerite>
SLA?
<samueldr>
service level agreement
<sphalerite>
oh right you do mean that.
<sphalerite>
hehe
<samueldr>
no backwards compat intended for now :)
<samueldr>
though I try not to break things
<sphalerite>
also, I think the script would be a lot more readable if you used $ramdisk_addr_r style, since you wouldn't have to escape those in the nix strings?
<sphalerite>
is there a particular reason to prefer the ${} style?
<samueldr>
maybe
<samueldr>
I don't remember
<samueldr>
but hush is weird
<samueldr>
hush is the U-Boot shell
<samueldr>
I wasn't too confident in what I was doing with that script at first
<sphalerite>
eeeeeeh I guess I'll grab my SD card…
<sphalerite>
*dramatic sigh*
<samueldr>
if you *only* flash u-boot to it it probably will boot
<samueldr>
if it does, you can flash u-boot the same way on the internal mmc
<samueldr>
alternatively, build the target disk mode image, and work on the eMMC as if it was a usb drive
<sphalerite>
that sounds good
<sphalerite>
maybe I can convert it to GPT while I'm at it
<samueldr>
would be a bit hard because of how it needs to be a holey gpt
<sphalerite>
nice tooling you've put together in any case :)
<sphalerite>
why that?
<samueldr>
unless you don't mind doing work to shrink your rootfs a bit
<samueldr>
because the allwinner u-boot sector is straight in the middle of the usual location for the GPT entries
<samueldr>
not sure if one is better than the other?
<sphalerite>
I think mine is easier to remember, but they end up having the same effect
<samueldr>
auto-detection for cross-compilation is, for now, not intended to go away... but at the same time I know it can be confusing or surprising
<sphalerite>
what I've seen and done quite frequently is adding a top-level system argument, like nixpkgs has
<sphalerite>
so I can pass --argstr system aarch64-linux
<samueldr>
hmm
<sphalerite>
not sure that would work without duplicating the code across all of examples/*/default.nix, but it should work for the top-level default.nix I think
zupo has joined #nixos-aarch64
<samueldr>
if it's an argument to eval-with-configuration.nix I guess it can work
<sphalerite>
will that play along with nix's awkward handling of --arg[str]?
<samueldr>
not sure
<sphalerite>
because iirc it will only fill in explicitly named arguments of the top-level function with that
<sphalerite>
i.e. it won't land in @args
<samueldr>
right
<samueldr>
but I can probably remove that unneeded "top level" function and directly import
<samueldr>
you were on an install from before november I suppose
<sphalerite>
yep, August
<sphalerite>
hm, "2 tasks are waiting on 3 unique dependencies"
<samueldr>
after a minute it'll tell you which
<samueldr>
>> Speaking of hung tasks. Our init now detects when no tasks resolved in a given amount of time. When this happens, the boot is being failed with, hopefully enough context in the error message to help the user.
<sphalerite>
any network interface and /lib/modules…
<sphalerite>
This is using the target disk example system
<sphalerite>
and Dependencies::Target(Environment)
<samueldr>
hmm
<samueldr>
lib/modules and network interfaces are "soft" in that they shouldn't cause the boot to be aborted
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
<sphalerite>
so uh… how do I proceed?
<samueldr>
you rebooted and it still does that?
<sphalerite>
yeah
<samueldr>
any logs?
<samueldr>
it's odd, since I rely on target disk mode generally to do... many things
<samueldr>
like, that's what I used to setup the new pinephone
<sphalerite>
huh, and the power off button didn't work
<sphalerite>
hm, I'll try blkdiscarding the sd card and writing the image again
<sphalerite>
who knows what might have gone wrong there
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
could be a lot!
<samueldr>
you did a native build, though, right?
<samueldr>
I don't expect it to change anything, but I'm pretty sure I only did cross builds
<sphalerite>
yeah native build
<sphalerite>
hrm, same again
<sphalerite>
I guess I'll try a cross build
<samueldr>
what may make a bigger difference, is the Nixpkgs revision used... but even then if it does it's... unexpected
<sphalerite>
I'm using the nixpkgs used by the latest hydra evaluation where firefox built on aarch64-linux :>
<sphalerite>
which is to say 800a3dd90970a277e3f6853633bd7faf04d6691e from 2021-03-18
<sphalerite>
so it's not the freshest
* samueldr
tries a cross-compilation from there
* sphalerite
is waiting for his as well
<samueldr>
that was quick to fail
<samueldr>
OSError: [Errno 8] Exec format error: '/build/source/tools/xml_helper.py'
<sphalerite>
alright, I'll give that a try. Another day
<sphalerite>
riddle: why does touching the "Power off" button not work, but selecting it with the keys does, but touching "Reboot to system" works just fine?
<sphalerite>
The touch "puck" appears in both cases
<samueldr>
because the text layer is probably misplaced
<samueldr>
known (by me) bug
<sphalerite>
aah ok
<sphalerite>
right, but for now I'm off to bed. Good night, and thanks for the help!
<samueldr>
I actually need to investigate and see actually why, but that's my assumption
<samueldr>
thanks for your patronage!
<sphalerite>
hm, hm, patronage
<sphalerite>
*clicky clicky button*
<sphalerite>
gnight!
<samueldr>
was thinking "the regular business given to a store, restaurant, or public service by a person or group." mainly
<samueldr>
'night!
<samueldr>
but it's appreciated!
<samueldr>
Nixpkgs-built U-Boot for a new board [family] soon
<samueldr>
Nixpkgs U-Boot adjacent people with opinions