<clever>
elvishjerricco: what is the contents of the status file in there?
<elvishjerricco>
clever: disabled
<calebccff>
samueldr: well, it's an Android device unfortunately. There's some unofficial edk2 builds floating about but nothing really useful. My device is the OnePlus 6
<calebccff>
SDM845
<calebccff>
It runs Mainline
<samueldr>
ah! you should have said it was about mobile nixos :)
<clever>
elvishjerricco: is otg_mode present in configl.txt?
<samueldr>
different beast than porting to an SBC :)
<elvishjerricco>
clever: nope
<samueldr>
I'm sorry, there's not a guide *yet*
<elvishjerricco>
Nor is it in the ubuntu image's config.txt
<clever>
elvishjerricco: then something is wrong with overlays, does /boot/overlays/dwc2.dtb exist?
<elvishjerricco>
clever: there is no /boot/overlays directory. Guess that seems important :P
<clever>
elvishjerricco: is the fat32 mounted to /boot ?
<elvishjerricco>
Yea
<samueldr>
and I don't know (yet) about the better way to support mainline kernel based phones, there are some minor differences which would be important
<clever>
elvishjerricco: then you need to fill in the mising overlays dir, its requiredfor dtoverlay= to work
<calebccff>
samueldr: oh lol my mistake, shame there's no guide yet, I've previously ported Manjaro ARM where I basically just built a standard aarch64 image and used a custom initramfs. Could I apply something similar here?
<elvishjerricco>
clever: Got it, that makes sense
<elvishjerricco>
clever++
<{^_^}>
clever's karma got increased to 0o1073
<samueldr>
calebccff: for *NixOS*, probably, though custom initramfs needs to be aware of NixOS semantics... which is what Mobile NixOS basically does... a custom initramfs that knows about NixOS semantics (and extra nice things)
<elvishjerricco>
clever: Actually, I have no idea how to do that :P
<samueldr>
calebccff: there is the autoport scripts that will help get a phone started, assuming the vendor kernels are used https://github.com/mobile-nixos/autoport
<samueldr>
(as I haven't had any android-based devices with a mainline port on my hands to see what matters and what doesn't)
<calebccff>
samueldr: well that doesn't sound too bad, is autoport meant for devices using Halium?
<samueldr>
nope, peeks through vendor roms to see what's needed :)
<clever>
elvishjerricco: git clone that repo, copy the overlays dir
<calebccff>
It's basically the same as an SBC except with a locked bootloader and a partition map that should not be touched :>
<samueldr>
note that we aren't interfacing with android userland drivers yet, so "halium" and "halium-like" isn't _yet_ a thing
<calebccff>
Oh that sounds interesting ??
<elvishjerricco>
clever: Well yea, but I mean in the framework of nixos.
<samueldr>
(but later this year I have a task to finally look at userland drivers for using vendor kernel trees)
<calebccff>
you're aiming to not even have to recompile the kernel?
<calebccff>
that's quite a feat
<elvishjerricco>
Like if this were the sd image I guess I'd put some commands in populateFirmwareCommands
<samueldr>
nope, recompile the kernel, but using the vendor kernel trees
<samueldr>
so that you don't _need_ a mainline effort to get started
<clever>
elvishjerricco: this shell script is responsible for updating /boot on every switch
<samueldr>
ideally all phones will end up mainlined... but that's not a reality (yet?) :)
<elvishjerricco>
Ah, that would be the place then :)
<calebccff>
samueldr: right, I was glancing through some of the code ^.^
<calebccff>
yeah mainline isn't feasible for many devices, although we're slowly making it a reality for SDM845 at least
<calebccff>
Slowly msm8998 and sm8150 are catching up too :D
<samueldr>
calebccff: yep, lowering the barrier of entry so that it becomes more "normal" to run non-android linux on android-based devices, first
<calebccff>
I'll take a look at the aarch64 guide and the mobile stuff and see, hopefully it'll be doable with the existing nixos-mobile stuff, just with a mainline kernel instead
<calebccff>
Do downstream devices make it to UI yet?
<samueldr>
unaccelerated, yes, definitely
<samueldr>
all of the devices on the devices page have booted to the X11-based example system
<samueldr>
older devices even have wifi working
<samueldr>
for newer devices, it may or may not require userland drivers for wifi, to be looked at later :)
<samueldr>
(yours is a newer device)
<samueldr>
still, all with vendor kernels
<calebccff>
yeah, there's no chance of getting wifi without halium on sdm845
<calebccff>
that's pretty nice
<samueldr>
I'm not sure... there may be a way, from what I've seen
<calebccff>
It's good to have the option - although if mainlining is an option it's way way better in the long run
<samueldr>
but that's still superficial research
<samueldr>
yes!
<samueldr>
for a mainline-possible device, I'd like to see both mainline and vendor based ports, initially
<calebccff>
that would be impressive, given how much of the remoteproc stuff seems to be in userspace on Android
<samueldr>
yeah, I'm going from superficial knowledge, from reading a thread about vendor-based kernel for a specific device
<samueldr>
I'm not sure what I understood is right
<calebccff>
What do you think is possible without halium on qualcomm?
<samueldr>
but *anyway* userland drivers will end up required most likely
<calebccff>
yeah
<samueldr>
ah, wifi
<samueldr>
specifically ib qcacld-3.0
<samueldr>
with*
<samueldr>
(why did I write ib? no one knows)
<calebccff>
re: mainline AND vendor based, unless you're going with halium, it's a lot of work spent REing blobs that will never get security patches, that could be spent improving support on Mainline
<samueldr>
sure
<samueldr>
AFAIUI halium is a userland component, mainly, which is what is likely going to be used
<samueldr>
but not the halium kernel *builds*
<samueldr>
it's not been time yet to actually look and grok all of it, but AFAIUI Halium is an LXC based container to run the userland services, no?
<samueldr>
(with opinions about the kernel build and provenance)
<calebccff>
afaik halium basically runs Android system in the background, and then runs a glibc Linux system on top via libhybris
<samueldr>
yep
<calebccff>
SailfishOS doesn't use LXC for halium I don't think, ubuntu touch does though
<samueldr>
so it'll most likely end up using halium, or halium-like semantics
<calebccff>
Do you know what mobile DEs are supported?
vikanezrimaya has joined #nixos-aarch64
<samueldr>
depending on what my research says later down the line
<samueldr>
"supported" in? :)
<calebccff>
nixOS
<samueldr>
right now: none
<samueldr>
but there's work with phosh in an open PR
<calebccff>
OK cool
<samueldr>
and I have to finish testing and open a PR for plasma-mobile
<samueldr>
note that this happens in upstream Nixpkgs, and not Mobile NixOS
<calebccff>
What devices do you guys use? PinePhone?
<samueldr>
I don't think there's much "actual" users still
<calebccff>
well, in terms of testing at least :>
<samueldr>
but many of those putting some of their time off towards Mobile NixOS are using a Pinephone
<calebccff>
That makes sense
<samueldr>
most of the ports are devices I own and test on and with
<samueldr>
I'm working basically full time on Mobile NixOS for the time being
<calebccff>
Oh awesome :D
<calebccff>
I'm yet to actually use nixos to be perfectly honest, I quite like the concepts behind it but haven't booted it up yet
<calebccff>
Do you need a nixOS system to build it?
<samueldr>
you need Nix on Linux
<samueldr>
or well, Nix with a Linux builder
<calebccff>
oh yeah, your package manager runs basically everywhere right?
<samueldr>
basically
<calebccff>
How is cross-compiling?
<samueldr>
but to better "get" Mobile NixOS it really helps to "get" NixOS since it's a superset :)
<calebccff>
yeah that makes sense
<samueldr>
cross-compiling the system (what we call stage-2) is pretty bad
<samueldr>
stage-2 is "after switch_root happens"
<samueldr>
stage-1 is "initramfs"
<calebccff>
damn! it's the issue everyone seems to have
<samueldr>
yeah, cross-compiling is hard! and many projects are just bad at making it work!
<calebccff>
Manjaro ARM does everything inside QEMU and it's NOT. FUN
<samueldr>
with Mobile NixOS stage-1 is entirely meant to stay compatible with both native builds and cross-compiling
<calebccff>
I'm not sure exactly what the postmarketOS guys do, qemu user I think, seems to be the best approach os far anyway
<samueldr>
because as I've found out, the same stage-2 image (rootfs) works on all devices for now :)
<samueldr>
I think postmarketOS is all cross-compiling
<calebccff>
I guess when cross-compiling packages, you need to make depends, which must also be cross compiled, etc
<calebccff>
yeah it is
<samueldr>
but they already are going hard-mode with their alpine base
<samueldr>
so I think it gives them a leg up for cross-compiling
<calebccff>
hahaha, they are INSANE to be fair, I'm a really big fan of how they do things
<samueldr>
speaking of QEMU, qemu-user can be used to do native-build-with-extra-steps with Nix
<calebccff>
has made porting this far such a dream, in comparison to wrestling with buildroot or something more annoying
<calebccff>
Ok that's cool
<samueldr>
personally I prefer delegating to a real aarch64 machine since *sometimes* it doesn't quite right
<calebccff>
I think I'll slap nixOS on my laptop and go from there
<calebccff>
Ah, to have a real aarch64 machine u.u
<samueldr>
I'm really biased, but I strongly recommend using NixOS on everything ;)
<samueldr>
"real" is an RK3399 SBC
<samueldr>
and generally I end up relying mainly on built artifacts from NixOS
<samueldr>
only building the "leaf" packages
<calebccff>
my current understanding is nixOS keeps your whole machine state in an easily transportable form, so I can say, keep two computers in sync package-wise?
<samueldr>
and, biased still, I would assume the quality of life imrovements you've seen in postmarketOS compared to buildroot, you'll see the same in Mobile NixOS compared to postmarketOS :)
<vikanezrimaya>
Yes, sharing configuration snippets, including packages, is possible with NixOS
<calebccff>
yknow, when I first mainlined the Pixel 2 a few months ago and was lovely and naive, I put the damn thing on ice so that pstore ramoops would work after a col reboot
<samueldr>
haha!
<samueldr>
get yourself a couple of the boards linked in my comment
<samueldr>
get yourself *SHORT* uart cables
<samueldr>
(or maybe twist them?)
<calebccff>
ah yeah
<samueldr>
and it'll work
<samueldr>
for me it was important to get short UART cables, otherwise serial wouldn't work
<calebccff>
good find with those boards
<calebccff>
interesting, any ideas why?
<samueldr>
signal loss I assume
<calebccff>
hmm
<samueldr>
haven't investigated
<calebccff>
So, you have walleye? It's only 1080p right?
<calebccff>
It doesn't use display stream compression probably, you should be able to write a display panel driver and get mainline booting with display up in that case
<calebccff>
it's only 1080p
<samueldr>
which I think I thelepathically guessed what you wanted to get at
<calebccff>
surely it doesn't need dsc?
<samueldr>
I don't *know*
<calebccff>
I think kernel logs will tell you
<samueldr>
but I think I've seen it stated somewhere about "Pixel 2"
<samueldr>
clever: with android-based devices it's "something else" that is called dtbo, it's more about the concept of the partition
<clever>
ahh
<calebccff>
all my other devices, just erase dtbo and good to go, the pixel 2 just hangs on bootloader if you do that
<calebccff>
sorry, yeah DTO and dtbo slightly different
<calebccff>
not a fan of Android specifics tbh
<samueldr>
pretty sure walleye can have its dtbo partition erased
<samueldr>
though they're from two different ODM designs, no?
* samueldr
verifies
<calebccff>
damn, what's so special about taimen?
<calebccff>
oooohhhh that could be it yeah
<samueldr>
yeah, HTC and LG
<calebccff>
taimen is LG
<calebccff>
I see
<samueldr>
though I am not *sure* about it
<samueldr>
it's been a good while since I spent time looking at this
<samueldr>
and in all cases the dtbo partition still apply correctly
<samueldr>
because I haven't been using a different enough kernel yet
<calebccff>
Thanks for pointing me to that android dumps thing, shame gitlab can't really handle it lol
<samueldr>
it can
<samueldr>
I don't know what is going on with their instance
<calebccff>
huh, weird
<samueldr>
it worked properly a few weeks back when they moved there
<samueldr>
and it had been working fine for a couple of months on "git.rip" before git.rip got FBI'd
<samueldr>
(not related to android dumps)
<calebccff>
oh yeah rip git.rip
<samueldr>
though, just to close the topic of suzy-q: it will work to communicate with the Titan chip on pixel3 and + devices
<samueldr>
which is not what's needed for our uses :)
<samueldr>
and (obviously) suzy-q does work properly with ChromeOS hardware
jumper149 has joined #nixos-aarch64
<alexeyan>
I want to build a nixos img for the raspi4 and not use uboot, so I need a dedicated boot partition. How can I specify the size of that partition?
<samueldr>
sorry, you'll have to piece it together from there, but that's what sets its size IIRC
<clever>
it should be a normal nixos option
<clever>
and nixos/release.nix accepts a --arg configuration
apache8080 has joined #nixos-aarch64
<apache8080>
samueldr: for uboot have you ever had to run mkimage on the generated initrd from nixos to create a initrd with uboot headers?
<samueldr>
nope
<samueldr>
but "for uboot" is a bit vague
<samueldr>
because U-Boot has about a bajillion ways to boot things
<samueldr>
and there's a further billion vendor forks of U-Boot with different default semantics
<samueldr>
mainline U-Boot or a vendor fork?
<samueldr>
using which boot strategy?
<apache8080>
yeah lol, I am setting up nixos on a Analog devices board that has a Xilinx SoC
srk has quit [Ping timeout: 246 seconds]
<apache8080>
and it can boot the nix kernel but then panics since it can't find init
<apache8080>
I tried then using the version of booti in u-boot that takes the initrd address but then u-boot complains about the initrd image format being wrong
<samueldr>
I haven't had any experience with most boot strategies
<apache8080>
ok no problem
<samueldr>
only two I have experience with is exlinux.conf based boot, and uefi, both through "generic distro bootcmd"
<apache8080>
ok
<alexeyan>
I think I can't use uboot because I want to use the hyperpixel 4 display and that depends on dtbs which don't seem to play nice with uboot.
<alexeyan>
How can I set the firmwareSize option? My current command is nix-build '<nixpkgs/nixos>' -A config.system.build.sdImage -I nixos-config=/etc/nixos/configuration.nix
<alexeyan>
Just appending --arg firmwareSize 256 for example?
<samueldr>
alexeyan: yeah, using "ecosystem hardware" right now is a bother when going with u-boot, you're right
<clever>
alexeyan: add it to your configuration.nix
<alexeyan>
clever: under which option? like this: nixpkgs.nixos.modules.installer.sd-card.firmwareSize = 256 ?;
<clever>
alexeyan: sdImage.firmwareSize
srk has joined #nixos-aarch64
srk has quit [Ping timeout: 268 seconds]
apache8080 has quit [Ping timeout: 252 seconds]
apache8080 has joined #nixos-aarch64
<alexeyan>
So I'm somewhat confused. The nixos wiki says the standard raspi4 image is not using uboot, but the Raspberry Pi Bootloader. The I boot that image I see that a FIRMWARE partition exists, but isn't mounted or flagged as bootable. The root partition has a /boot folder however. Why is the firmware parititon there? Is the uboot loader actually not used? Because I had the dtb issues.
<samueldr>
alexeyan: wiki documentation didn't keep up with the changes in the Nixpkgs repo