<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>
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
<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