mdz has quit [Ping timeout: 252 seconds]
<Wizzup> tmlind: I briefly measured the ground of the microsd solder points on the mz617 and it does seem to be hooked up at least
xmn has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
xmn has joined #maemo-leste
ikmaak has quit [Ping timeout: 264 seconds]
ikmaak has joined #maemo-leste
xmn has quit [Ping timeout: 264 seconds]
Juest has quit [Ping timeout: 260 seconds]
mqlnv has quit [Ping timeout: 252 seconds]
mqlnv has joined #maemo-leste
mdz has joined #maemo-leste
<Wizzup> uvos: hm, did you include powervr stuff in this kernel?
<Wizzup> hm, I think I see what happened
STNX has joined #maemo-leste
<Wizzup> tmlind: ok, I'm in :)
<Wizzup> tmlind: amazing work
<Wizzup> tmlind: somehow the sd card was just picked up with default mz617 dts
arno11 has joined #maemo-leste
<Wizzup> so with the right dts it boots
<Wizzup> scree nworks
<Wizzup> touchscreen doesn't yet, but wifi works, serial works, usb otg works
<Wizzup> now I can't help but wonder if it's just hooked up on the mz617 without us knowing
<Wizzup> it being the microsd card
pere has quit [Ping timeout: 245 seconds]
<arno11> Wizzup: hi, i need your advice/help to find those bloody ret/off mode blockers: i have a basic sdcard to try to load a very minimal config on the n900 and to try to add one by one every modules. But i don't know what's the trick to load a minimal config :P
<Wizzup> tmlind: looks like ts works actually
<Wizzup> arno11: give me 5-10 mins
<Wizzup> tmlind: but some leste config or xorg config messes it up
uvos has joined #maemo-leste
<uvos> ts worked, so thats a regession
<uvos> the micro sdcard holder is not simply not installed, tmlind solderd one on his and that dident work
<uvos> pvr works fine
<uvos> d4 leste ofc stopes ts working
<uvos> because the ts is blaklisted in libinput
<uvos> since we use the filtered touchscreen device instead (from ts-buttons)
<Wizzup> uvos: hi, just a few mins
<arno11> Wizzup: finally i have to go, let's see pm stuff later ;)
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup> uvos: hi
<Wizzup> arno11: ok, I'll write here anyway
<Wizzup> uvos: so it looks like there is a ts, but there are some probe errors
<Wizzup> so there is a 004a and 005b
<Wizzup> uvos it looks like X saw the ts but then dropped it
<Wizzup> [ 451.889] (EE) libinput: Atmel maXTouch Touchscreen: Failed to create a device for /dev/input/event3
<Wizzup> [ 451.889] (EE) PreInit returned 2 for "Atmel maXTouch Touchscreen"
<Wizzup> uvos and of course there is still the droid4 calibration file in udev
<Wizzup> uvos: so the mz609 and mz617 dts do not build, otherwise I might be able to try another kernel build for experimental
<Wizzup> uvos: worth noting is that it seems like the cache partition containing kexecboot somehow gets messed up by android, so it's not just android getting buggy
<Wizzup> uvos: I have some hack fixes for the dtses, shall I just push those to a test branch to debug the rest of the process?
fab__ has joined #maemo-leste
<Wizzup> uvos: so this time on boot both atmel_mxt_ts probes failed
<Wizzup> [ 7.488616] atmel_mxt_ts: probe of 1-004a failed with error -121
<Wizzup> [ 8.142578] atmel_mxt_ts: probe of 1-005b failed with error -121
<Wizzup> well, this time the ts works
<Wizzup> https://wizzup.org/MVI_1083.MP4 <- not promotional material
<uvos> no idea about the ts not probeing
<uvos> havent seen that
<Wizzup> uvos: I suppose I could take the part from mz616 and put it on my mz617 and see if it seems a microsd
<uvos> i never tried building the mz6xx dts's in that branch
<uvos> so them being broken in the merge is not compleatly suprising
<Wizzup> check
<uvos> as i say
<Wizzup> I would like to see if my changes to builddeb worked, so for that purpose I might commit a change that just kludge fixes them for building, not for using purposes
<uvos> i presume you removed the blacklist of the ts
xmn has joined #maemo-leste
<uvos> ok
<Wizzup> yes I removed the blacklist and blacklisted ts buttons
<uvos> ts-buttons should not load at all
<uvos> as it should not be in the dts
<Wizzup> not sure, I just flashed a d4 image, never booted it, then changed boot.cfg, added dtb and kernel and modules
<uvos> ok
<freemangordon> wow, that's fast
<freemangordon> why it seems smoother than d4?
<uvos> same as bionic
<uvos> it lacs the pannel refesh bug of d4
<freemangordon> ah
<Wizzup> uvos: btw you said the display doesn't turn off yet, or idle correct, if I recall correctly?
<uvos> no that used to be the case
<uvos> it should now
<Wizzup> ah, okay
<uvos> it also sleeps fine
<uvos> and has very low power cosumption when it dose
<uvos> i can run weeks if you dont touch it
<Wizzup> hmm
<Wizzup> on leste?
<uvos> no just minimal debian
<Wizzup> I see
<uvos> but leste too really
<Wizzup> right now it uses about 0.180A at 3.85V on my lab psu
<Wizzup> with the screen off, but wifi on
<uvos> hmm
<Wizzup> I suppose we might need some idling scripts
<uvos> ret?
<Wizzup> RET is 0 atm
<uvos> hmm ok something is blocking
<Wizzup> root@devuan-xt616:~# /etc/init.d/droid4-powermanagement status
<Wizzup> d=2024-01-14|t=13:47:26|i=OFF:0,RET:0|p=673|c=NA|b=none
<uvos> the b= dosent work on leste anymore
<uvos> omapconf time
<Wizzup> is that because of kernel changes, or?
<uvos> no
<Wizzup> (the b=not working anymore)
<uvos> becasue the version of a utility used to parse the bits changed
<Wizzup> so droid4-powermanagement says:
<Wizzup> * Module omap_hdq blocks idle: Seems to poll devices, blacklist?
<Wizzup> * Module atmel_mxt_ts blocks idle: Should be unloaded when screen is blanked
<uvos> thats old/wrong
<Wizzup> both are loaded
<Wizzup> ok, we should maybe update those eventually
<uvos> its wrong
<uvos> atmel_mxt_ts got idle support since then
<Wizzup> I mean we should update the script :)
<uvos> omap_hdq we tamed by changing the parameters
<Wizzup> right
<uvos> anyhow omapconf will tell you
<uvos> just compeare it with the d4 output
<Wizzup> understood
<Wizzup> I think I want to try to build the chimaera-experimental kernel first atm, many things happening at once
<Wizzup> it's on a lab psu anyway so I don't mind the power usage
<uvos> sure
<uvos> working is at all is more important
<uvos> than ret
<uvos> anyhow even at 0.5w it should last quite a while
<uvos> the battery is huge
<Wizzup> yes, but if we can get it to idle then it should be able to charge while in RET
<Wizzup> (that would be my main motivation atm)
<uvos> if you upp cpcap to 2A in sysfs it will charge fine
<uvos> still takes a long time since the battery is huge
<Wizzup> oh, so what I read in the logs a while ago, wrt charging being a problem is no longer relevant?
<uvos> its less of a problem
<Wizzup> ok
<uvos> back when the bridge chip dident work
<uvos> we could not turn off the display at all
<uvos> which drew like 1.5A or so
<uvos> its sill hillariously slow to charge via cpacp ofc
<Wizzup> 2A doesn't seem to be that slow, or?
<uvos> i mean its a 7Ah battery
<uvos> so takes like 4h
<uvos> you also going to have an extreamly hard time to charge it its empty
<uvos> since the power draw of the display on boot is intense
<Wizzup> right
<Wizzup> uvos: I think kexecboot has a charging mode now
<uvos> so it has the d4s low power boot problem on sterioids
<uvos> right
<Wizzup> uvos, not important now, but I think speaker audio doesn't probe either at mfor me
<uvos> hmh
<uvos> strange
<uvos> should be the same as d4
<Wizzup> in any case, I'm super surprised by how well this works now already
<Wizzup> [ 39.769256] mot-mdm6600-codec 4806a000.serial:modem:audio-codec@2: ASoC: error at snd_soc_component_probe on 4806a000.serial:modem:audio-codec@2: -110
<Wizzup> [ 39.797454] asoc-audio-graph-card soundcard: ASoC: failed to instantiate card -110
<Wizzup> [ 39.812561] asoc-audio-graph-card soundcard: error -ETIMEDOUT: parse error
<uvos> yeah i mean once tmlind figured out whats wrong with the bridge driver
<Wizzup> [ 39.827178] asoc-audio-graph-card: probe of soundcard failed with error -110
<uvos> its just a big d4
<Wizzup> still :)
<Wizzup> which reminds me, does razr still have this screen issue?
<uvos> you have some mz604 right
<uvos> just mentioning: according to xda some of those have unlocked bootloaders
<uvos> not that its super revelant to us
<uvos> its not like we are going to use a different boot procedure for some random mz604
<Wizzup> are those omap?
<Wizzup> hm yeah so this time to atmel probe failed again
<Wizzup> s/ to / the /
<uvos> i ment 607 sry
<Wizzup> ok
<uvos> all 604s are unlocked
<uvos> but thats nvidia powered xoom1
<Wizzup> let me check @ mz607
<Wizzup> I have something labelled mz608 here as that is what the firmware says, but it doesn't have a microsd card slot exposed
<Wizzup> I *think* the rest are mz609
<uvos> ok
<uvos> no
<uvos> mz607 european wifi only version
<uvos> same story as xt912/xt910 some european examples have unlocked bootloaders
<uvos> depends on where they where sold exactly
<Wizzup> we have the luxury to get one on ebay in any case, or if you find specific xt91x es
<Wizzup> if it helps with the devel we can use funding money to acquire them
<uvos> i have one allready
<Wizzup> mz607?
<uvos> xt910 (or 12 i dont remember) with a unlocked bootloader
<Wizzup> right
<uvos> i have no mz60x variant at all
<Wizzup> I know there's a lot of different chat threads, but do you recall if the razr still had this refresh bug?
<uvos> yes it dose
<uvos> i never got to that either
<Wizzup> ok
<uvos> i was going to ajust the timeings slightly to see if it goes away
<Wizzup> ok
<Wizzup> once the conversations/telepathy settles down a little I would like to retry droid3/razr/atrix 2
<uvos> working droid3 would probubly be most usefull
<uvos> razr has a nice display, atrix 2 is kinda just a bionic (maybe it even boots the bionic image, would not suprise me at all, stock android dmseg output suggests its exatcly the same as bionic)
<uvos> minus the lte modem ofc
<Wizzup> I think getting them all to work would be great and I agree d3 is most useful, in the sense that it is mostly d4, but just with less ram, but no modem restrictions in the us
<Wizzup> (which is useful for me :))
<uvos> well it also has the older non-vunerable bootloader
<uvos> which is booo
<uvos> thats a benefit xt91x has over bionic too
<Wizzup> right, clown boot
<tmlind> good to hear the micro-sd works with leste on some tablets :)
<Wizzup> yes, it's amazing :D
<tmlind> so which tablets are now confirmed to work for micro-sd?
<tmlind> only mz616?
<Wizzup> so far, yes
<Wizzup> the mz608 that I have here (presumably) according to some websites has microsd, but it is not exposed, I had not pried it open yet
<tmlind> oh interesting
<Wizzup> cute
<Wizzup> sicelo: so we need to work on a risc-5 port? ;)
Juest has joined #maemo-leste
<Wizzup> uvos: I have a mb865 here
<Wizzup> you're suggesting I try clown boot on it like it's bionic?
iamzim has joined #maemo-leste
<Wizzup> InlineFlashing_Edison_67.21.125_CFC_P3_APBP.xml/allow-mbmloader-flashing-mbm.bin well that is helpful
<uvos> Wizzup: yeah, possibly you have to rebuild the kexec modules against the edison kernel
<uvos> Wizzup: and you have to use edison mbm ofc
<uvos> otherwise it could just work
<Wizzup> hm, right, I did do some of that for solana (I still have the clownboot fork of that)
<uvos> iirc you treid but in the end i had to compile the modules :P
<uvos> but i can do that for edison too
<uvos> anyhow possibly its the same kernel as bionic anyhow so it should
<uvos> work
<uvos> just try instmoding them in android
<uvos> or just compeare uname
<uvos> over all confidence my is high that it shal just boot the bionic image otherwise
<Wizzup> ok
<Wizzup> I'll root it first, then try the insmod\
<uvos> needs to be updated to android 4.0.4 first ofc
<uvos> if its 4.1 you might have to flash 4.0.4's boot.img
<uvos> you do on bionic anyhow
<Wizzup> freemangordon: btw I removed iphdb and glib from experimental sicne I don't think we need them anymore
<Wizzup> uvos: yeah it's 4.0.4 already
<Wizzup> the droid 3 was actually using android 2.3.4 iirc
<uvos> yes droid 3 was the only mapphone device that never got the 4.0+ updates
<uvos> this is because /system is too small
<uvos> but all of them started with 2.3 besides the tablets that started at 3.1
iamzim has left #maemo-leste [#maemo-leste]
<Wizzup> uvos: btw, the droid 3 dts that I made is not in your 6.6 kernel
<Wizzup> this is not a big problem but this is why the postinst fails on the experimental kernel ;)
ikmaak has quit [Ping timeout: 264 seconds]
ikmaak has joined #maemo-leste
<uvos> yeah that dosent merge
<uvos> and i havent rebased that yet
<uvos> d3 branch that is
pere has joined #maemo-leste
<Wizzup> makes sense
<Wizzup> let me try booting the experimental kernel
<Wizzup> worked
<Wizzup> (mz616)
<uvos> here be d3 branch
<Wizzup> thanks
<Wizzup> probably won't get to it today, planning to try the atrix and then take a break, but good to have it around :)
pere has quit [Ping timeout: 264 seconds]
<Wizzup> uvos: well insmod uart.ko made me lose adb shell but the device is on
<Wizzup> so I guess it's compatible
<uvos> yeah best do this via local shell on device
<Wizzup> do you think I should try the other steps too?
<Wizzup> I figured I'd just assume it works
<uvos> its probubly fine yeah
* Wizzup prepares bionic mage
<Wizzup> image , not mage :)
<uvos> no nead
<uvos> *eed
<uvos> *need
<uvos> if it boots to kexecboot via clownboot obv its booting the mainline kernel as a bionic
<Wizzup> yeah but I'm going to make a leap of faith and see if it just works
<Wizzup> the atrix has an extra button it seems
<Wizzup> hm, I think there's some read-only mount stuff going on again, the install.sh script failed
<Wizzup> that really needs set -e I think
<Wizzup> hm, it doesn't let me reflash, complains about preflash validation failure
Twig has joined #maemo-leste
<Wizzup> so I guess somehow the bootloader is not unlocked even with the allow-mbm...
<uvos> what partition?
<Wizzup> cdt.bin
<uvos> you dont need to reflash that
<uvos> also cdt.bin needs to be from the exact version
<uvos> since thats where the keys live
<uvos> so thats not unusual
<Wizzup> also lbl
<uvos> allow-mbm... only unlocks a couple of extra partions but def not cdt
<uvos> yes all of those need to be signed with the right key
<uvos> so what you are trying to flash is not signed with the same key as the device
<Wizzup> hm
<Wizzup> ok, so I am able to flash mbm for sure
<Wizzup> ok, so I need to find another android zip to flash?
<uvos> yes the signing keys for mbm never changed
<uvos> you can flash any mbm from the same device
<uvos> yes
<uvos> or even from different devices often (for mbm)
<Wizzup> ok
<Wizzup> from this: https://firmware.center/firmware/Motorola/MB865%20Atrix%202%20%28Edison%2C%20Fuath%29/Stock/MB865/ I got the latest InlineFlashing, as well as the ASIAOPS, MEARET and SEARET
<uvos> i would really just ignore all of this and only worry about it if you cant flash /system
<Wizzup> from the InlineFlashing I can flash cdt.bin
<uvos> or bpsw
<Wizzup> hmm ok
<uvos> and boot
<uvos> those are the only partitions you need to touch really
<uvos> clownboot only touches system
<Wizzup> ok, but should system not be compatible with the rest?
<uvos> and pds
<uvos> i think
<uvos> system dosent care
<Wizzup> I am able to flash InlineFlashing files, so I'm planning to just flash those enirely
<Wizzup> entirely*
<uvos> you can boot different /system
<Wizzup> but I can stop doing that if you think that doesn't make sense
<uvos> it makes no sense to reflash all that stuff and its needless danger
<uvos> just reflash what you touched
<Wizzup> well I didn't flash the phone initially
<Wizzup> that's the thing, so I don't know what's flashed in particular
<uvos> yeah but any system will do
<uvos> even 4.1 vs 4.0 dosent matter
<uvos> as long as the bootloader eats it its fine
<Wizzup> hm ok
<uvos> same with boot
<Wizzup> and preinstall?
<uvos> ah right preinstall is where we place some clownboot stuff
<uvos> yes you need to reflash that
<uvos> but also dosent matter
<Wizzup> ok
<uvos> preinstall just contains some application
<uvos> s
<uvos> that are wait for it.. preinstalled
<Wizzup> I just want to boot it android again first and root it, and then run the install.sh one by one
<Wizzup> ok, will boot now and see
<Wizzup> thanks for the help as usual :)
<uvos> yw, i presume it booted
<Wizzup> if it gets past the 'rethink possible' logo then it will, otherwise I am stuck at where I was before :)
<Wizzup> says 'preparing device', so looks like it'll get there eventually
<Wizzup> ok, rooting again
<Wizzup> freemangordon: it looks like chimaera-testing in extras has a newer openmediaplayer, maybe we can move that?
<Wizzup> brb dinner
<Wizzup> will let you know how atrix goes :)
<uvos> if it gets stuck at prepearing device you have to erase cache and data
<uvos> (you should do this when downgradeing android (even patch levels))
<uvos> and that might be what you are doing, since we dont know what the old version was
<uvos> dazu: guten appetit!
xmn has quit [Ping timeout: 246 seconds]
pere has joined #maemo-leste
<Wizzup> uvos: ok so /sdcard is not writeable
<Wizzup> I used /data/bionic
<Wizzup> uvos: hm:
<Wizzup> $ fastboot flash bpsw ~/maemo-leste/droid4-kexecboot/current/droid4-kexecboot.img
<Wizzup> Sending 'bpsw' (4096 KB) OKAY [ 0.202s]
<Wizzup> Writing 'bpsw' (bootloader) Command restricted
<Wizzup> also can't override boot.img per the bionic's readme
<Wizzup> Warning: skip copying boot image avb footer (boot partition size: 0, boot image size: 8388608).
<Wizzup> $ fastboot flash boot boot.img
<Wizzup> Sending 'boot' (8192 KB) OKAY [ 0.440s]
<Wizzup> Writing 'boot' (bootloader) Preflash validation failure
<Wizzup> FAILED (remote: '')
<Wizzup> fastboot: error: Command failed
<Wizzup> interesting, now it just shows 'ap fastboot flash mode (s) (flash failure)'
<Wizzup> so it doesn't boot to android
<Wizzup> I guess I need to dd?
<uvos> for /sdcard you might need a fat32 sdcard there
<uvos> Wizzup: no maybe it dosent have bpsw at all
<uvos> could be that bpsw, altho never used, was intended for something todo with lcm2.0
<uvos> which we dont have
<uvos> you can check in android ofc for the partitions
<uvos> if it isent there you might have to use cache
<Wizzup> will check
<uvos> (and modify the clownboot scripts to suit
<uvos> )
<uvos> thats already annoying if true
<uvos> because now we already have to support the atrix as another distinct device
<Wizzup> it has more buttons anyway
<uvos> those are just on the button matrix
<uvos> you could add them to the bionic dts
<Wizzup> so /proc/partitions doesn't show a bpsw
<uvos> the bionic wont care
<Wizzup> I don't know if it is normally labelled
<uvos> not sure
<uvos> but look at the partition
<uvos> should be 4mb
<Wizzup> I don't know how to resolve it to a partition
<Wizzup> the name
<uvos> so some are listed in cmdline
<Wizzup> <5>[ 0.000000,0] Kernel command line: omap_wdt.timer_margin=60 oops=panic console=/dev/null rw mem=1024M@0x80000000 vram=10300K omapfb.vram=0:8256K,1:4K,2:2040K init=/init ip=off mmcparts=mmcblk1:p7(pds),p15(boot),p16(recovery),p17(cdrom),p18(misc),p19(cid),p20(kpanic),p21(system),p22(cache),p23(preinstall),p24(webtop),p25(userdata) androidboot.bootloader=0x0A72
<uvos> the bootloader lists them there
<uvos> /dev/mmcblk1p14
<uvos> if thats 4mb and empry
<uvos> *empty
<uvos> then its bpsw
<Wizzup> 179 14 4096 mmcblk1p14
<Wizzup> it does not seem to be mounted
<uvos> fs?
<Wizzup> let me root again so I can check the partition contents
<uvos> the mild danger here is that bpsw might be used for something on this device, in difference to all the others
<uvos> maybe because the modem is slighly different or something
<uvos> i gues risking bricking one as an expirament isent so big a deal
<Wizzup> there is webtop
<Wizzup> you think it would be a hard brick?
<uvos> yeah you could use that
<uvos> Wizzup: unless you can find a singed bpsw image, maybe
<Wizzup> right
<uvos> android might not boot if the modem freaks out
<Wizzup> flashing a wrong boot.img should not brick anything though right?
<uvos> no thats safe
<Wizzup> (rather, dding yours)
<uvos> wait
<uvos> what boot.img are you dding?
<uvos> no no
<uvos> dont do that
<Wizzup> ok, it also didn't work
<uvos> yeah its bionic signed
<uvos> thats just a specific bionic kernel version
<Wizzup> so just use a boot.img that I have?
<Wizzup> ok
<uvos> that i know works, since the one from 4.1 dosent
<Wizzup> let me double check that insmod still works since I reflashed system and such
<uvos> just use a android 4.0.4 boot.img from atrix in its place
<Wizzup> ok
<uvos> dding a bionic image here
<uvos> wont brick your device, but it wont work either
<uvos> since the bootloader will reject it and force you into fastboot asking you to reflash
<Wizzup> right
<Wizzup> I think this might be what happened earlier
<uvos> yeah if you dont want to use mmcblk1p14
<uvos> might make sense if webtop flashable from fastboot
<Wizzup> will try that now
<Wizzup> yes that works
<Wizzup> ok, let me install bionic again with a fixed script for the partition
<Wizzup> bionic->clown boot
<Wizzup> uvos: got to kexecboot
<uvos> weee
<Wizzup> also see kernel console
<uvos> that basicly guarentees that the device is otherwise 100% bionic compatabile
<Wizzup> it might get to h-d
<Wizzup> generting ssh keys atm
<Wizzup> (..)
<uvos> needs more random data :P
<uvos> sweet
<uvos> looks like Wizzup is having a pretty good sucess rate today
<Wizzup> nah, this is just me aping my way through trying to use your knowledge and work as well as tmlind's knowledge and work :P
<uvos> could you grab p14
<uvos> for examination
<uvos> we also need the battery nvme
<uvos> altho i presume its the same
<uvos> since it shares its battery form factor with bionic
<Wizzup> yup, sec
<Wizzup> seems to be ... just zeroes
<Wizzup> for p14
<Wizzup> how do I get you the battery data?
<uvos> /sys/bus/1w/devices/
<uvos> some lower directory of that
<Wizzup> there are some differences it seems
<uvos> mbm is setting higher voltages
<uvos> thats harmless
<uvos> and not really a relevant difference
<Wizzup> no, but like
<Wizzup> [ 8.487579] kxcjk1013 3-000f: Error reading who_am_i
<Wizzup> [ 8.498779] kxcjk1013: probe of 3-000f failed with error -121
<Wizzup> and
<Wizzup> [ 7.697601] cpcap_adc cpcap_adc.0: CPCAP ADC device probed
<Wizzup> [ 7.704803] lm75: probe of 0-0048 failed with error -121
<Wizzup> [ 7.712951] cpcap_battery cpcap_battery.0: failed to register power supply
<Wizzup> the emif_probe and omap-sham seems less relevant
<uvos> the emif error is on all our devices
<Wizzup> right
<uvos> we dont setup emif correctly
<Wizzup> I also don't see the modem in lsusb
<Wizzup> which is probably why there is no audio card either:
<uvos> ok so the cpcap battery thing is pretty wierd
<Wizzup> [ 38.398345] mot-mdm6600-codec 4806a000.serial:modem:audio-codec@2: ASoC: error at snd_soc_component_probe on 4806a000.serial:modem:audio-codec@2: -110
<Wizzup> [ 38.462890] asoc-audio-graph-card soundcard: ASoC: failed to instantiate card -110
<Wizzup> [ 38.483459] asoc-audio-graph-card soundcard: error -ETIMEDOUT: parse error
<Wizzup> [ 38.498901] asoc-audio-graph-card: probe of soundcard failed with error -110
<uvos> ok ok
<Wizzup> I am not trying to make a point :)
<uvos> maybe the modem isent on usb like bionic but on spi like razer
<Wizzup> I just enumerated all the things I could find
<uvos> that would be annoying
<Wizzup> maybe superflous but /sys/bus/1w/devices/ does not exist currently
<uvos> no thats a problem
<uvos> but it exits on my d4 too
<uvos> hmm
<uvos> so previously unoticed bug
vahag has joined #maemo-leste
<Wizzup> do you mean that it doesn't exist on your d4?
<uvos> *it DOSENT exist
<uvos> yes
<Wizzup> check
<Wizzup> let me reboot, see if -devel works ok, and then try to boot to android from kexecboot as well
<Wizzup> just to confirm that that still works
<uvos> "android from kexecboot" er no
<uvos> clowboot burns that bridge by hijaking androids boot process to start kexecboot
<Wizzup> ah ok
<Wizzup> my bad
<Wizzup> in any case, I have a second atrix 2
<Wizzup> so we can use that for android debugging
<uvos> we cant get to android from kexecboot anyhow
<uvos> since we are in mainline linux at that point
<Wizzup> ah, right, of course
<uvos> and the motorola kernel has a bug that it dosent survive warm boots
<uvos> so you cant kexec it
<uvos> buuut
<Wizzup> hehe
<Wizzup> in any case, -devel boots fine :)
<uvos> we could improve clownboot to disable itself and let android continue if vol-up is held or so
<Wizzup> right
<uvos> ok
<uvos> do you have decoded stock dts and the signal map?
<Wizzup> not yet
<Wizzup> screen brightness doesn't work either fwiw
<uvos> yeah
<Wizzup> adjusting it I mean
<uvos> the led controller dient work
<uvos> *probe
<uvos> thats lm75
<uvos> maybe the backligt is connected to cpacap instead
<uvos> or the lm75 has a different enable gpio
<uvos> (which would be in the singal map
<uvos> )
<Wizzup> ok
<Wizzup> the atrix2 dir as a device_tree.img now
<Wizzup> has a*
<uvos> Wizzup: ok ill decode the signal map and dt tomorrow
<uvos> Wizzup: should still have the scripts somewhere
<Wizzup> cool ty
<Wizzup> I'll write up the steps I took on a gh issue
<uvos> you can check with evtest what the shutter button has, matrix address wise
<uvos> btw
<Wizzup> ok
<Wizzup> 2 mins
<Wizzup> I'm curious if the modem is on spi or not, if so that would be shame
<uvos> should be able to find out in android sysfs
<Wizzup> yeah
<uvos> but if so then its a theme with gsm only mapphones
<Wizzup> what bothers me mostly is that tmlind said it's unlikely we'll ever get that to work :P
<uvos> yeah
<Wizzup> we'll never*
<Wizzup> uvos: which input device do you want me to evtest?
<Wizzup> I thought: /dev/input/event2:cpcap-pwrbutton
<uvos> omap keypad
<uvos> no
<Wizzup> ok
<uvos> the volume buttons are only on cpcap on devices with no removeable battery
<uvos> (for the reboot claw)
<uvos> otherwise they are matrix keys
<Wizzup> Testing ... (interrupt to exit)
<Wizzup> Event: time 1705264818.732375, type 4 (EV_MSC), code 4 (MSC_SCAN), value 10
<Wizzup> Event: time 1705264818.732375, -------------- SYN_REPORT ------------
<uvos> great
<uvos> ok we can add that to dts
<Wizzup> ok, the other mb865 needs a bit of time to charge the battery
* uvos is also charing several mb865
<Wizzup> one thing that might need to be done is to network unlock these before installing leste
<Wizzup> I guess not for us in europe of course
<uvos> are they generally locked?
<uvos> even outside the us?
<Wizzup> not sure regarding outside the us
<Wizzup> I still do have a sigma key dongle and license.... used it just once
<uvos> something to try i gues
<uvos> anyoingly they use old school huge sims
<uvos> providers here dont even supply those anymore
<Wizzup> you don't have 20 pcs of those lying around?
<Wizzup> :D
<uvos> i need to source an adapter
<uvos> no :P
<Wizzup> If you still used nokia n900 you would :p
<uvos> i gues so
<Wizzup> btw, the battery indication does give me 86%, so it looks like it might work
<uvos> but the n900's older is so over engeneerd you can place a micro sim in there, if its just for testing ;)
<uvos> *holder
<Wizzup> true
<Wizzup> unfortunately I have a piece of paper folded about 5-6 times in between my battery and sim holder ;)
<uvos> why that
<Wizzup> classic n900 problems where it will sometimes lose sim contact
<Wizzup> or lose modem somehow
<Wizzup> btw I wrote some info here https://github.com/maemo-leste/bugtracker/issues/649
<uvos> oh so its over-engeneerd and bad
<uvos> great
<Wizzup> hehe
<Wizzup> ah, mb865 is not supported by sigmakey https://forum.gsmhosting.com/vbb/f719/unlock-mb865-1629642/
<Wizzup> ./bus/spi/drivers/mdm6600_spi
<Wizzup> :(
<uvos> :(
<uvos> now its really not very interesting
<uvos> a bionic with no modem.. pass :P
<Wizzup> you're looking at it all wrong, this is a challenge to make the modem work ;)
<uvos> xD
<Wizzup> do you remember what made supporting mdm6600 over spi particularly hard?
* Wizzup will try to grep irc logs
<uvos> Wizzup: kernel just dosent implement qmi over spi (just from what tmlind explained from memory)
<Wizzup> right
<Wizzup> there must be non-omap phones using qmi over spi
<Wizzup> but maybe not mainlind :)
<Wizzup> mainlined*
<uvos> iirc on android the kernel just exposes the modem interfaces to userspace and some blob talks qmi
<uvos> so the downstream implementations are not very usefull
<Wizzup> oof that would be ugly
<uvos> now i wonder if mz608 is also mdm6600 over spi
<uvos> that would complete the theory that all gsm only devices are so
<Wizzup> from what I found tmlind wrote that xyboards have modem on spi
<uvos> nah
<Wizzup> 16:22 < tmlind> uvos: xt910, xt912 and xyboard all uses qmi over spi for the modem i think, so at least i'm not working on that stuff
<Wizzup> 18:46 < tmlind> uvos: i think also droid4 has spi2 wired to the modem but not in use in the phone firmware. maybe that's just a config option though who knows
<Wizzup> but this was many years ago
<uvos> pretty sure he is wrong for xt617
<Wizzup> probably 4+ years
<uvos> he is def wrong for xt912
<uvos> only xt910 has it over spi
<uvos> and im pretty sure he is wrong too for mz617
<Wizzup> right, I think he got the modem working on mz617 :)
<Wizzup> just data only
<Wizzup> if the blob speaks qmi over spi, it might not be super complicated, but yeah, maybe cm or lineage can tell us a bit more
<Wizzup> on the mz616, I also don't see the modem on usb, but the kernel reported the modem powered up ok
<Wizzup> uvos: there seems to be /sys/bus/platform/drivers/qmi-over-spi and /sys/module/qmi_spi on the 3.0.8 kernel
<Wizzup> any idea where the kernel tree for edison could be found?
<uvos> probubly its just the motorola_mapphone_common tree
<uvos> otherwise motorola published the code on sourceforge
<uvos> (we should really save all of that sourceforge gets iffier by the month)
fab__ has quit [Quit: fab__]
<uvos> (https://github.com/STS-Dev-Team/android_kernel_motorola_omap4-common) this one if you dont know where to find it
<Wizzup> ty
<uvos> drivers/net/spi/qmi_net.c
<Wizzup> yeah, I was looking at that, looks like very little code
<Wizzup> there must be more
<uvos> something something 30mb userspace blob :P
<Wizzup> so there is arch/arm/mach-omap2/board-mapphone.c
<uvos> sure thats just board source
<Wizzup> oh this just refers to qmi over spi
<Wizzup> yeah
<Wizzup> are you sure about the userspace blob? I mean it's entirely possible of course
<Wizzup> I just did find / | grep qmi and all I found was some sysfs stuff
<Wizzup> (on android)
<uvos> yeah i mean there is a huge blob that just opens all the modem device files
<uvos> anyhow tmlind surely knows why he thinks implementing qmi over spi would be very hard
<Wizzup> mhm
<uvos> probubly best to just interrogate him
<Wizzup> well let's just get an image going at least for mb865 in any case
<uvos> ill bring the thumb screws
<Wizzup> I don't think that's necessary :P
pere has quit [Ping timeout: 268 seconds]
<Wizzup> I'm curious about the blob, I always thought qmi was some protocol / standard thing, but I guess not
* uvos sad trombone
<Wizzup> hmm
<Wizzup> wait
<Wizzup> root@edison:/ # dmesg|grep qmi
<Wizzup> <6>[ 0.259033,0] feature_qmi_over_spi=0
<Wizzup> we should check the device_tree tomorrow
<uvos> or lsusb
<uvos> anyhow ill head out
<uvos> ttyl
<Wizzup> yeah lsusb says nothing but that could just mean the modem didn't power
<Wizzup> ok, ttyl
<uvos> on android ofc
<Wizzup> root@edison:/ # lsusb
<Wizzup> Bus 001 Device 001: ID 1d6b:0002
<Wizzup> that's just some root hub I think
uvos has quit [Quit: Konversation terminated!]
Twig has quit [Remote host closed the connection]
<Wizzup> <6>[ 113.538391,0] omap_hsi omap_hsi.0: Modem wakeup detected from HSI CAWAKE Pad port 1
<Wizzup> hm
<Wizzup> isn't that what the n900 uses too? ssi/hsi?
<bencoh> it is indeed
mdz has quit [Ping timeout: 264 seconds]
mdz has joined #maemo-leste
pere has joined #maemo-leste
<Wizzup> arno11: on the n900 pw question... it's difficult/complicated. what you (imo) really need is the ability to use a serial device with the n900, and (probably) also some external power supply
<Wizzup> arno11: something like this: http://n900.elektranox.org/serial-adapter-gallery.html
<Wizzup> arno11: then you can boot just the kernel to say init=/bin/sh and probe modules one by one
<Wizzup> and if you use a lab power supply you can just see the power usage on the display
<Wizzup> the problem is that for these tests, you really probably don't even want the display on, or the keyboard enabled, initially
<Wizzup> arno11: perhaps more feasible is just trying to identify blockers from a running maemo leste system, but this is also not at all easy unfortunately, we do have a way to print the (sub)system that is blocking idle, and then we can maybe guess the driver