<clever>
the initrd network, depends on the dhcp flags in nixos
<clever>
i had removed them, thinking they conflicted with networkd
<clever>
samueldr: and now systemd broke the network during a switch
<clever>
rpi> stopping the following units: systemd-networkd.service, systemd-sysctl.service
<clever>
rpi> starting the following units: systemd-networkd.service, systemd-sysctl.service
h0m1 has quit [Ping timeout: 256 seconds]
h0m1 has joined #nixos-aarch64
cidkid_ has joined #nixos-aarch64
cidkid has quit [Quit: Quit]
cidkid_ has left #nixos-aarch64 [#nixos-aarch64]
cidkid_ has joined #nixos-aarch64
cidkid_ has quit [Client Quit]
cidkid has joined #nixos-aarch64
<cidkid>
samueldr: you were talking about a option to have my phone boot into fbdev to see if new init least gets me to framebuffer, how would I do that?
<samueldr>
if you `nix-build --argstr device ...`, it will, by default, load `local.nix` as an additional configuration file if it exists
<samueldr>
(though it wasn't an issue to get the URL back)
<cidkid>
ah alright
<cidkid>
good to know though
<samueldr>
I often refer back to those logs :)
<cidkid>
If i ever get audio working everything will be relatively up and going as I ordered a pi and will build rootfs with that along with passing wifi through to my phone with it
<cidkid>
lmao
wavirc22 has joined #nixos-aarch64
cidkid is now known as cidkid_
<cidkid_>
samueldr: is there a way to set scripts that run at boot time, eg. sending a command to have the led go blue if it's booting?
<samueldr>
less so since I rewrote this as a tasks-based non-script thing
<samueldr>
but that's an excellent point, it should be trivial to help debugging to do so
<samueldr>
since you're right, it's a good first debugging step to know whether stuff is booted or not
<cidkid_>
yeah, it's fine that it's not like that imo although it would be a nice feature
<samueldr>
at one point I was vibrator-debugging a device
<cidkid_>
only reason I ask is since currently the sad phone screen doesn't show on new init, and it would be words of help to have a led knowing at least stage-1 is booted
<samueldr>
you would System.run("some sh command here") in the run function
<cidkid_>
*worlds
<cidkid_>
alright
<cidkid_>
2h till rootfs is redownloaded due to my bad internet
<cidkid_>
:(
<cidkid_>
anyways that would be a perfect option for the device configs might I add
<cidkid_>
setting a debug config option and a command to run for debug would be nice
<cidkid_>
also as reference, as long as I throw a option for nix overlays in /etc/nixos/configuration.nix I should be able to use my custom nix repo on my phone yeah?
<samueldr>
I don't have a sample config yet, but yes, on-device mobile-nixos is treated like an additional configuration to import in your standard nixos configuration
<cidkid_>
alright thats good
<cidkid_>
as I'm wondering if the pulseaudio module will fix my audio issues
<cidkid_>
as the only other resource I have for fixing audio is a ubports repo for the 5 from when my phone had nougat as it's base firmware
<cidkid_>
so basically ages ago
<cidkid_>
also libhybris should work relatively the same as other distros for phones yeah?
<samueldr>
not sure, hopefully yes
<cidkid_>
that gives me a lot of hope if it actually does
<samueldr>
not really had the chance to work with the actual library loading much, only tested a bit for the xorg PR and stuff didn't seem to work...
<samueldr>
... but it could have been ser error
<samueldr>
though, with all that said, it should be possible to make it work
<samueldr>
been user error*
<cidkid_>
as wifi and audio have been implemented for another distro (sailfish)
<cidkid_>
so their maybe hope
<samueldr>
yeah, most things are more of a when and not if
<cidkid_>
yeah
<cidkid_>
we'll see if it works
<cidkid_>
as I'm in contact with the dude that maintains sailfish
<cidkid_>
and their maybe a chance I can get things working
<cidkid_>
*there
<cidkid_>
I will let you know if it does btw, as it will probably fix audio and wifi on google-walleye
<samueldr>
possibly on all "newer" vintage qualcomm platforms too
<cidkid_>
yeah
<samueldr>
it'd be nice to figure out if they have names for generation of features
<cidkid_>
do you know where libhybris mainly loads .so and firmwares from?
<samueldr>
yeah, from a quick glance it looks like it should work too
<cidkid_>
my bad
<cidkid_>
Alright, libhybris expects drivers in /system or /vendor and firmware in /lib/firmware
orivej has joined #nixos-aarch64
<cidkid_>
samueldr: does nix currently run android init in a lxc container after boot?
<cidkid_>
if I'm pinging you too often please tell me
<samueldr>
not much has been done on the system that is specific to those android-based systems
<samueldr>
pretty much the only thing has been the framebuffer thing
<cidkid_>
eh never mind
<cidkid_>
lxc container is halium only
<samueldr>
it's one of the avenues to be explored as far as making stuff work
<samueldr>
so no, not "never mind" :)
<cidkid_>
yeah
<cidkid_>
we'll see if fbterm gives me anything soon
<cidkid_>
samueldr: fbterm gives nothing aswell
<cidkid_>
:/
zupo has joined #nixos-aarch64
<cidkid_>
so oof
<cidkid_>
so idk whats wrong
FRidh2 has joined #nixos-aarch64
<cidkid_>
new init doesn't work and old init refuses to build anymore
<cidkid_>
so oof
chiefgoat has quit [Remote host closed the connection]
chiefgoat has joined #nixos-aarch64
<cidkid_>
samueldr: good news and bad news, I now know new init doesn't even boot far enough for me to send a echo 255 > /sys/class/red/brightness, bad news is I don't know why it's doing this
<cidkid_>
so something fails within stage-1
<cidkid_>
ping me when you have a idea ig
lovesegfault has quit [Ping timeout: 268 seconds]
wavirc22 has quit [Read error: Connection reset by peer]
<cidkid_>
Hmm still can't figure out whats wrong with the new init
<cidkid_>
all I know for sure is stage-1 fails somewhere
<mvnetbiz_>
What are you building on, I'm trying to get started with this?
<samueldr>
mvnetbiz_: what are you thinking about using?
<samueldr>
cidkid_: are you already comfortable with console ramoops?
<samueldr>
I might bring forward writing the ramoops debug guide
<cidkid_>
no although I think I'm pretty sure how to get them
* samueldr
thinks
<samueldr>
the biggest issue is how you need to crash the phone for it to save
<cidkid_>
mmm
<mvnetbiz_>
samueldr, just got pinephone last night
<samueldr>
99% sure this means I need to add a timeout option to the tasks resolution
<cidkid_>
I wouldn't know how to do that part
<mvnetbiz_>
Looks like ideally we want to make a real uboot builder
<samueldr>
what do you mean by real u-boot builder?
<samueldr>
(not that I disagree)
<samueldr>
is it because of my WIP note in that WIP PR?
<mvnetbiz_>
I mean right now it looks like it makes an android-like boot image and uboot boots that vs maybe something more straightforward. I haven't had much time to orient myself with this so I'm not sure if that is acurate
<samueldr>
ah, I'm building an android-like system by design, but I'm open to a more traditional boot, too
<samueldr>
after all the pinephone is "just" an A64 platform
<samueldr>
do you know if they got display init in u-boot still?
<mvnetbiz_>
I am not super experienced with uboot. I have connected to router uart and messed with booting Linux from uboot console that's about it
<mvnetbiz_>
Like an embedded arm router
<samueldr>
right, though here it's specific to the pinephone, I hoped you were up-to-date with their progress :)
<samueldr>
last time I looked no one had implemented display in u-boot, this means that there is no way to select a generation or something similar during the boot
<mvnetbiz_>
Nope! I was looking at their Linux but I don't know about uboot
<cidkid_>
all I know for sure at this point is, it gets past booting into the image but stage-1 doesn't get far enough to echo a value to the led controllers to get a color
<samueldr>
this is why I was falling back to making it an android-like boot, so I would rely on the same exact thing I'm going to rely for other devices
<mvnetbiz_>
How is this different than NixOS raspberry pi image builder? Is it mainly supposed to be more lightweight?
<samueldr>
not really, the main difference is how the kernel and stage-1 is handled, from stage-2 onwards mobile-nixos is just nixos
<samueldr>
(but sometimes with software added from mobile-nixos' overlay)
<samueldr>
here it's really more about harmonizing the boot process of the different devices
<mvnetbiz_>
Ok.
<samueldr>
though I'm not against another boot process, but it has to give the user the ability to select a boot option
<samueldr>
which normal u-boot, unless they fixed it in the last ~2 months, doesn't still
<mvnetbiz_>
I saw one of your commits was remove stage-2, what does that mean? Or did you just refactor it and it uses NixOS' stage-2?
<samueldr>
that logic is handled in a task part of the new init
<samueldr>
so it should have been "initrd: Remove dead code from old init that loaded stage-2"
<samueldr>
oh, another nice thing of the android-like boot, but lacking bits to actually make it usable without a serial cable: it can use fastboot to flash partitions
<samueldr>
(or you can also use the full usb gadget mode, and completely rewrite the system)
<mvnetbiz_>
Does fastboot some kind of format other than just raw image?
<samueldr>
raw image
<samueldr>
it's more about the convenience of not having to remove the SD card
<samueldr>
or here, even allows you to manage the eMMC
<mvnetbiz_>
Is it easy to tell what your Android boot selection idea is from the code?
<samueldr>
not yet implemented, currently working on the final bits to make it work
<samueldr>
but basically, a GUI program that pauses stage-1
<samueldr>
this is the extremely proof-of-concept thing that I'm now re-working into an actually usable thing
<samueldr>
at this point it's now sitting in the recovery partition of the asus phone you see, and actually replaces TWRP for all my mobile-nixos needs :)
<mvnetbiz_>
Would it modify the boot priority and then reboot? Or does it just select which generation from stage1 and boot it? I'm guessing the former
<samueldr>
former, optionally with a sprinkle of kexec
<samueldr>
with kexec, it *should* be possible to fully boot another kernel
<mvnetbiz_>
Yeah I knew about that I was thinking it might be a possibility
<mvnetbiz_>
There was an Android thing called multirom, I think it used kexec
<samueldr>
yeah
<cidkid_>
dualbootpatcher also used kexec
<cidkid_>
although both of those projects are dead due to a9 and a10 changes
<samueldr>
but not relevant to our non-android systems :)
<cidkid_>
I'm going to try one thing before I try to get ramoops
<cidkid_>
I'mma see if going to the latest kernel commit for android-linux-stable for my phone works
<samueldr>
you could also look at `config.aarch64` for walleye and compare the missing options, though without experience in doing so it might not be obvious what options are missing
<samueldr>
I could take a peek and see if anything obvious is missing...
<samueldr>
... though you did import from postmarketOS so AFAIK all main required things should be there
<cidkid_>
yea I'll diff check them I guess
<cidkid_>
hmm
<cidkid_>
would it be a bad idea to use the walleyes config?
<samueldr>
"yes"
<cidkid_>
alright
<samueldr>
OEMs generally add custom options that won't be present in your kernel
<samueldr>
so it plainly will not build
<samueldr>
it also would likely be lacking some options specific to your hardware
<samueldr>
maybe the display driver, the touch driver, etc
<cidkid_>
yeah fair
<samueldr>
but, some options would probably be fine to harmonize between devices, and I'd like it at some point to identify them and make more closely related builds
<cidkid_>
oh yeah another thing that I'm pretty sure that we don't get to is bootlogd
<samueldr>
some devices have different options that, AFAICT, do not need to be different
<samueldr>
how come?
<samueldr>
oh
<mvnetbiz_>
samueldr, I'm not really sure how to test this. I have rebased with your wip branch and changed some basic stuff, but it is hard to tell which sources and stuff I should use. I have been looking through pmOS and pine64 gits a little bit only.
<samueldr>
cidkid_: could be, depending on what the failure mode is
<mvnetbiz_>
samueldr, I have a bunch of raspbery pi 3+. Are you talking about testing the images on or for building? Should I add keys on this community aarc64 server?
<samueldr>
mvnetbiz_: Allwinner A64, the SoC in the pinephone, so, not raspberry pis :)
<mvnetbiz_>
Oh, then no
<samueldr>
mvnetbiz_: simply because they share the same boot chain, it could have allowed you to tinker in another way
<samueldr>
mvnetbiz_: the pinephone boot chain is basically the normal Allwinner A64 bootchain
<samueldr>
do you have the serial cable?
<cidkid_>
ooh boy going through kernel configs will take ages
<samueldr>
cidkid_: using `meld` or `vimdiff` could help :)
<samueldr>
mvnetbiz_: if you don't have the cable, it's going to be harder to gather more knowledge of the early boot process here
<mvnetbiz_>
I don't I need to dig around for a broken TRS or something, I have usb adapters I can solder it to if I find one
<samueldr>
I would highly suggets doing so, and maybe ordering it if you don't find yours quickly
<samueldr>
especially if you end up trailblazing a bit
<mvnetbiz_>
Does it also ship from china? I can probably make one faster :)
<samueldr>
I think so, and I think so
<samueldr>
the important bit was "if you don't find the things quickly" :)
<cidkid_>
hmm what kernel sections would be the most recommended to look at, as mostly the oneplus config.aarch64 has more set then the walleye config
<samueldr>
I'm not sure
<mvnetbiz_>
Found a little "aux" cord so I have 2 tries to not break it lol
<mvnetbiz_>
It's weird I see that it claims it supports usb-pd but it won't charge with any of my usb-pd chargers only from a usbA to usbC cable
<samueldr>
(I only have an early devkit)
<mvnetbiz_>
Yeah I saw :(
<samueldr>
I'm actually waiting for the "final" hardware batch
<mvnetbiz_>
you mean you don't want one like this with all the I/Os connected wrong?
<samueldr>
the what nows?
<samueldr>
I really haven't been following things
<samueldr>
what with my work, and pinebook-pro shenanigans
<mvnetbiz_>
Not fatally wrong but definitely some non-ideal things
<samueldr>
I lost a bunch of interest once I saw that the SPI flash was not going to be there on the final device :/
<mvnetbiz_>
I never heard about that, would it be for the bootloader?
<samueldr>
exactly
<samueldr>
the devkits had it accidentally commoned with the LED Flash (as in photo flash)
<samueldr>
and I think from there on it was never relied upon and it slowly faded away
<samueldr>
I *think* it's on the device, but completely inaccessible, but not sure
<samueldr>
it might have been only on the developers batch
<mvnetbiz_>
huh. how is it on other devices without spi? is it in a rom on the SOC or something
<samueldr>
you have to compare with other A64 devices, and not twith other SoCs :)
<samueldr>
it's not much of a drawback, u-boot (which acts as both a firmware and bootloader) lives on either eMMC or SD card
<samueldr>
the main thing being in SPI would have allowed is producing a universal u-boot build that lives there, allowing booting all distros in a common manner
<samueldr>
it could have been through UEFI even!
<samueldr>
but now since it needs to be on the device it boots from (eMMC or SD), it's again custom builds all around :(
<cidkid_>
I'll work on this again in probably a 2weeks to a month, thanks for the help and I'll stick around in irc just incase I star work early again but unitl then o/
<cidkid_>
*start
<mvnetbiz_>
cool!
<samueldr>
cidkid_: no worry, hopefully things will have stabilized a bit more with the new init
<samueldr>
cidkid_: you're really enthusiastic and early
<samueldr>
with a bit more time I'm sure things will work out
<cidkid_>
the only thing that I could really really see wrong with the kernel atm is it seems even if I set it to build with gcc6 it's building with gcc8
<samueldr>
why do you say so?
mDuff has joined #nixos-aarch64
<cidkid_>
build logs spam a bunch of stuff around when the kernel is building with gcc8 tagged on
<samueldr>
could it be from another job running in parallel?
<cidkid_>
maybe now I think of it
<samueldr>
since if the gcc-6 thing was broken, I wouldn't be able to run for some devices
<cidkid_>
the only thing I could see wrong is my kernel config
<cidkid_>
*kernel default.nix
<cidkid_>
although I don't see anything
<samueldr>
if your devie is not rebooting automatically, the kernel is running
<cidkid_>
so it's probably not finding the generation?
<samueldr>
it could be anything
<samueldr>
but it's a likely option
<samueldr>
it could be udev that doesn't start, making it impossible for /dev/disks/by-* links to exist
<cidkid_>
did old init not use udev?
<samueldr>
it did
<cidkid_>
as oldinit worked
<samueldr>
it worked, meaning that it booted the rootfs?
<cidkid_>
yeah
<samueldr>
hmm
<samueldr>
weird
<cidkid_>
old init booted to rootfs
<cidkid_>
thats why I'm confused
<cidkid_>
and I can't even get my repo with old init to boot anymore
<cidkid_>
so I'm pretty stuck even if I wanted to work on audio/wifi/libhybris
Thra11 has quit [Ping timeout: 240 seconds]
<cidkid_>
*old repo with old init to build
<cidkid_>
not boot
<cidkid_>
I'll flash userdata through fastboot and see if that gets me anything
<cidkid_>
if not I'll probably stop for now
<cidkid_>
I wish ssh-initrd worked for my phone as it would loads and loads of useful rn
<samueldr>
it might if you setup the gadgetfs stuff like on walleye
<samueldr>
with the new init
<cidkid_>
how would you do that?
<samueldr>
not sure though if it uses *those* configs
<samueldr>
... but maybe whatever is happening to your boot happens before gadgetfs can be handled
cidkid has quit [Remote host closed the connection]
cidkid has joined #nixos-aarch64
<cidkid>
alright yeah idk then
<cidkid>
samueldr: if you think of something let me know, and I'll try and reflash, but I'm done for right now and I'm probably unbrick tooling back to android
<mvnetbiz_>
no luck with serial idk what would be wrong
<samueldr>
cidkid: alright, will try and work on a debugging-friendly setup and guide in the future, once this is done I'll try and remember you, otherwise check-in when you feel like it :)
<samueldr>
mvnetbiz_: rx/tx swapped around?
<mvnetbiz_>
lol yep
<mvnetbiz_>
i double checked but i double checked wrong
<cidkid>
samueldr: one last question, is there a specific initrd-*.nix that deals with mounting partitions?
<samueldr>
mvnetbiz_: even double checking, sometimes the labels are "wrong" in that you want to connect TX to TX, and RX to RX and sometimes TX to RX and RX to TX, depending on the exact devices docs
<cidkid>
if I can mount a partition within there and dump logs to there at least it would be something
<samueldr>
so I just never know what to believe!
<samueldr>
cidkid: yeah, "proving" that something mounted is a way to check
<cidkid>
samueldr: would there be a reason that a echo to led control isn't working
<cidkid>
when I put the command in fbterm
<cidkid>
initrd-fbterm.nix to be specific
lovesegfault has joined #nixos-aarch64
<cidkid>
thats probably the most puzzling to me
<samueldr>
there could be manyh
<samueldr>
many*
<samueldr>
the first is that that tasks isn't being run
<samueldr>
(a dependency didn't resolve)
<samueldr>
the /sys filesystem could not be mounted
<cidkid>
hmm
<cidkid>
alrighty
<mvnetbiz_>
samueldr, so can the kernel be cross compiled, but the rest of the packages cannot right now, so that is why the disk image isn't built?
<samueldr>
mvnetbiz_: you get the gist of it
<mvnetbiz_>
is it crossbuilding the stuff in initrd?
<samueldr>
yes
<mvnetbiz_>
So I should get my keys in that aarch64 server if I am to get this working I guess
<samueldr>
that would help in getting a working stage-2, but considering there is not much compiling assembling on a lowly computer like a raspberry pi 3 is feasible
<samueldr>
most of it is cached
<mvnetbiz_>
I've never understood what the difficulty in cross compiling is. it must be mostly with linking and dependencies and stuff more than the code directly?
<cidkid>
Woah
<cidkid>
hold up
<cidkid>
My phone is sorta being recognized
<samueldr>
one of the difficulties, mvnetbiz_, is how nixpkgs was not setup with cross-compilation in mind when it started
cidkid has quit [Remote host closed the connection]
<samueldr>
so it's working against assumptions that don't hold for cross-compiling
<clever>
ntpd for some odd reason can cross-compile just fine, but galis due to gcc_s problems at runtime
<samueldr>
then the other bit is how the software itself sometimes is hard to cross-compile and only works due to impure stuff on other platforms
<samueldr>
but galis?
<samueldr>
fails?
<samueldr>
fails, most likely :)
<clever>
rpi> Feb 07 05:04:07 rpi ntpd[2332]: libgcc_s.so.1 must be installed for pthread_cancel to work
cidkid has joined #nixos-aarch64
<cidkid>
hmm
<cidkid>
my phone seems to support usbserial generic when in 900E mode
<cidkid>
wonder if it supports it with regular boot
<samueldr>
unlikrlu
* samueldr
readjusts
<samueldr>
unlikely
<samueldr>
those qualcomm recovery modes are completely different execution paths
<clever>
something i wonder about, do any modern phones have the jtag exposed?
<samueldr>
jtag less often, UART sometimes, but in inconvenient ways
<clever>
now that ive learned how to use it, every problem looks like a nail to hammer in
<samueldr>
when you e.g. make menuconfig that's what ends up configuring the kernel build
<samueldr>
I have a utility in the mobile nixos repo that "normalizes" those files, what I mean is that it takes the file in input, builds the kernel, this makes a fresh one with all new updated options
<samueldr>
and then copies it back right there
<mvnetbiz_>
Yeah but for example, I want to use this pine64 5.5.y rev of the kernel, I guess I could just keep that config, or should I make a new one somehow
Thra11 has quit [Quit: WeeChat 2.7]
<samueldr>
it should be fine to start from that one
<samueldr>
generally it's pretty forward compatible
<samueldr>
any missing option will be answered with the default answer
cidkid has quit [Ping timeout: 268 seconds]
<mvnetbiz_>
I just didn't know if there was some kind of tool you had that I should keep up with.
<mvnetbiz_>
Do you think the kernel config will be done like it is in Nixpkgs? and have any device specific things in the mobile-nixos device modues
<samueldr>
for mainline-using devices, I believe it could
<mvnetbiz_>
can uboot on the pinephone not load something like systemd-boot with a gui? or would that not work as is because uboot needs to set up the fb for it
<mvnetbiz_>
oh that doesn't support arm I thought it might
samueldr has quit [*.net *.split]
samueldr has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
samueldr has quit [Excess Flood]
FRidh2 has quit [Quit: Konversation terminated!]
samueldr has joined #nixos-aarch64
worldofpeace has quit [*.net *.split]
davidtwco has quit [*.net *.split]
shad has quit [*.net *.split]
Ashy has quit [*.net *.split]
Irenes[m] has quit [*.net *.split]
contrun[m] has quit [*.net *.split]
lirzhv has quit [*.net *.split]
pkral has quit [*.net *.split]
{^_^} has quit [*.net *.split]
Dezgeg has quit [*.net *.split]
fpletz has quit [*.net *.split]
flokli has quit [*.net *.split]
danielrf[m] has quit [*.net *.split]
<samueldr>
ugh, the irc server is kinda broken
danielrf[m] has joined #nixos-aarch64
Irenes[m] has joined #nixos-aarch64
worldofpeace has joined #nixos-aarch64
pkral has joined #nixos-aarch64
flokli has joined #nixos-aarch64
LnL has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
fpletz has joined #nixos-aarch64
Dezgeg has joined #nixos-aarch64
Ashy has joined #nixos-aarch64
shad has joined #nixos-aarch64
lirzhv has joined #nixos-aarch64
davidtwco has joined #nixos-aarch64
<samueldr>
mvnetbiz_: I think messages got lost in the IRC shuffling around
mDuff has quit [*.net *.split]
mvnetbiz_ has quit [*.net *.split]
andi- has quit [*.net *.split]
ryantrinkle has quit [*.net *.split]
zupo has quit [*.net *.split]
h0m1 has quit [*.net *.split]
ehmry has quit [*.net *.split]
WilliButz has quit [*.net *.split]
misuzu has quit [*.net *.split]
craige has quit [*.net *.split]
Adluc has quit [*.net *.split]
t184256 has quit [*.net *.split]
srk has quit [*.net *.split]
<samueldr>
[16:25:53] <samueldr> but as you said, GUI, setting up FB are the issues
<samueldr>
[16:25:38] <samueldr> u-boot can boot EFI programs
<samueldr>
[16:25:35] <samueldr> systemd-boot does work on arm
srk has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
misuzu has joined #nixos-aarch64
WilliButz has joined #nixos-aarch64
mDuff has joined #nixos-aarch64
andi- has joined #nixos-aarch64
ehmry has joined #nixos-aarch64
mvnetbiz_ has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
craige has joined #nixos-aarch64
t184256 has joined #nixos-aarch64
Adluc has joined #nixos-aarch64
colemickens has quit [Ping timeout: 240 seconds]
hsngrmpf[m] has quit [*.net *.split]
marijan[m] has quit [*.net *.split]
Aleksejs has quit [*.net *.split]
davidtwco has quit [Ping timeout: 246 seconds]
andi- has quit [Max SendQ exceeded]
alienpirate5 has quit [Ping timeout: 245 seconds]
thequux[m] has quit [Ping timeout: 245 seconds]
Ox4A6F has quit [Ping timeout: 258 seconds]
danielrf[m] has quit [Ping timeout: 240 seconds]
Irenes[m] has quit [Ping timeout: 248 seconds]
dtz has quit [Ping timeout: 245 seconds]
worldofpeace has quit [Ping timeout: 246 seconds]
Aleksejs has joined #nixos-aarch64
davidtwco has joined #nixos-aarch64
samueldr has quit [*.net *.split]
Thra11 has quit [*.net *.split]
wavirc22 has quit [*.net *.split]
alunduil has quit [*.net *.split]
jackdk has quit [*.net *.split]
DigitalKiwi has quit [*.net *.split]
mDuff has quit [*.net *.split]
mvnetbiz_ has quit [*.net *.split]
ryantrinkle has quit [*.net *.split]
h0m1 has quit [*.net *.split]
ehmry has quit [*.net *.split]
WilliButz has quit [*.net *.split]
misuzu has quit [*.net *.split]
Adluc has quit [*.net *.split]
craige has quit [*.net *.split]
t184256 has quit [*.net *.split]
srk has quit [*.net *.split]
LnL has quit [*.net *.split]
shad has quit [*.net *.split]
Ashy has quit [*.net *.split]
davidtwco has quit [*.net *.split]
lirzhv has quit [*.net *.split]
pkral has quit [*.net *.split]
{^_^} has quit [*.net *.split]
Dezgeg has quit [*.net *.split]
fpletz has quit [*.net *.split]
flokli has quit [*.net *.split]
zarel has quit [*.net *.split]
bennofs[m] has quit [*.net *.split]
CrystalGamma[m] has quit [*.net *.split]
goibhniu has quit [*.net *.split]
Ericson2314 has quit [*.net *.split]
cptchaos83 has quit [*.net *.split]
tilpner has quit [*.net *.split]
kcalvinalvin has quit [*.net *.split]
exarkun has quit [*.net *.split]
minicom has quit [*.net *.split]
Aleksejs has quit [*.net *.split]
chiefgoat has quit [*.net *.split]
Smith[m] has quit [*.net *.split]
cornu has quit [*.net *.split]
thefloweringash has quit [*.net *.split]
qyliss has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
makefu has quit [*.net *.split]
ekleog has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
yvan-sraka has quit [*.net *.split]
clever has quit [*.net *.split]
nbp has quit [*.net *.split]
bdju has quit [*.net *.split]
adisbladis has quit [*.net *.split]
zfnmxt has quit [*.net *.split]
grw has quit [*.net *.split]
Acou_Bass has quit [*.net *.split]
sigtrm has quit [*.net *.split]
dongcarl has quit [*.net *.split]
FireFly has quit [*.net *.split]
samrose has quit [*.net *.split]
evils has quit [*.net *.split]
lopsided98 has quit [*.net *.split]
feepo has quit [*.net *.split]
c00w has quit [*.net *.split]
angerman has quit [*.net *.split]
sphalerite has quit [*.net *.split]
disasm has quit [*.net *.split]
chessai has quit [*.net *.split]
hexa- has quit [*.net *.split]
fadenb has quit [*.net *.split]
pbb_ has quit [*.net *.split]
gchristensen has quit [*.net *.split]
NekomimiScience has quit [*.net *.split]
fooker has quit [*.net *.split]
njd has quit [*.net *.split]
ornxka has quit [*.net *.split]
lorem_ipsum has quit [*.net *.split]
andi- has joined #nixos-aarch64
t184256 has joined #nixos-aarch64
dongcarl has joined #nixos-aarch64
FireFly has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
feepo has joined #nixos-aarch64
ornxka has joined #nixos-aarch64
kcalvinalvin has joined #nixos-aarch64
minicom has joined #nixos-aarch64
srk has joined #nixos-aarch64
makefu has joined #nixos-aarch64
makefu has quit [*.net *.split]
dongcarl has quit [*.net *.split]
FireFly has quit [*.net *.split]
wavirc22 has joined #nixos-aarch64
jackdk has joined #nixos-aarch64
alunduil has joined #nixos-aarch64
DigitalKiwi has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
samueldr has quit [Excess Flood]
aminechikhaoui has joined #nixos-aarch64
qyliss has joined #nixos-aarch64
zfnmxt has joined #nixos-aarch64
bdju has joined #nixos-aarch64
adisbladis has joined #nixos-aarch64
nbp has joined #nixos-aarch64
clever has joined #nixos-aarch64
yvan-sraka has joined #nixos-aarch64
Raito_Bezarius has joined #nixos-aarch64
ekleog has joined #nixos-aarch64
makefu has joined #nixos-aarch64
elvishjerricco has quit [Ping timeout: 260 seconds]
makefu has quit [Quit: WeeChat 2.6]
makefu has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
bennofs[m] has quit [Ping timeout: 256 seconds]
evils has joined #nixos-aarch64
lopsided98 has joined #nixos-aarch64
samrose has joined #nixos-aarch64
feepo has quit [Ping timeout: 245 seconds]
ornxka has quit [*.net *.split]
andi- has quit [*.net *.split]
cstrahan____ has quit [Ping timeout: 260 seconds]
Acou_Bass has joined #nixos-aarch64
sigtrm has joined #nixos-aarch64
FireFly has joined #nixos-aarch64
dongcarl has joined #nixos-aarch64
grw has joined #nixos-aarch64
chessai has joined #nixos-aarch64
hexa- has joined #nixos-aarch64
fadenb has joined #nixos-aarch64
fooker has joined #nixos-aarch64
gchristensen has joined #nixos-aarch64
NekomimiScience has joined #nixos-aarch64
pbb_ has joined #nixos-aarch64
lorem_ipsum has joined #nixos-aarch64
ornxka has joined #nixos-aarch64
njd has joined #nixos-aarch64
disasm has joined #nixos-aarch64
sphalerite has joined #nixos-aarch64
angerman has joined #nixos-aarch64
c00w has joined #nixos-aarch64
andi- has joined #nixos-aarch64
alunduil has quit [Ping timeout: 268 seconds]
andi- has quit [Max SendQ exceeded]
sphalerite has quit [Max SendQ exceeded]
hexa- has quit [Max SendQ exceeded]
<mvnetbiz_>
irc is crazy haha
sphalerite has joined #nixos-aarch64
chessai has quit [Ping timeout: 240 seconds]
angerman has quit [Ping timeout: 242 seconds]
andi- has joined #nixos-aarch64
mvnetbiz_ has joined #nixos-aarch64
hexa- has joined #nixos-aarch64
feepo has joined #nixos-aarch64
angerman has joined #nixos-aarch64
chessai has joined #nixos-aarch64
cstrahan____ has joined #nixos-aarch64
<FireFly>
yeah, maintenance, there was a recent global notice
alunduil has joined #nixos-aarch64
<samueldr>
yep
<samueldr>
did you see my three lines?
<mvnetbiz_>
samueldr, who can I talk to to get the nixos cloak? someone in #nixos or something?
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
<mvnetbiz_>
samueldr, seems like I should make the mobile-nixos-pinephone not use the qualcomm image maker thing, rather than keep using the old u-boot with your patch, or rebasing the patch onto updated u-boot or something
<samueldr>
I'm open to other ways to handle this
<samueldr>
one of the ideas with using the same tooling was to better harmonize, and more importantly, have a target that's easy to debug with
<mvnetbiz_>
Is that patch something that makes sense to upstream to u-boot?
<samueldr>
I don't recall
<samueldr>
maybe, but once cleaned-up
<samueldr>
android boot process is a bit of a mess
<mvnetbiz_>
I am guessing android boot image is kernel, ramdisk, and dtb packed together? I'm obviously not familiar with android boot
<samueldr>
pretty much yes
<clever>
that gives me a thought
<clever>
what if the rpi firmware did the same thing?
<mvnetbiz_>
Doesn't the main linux source support init ramdisk in the same kernel image? What is the point of this
<samueldr>
with mobile-nixos, to work with android devices, and with pinephone in mobile-nixos, so it closely matches android devices
<mvnetbiz_>
oh yeah I get why you did it this way that makes sense
<mvnetbiz_>
but like you said android boot process is weird
<mvnetbiz_>
clever, do you mean adding rpi target to mobile-nixos?
<clever>
mvnetbiz_: i was thinking more along the lines of using that combo kernel+ramdisk+dtb file on rpi
<mvnetbiz_>
Yeah exactly
<clever>
rootfs could still be a plain partition, and plain nixos
<clever>
though, one crazy idea i had was to involve sqlite or protobuf
orivej has joined #nixos-aarch64
<mvnetbiz_>
for what, boot entries?
<clever>
yeah
<mvnetbiz_>
that is crazy
cidkid has joined #nixos-aarch64
cidkid has quit [Client Quit]
lordcirth has joined #nixos-aarch64
Thra11 has quit [Quit: WeeChat 2.7]
cidkid has joined #nixos-aarch64
cidkid has quit [Remote host closed the connection]