orivej has quit [Ping timeout: 240 seconds]
h0m1 has quit [Quit: WeeChat 2.6]
h0m1 has joined #nixos-aarch64
v0|d has joined #nixos-aarch64
v0|d has quit [Remote host closed the connection]
h0m1 has quit [Ping timeout: 246 seconds]
h0m1 has joined #nixos-aarch64
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 250 seconds]
Acou_Bass has joined #nixos-aarch64
orivej has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
THFKA4 has quit [Ping timeout: 246 seconds]
THFKA4 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 265 seconds]
zupo_ has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
bennofs[m] has quit [*.net *.split]
dtz has quit [*.net *.split]
dtz has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
bennofs has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bennofs has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 268 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has joined #nixos-aarch64
bennofs has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bennofs has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 250 seconds]
v0|d has joined #nixos-aarch64
zupo has joined #nixos-aarch64
bennofs has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bennofs has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> welp, for now I'm defeated by qualcomm's SDM845 DRM fbdev emulation seemingly being broken
<gchristensen> :(
<samueldr> I guess once I'm more familiar with those bits I'll tackle the issue agin
<samueldr> again*
<samueldr> the unfun bit is how it seems they have harcoded "0" here
<clever> samueldr: ive been making some progress on understanding the open rpi firmware
<samueldr> but I'm not entirely convinced it should work with 0
<simpson> Welcome to ARM GPU driver hell.
<clever> samueldr: ive found a magic flag, that should enable 64bit arm, but it doesnt do anything yet
<simpson> You *should* be able to just parameterize that, and then we can become Yet Another Carrier of ARM Kernel Patches~
<samueldr> simpson: it's already too late about not being a carrier of ARM kernel
<clever> simpson: YACAKP?
<samueldr> and "just" parameterize
<samueldr> if you can give me an overview of how to "just" parameterize, I will be glad to listen
<simpson> samueldr: Yeah, I know, it's nasty nasty code.
<samueldr> though those parts are upstream
<samueldr> and I tried to make sense of it from upstream, but it's not exactly trivial to
<samueldr> so it defnitely looks like 0 is not a value that should work here
<samueldr> and nothing in between in the call stack tries to make it be something sane
orivej has quit [Ping timeout: 268 seconds]
<simpson> Hm. Curious. Yeah, I'd probably try to figure out what 'iova' is next. You're right that it doesn't look easy to fix. It doesn't help that I've forgotten a lot of stuff.
<samueldr> though, I'm also a bit salty about getting the thing booting first :)
<samueldr> I had issues
<samueldr> and all of them were my own damn fault
<samueldr> though once I got a kernel booting, I started figuring out what the DRM-based driver meant
<samueldr> it's probably better to not rely on FBDEV emulation only in the tooling, and *also* implement DRM-based backends
<samueldr> it just would have given me a fuzzy feeling to see the ol' splash on the phone
<simpson> No worries. DRI is definitely the way forward. The DRM itself is only one part of the puzzle; these days, memory management is probably the trickiest thing to get right.
<samueldr> I assume the driver is good enough considering that's seemingly what's used by android
<samueldr> when I plug a display to its Type-C port, it's all DRM stuff in dmesg, and everything /sys/ is hooked up seemingly right :)
<simpson> samueldr: FWIW I am the average-quality GPU developer writing these drivers~ Rob's definitely more skilled than me, and this code is not really that hard to read, just uncommented. As usual, the datasheet would help a lot, but good luck with that.
<betaboon> samueldr: yesterday i checked op3-usb-c->monitor. you're right: doesnt work XD
<samueldr> simpson: I'm definitely not a kernel developer (yet) neither really a kernel hacker, but it's slowly becoming something I need to
<betaboon> + i now got a system.img built, but fail to get it onto the device :( tried with android-burn-tool and with adb flash with no success
<samueldr> haven't looked into the recovery flashing processes, couldn't say
<samueldr> ah
<samueldr> it might be too big to flash in the system partition
<samueldr> I've been using userdata
<samueldr> it's highly likely that the project will end up adding LVM on top of system+userdata
<betaboon> yeah i tried to flash to userdata. `adb flash userdata system.img` succeeds, but init.log complains about /dev/disk/by-partlabel/NIXOS_SYSTEM not being found. which is true.
<samueldr> adb flash or fastboot flash?
<betaboon> *fastboot flash. sorry
<samueldr> anyway, the oneplus3's fastboot flash apparently doesn't work for flashing the img to userdata, it doesn't work for me either
<betaboon> what's funny is that it claims to have succeeded.
<samueldr> for the oneplus3 I *have* to use the burn tool, which might be a tad under-documented
<samueldr> yes, "funny" :)
<betaboon> using the ssh-connection with burn-tool is just soooo slow XD tried to get something to work with adb forward. but didnt succeed and then ran out of time
<samueldr> so slow?
<samueldr> I think it was in the same ballpark as fastboot flash for me
<samueldr> $ pv ../images/system.nixpkgs-5b7be2a16f583cc854cdf1c9d502ca6aeb0823e8.img | ../ssh.sh dd of=/dev/disk/by-partlabel/userdata bs=8M
<betaboon> realy ?
<samueldr> this is what I used last week
<betaboon> I've been using your ssh-initrd
<samueldr> oooh
<samueldr> *that*'s how I was doing it
* samueldr deletes new wrapper
<samueldr> lol, they're basically identical
<betaboon> that's how it is documented in examples/demo/README.md xD
<samueldr> I was in a hurry last week when trying to debug something else that was driving me nuts
<betaboon> samueldr: how is using `pv` different from using dd ?
<samueldr> probably not much
<samueldr> but it gets you a neat progress bar
<samueldr> though it's not a 100% truthful progress bar, it's progress of shoving bytes in the pipe
<betaboon> I'm getting like 2KiB oO
<betaboon> thats what i meant by 'soooo slow'
* samueldr checks
<betaboon> ah now it's up to 6.3MiB
<betaboon> but still 20min+ ETA
<samueldr> oops
<samueldr> I let the battery go too low
<samueldr> I think the battery is toast on that one :/
<samueldr> so I can't test for a while
<samueldr> but I'm 99% sure it was uin the order of less than a minute, if not, two
<betaboon> no problem. I'll try to let this run through and see if that works.
<samueldr> maybe try another type-c cable
<betaboon> different cable, same behavior: starts out at around 3KiB/s then goes up to around 6MiB/s after two minutes
<betaboon> and now after 7minutes (1000MB) it's back down to 20KiB/s
<samueldr> I'm about ready to test
<betaboon> which might be where that slow speed comes from
<samueldr> sounds plausible
<samueldr> what's the nixpkgs checkout you're using?
<samueldr> I assume mobile-nixos master as of right now
<betaboon> mobile-nixos@master(+lightdm-patch) + nixpkgs-channel@nixos-unstable(at: 3ccbc8d8915)
<samueldr> initrd built using cross-compilation?
orivej has joined #nixos-aarch64
<betaboon> yes i think so
<samueldr> or... maybe I'm misremembering and just did something else while it flashed
<samueldr> 3.10MiB/s though
<samueldr> but I do have traces in dmesg
<samueldr> I have an ETA of 14 minutes though
<samueldr> the ~3MiB/s is solid for me
<betaboon> since it went down to 20KiB/s it didnt recover
ryantrinkle has quit [Ping timeout: 240 seconds]
<samueldr> 3058851840 bytes (2.8GB) copied, 949.889858 seconds, 3.1MB/s
<samueldr> took 15 minutes, just like pv was estimating
<samueldr> well, 15:49
<betaboon> did you have similar errors in dmesg ?
<samueldr> yes
orivej has quit [Ping timeout: 265 seconds]
ryantrinkle has joined #nixos-aarch64
<betaboon> I'm trying to rebuild and try again
orivej has joined #nixos-aarch64
<betaboon> samueldr: sometimes i dont get an ip on the rndis device when starting into burn-tool. did that happen to you too ?
<samueldr> not really, but another user also had issues with gadget mode
<samueldr> wondering if there are differences in firmware / hardware
<samueldr> is it reproducible enough or only once in a blue moon?
<samueldr> (also note that I haven't booted it often with gadget/rndis, I ported it to the device, but almost haven't done anything with it... it just worked o.O)
<betaboon> once in a blue moon. then takes 1-2 reboots and its back to normal
<samueldr> aw, if it was happening often or reproducibly I would have asked you to try the PR
<betaboon> will keep a look out for it :X
<samueldr> grumble grumble
<samueldr> I had things I wanted to achieve first, but it looks like the community wants to get involved and those goals are useless to most of those getting involved
<samueldr> that's a nice problem to have though :)
<betaboon> i would be totaly fine if you would do a rightup of exactly that situation and say something like "gonna do abc first, will take n-m month, then gonna be more open to the community "
<samueldr> there's no clean writeup other than "I want to solve *my* problems first"
<samueldr> and this is said jokingly
<betaboon> XD
<betaboon> so i just tried dding the system image again. same behavior. ~3KiB/s for first ~2min. then ~6MiB/s until 1000MiB are transfered, then back down to 20KiB/s. not recovering :/
<samueldr> might be something to do with writing to the block device
<samueldr> not trivial to do, but if you could add f3 to the initrd, format a clean ext4fs on userdata, run f3write it could help identify an issue
<samueldr> there's also f3probe, never used it, and a bit dangerous as playing with the block device is not the best idea
<samueldr> (though in theory the op3 is fully recoverable from most brick situations)
<betaboon> `fdisk -l` gets stuck the moment the 1GiB situation occures as well
zupo has joined #nixos-aarch64
<samueldr> that gives credibility to block device access issues
lordcirth has joined #nixos-aarch64
aminechikhaoui6 has joined #nixos-aarch64
chris|_ has joined #nixos-aarch64
NekomimiScience_ has joined #nixos-aarch64
Piece_Maker has joined #nixos-aarch64
shad_ has joined #nixos-aarch64
pbb_ has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
sphalerite_ has joined #nixos-aarch64
grahamc has joined #nixos-aarch64
orivej has quit [*.net *.split]
Acou_Bass has quit [*.net *.split]
lordcirth__ has quit [*.net *.split]
pbb has quit [*.net *.split]
Ericson2314 has quit [*.net *.split]
Dezgeg has quit [*.net *.split]
aminechikhaoui has quit [*.net *.split]
{^_^} has quit [*.net *.split]
chris| has quit [*.net *.split]
sphalerite has quit [*.net *.split]
simpson has quit [*.net *.split]
gchristensen has quit [*.net *.split]
shad has quit [*.net *.split]
nervengift has quit [*.net *.split]
NekomimiScience has quit [*.net *.split]
flokli has quit [*.net *.split]
chris|_ is now known as chris|
Piece_Maker is now known as Acou_Bass
NekomimiScience_ is now known as NekomimiScience
flokli has joined #nixos-aarch64
nervengift has joined #nixos-aarch64
simpson has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
Dezgeg has joined #nixos-aarch64
<betaboon> samueldr: mkfs succeeded. now running f3probe
<samueldr> ooh, that's nice to hear, wasn't sure it was a sound thing to attempt
<samueldr> errr, mostly mobile-nixos ssid
<samueldr> side*
<samueldr> the initrd code sometimes cause issues with dependencies
<betaboon> f3probe says the drive is good
<betaboon> dont know how to run f3write.
<samueldr> f3write needs a mounted filesystem
<betaboon> adding those packages was a breeze ;)
<samueldr> it fills it
<samueldr> though I'm misusing it for its speed figures
<betaboon> ah i see
<samueldr> it's not its main usage
<samueldr> but since i's randomish data, AFAIK it should show trustworthy speed results
<samueldr> though I'm sure there are other tools for that
<betaboon> f3write reports 99.48MB/s
<betaboon> hm.
<samueldr> good news, flash is not busted
<{^_^}> mobile-nixos#45 (by kirelagin, 5 weeks ago, open): oneplus3: Enable otg-switch
<samueldr> I'm not sure what it's supposed to fix :/
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
<betaboon> lemme try
<betaboon> hm. fastbook doesnt come up anymore
<betaboon> *fastboot
<betaboon> ah there it is oO
<betaboon> that was weird
<samueldr> check your dmesg for qualcomm usb devices connection
<samueldr> there's a trivial way to start EDL mode, which makes the OP3 look bricked as heck
<samueldr> basically nothing seems to respond, and no fastboot nor adb connections
<betaboon> ok two reboots in a row no ip on rndis. so not once in a blue moon
<samueldr> that's with that PR applied?
<samueldr> do you have another cable to test with?
<betaboon> thats with the pr. yes. gonna try if i can get ip again. i have two cables to test. both the same
<samueldr> do you also have adb active?
<samueldr> with the OP3 it should work, so you can inspect the device if adb works, but not rndis
<betaboon> adb works, rndis does not right now.
<betaboon> gotta run for now. will most likely be back later
<samueldr> oh, try pv with adb, next, see if it's faster
<samueldr> I might have been wrong in assuming adb didn't work for that purpose
<samueldr> (and next meaning in the future whenever you come back to that issue :))
<betaboon> ah turns out i got some more time xD
<samueldr> if it's faster, dropbear/rndis are to blame, if it's the same, cable/gadget drivers/storage are to blame, but storage is likely fine since f3write seemingly wrote fast
<clever> samueldr: i tried running the rpi3 kernel on the rpi3, but it fails, due to being arm64 running in arm32 mode
<samueldr> clever: tried a random 32 bit kernel to see?
<clever> samueldr: building the rpi2 kernel now
<samueldr> I wonder what's implementing trustzone for rpi3
<samueldr> in fact, most of the 64 bit boot chain I don't really know about
<samueldr> I think it's all bootcode.bin based
<clever> [BRINGUP:main]: Execution mode: Supervisor
<clever> samueldr: for proper arm devices, the arm core will start in the highest bit-width it supports
<clever> and there is a special register to soft-reset to a given addr, and drop to 32bit mode
<clever> and once you drop to 32bit, your stuck there, forever
<clever> arm64 has several exception levels, EL0 thru EL3 i think
<clever> and each one can be in 32bit or 64bit mode
<clever> so when you go from 0->1, the mode switches automatically
<clever> so a 32bit userland can run under a 64bit kernel
<clever> and once you become 32bit, you need a layer above you to grant 64 again
<clever> but, the procedure to drop 64bit at the kernel level, is the highest layer
<clever> so it becomes permanent
<clever> but, broadcom ignores all of those rules!
<clever> there is some broadcom specific flag, to force the cpu to boot in arm32 mode
<betaboon> samueldr: seems like piping into `adb shell` is not supported
<clever> samueldr: oh, which pkgsCross should i use for the rpi2 kernel, arm-embdeded seems to fail?
<samueldr> ~/Projects/samuel.dionne-riel.com $ echo test | adb shell cat
<samueldr> test
<samueldr> betaboon: ^
<samueldr> clever: pkgsCross.armv7l-hf-multiplatform
<samueldr> clever: you should also be able to use linux_rpi3
<samueldr> it knows it's supported for armv7l-linux
<clever> samueldr: the cpu is stuck in 32bit mode, so a 64bit kernel instantly fails with panic(): "Fatal CPU exception!"@trap.cc:47
<samueldr> clever: when building for armv7l linux_rpi3 should be built 32 bit
<samueldr> it will differ from the defconfig used
<samueldr> though you're also probably right in assuming the rpi2 kernel will work fine there
<clever> *** Can't find default configuration "arch/arm/configs/bcmrpi3_defconfig"!
<samueldr> I guess I'm wrong then lo
<samueldr> lol*
<clever> and its now building systemd, wut?
<samueldr> stdenv-linux needs it, it looks like
<clever> but this is pinned to a rev from, hmmm....
<samueldr> sorry, util-linux, I think
<samueldr> I looked at the build dependencies tab
<clever> its pinned to a commit you authored! lol
<clever> why there though, i dont remember
<clever> and its been on that rev since day 1
<samueldr> random luck at that exact moment I was merging the PR?
<clever> probably
marius851000[m] has quit [Ping timeout: 240 seconds]
insep[m]1 has quit [Ping timeout: 240 seconds]
NickHu has quit [Ping timeout: 240 seconds]
<betaboon> hm. samueldr pv|adb shell behaves weird
<betaboon> but adb push works but only if you push directly to the device. to symlinks doesnt work
<samueldr> interesting
<betaboon> so `adb push /dev/sda15` (in my case) worked great
<betaboon> and i was able to boot :)
<samueldr> good to know, would be trivial to do from TWRP, too, while waiting for a more proper "installer"
<samueldr> but scary a bit since overwriting the wrong partition can mean a real brick
<samueldr> (namely, overwriting the bootloader partitions)
<betaboon> yeah.
aminechikhaoui6 is now known as aminechikhaoui
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ryantrinkle has quit [Ping timeout: 246 seconds]
grahamc is now known as gchristensen
<clever> samueldr: the rpi2 kernel at least doesnt throw exceptions
<clever> but its giving zero uart output
ryantrinkle has joined #nixos-aarch64