f_ has quit [Read error: Connection reset by peer]
f_ has joined #linux-msm
JoelSelvaraj[m]1 has joined #linux-msm
AffeNull[m]1 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
svarbanov has joined #linux-msm
konradybcio has joined #linux-msm
<travmurav[m]>
javierm: hm I'm afraid I'm not sure why modem would fail to boot on your device, it's probably worth comparing your system state with Kieran Bingham then...
<travmurav[m]>
i.e. I thiiiink one of the reasons for it to time out would be if the firmware is not correctly signed but that shouldn't matter for chromeos devices...
jhovold has joined #linux-msm
<javierm>
travmurav[m]: no worries, thanks for your help
xtex has joined #linux-msm
<xtex[m]>
It seems that enabling CONFIG_MODULE_COMPRESS_GZIP causes some mysterious errors on samsung-klte...
<xtex[m]>
module_decompress called kunmap_local_indexed and then panics
pespin has joined #linux-msm
<javierm>
travmurav[m], KieranBingham[m]: the WiFi finally worked!
<KieranBingham[m]>
<travmurav[m]> "i.e. I thiiiink one of the..." <- Aha, I played around with firmwares too. I'll boot up and retest that to see if I can reproduce the issue.
<KieranBingham[m]>
Aha even better ... I won't mess up my system. What was the final straw?
<javierm>
I don't know what the problem was, but I ran out of ideas so I did a ChromeOS recovery this morning just to make sure that I the latest FW
<javierm>
and with a clean install, rm -rf /var/lib/rmtfs and ran the msm-cros-efs-loader.sh again, this time rmtfs started correctly and the FW loaded
<KieranBingham[m]>
Aha. Oh yes, I've been using the device in Chrome OS so it should be up to date
<KieranBingham[m]>
So do we need to extract and package those files specifically?
<javierm>
KieranBingham[m]: yeah, while installing Fedora I missed the KERN-{A,B} partitions but I assumed the emmc boot should be safe (since that's read-only)
<javierm>
KieranBingham[m]: unsure... because travmurav[m] said that there are device specific info in those
<KieranBingham[m]>
I guess that's hard to package at fedora/distro level.
<javierm>
KieranBingham[m]: I think that I'll package everything and have some Fedora wiki page explaining how to extract the firmware from the ChromeOS install
<javierm>
everything meaning rmtfs, qrtr-ns and msm-cros-efs-loader.sh
<javierm>
KieranBingham[m], travmurav[m]: thanks a lot folks for your help on this. I'll move forward with the packaging and write that Fedora wiki page
<KieranBingham[m]>
I guess this will only be able to target dual boot scenario. Not overwritting the chromeos. The device feels a bit sluggish running from SD card.
<travmurav[m]>
javierm: hm very interesting, maybe I misunderstood the error and the modem bootloader(mba.mbn) actually booted properly but the real modem os later failed to find what it wants in the efs
<travmurav[m]>
javierm: fwiw I'm actually not even sure if wifi devices have populated efs but it generally should be per-device and afaik they are intended to be preserved from the device manufacturing (so across the cros updates)
<javierm>
KieranBingham[m]: unfortunately, yes. A USB type-c mass storage device is faster IME but it's more convenient the uSD card
<travmurav[m]>
and kernel a/b shouldn't really matter there I think...
<javierm>
travmurav[m]: yeah, that was my thinking and the reason why it took me that long to think that the FW wasn't good
<travmurav[m]>
my only guess would be that boot0 have been corrupted somehow and chromeos recovered it from defaults only because it's a non-lte sku
<KieranBingham[m]>
Yeah I want to maintain the device not having things sticking out of it :-)
<javierm>
KieranBingham[m]: otherwise we could had just used a USB wifi dongle and not have to deal with this crazines :P
<travmurav[m]>
I still do believe it should be safe to wipe emmc (apart from the special boot0/1 and not sure about rpmb) on chromeos
<KieranBingham[m]>
Haha maybe
<javierm>
travmurav[m]: that's indeed a good point. One should be able to wipe ChromeOS and install Fedora there, and the boot{0,1} (where the FW seems to live) should be safe
<javierm>
and yet, that was the issue I had :)
<travmurav[m]>
afaik firmware on cros lives on a dedicated spi flash not even on emmc (cough windows cough)
<javierm>
anyways, I'm a happy camper now. Can't believe that spend most of yesterday trying to get wifi working
<KieranBingham[m]>
Unfortunately I can :-(
<javierm>
it's for sure the most complex WiFi setup I've ever seen
<travmurav[m]>
indeed, on those generations of socs, wifi runs as an "application" ("protection domain") inside the modem OS so need to make multiple things happy for it to run
<KieranBingham[m]>
I've sunk 20 hours on QCOM devices this weekend :-) and we discovered the camera we were looking at on op6 is using c-phy not d-phy which isn't yet supported in camss which halts my fun until linaro add that
<travmurav[m]>
i.e. rmtfs so modem os can boot and access (useless for wifi) efs partitions, then tqftpserv so the modem os can download the wifi firmware "app" from linux fs...
<KieranBingham[m]>
(weekend may be four days long in this instance)
<javierm>
KieranBingham[m]: :/
<KieranBingham[m]>
It's still the fosdem weekend until I get home. Just waiting to board Eurostar :-)
<javierm>
KieranBingham[m]: hope you had fun there :)
<travmurav[m]>
javierm: also re "is it safe to package efs", there are 4 partitions, two are "plain backup" (some tar.gz iirc) and two "working" that are encrypted with a per-device key so they can get corrupted if you i.e. boot on one device, extract efs, then move to another and use that efs again
<javierm>
travmurav[m]: yesterday I learned that QC has a custom socket family (AF_QIPCRTR) to communicate with their remote processors
<javierm>
travmurav[m]: I see...
<travmurav[m]>
yeah, qrtr, there is even qrtr-lookup as "nmap" equivalent for it
<KieranBingham[m]>
It does sound like this is completely ignoring the standard Linux mechanisms
<travmurav[m]>
(...) so if you package wifi efs and only keep the backup ones, then maaaaybe wifi devices would work fine, but not lte ones
<javierm>
KieranBingham[m]: yeah, rpmsg has standard interfaces (chardev and sysfs IIRC) for this...
<javierm>
KieranBingham[m]: in 2012 I got a nack when trying to add a new socket family (AF_BUS), the argument was that there would be a single user (d-bus) but QC could had one 4 years later :)
<travmurav[m]>
fwiw old devices used rpmsg sockets for some messaging (i.e. qmi to modem)
* travmurav[m]
thinks about standards and mumbles something about qcom not even caring about arm ebbr on uefi woa devices
<javierm>
travmurav[m]: maybe firmware loading software architectures is for QC what messagins apps are for Google :D
<travmurav[m]>
Well I think it's somewhat stable nowdays and doesn't get changed much so perhaps they won't break what works anymore
<javierm>
cool
telent has quit [Quit: Ping timeout (120 seconds)]
telent has joined #linux-msm
pg12 has quit [Remote host closed the connection]
pg12 has joined #linux-msm
Caterpillar has joined #linux-msm
Caterpillar has quit [Quit: Konversation terminated!]
mripard has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
Caterpillar has joined #linux-msm
Caterpillar has quit [Quit: Konversation terminated!]