Ericson2314 has quit [Ping timeout: 256 seconds]
<elvishjerricco> Anyone have any tips for debugging my android kernel not working with the rpi's hdmi? I can ssh in and check out journalctl but nothing stands out to me. Would it be in stage 1 or stage 2?
<samueldr> elvishjerricco: does uboot show up?
<elvishjerricco> samueldr: Yea the thing boots; I'm SSH'd in right now
<samueldr> I mean, does uboot work on the HDMI display?
<elvishjerricco> OH
<elvishjerricco> yea
<elvishjerricco> it does
<elvishjerricco> It say "Starting kernel" or whatever then the whole screen goes black
<samueldr> ah, then it's probably not something obvious with config.txt disabling the output :)
<elvishjerricco> heh, no probably not
<samueldr> though, do you have any differences with the aarch64 default image's config.txt?
<elvishjerricco> Don't think so
<elvishjerricco> I think the main source of difference is going to be my kernel config file
<samueldr> (I'm downloading the aarch64 image to at least verify it should work with the mainline kernel shipping with it)
<samueldr> are you building with modules?
<elvishjerricco> samueldr: I have the 3 b +, which required 4.18 at least
<elvishjerricco> I am, I think?
<samueldr> oh, I don't have the 3b+, won't try then :/
<samueldr> (in case it's an issue with a peculiarity of it)
<elvishjerricco> Regular mainline linux 4.18 does work fine; screen and all
<elvishjerricco> but android-mainline-tracking from 4.18 does not show the screen
<samueldr> ah, that's good, would it be hard to do a lsmod on both and diff?
<elvishjerricco> Good idea
<samueldr> I'm kinda thinking something like not building its modesetting driver or vc4
<samueldr> (though unlikely)
<elvishjerricco> Gotta rebuild my kernel now; brb :P
<elvishjerricco> Huh. All of a sudden my nix expression stack overflows....
Ericson2314 has joined #nixos-aarch64
<elvishjerricco> samueldr: Here's the output of lsmod with the android build: https://www.irccloud.com/pastebin/M9Rjums2/
<elvishjerricco> samueldr: And here it is from the mainline linux build: Module Size Used by btsdio 16384 0 brcmfmac 278528 0 brcmutil 16384 1 brcmfmac hci_uart 73728 0 btbcm 16384 1 hci_uart cfg80211 733184 1 brcmfmac vc4 167936 3 bluetooth 516096 5 btsdio,hci_uart,btbcm cec
<elvishjerricco> 53248 1 vc4 drm_kms_helper 184320 2 vc4 microchip 16384 1 drm 458752 3 drm_kms_helper,vc4 nls_iso8859_1 16384 1 nls_cp437 20480 1 lan78xx 57344 0 ecdh_generic 24576 1 bluetooth rfkill 28672 3 bluetooth,cfg80211 vchiq 323584 0 iptable_nat 16384 0 nf_nat_ipv4 20480 1
<elvishjerricco> iptable_nat nf_nat 40960 1 nf_nat_ipv4 i2c_bcm2835 16384 0 bcm2835_rng 16384 0 pwm_bcm2835 16384 0 bcm2835_thermal 16384 0 rng_core 20480 2 bcm2835_rng nf_conntrack_ipv6 20480 1 bcm2835_dma 20480 1 nf_defrag_ipv6 20480 1 nf_conntrack_ipv6 nf_conntrack_ipv4 20480 2 nf_defrag_ipv4 16384 1
<elvishjerricco> nf_conntrack_ipv4 xt_conntrack 16384 2 uio_pdrv_genirq 16384 0 nf_conntrack 147456 5 xt_conntrack,nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat,nf_nat_ipv4 uio 20480 1 uio_pdrv_genirq crc32_ce 16384 0 libcrc32c 16384 2 nf_conntrack,nf_nat xt_tcpudp 16384 5 ip6t_rpfilter 16384 1 ipt_rpfilter 16384 1
<elvishjerricco> ip6table_raw 16384 1 iptable_raw 16384 1 xt_pkttype 16384 2 ip6table_filter 16384 1 ip6_tables 28672 4 ip6table_filter,ip6table_raw iptable_filter 16384 1 ip_tables 28672 4 iptable_filter,iptable_raw,iptable_nat x_tables 40960 11
<elvishjerricco> ip6table_filter,xt_conntrack,ip6table_raw,iptable_filter,ip6t_rpfilter,xt_tcpudp,ip6_tables,ipt_rpfilter,xt_pkttype,iptable_raw,ip_tables ipv6 483328 23 nf_conntrack_ipv6,ip6t_rpfilter,nf_defrag_ipv6 dm_mod 139264 0 https://www.irccloud.com/pastebin/90e2eaVf/
<samueldr> oops!
<elvishjerricco> Whoops. Pasted bad
<elvishjerricco> The link is there though :P
<samueldr> yeah
<samueldr> good thing freenode's anti-spam bot isn't here
<elvishjerricco> The android one is much shorter
<samueldr> it sure is
<samueldr> there are drm (not the bad DRM) things on both, same vc4 things
<samueldr> so not obviously at fault
<samueldr> anything in dmesg funny about either mode/modesetting/vc4/video.?core/drm ?
<elvishjerricco> samueldr: `dmesg | grep -E 'mode|modesetting|vc4|video.?core|drm'` : https://www.irccloud.com/pastebin/MLwCuIrU/
<samueldr> maybe doing the same on the mainline kernel that work could reveal differences, though I don't see anything outright wrong, not sure if it would show up in there...
<samueldr> (I'm mostly throwing things I would try around)
<elvishjerricco> samueldr: Is the `ASoC: no DMI vendor name!` not worrisome?
<elvishjerricco> (And your throwing things around is better than my no idea of what to do :P)
<samueldr> that warning (in a not too old checkout) seems to come from "sound/soc/soc-core.c"
<samueldr> (audio over hdmi probably)
<samueldr> and AFAIK, DMI is an x86ism
<samueldr> ah
<samueldr> yeah
<samueldr> (sorry for screnshotting text)
<elvishjerricco> samueldr: So that's not relevant then?
<samueldr> I'm pulling from (another mainline tracker) kernel repo just in case something else copied the debug message
<samueldr> but I'm 99.9% confident it's not relevant
<elvishjerricco> samueldr: Should be noted, I am using a custom kernel config file
<elvishjerricco> And I have no idea how much of it is right :P
<samueldr> you could diff /proc/config.gz to get an idea of what's different
<elvishjerricco> Basically I just merged the defconfig for aarch64 with the android recommended and base configs
<samueldr> or could even build mainline with your config?
<elvishjerricco> samueldr: Building mainline with this config is interesting
<elvishjerricco> I'm guessing it would almost certainly display the same problem
<samueldr> elvishjerricco: do you have access to the aarch64 build machine? real helpful for kernel builds :)
<samueldr> if you don't look at the topic and ask for access
* samueldr could also look at the repo to see
<samueldr> you don't seem to be in the config
orivej has quit [Ping timeout: 240 seconds]
<elvishjerricco> samueldr: I'm doing all this cross compiled
<samueldr> oh right duh!
<elvishjerricco> so my thread ripper rips through the kernel in like 5min :P
<samueldr> I forgot how long it was on the 96 core machine
<samueldr> the kernel build is highly parallelized
<elvishjerricco> Yea most C builds are
<samueldr> most well-made C builds :)
<samueldr> some only think they are :)
<elvishjerricco> Aw. The config files are 1141 lines different... That's gonna be hard to debug
<samueldr> | sort them?
<elvishjerricco> This is after sort -u :P
<samueldr> :)
<samueldr> yeah, I had a hell of a time working through the `flo` downstream-oem defconfig vs. mainline
<samueldr> (nexus 7 2013, I want to also use downstream kernels even when mainline has support as not all platforms ha)
<samueldr> has*
<elvishjerricco> It's weird to me that there doesn't seem to be any error in dmesg or journalctl
<samueldr> maybe it's a part that expects something else and just silently fails
<elvishjerricco> I just wish I had any idea what I was looking for :P
<elvishjerricco> Seems like almost all the diff between these two configs is just switching things from =m to =y
<samueldr> :%s/=m/=y/ could highlight major deficiencies?
<elvishjerricco> Hm... Perhaps
<elvishjerricco> Yea, applying this function to the files brings it down to 269 different lines: foo() { sed 's/=m/=y/' "$1" | grep -v '^#'; }
<elvishjerricco> Here is the diff if you're wondering: https://www.irccloud.com/pastebin/6gHDHaRX/
<elvishjerricco> < is the mainline config and > is the android config
<samueldr> kinda and kinda not :) updating a PR
* samueldr wonders about seline
<samueldr> selinux*
<samueldr> maybe even the other hardened things
<elvishjerricco> Yea I dunno what selinux is :P
<samueldr> and then the binder config options, no idea what they do, but if it's about binding to hardware, maybe it grabs the framebuffer before anything else does?
<Dezgeg> are you expecting to see the virtual console or X11? CONFIG_VT being disabled will drop the virtual console
<samueldr> selinux does *waves hands* access control management stuff
<samueldr> haha, good catch there!
<elvishjerricco> Dezgeg: Oh crap I missed that
<elvishjerricco> darn android configs disabling that
<samueldr> darn downstream OEMs breaking it :(
<elvishjerricco> This is just the android-mainline-tracking branch without any device specific changes or anything
<samueldr> (I'm talking about my devices, sorry for the confusion)
<samueldr> either asus or qualcomm broke that on two kernel revisions
<samueldr> for two different devices
<elvishjerricco> Alright, building with a few of the lines from that diff included. Here's hoping...
<Dezgeg> surely there's a rpi3-with-mainline android port somewhere with the things figured out?
<elvishjerricco> Dezgeg: There's https://github.com/android-rpi/kernel_rpi/, but it's far from mainline
<elvishjerricco> Doesn't seem to get much attention
<elvishjerricco> Doesn't even support the 3 b + yet
<elvishjerricco> which is the hardware I have
<Dezgeg> it would seem this guy has it implemented: http://raspex.exton.se/
<Dezgeg> no idea if he distributes the sources though
<elvishjerricco> Doesn't he have to, because GPL?
<Dezgeg> well yes technically someone could sue him, yes
<Dezgeg> seems like this is active: https://github.com/lineage-rpi
<elvishjerricco> Dezgeg: Yea the lineage stuff was going to be my fallback if I couldn't get the mainline tracking branch working
<Dezgeg> I would think 4.14 already has good enough vc4 support to get GPU acceleration
<elvishjerricco> Dezgeg: There's some specific hardware things about the 3b+ that are only in 4.18. Something about the lan and something else I can't remember... Plus a different dtb
<Dezgeg> backporting those bits sounds way less work
<elvishjerricco> Nah. The only work involved here so far has been these 15 lines of kernel config, and I expect that to be enough for now
<Dezgeg> maybe some distro like fedora has it already sorted out
<elvishjerricco> I mean mainline already works perfectly
<elvishjerricco> 4.18 actually
<elvishjerricco> It's really just that android disabled these things I wanted
<elvishjerricco> Which would have been the case either way
<Dezgeg> well yes but I presume lineage has the userspace bits sorted out
<elvishjerricco> userspace bits?
<Dezgeg> to actually run android
<elvishjerricco> Ah
<elvishjerricco> Yea but I'm intending on redoing a ton of that kind of stuff anyway just to get it build with nix stuff
<elvishjerricco> It worked!
<elvishjerricco> NixOS running on android on an rpi 3 b +, all cross compiled :)
Ericson2314 has quit [Ping timeout: 240 seconds]
Ericson2314 has joined #nixos-aarch64
jtojnar has quit [Quit: jtojnar]
Ericson2314 has quit [Ping timeout: 265 seconds]
FRidh has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ZoomZoomZoom has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
globin has quit [Ping timeout: 260 seconds]
ZoomZoomZoom has quit [Quit: Leaving]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 240 seconds]
Ericson2314 has quit [Ping timeout: 240 seconds]
Ericson2314 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Ericson2314 has quit [Ping timeout: 240 seconds]