orivej has quit [Ping timeout: 240 seconds]
<clever> samueldr: do you know how to manage timedatectl? i need to get ntp to kick its butt into gear...
<samueldr> nope
<clever> rpi> Feb 07 05:04:07 rpi ntpd[2332]: libgcc_s.so.1 must be installed for pthread_cancel to work
<clever> and ntpd fails when cross-compiled
<samueldr> I'm not even sure how on our images it ends up working
<samueldr> that's in an initramfs or stage-2?
<clever> stage-2
<samueldr> weird
<clever> via nixops!
<clever> i figured out the segfaulting issues, so nixos now boots on both the rpi2 and rpi3
<samueldr> nice!
<clever> on the rpi2, if you dont set a magic SMP enable register, the spinlock code will cause a cpu exception, which linux doesnt properly handle
<clever> on the rpi3, if that same SMP bit isnt set, it just randomly segfaults in userland
<clever> and if you just disable SMP support in the linux build, the rpi2 will run with the caches entirely disabled
<clever> so it runs 1/50th of the normal speed
<samueldr> does that mean that since you solved it it runs at fifty out of fifty?
<clever> yeah
<clever> `openssl speed` reports similar numbers, for both open and closed firmware
<clever> and it no longer takes 8 minutes to boot
<clever> i'm now writing a boot.loader.openpi module, that will deal with the quirks of the bootloader api, and copying firmware to /boot
<clever> samueldr: oh, do you know about the clock saving hack in raspbian? does nixos have that?
<samueldr> I don't know about it
<samueldr> I don't think we have
<clever> on clean shutdown, it just saves the current time to a file
<clever> and on bootup, it sets the time, based on the contents of the file
<samueldr> pretty much what I assumed
<clever> so the clock never goes backwards
<clever> `journalctl -f` is heavily confused by time going backwards
<clever> so i cant get any usable log out of the pi
<samueldr> smells to me that should be part of systemd somehow
<clever> `hwclock` is supposed to pull the time out of the RTC
<clever> but if you lack an RTC, it just does nothing
<clever> currently, my bootloader lacks support for generations, and the kernel cmdline cant even update
<clever> so ive been using /init directly in the rootfs, as the entrypoint
<clever> 4 ln -svf $1/init /init
<clever> and now nixos can update that properly
<clever> on to the actual bootloader code!
cidkid has joined #nixos-aarch64
<clever> done!
<clever> now to begin fixing ugly hacks
<clever> 10 echo "systemConfig=$1 init=$1/init $(cat $1/kernel-params)" > /boot/cmdline.txt
<samueldr> are you writing this in some kind of BASH-BASIC variant?
<samueldr> (joking about the 10 )
<clever> vim line numbers :P
<clever> [root@rpi:~]# cat /boot/cmdline.txt
<clever> systemConfig=/nix/store/bgclbkks7vpm1d2h58zx849dcgbl7cfq-nixos-system-rpi-20.03pre-git init=/nix/store/bgclbkks7vpm1d2h58zx849dcgbl7cfq-nixos-system-rpi-20.03pre-git/init loglevel=4
<clever> looks good
ryantrinkle has quit [Ping timeout: 260 seconds]
<clever> the only major hack left, is that it can only boot with a kernel built under nix-shell
<clever> everything else is just features, like switching over to a u-boot and having proper generation support
<clever> and gfx
<clever> lets confirm it can still boot!
<clever> and what happens if i try to reboot? lol
<clever> [ 3006.546595] Reboot failed -- System halted
<clever> it cant!
<samueldr> I'm curious if you can't just boot u-boot instead of linux
<samueldr> after all, that's what's going on with u-boot with the foundation's firmware, no?
<clever> samueldr: already tried it, it hangs hard
<clever> samueldr: u-boot tries to ask the firmware how much ram is in the system
<clever> and the firmware doesnt exist
<samueldr> ah
<clever> so it gets no answer
<clever> i could implement that part of the firmware, or i could make a custom u-boot
<clever> samueldr: that is my new nixos bootloader!
<clever> samueldr: ive also been talking with the uefi-rpi guys on discord
ryantrinkle has joined #nixos-aarch64
<clever> 108 + optionalString (config.networking.useDHCP || dhcpinterfaces != []) ''
<clever> ack!
<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> so you could add one with `mobile.boot.stage-1.fbterm.enable = true;`
cidkid_ has joined #nixos-aarch64
cidkid has quit [Ping timeout: 240 seconds]
cidkid has joined #nixos-aarch64
cidkid_ has quit [Ping timeout: 240 seconds]
cidkid has quit [Ping timeout: 268 seconds]
cidkid has joined #nixos-aarch64
<cidkid> local.nix should be put just in the root directory of the git right?
<samueldr> yep
<samueldr> cidkid: yes
<cidkid> alright
cidkid has quit [Ping timeout: 260 seconds]
cidkid has joined #nixos-aarch64
<cidkid> samueldr: also do you still have the link for the rootfs?
<cidkid> ty
<samueldr> if for any reason you need to refer to previous conversations, most nixos irc channels are logged https://logs.nix.samueldr.com/nixos-aarch64/
<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> by default, from /vendor AFAIK
<samueldr> well, IIRC, more than AFAIK
<cidkid_> alright
<cidkid_> what hybris version is nix using
<cidkid_> also is there a way to use this repo for audio https://github.com/sailfishos-oneplus5/android_hardware_qcom_audio on nix?
<cidkid_> as I know where to get lineage-15.1 builds for it's vendor
<samueldr> what hybris version? most recent it was when it was last updated IIRC
<cidkid_> mmm
<cidkid_> I wonder if hybris-15.1 things will work on newest
<samueldr> that qcom_audio thing, not sure, haven't explored that yet
<samueldr> ah, but the API version hybris targets might be what 15.1 is about
<cidkid_> yeah
<cidkid_> If I get this repo working audio should come up
<cidkid_> as it points the hardware to all the .so's
<samueldr> I haven't had the need/chance to get deep in hybris yet, so sadly I can't answer much yet
<cidkid_> WAIT
<cidkid_> hold on
<cidkid_> postmarketos irc came through
<cidkid_> I need a alsamixer ucm for my audio
<cidkid_> and it *should* work
<samueldr> once I get boot stronger, I *think* I'll be about ready to do the big passes drivers stuff
<cidkid_> alright
<samueldr> hopefully by next month
<cidkid_> if I get audio working after new init is fixed for my phone
<cidkid_> I will let you know as walleye can probably use it
<cidkid_> if this fixes it I can keep nixos as my main OS on my phone for now as all I need from my phone really is music
wavirc22 has quit [Read error: Connection reset by peer]
<cidkid_> samueldr: would you mind if I gave out the example rootfs as long as I specify it's not official in any way?
<samueldr> "gave out" how?
<cidkid_> give the link to your website with the rootfs hosted
<samueldr> in what context, I meant
<cidkid_> so that
<cidkid_> postmarketos people are wondering about requirements, and pretty sure some of them don't have a full aarch64 device to build rootfs on
wavirc22 has joined #nixos-aarch64
<cidkid_> samueldr: when/if libhybris works, I can more than likely also get RIL up
<cidkid_> also how not recommended is making a /lib/firmware directory and /system directory on rootfs?
* DigitalKiwi downloads the top sekrit img
<samueldr> it might be the easiest way to handle those things
<samueldr> and with newer devices having a partition to hold such files, possibly how it's going to be handled
<samueldr> while not ideal with regards to generations, it's likely they'll never really get upgraded anyway
<cidkid_> ooh hold on
<cidkid_> would it be better to define filesystems in configuration.nix?
<samueldr> it's starting to be
<cidkid_> just mount /modem/image/ to /lib/firmware
<cidkid_> and then mount /vendor to /system
<samueldr> it might not be as trivial as that, we'll have to see with the variety of devices :)
<cidkid_> alright
<cidkid_> assuming libhybris wants /vendor on /system
<cidkid_> also any non-device specific things you need someone else to test please let me know as I'm willing to test pretty much anything
<cidkid_> samueldr:libhybris might not be viable for every device just so you know, due to libhybris only supportings arm 32bit
<cidkid_> now I think of it
<cidkid_> or can libhybris run in 32bit while the rest of the system is aarch64?
<FireFly> huh, didn't know libhybris only supports ARM32.. hmm
<cidkid_> maybe I'm wrong
<cidkid_> I don't know tho
<FireFly> You're probaby right, Ihaven't really looked into it
<samueldr> I don't know yet, but never saw anything stating arm32
* FireFly eager to return home to a pinephone to mess with
<cidkid_> samueldr: nevermind it does
<cidkid_> I think docs just never got updated
<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]
wavirc22 has joined #nixos-aarch64
bennofs has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
bennofs has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 260 seconds]
tilpner has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 260 seconds]
ryantrinkle has joined #nixos-aarch64
bennofs has joined #nixos-aarch64
bennofs has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bennofs has joined #nixos-aarch64
bennofs has quit [Ping timeout: 272 seconds]
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
mvnetbiz_ has joined #nixos-aarch64
andi- has quit [Quit: WeeChat 2.6]
andi- has joined #nixos-aarch64
samrose has joined #nixos-aarch64
<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> ah, that's the name of the file
<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.
<samrose> been a long time since I've checked in here. Thanks to Yegor Timoshenko we now have https://github.com/Holo-Host/holo-nixpkgs/blob/develop/overlays/holo-nixpkgs/linux-packages/sun50i-a64-gpadc-iio/default.nix for bpim64
<samueldr> nice!
<cidkid_> I edited modules/initrd-logs.nix to dump to /, and another place where I could grab it from TWRP and nothing shows
<samrose> (dynamic loading modules)
<samrose> maybe this approach will help other efforts
<mvnetbiz_> I don't know anything about these uboot patches, or how the pinephone kernel config is generated
<samueldr> cidkid_: / is in a tmpfs, so it wouldn't be saved, and "another place" would need to be mounted first
<samueldr> mvnetbiz_: do you, per chance, have access to another A64 device?
<cidkid_> would that be difficult to do?
<samueldr> it helps to make heads and tails of the pinephone
<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> it's less likely to be the xiaomi one
<samueldr> but that's another example
<cidkid_> would the ab_partitions config matter at all
<cidkid_> dumpling doesn't have ab
<samueldr> no, but vendor_partition would
<samueldr> if it needs a firmware for gadgetfs to work
<samueldr> like it did for lavender
<cidkid_> lets see if it works ig
<cidkid_> I'm building bootimg now so
<cidkid_> do I have to uncomment this? # FIXME: This is the right function name, but doesn't work.
<samueldr> that would be for adb
<samueldr> I don't have adb working at all with gadgetfs
<samueldr> so I wouldn't expect it to work
<samueldr> while rndis does
<cidkid_> alright
Thra11 has joined #nixos-aarch64
<samueldr> so it looks like it *is* gsi.rndis
<cidkid_> rndis will allow ssh-initrd?
<samueldr> yes
<samueldr> but keep the nexus 4 one for the first test
<cidkid_> WARNING: modpost: Found 2 section mismatch(es)is that of any worry?
<samueldr> it's not known what exactly made it that the lavender really didn't want to use another vendor/product
<samueldr> I wouldn't think
<samueldr> but I don't know for sure
<cidkid_> Connect refused
<cidkid_> *connection
<cidkid_> time to change ids
<samueldr> wait
<samueldr> did a network card show up?
<samueldr> if so, rndis worked
<samueldr> connection refused makes me think it's even simpler: ssh might not be enabled :)
<samueldr> mobile.boot.stage-1.ssh.enable = true;
<samueldr> mobile.boot.stage-1.networking.enable = true;
<samueldr> for good measure
cidkid_ has quit [Remote host closed the connection]
<samueldr> connection refused makes me think the network connection worked
<samueldr> pretty sure it only uses that wording when there is something on the other side replying
cidkid has joined #nixos-aarch64
cidkid has quit [Client Quit]
cidkid has joined #nixos-aarch64
<cidkid> alright I'm back my bad
<cidkid> no network card shows
<cidkid> samueldr: enabling ssh in local.nix doesn't work either
<cidkid> still connection refused
<samueldr> you would need to see a new usb device in your dmesg logs
<samueldr> use `dmesg --follow
<cidkid> there is a new usb device
<samueldr> then, this would be a USB network interface
<samueldr> and depending on your computer setup, use dhcp to connect to it
<cidkid> wait
<cidkid> nevermind
<cidkid> it connects for a second then dc's
<samueldr> can you gist/pastebin the dmesg output around that time?
<cidkid> It see's fastboot stuff
<cidkid> thats it
<samueldr> right, so it's not setting up the gadget after it boots I presume
<cidkid> yeah
<cidkid> vendor_partition = "/dev/block/by-name/vendor";
<cidkid> is that fine?
<samueldr> plausible
<cidkid> do you want a full paste of my current default.nix for my device?
<samueldr> cidkid: yeah, let's see
<samueldr> looks alright...
<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> I wouldn't be surprised if some of those test pads would be JTAG in some devices
<cidkid> alright, well I'm out of steam for this project for a little while
<cidkid> I'll stick around in the irc tho
<samueldr> don't despair, you've done well in the situation where not enough is documented
<samueldr> and taking a pause is a good thing to do :)
<samueldr> clever: do an image search for "android JTAG" to see some examples
<samueldr> thoguh most of them are older devices
<cidkid> I might either do halium stuff (unlikely due to the old firmware requirements) or work on postmarket
<cidkid> as postmarket things would be easily ported to nixos mobile
<clever> samueldr: with the number of pins i see on some of those devices, it definitely could have jtag
<samueldr> yep
lovesegfault has quit [Quit: WeeChat 2.7]
<samueldr> a big part of this is that it's often left undocumented since it's being sold as part of a hardware box
<clever> rpi for example, has 2 jtag ports, the arm one is behind the normal gpio mux, so its somewhat documented
<clever> but the vpu jtag is undocumented, a few have scanned it to find the device id, but havent gotten anything useful out of it
cidkid_ has joined #nixos-aarch64
cidkid__ has joined #nixos-aarch64
cidkid__ has left #nixos-aarch64 [#nixos-aarch64]
<samueldr> mvnetbiz_: mostly original I think
<mvnetbiz_> samueldr
<mvnetbiz_> How was it generated?
<samueldr> kernel .config file
<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.
cidkid_ has quit [Ping timeout: 272 seconds]
<samueldr> ah, yes
<samueldr> but mostly to re-generate it
<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?
<mvnetbiz_> I don't think so
<mvnetbiz_> What do you get that web log from?
<samueldr> an irc bot that is used for that
<samueldr> that's the logger https://github.com/whitequark/irclogger
<mvnetbiz_> thanks.
elvishjerricco has joined #nixos-aarch64
cidkid has joined #nixos-aarch64
cidkid has quit [Client Quit]
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]
dongcarl8 has joined #nixos-aarch64
Piece_Maker has joined #nixos-aarch64
sigtrm_ has joined #nixos-aarch64