View Full Version : [HOWTO] Comprehensive Firmware Flashing Guide for Jolla
I think we need a thread for flashing new kernels / OS releases for Jolla too :D
So, I'll open this:
1. Where to get flasher tool (for linux of course)?
2. Is it possible to flash kernel in situ?
3. What support binaries are needed, like FIASCO images?
4. Where to get kernel build tree and toolchains?
OnTwitter, they replied that information on kernel development, craeting images and flashing, will be available via merproject.org.
So, lets see ....
rainisto
2013-12-01, 15:53
I think we need a thread for flashing new kernels / OS releases for Jolla too :D
So, I'll open this:
1. Where to get flasher tool (for linux of course)?
2. Is it possible to flash kernel in situ?
3. What support binaries are needed, like FIASCO images?
4. Where to get kernel build tree and toolchains?
1. Currently there is no flasher tool available for general public. Flashing is only possible on care centers (or by Jolla employees). This means that you need to be carefull out there when beeing in developer mode, if you brick your device it can take some time to get device to care for reflashing (and on worst case you may have void your warranty for example if you have overclocked and fried the cpu with custom kernel module while beeing in developer mode). However we are working on possible flashing solution to be available for developers during 2014, but there is no decisions nor ETA defined yet.
4. Most likely by sending source code request to address which is stated in about device settings page.
Thanks for the details Rainisto.
I really hope that flasher will come out, and not only for developpers. That's a big part of what made the N900 and N9 what they are. Plus it should lower the need for asking Jolla Care to fix things that could be fixed by users.
I think Nokia haven't received more devices to unbrick because users messed up with the flasher, than they would have received devices to unbrick because users couldn't unbrick them by themselves. People who use the flasher do this at their own risk anyway, and are usually involved in the community (otherwise they wouldn't even be aware a flasher exists), so they know it'll be faster to *not* send the device for service, but rather find how to properly use the flasher by asking the community.
1. Currently there is no flasher tool available for general public. Flashing is only possible on care centers (or by Jolla employees). This means that you need to be carefull out there when beeing in developer mode, if you brick your device it can take some time to get device to care for reflashing (and on worst case you may have void your warranty for example if you have overclocked and fried the cpu with custom kernel module while beeing in developer mode). However we are working on possible flashing solution to be available for developers during 2014, but there is no decisions nor ETA defined yet.
4. Most likely by sending source code request to address which is stated in about device settings page.
Wow, this really surprises me. That is one thing that should be there from the beginning, at least that's what I think many expect.
Mikkosssss
2013-12-01, 17:25
I think Nokia haven't received more devices to unbrick because users messed up with the flasher, than they would have received devices to unbrick because users couldn't unbrick them by themselves.
Then there have been few cases where Nokia Care says that phone cant be fixed and community has helped to fix it.
4. Most likely by sending source code request to address which is stated in about device settings page.
Is this going to change in the future? It doesn't sound too good. How can one for example flash Nemo there, without being able to make a hw adaptation (which includes the kernel)? Since kernel has to be published anyway as per GPL, why can't Jolla just put out the sources and .ks build instructions somewhere which can be updated in the timely fashion? That old practice of Nokia with sending the sources on DVDs instead of just hosting the whole thing on-line somewhere always looked pretty bizarre. I hope Jolla will avoid doing such stuff.
Requested and received. I've merged the Jolla kernel source release (kernel-adaptation-sbj-3.4.0.20131115.2) on top of tagged Qualcomm (Android) kernel release so that it's possible to view all Jolla specific changes. Only really major change I noticed in my first quick glance through it, was that they've backported btrfs (from linux-stable 3.5.7). Other than that, their changes are mostly hardware enablement related (display, touchscreen, camera, sensor, etc drivers). Stuff you'd see in any kernel source for any e.g. Android device. Vast majority of their (or their ODM's) changes are even commented (who, when, what) which is great compared to some other stuff I've seen. In general quite clean, though I (literally :P) see red when I see all those whitespaces.
I've pushed the source to my GitHub. Happy forking. :)
https://github.com/KonstaT/sailfishos_kernel_jolla_msm8930
I can write some instructions if someone is interested in building/booting custom kernels. It should be pretty basic stuff for anyone familiar with e.g. Android development (and the necessary tools are the same). From a brief chat I had with a Jolla engineer, flashing/booting a custom kernel image will result a permanent unlocked status (in bootloader?) and it will most likely void your warranty!
Edit. Stskeeps has cleared the situation in this post:
http://talk.maemo.org/showpost.php?p=1399188&postcount=40
Flashing/booting a kernel image using fastboot is not possible without 'fastboot oem unlock', which will most likely void your warranty. Flashing a kernel image using root/developer mode is possible. Flashing kernel images to recovery partition instead should be more suitable for any possible experiments at least for now (until actual Jolla system recovery is added in a future update).
Why software changes can void hardware warranty? That was always puzzling to me. Can something actually break in the device from such thing?
rainisto
2013-12-13, 16:03
Why software changes can void hardware warranty? That was always puzzling to me. Can something actually break in the device from such thing?
Yes, you can for example compile kernel module that overclocks and fries the cpu.
Why software changes can void hardware warranty? That was always puzzling to me. Can something actually break in the device from such thing?
Yes
10 Chars
Requested and received. I've merged the Jolla kernel source release (kernel-adaptation-sbj-3.4.0.20131115.2) on top of tagged Qualcomm (Android) kernel release so that it's possible to view all Jolla specific changes. Only really major change I noticed in my first quick glance through it, was that they've backported btrfs (from linux-stable 3.5.7). Other than that, their changes are mostly hardware enablement related (display, touchscreen, camera, sensor, etc drivers). Stuff you'd see in any kernel source for any e.g. Android device. Vast majority of their (or their ODM's) changes are even commented (who, when, what) which is great compared to some other stuff I've seen. In general quite clean, though I (literally :P) see red when I see all those whitespaces.
I've pushed the source to my GitHub. Happy forking. :)
https://github.com/KonstaT/sailfishos_kernel_jolla_msm8930
I can write some instructions if someone is interested in building/booting custom kernels. It should be pretty basic stuff for anyone familiar with e.g. Android development (and the necessary tools are the same). From a brief chat I had with a Jolla engineer, flashing/booting a custom kernel image will result a permanent unlocked status (in bootloader?) and it will most likely void your warranty!
I apologize if I don't quite understand the full meaning of your post but if you are able to provide instructions for porting Sailfish to an android phone I'd be happy to try. I have a Galaxy Note 1 and 2 and am willing to try even though it is likely that such port will have its share of problems. Anyways as I live in the US, it is unlikely a Jolla phone will be available in the near future, so this would give me an opportunity to share in the "fun". Thanks!
Why software changes can void hardware warranty? That was always puzzling to me. Can something actually break in the device from such thing?
Yeah, overclocking the CPU is the common excuse given even though in the rare cases that something bad happens, it's the NAND that fries. In theory you could change voltage given to any hardware component on the device and quite easily break any of them. I don't think it's ever anyone's intention though. Mostly people just like to have full control of their devices and building a linux kernel (being open source) is essential part of that.
I apologize if I don't quite understand the full meaning of your post but if you are able to provide instructions for porting Sailfish to an android phone I'd be happy to try. I have a Galaxy Note 1 and 2 and am willing to try even though it is likely that such port will have its share of problems. Anyways as I live in the US, it is unlikely a Jolla phone will be available in the near future, so this would give me an opportunity to share in the "fun". Thanks!
Pretty sure I'm the wrong guy you're asking. :P Coming from Android development I have pretty much zero experience on Sailfish OS/Mer/Nemo/etc. I'm still looking into what it would take to port Sailfish OS to other Qualcomm hardware. There's certainly not too much documentation (or open sourced device configurations) on porting e.g Mer, which is where you'd most likely needed to start.
This kernel source is useful for Jolla device only. Jolla kernel being based on a regular Qualcomm Android kernel tells us though that the Android kernel you have for your device should already be just fine for porting Sailfish OS. There's probably some config options that you need to enable as Mer requirements, but any crazy driver porting shouldn't be necessary at least on the kernel side.
javispedro
2013-12-16, 16:41
Yes, you can for example compile kernel module that overclocks and fries the cpu.
This can be easily detected however -- via blown fuses. In fact, Qualcomm already blew a few ones after binning it that indicate the "max recommended speed" (aka castrate it).
javispedro
2013-12-19, 23:17
There may indeed never be a way to flash a Jolla device -- see https://twitter.com/JollaHQ/status/413594939415859200 and ensuing discussion.
Unless there's some news in this regard, even chmoding the wrong directory (http://jollafin.blogspot.com.es/2013/12/i-broken-my-jolla-to-unbootable-state.html) will get you a Eur400 paperweight.
Sigh.
javispedro: I don't really get why they can't offer something similar to Moslo method. On Nexus 7 you can write Moslo first with fastboot, then boot into it, and it exposes the internal storage partition, which you can mount on regular Linux, format as any filesystem you want and trivially copy the OS image there. What prevents such kind of scenario in Jolla's case?
Out of all manufacturers, Jolla are simply expected to be open for this.
javispedro
2013-12-20, 01:17
Out of all manufacturers, Jolla are simply expected to be open for this.
Since the Jolla device uses what Replicant calls the most open source unfriendly SoC (http://redmine.replicant.us/projects/replicant/wiki/TargetsEvaluation) (why???) I would not be surprised they really are prevented from offering flashable images by them.
We need a way to be able to flash to stock, I know after a month or two of tweaking the phone I'd need to flash clean.
javispedro: From that table it looks like Qualcomm is just "bad for freedom". It's a pity that their SoCs are becoming one of the most popular ones. May be next time Jolla should go with Intel already and get rid of all that ARM idiocy with no drivers and closed stuff.
May be next time Jolla should go with Intel already and get rid of all that ARM idiocy with no drivers and closed stuff.
Well, even Intel could be problematic in this regard - see for example the Paulsbo disaster (http://www.phoronix.com/scan.php?page=news_item&px=MTMyODA). On the other hand, their latest mobile systems fortunately seem to be using their own GPUs & open drivers. But I'm still not sure even the latest Intel mobile systems do the same things in the same power envelope as ARM based SOCs.
thedead1440
2013-12-20, 02:34
There may indeed never be a way to flash a Jolla device -- see https://twitter.com/JollaHQ/status/413594939415859200 and ensuing discussion.
Unless there's some news in this regard, even chmoding the wrong directory (http://jollafin.blogspot.com.es/2013/12/i-broken-my-jolla-to-unbootable-state.html) will get you a Eur400 paperweight.
Sigh.
I am just pleased I held off from pre ordering a device from a company that is truly open (TM). Even Android devices seem better than the myriad of nonsense one has to put up with Jolla and their dodging of important questions.
Not to mention the fanboys Jolla seems to have lingering around who defend the most indefensible things. At present, from rainisto's post, 2014 may see the release of flasher for developers (warranty void?) so another month(s) of waiting :)
/rant
I don't think Jolla folks are thrilled about using Qualcomm. But they chose it for some reason.
On the other hand, their latest mobile systems fortunately seem to be using their own GPUs & open drivers. But I'm still not sure even the latest Intel mobile systems do the same things in the same power envelope as ARM based SOCs.
Well, Intel is playing the catch up game for a long time already. At some point they need to really catch up. Would be interesting to see if some handsets with Merrifield are coming out next year. I suspect Intel is the only chance to get Sailfish in the future running on native drivers without libhybris hacks. Can't say about flashing aspects and so on though. Some more info about Merrifield is supposed to be published in February.
rainisto
2013-12-20, 05:38
We are working on solution where end user can reset their devices back to factory state, even if they have managed to get their devices filesystem in non bootable state (as long as btrfs works). That will most likely happen with custom recovery mode which will be installed at some coming update. More info will be available next year.
We are also investigating if we can offer real flashing solution without breaking device security, but for now the approach will most likely be to update recovery image which will allow resetting back to factory state (after querying devicelock code if that has been set).
ste-phan
2013-12-20, 08:02
So for the time being we are driving through the desert without a spare tire?
"real flashing solution without breaking device security"
-> Just curious would be the disadvantage of broken security on this level?
Testing the Jolla for 1 week was a good opportunity to flash my daily productivity phone to a clean and up to date state.
We are working on solution where end user can reset their devices back to factory state, even if they have managed to get their devices filesystem in non bootable state (as long as btrfs works). That will most likely happen with custom recovery mode which will be installed at some coming update. More info will be available next year.
We are also investigating if we can offer real flashing solution without breaking device security, but for now the approach will most likely be to update recovery image which will allow resetting back to factory state (after querying devicelock code if that has been set).
Thanks for the 'update' on this.
But, quite frankly, this is dissapointing news.
Initially this was expected to be a open device, based on the experience from Nokia and limitations.
Perhaps my Jolla will end up in my local museum for useless stuff.
Unless, of course, either Jolla comes up with a flashing solution and tools, factory images, including sources etc.
Or, I can use some less available Qualcomm tools to break this thing apart.
Just keeping this here for further hacking
http://forum.xda-developers.com/showthread.php?t=1856327
rainisto
2013-12-20, 09:19
So for the time being we are driving through the desert without a spare tire?
Yes currently the spare tire is the care centers flashing stations. But update is coming soon, which gives you factory spare tire.
"real flashing solution without breaking device security"
-> Just curious would be the disadvantage of broken security on
The thing which we protect is that if you have set devicelock code and someone steals your device, then he/she is not able to wipe it clean for selling it off by reflashing without knowning your lockcode.
rainisto
2013-12-20, 09:26
One vision would be to offer imei based certificate which would allow flashing your own devices that have been registered to your Jolla account. And that would most certainly be behind some warranty void submit button. But lets see what spring will bring us, upcoming rescue image should offer solution to recover from most of the basic booting problems.
javispedro
2013-12-20, 09:35
The thing which we protect is that if you have set devicelock code and someone steals your device, then he/she is not able to wipe it clean for selling it off by reflashing without knowning your lockcode.
To be honest, I think that Jolla needs to set its priorities straight. It is going to be so ironic (ironic at "head explodes" levels) if the company whose CEO encourages its users to install their OS on other devices (http://www.talouselama.fi/nakoislehti/jolla+ceo+you+will+soon+be+able+turn+your+android+ device+into+a+sailfish+device/a2218386) is going to close the bootloader because of "device security", "evil Qualcomm made me do it", or some other inane reason.
MR. JOLLA, TEAR DOWN THIS LOCKED BOOTLOADER!
The thing which we protect is that if you have set devicelock code and someone steals your device, then he/she is not able to wipe it clean for selling it off by reflashing without knowning your lockcode.
Honestly, if someone steals my phone I do not care much if that person is able to wipe and sell it, it's gone for me anyhow, it would not return just because the bootloader is locked, but would end up in a trashcan or sold in parts. Until thieves start to watch out specially for jollas there's still a long way to go...
The IMEI solution sounds nice, but a but complicated... is it possible that the user just sets a flag "allow free flashing y/n" and that it is disabled by default? I guess for many people here the risk of bricking is higher than the risk of theft.
rainisto
2013-12-20, 09:56
Honestly, if someone steals my phone I do not care much if that person is able to wipe and sell it, it's gone for me anyhow, it would not return just because the bootloader is locked, but would end up in a trashcan or sold in parts. Until thieves start to watch out specially for jollas there's still a long way to go...
The IMEI solution sounds nice, but a but complicated... is it possible that the user just sets a flag "allow free flashing y/n" and that it is disabled by default? I guess for many people here the risk of bricking is higher than the risk of theft.
Most likely software updates will also bring your remote security features where you can track and hopefully retrieve your stolen devices. And that lockcode prevention is part of that story.
Users beeing able to set a flag which would allow bootloader unlock would be one idea, not making any promises, but putting it in drawing board along with imei based solution.
PS. Oh and forgot to mention that locked bootloader+lockcode combination is also protecting your data, so if someone steals your phone with company secrets then he is not able to access them (but with factory reset & lockcode combination device can be still wiped). Some people like that their secrets remain secret, but yes, some people dont care if their nosy wife or husband can spy them by bypassing the lockcode with bootloader commands.
javispedro
2013-12-20, 10:23
Not even Apple with its überstrict bootloader disallows a "thief" from reflashing the device.
They'll even do it at the stores, for free, no questions asked. But for DIY guys, booting with "Home" button pressed will skip password, lock code, whatever and enter flashing mode.
EDIT:
PS. Oh and forgot to mention that locked bootloader+lockcode combination is also protecting your data, so if someone steals your phone with company secrets then he is not able to access them (but with factory reset & lockcode combination device can be still wiped). Some people like that their secrets remain secret, but yes, some people dont care if their nosy wife or husband can spy them by bypassing the lockcode with bootloader commands.
Oh well. I can see the point there, though. Still, I think it is beyond doubt that a device should be reflasheable whether it has lock code or not.
Most likely software updates will also bring your remote security features where you can track and hopefully retrieve your stolen devices. And that lockcode prevention is part of that story.
Users beeing able to set a flag which would allow bootloader unlock would be one idea, not making any promises, but putting it in drawing board along with imei based solution.
PS. Oh and forgot to mention that locked bootloader+lockcode combination is also protecting your data, so if someone steals your phone with company secrets then he is not able to access them (but with factory reset & lockcode combination device can be still wiped). Some people like that their secrets remain secret, but yes, some people dont care if their nosy wife or husband can spy them by bypassing the lockcode with bootloader commands.
Thank you for your answer, those are very valid points. However I think security measures should be optional so the user can decide what's valued more. Regarding data protecting, I'm using dm-crypt on my laptop for exactly the reasons you mentioned (minus nosy && linux-skilled partner :D), I feel however not too much reassured by a lock code & locked bootloader. At least jolla care can flash it and access my data, and so probably someone else at some point. Maybe the performance hit is too big atm for encryption on a mobile without hardware aes support, that's for example a thing I'd like to test at some point - but not if I'm risking to brick the device permanently. So a locked bootloader potentially may lower device security for me.
Fuzzillogic
2013-12-20, 12:51
We are working on solution where end user can reset their devices back to factory state, even if they have managed to get their devices filesystem in non bootable state (as long as btrfs works). That will most likely happen with custom recovery mode which will be installed at some coming update. More info will be available next year.
I am unpleasantly surprised by this. With all the "open" claims, I did expect an open bootloader. Now I'm again at the mercy of a company on which OS my device runs.
We are also investigating if we can offer real flashing solution without breaking device security, but for now the approach will most likely be to update recovery image which will allow resetting back to factory state (after querying devicelock code if that has been set).
So, it's up to the pc-side software whether your jolla's data can be read? How would that provide any security?
I would expect full storage encryption for any new OS these days. Linux has support for it for a long time. And I'd rather have something quirky, like Aegis, than nothing.
rainisto
2013-12-20, 13:05
So, it's up to the pc-side software whether your jolla's data can be read? How would that provide any security?
That would not provide any security, so its not up to the pc-side software. And thats also going off topic from this thread. I'll just stop commenting on security details all together, so people can focus on how they can possible recover from possible bricks and if they will be able to unlock their bootloaders at some point.
ste-phan
2013-12-20, 13:50
The thing which we protect is that if you have set devicelock code and someone steals your device, then he/she is not able to wipe it clean for selling it off by reflashing without knowning your lockcode.
Thanks for the information but no need.
If somebody is able to steal my phone, I hope he can wipe it , sell it and some service is able to track it down by IMEI number.
If not -and most likely- at least it doesn't need to be recycled , having my "personal little vengeance" on the thief become a burden on the environment.
Features I do expect.
-Full firmware flashing:
-Thief having to whipe my personal data if I had entered a security code.
I have no further expectations.
If someone gets a physical access to your device - you are already in a serious trouble. It's too late - the device is compromised and no locked bootloader will prevent nasty things. Same goes about desktop computers too. So this is hardly justifiable and always looks more like power grab than any real security reasons. In Jolla's case it's highly surprising. Having an open enough device was expected. Surely if some encryption is used it should be explicitly controlled by the user who sets it up (setting your own keys etc.). Otherwise this is completely not true:
Will you support DRM
No.
https://sailfishos.org/wiki/QA
djselbeck
2013-12-20, 16:23
Until Jolla opens up the bootloader I halt all my support for this closed platform.
No more updates on SMPC MPD Client and development stop of my MTB bicycle tracking application.
At this point if I support android, I support an more open platform.
Very sad that my device now just lays around and I cannot play with it over chistmas holidays
rainisto
2013-12-20, 17:10
Otherwise this is completely not true:
Will you support DRM
No.
In mobile world there are only 2 DRM solutions widely adopted and they are: Microsoft PlayReady and Google Widevine. Jolla does not support neither of those currently -> So _NO_, there is no support for neither of the Digital Rights Management frameworks in the device currently.
If you think that DRM-term in mobile devices means something else then you have been eating wrong kind of mushrooms. All media files in device are unprotected and there is no Digital Rights Management frameworks device to protect media companies interest (well there are unix filesystem groups, but with developer mode its does not protect against malicious user). That is the current state of course if some media company makes native client for their media files, they might deploy their own DRM solution for example into TOH.
Stskeeps
2013-12-20, 17:40
Okay, so, guys - here's the exact situation, with a large amount of gory technical details so you can understand what's going on too.
* Philosophy wise, we're into user privacy - protecting your private data against attackers, physical or applications - ie, not DRM (other people's rights..). When you've set a lock code, we try to protect your data as well as we can.
A way to see this is that I really wouldn't want my private conversations to be easily extractable because I put my phone into a malicious USB charger or a competitor stole my phone off the table in Amsterdam in Ruoholahti while I was getting a drink.
* The bootloader of the Jolla is 'little kernel' ("lk (https://www.codeaurora.org/cgit/quic/la/kernel/lk/)") which speaks the typical Android fastboot protocol, which has a open source flasher (https://github.com/android/platform_system_core/blob/master/fastboot/fastboot.c).
* There's three modes of booting:
- Normal booting - boot into 'boot' partition, which is a combined kernel + initrd + cmdline image (https://android.googlesource.com/platform/system/core/+/android-4.3_r3.1/mkbootimg/mkbootimg.c)
- Recovery booting (volume down + power on) - doesn't do anything at the moment as there's nothing in recovery but boots into 'recovery' partition (same format as boot)
- Fastboot mode (volume down + put USB in) - opens a fastboot session on USB that you can connect to with fastboot flasher (http://wiki.cyanogenmod.org/w/Doc:_fastboot_intro)
There's a few toggles in the device currently:
* Developer mode - which gives you full root on your device and it says, please note this: "this may void your warranty" - it does not say "this will void your warranty". The philosophy there is that if you break something with it, you get to keep both pieces - don't do anything stupid - like overwrite the boot loader, or use hardware parts beyond their specifications.
- It is possible to flash kernel, recovery, etc from within device as we do this in OTA updates. If you really have to hack, do it with recovery partition until the below is in place.
* OEM unlock - which determines if bootloader is open or not - no special code is required to unlock - just fastboot oem unlock, but the power comes with responsibility - and I'm not in any way as an employee recommending this.
Now - one of the things about breaking things is that you can glue things together and it's all good again - About recovery:
At an upcoming update (I cannot say which, because, until a feature is released, it can at any point be pulled and postponed), there will be a recovery partition installed that will 1) ask for your device lock code if you have one and 2) allow you to factory reset your device in case you've hacked it a bit too much ("unbootable brick" situation)
That recovery I'd like to improve in such a way that it enables users to do full system backup/restore from microSD and other useful bits that we've learnt from maemo times is just generally nice to have (BackupMenu, BootMenu, etc).
Now, about factory images.
The Jolla device has all it's system data on a eMMC, one big SD card practically. This is shared with the modem part and includes things like modem firmware and other bits (take a look at the 25+ GPT partitions!). The device factory image is a combination of SailfishOS, a Qualcomm Android hardware adaptation and modem bits. The hardware adaptation and modem bits are copyrighted by Qualcomm and are put in place by the factory partner - and Jolla cannot distribute those parts.
Due to a bit of a design flaw on my behalf that I hope to solve for future devices, our entire system is merged together in one big 'sailfish' BTRFS volume which makes it even harder to separate bad bits and 'good bits' and 'flash them seperately'
In practice, what this means, is that we cannot provide full factory images. And that sucks. But if we do a proper recovery, backup and restore possibilities, it takes care of a lot of the trouble.
I don't personally buy devices that can't be hacked. We started developing Sailfish on hackable devices - we know our roots. And I have one coming to me at full price - no rebates or special treatment.
Does this clear up the situation a bit? Device is open as is explained above, but, when you hack, you'll always want to be able to restore your device. And that's what I hope the recovery will sort out unless you really screw up the device. In which case it's your own fault.
djselbeck
2013-12-20, 17:47
Yes thats clears thing out quite nicely and I'm even more disappointed.
In fact I know now that I spend 400 bucks on a device which is hardly useable as an development unit for fun hacking. No factory images is a nogo for me and I'm evaluating right now if I won't sell the whole thing on ebay after christmas.
Perhaps you should've disclosed this information earlier. I'm really disappointed now and feel a bit ripped of because I asked this question several times and haven't got an answer until now.
But I think the 400 bucks from customers looked so nice you wouldn't bother telling the whole truth. :mad::mad::mad:
Stskeeps
2013-12-20, 17:50
Yes thats clears thing out quite nicely and I'm even more disappointed.
In fact I know now that I spend 400 bucks on a device which is hardly useable as an development unit for fun hacking. No factory images is a nogo for me and I'm evaluating right now if I won't sell the whole thing on ebay after christmas.
There's nothing whatsoever stopping you from writing the whole 'sailfish', 'boot', 'recovery' and other GPT partitions onto microSD and making a recovery image that'll restore those from a microSD card onto the main eMMC. Classic device hacking.
djselbeck
2013-12-20, 17:52
I've already backed most of them up, but at the moment I cannot back up a running/changing volume like / , can I?
Stskeeps
2013-12-20, 17:59
I've already backed most of them up, but at the moment I cannot back up a running/changing volume like / , can I?
Fair, the way I typically do it is to write a recovery with a kernel with initrd with USB networking up, telnetd -l /bin/sh, back up from there, restore from there too.
Nothing is in recovery atm anyway.
All this is hacking advice and my personal opinion.
djselbeck
2013-12-20, 18:03
Alright, I give it a try over the next days. So just to be clear and not waste 400 bucks ;) fastboot oem unlock; fastboot flash recovery somerecovery.img won't do any harm?
rainisto: DRM means any kind of taking away control from the user by means of obscurity, closed encryption and so on. Locked / encrypted bootloader with no way to set your own keys or unlock it is a perfect example of DRM. That's the way I understand the term. Preventing copying media files is just one example of it.
Protecting data and security with encryption is perfectly fine, as far as the user is in control of that protection. If user isn't - that's already DRM.
Stskeeps
2013-12-20, 18:10
Alright, I give it a try over the next days. So just to be clear and not waste 400 bucks ;) fastboot oem unlock; fastboot flash recovery somerecovery.img won't do any harm?
Avoid oem unlock if possible. Stick to developer mode/root capabilities, should be enough.
djselbeck
2013-12-20, 18:13
Ok, and without unlock I can boot custom recovery?
Stskeeps
2013-12-20, 18:14
Ok, and without unlock I can boot custom recovery?
AFAIK - if it doesn't work, lemme know.
djselbeck
2013-12-20, 18:19
Thanks for your help, this was very supporting. I will see what I can do :). If I can create my own recovery images I would be perfectly pleased
djselbeck: If you succeed in figuring out exact steps how to back up and restore various partitions, can you please summarize them somewhere on the Mer wiki?
djselbeck
2013-12-20, 18:21
Of course ;) but no timeframe.
Here probably is a good place: https://wiki.merproject.org/wiki/Sailfish#Jolla
djselbeck
2013-12-20, 19:18
AFAIK - if it doesn't work, lemme know.
Hello,
I tried flashing my custom recovery but failed:
fastboot -i 0x2931 flash recovery recovery.img
sending 'recovery' (5964 KB)...
OKAY [ 0.375s]
writing 'recovery'...
FAILED (remote: access denied. need privilege!)
finished. total time: 0.379s
rainisto
2013-12-20, 19:22
Hello,
I tried flashing my custom recovery but failed:
fastboot -i 0x2931 flash recovery recovery.img
sending 'recovery' (5964 KB)...
OKAY [ 0.375s]
writing 'recovery'...
FAILED (remote: access denied. need privilege!)
finished. total time: 0.379s
Maybe you didn't understand when Stskeeps said that stay with developer mode and root.
Did you try as root to run: "dd if=recovery.img of=/dev/disk/by-partlabel/recovery" while beeing logged inside Jolla phone shell?
djselbeck
2013-12-20, 19:25
my mistake, sorry
I try this
Okay, so, guys - here's the exact situation, with a large amount of gory technical details so you can understand what's going on too.
* Philosophy wise, we're into user privacy - protecting your private data against attackers, physical or applications - ie, not DRM (other people's rights..). When you've set a lock code, we try to protect your data as well as we can.
A way to see this is that I really wouldn't want my private conversations to be easily extractable because I put my phone into a malicious USB charger or a competitor stole my phone off the table in Amsterdam in Ruoholahti while I was getting a drink.
* The bootloader of the Jolla is 'little kernel' ("lk (https://www.codeaurora.org/cgit/quic/la/kernel/lk/)") which speaks the typical Android fastboot protocol, which has a open source flasher (https://github.com/android/platform_system_core/blob/master/fastboot/fastboot.c).
* There's three modes of booting:
- Normal booting - boot into 'boot' partition, which is a combined kernel + initrd + cmdline image (https://android.googlesource.com/platform/system/core/+/android-4.3_r3.1/mkbootimg/mkbootimg.c)
- Recovery booting (volume down + power on) - doesn't do anything at the moment as there's nothing in recovery but boots into 'recovery' partition (same format as boot)
- Fastboot mode (volume down + put USB in) - opens a fastboot session on USB that you can connect to with fastboot flasher (http://wiki.cyanogenmod.org/w/Doc:_fastboot_intro)
There's a few toggles in the device currently:
* Developer mode - which gives you full root on your device and it says, please note this: "this may void your warranty" - it does not say "this will void your warranty". The philosophy there is that if you break something with it, you get to keep both pieces - don't do anything stupid - like overwrite the boot loader, or use hardware parts beyond their specifications.
- It is possible to flash kernel, recovery, etc from within device as we do this in OTA updates. If you really have to hack, do it with recovery partition until the below is in place.
* OEM unlock - which determines if bootloader is open or not - no special code is required to unlock - just fastboot oem unlock, but the power comes with responsibility - and I'm not in any way as an employee recommending this.
Now - one of the things about breaking things is that you can glue things together and it's all good again - About recovery:
At an upcoming update (I cannot say which, because, until a feature is released, it can at any point be pulled and postponed), there will be a recovery partition installed that will 1) ask for your device lock code if you have one and 2) allow you to factory reset your device in case you've hacked it a bit too much ("unbootable brick" situation)
That recovery I'd like to improve in such a way that it enables users to do full system backup/restore from microSD and other useful bits that we've learnt from maemo times is just generally nice to have (BackupMenu, BootMenu, etc).
Now, about factory images.
The Jolla device has all it's system data on a eMMC, one big SD card practically. This is shared with the modem part and includes things like modem firmware and other bits (take a look at the 25+ GPT partitions!). The device factory image is a combination of SailfishOS, a Qualcomm Android hardware adaptation and modem bits. The hardware adaptation and modem bits are copyrighted by Qualcomm and are put in place by the factory partner - and Jolla cannot distribute those parts.
Due to a bit of a design flaw on my behalf that I hope to solve for future devices, our entire system is merged together in one big 'sailfish' BTRFS volume which makes it even harder to separate bad bits and 'good bits' and 'flash them seperately'
In practice, what this means, is that we cannot provide full factory images. And that sucks. But if we do a proper recovery, backup and restore possibilities, it takes care of a lot of the trouble.
I don't personally buy devices that can't be hacked. We started developing Sailfish on hackable devices - we know our roots. And I have one coming to me at full price - no rebates or special treatment.
Does this clear up the situation a bit? Device is open as is explained above, but, when you hack, you'll always want to be able to restore your device. And that's what I hope the recovery will sort out unless you really screw up the device. In which case it's your own fault.
;) working on it
Fuzzillogic
2013-12-20, 20:00
Thanks for the info. Exactly the kind of explanation which is needed, imo.
Some questions rise:
There's no possibility the problem of the too intertwined volumes can be solved by a software update?
How about the possibility for the end-user to create a back-up of the flash, which he then can use later to restore his otherwise FUBARred device?
Isn't it kinda ignorant of qualcomm not to allow distribution of those blobs, since every Jolla owner already has access to them on device?..
Edit: I missed part of the thread. Apparently Q2 is already answered, with a "yes, you can". That's good to know. Would be nice if the process could be automated a bit, and/or have a somewhat more n00b-friendly manual.
Kaacz: DRM is DRM. I didn't mix anything, see explanation above. For example "secure" boot in UEFI without a way to use your own keys or to disable it is DRM. Don't mix security with taking away control and choice from the user.
Isn't it kinda ignorant of qualcomm not to allow distribution of those blobs, since every Jolla owner already has access to them on device?..
Qualcomm aren't new to stupidity and nasty vendor behavior (for example this (https://datatracker.ietf.org/ipr/1520/)). So I wouldn't ask any questions on common sense and decency there.
shmerl: Sorry, i missed some of your comments and then i missed your PoV .. now i understand to you... :)
djselbeck
2013-12-20, 21:19
I've successfully booted my own compiled kernel right now. But at the moment I've some problems with initrd but should figure it out sooner or later
I've successfully booted my own compiled kernel right now. But at the moment I've some problems with initrd but should figure it out sooner or later
This should be how to create a boot.img.
https://github.com/KonstaT/sailfishos_kernel_jolla_msm8930/blob/master/scripts/create-boot-img.sh#L17
Looks like there's only a dummy ramdisk inside boot.img. Have you btw dumped the original boot partition from the device? Or at least could someone upload the kernel config (/proc/config.gz) from an actual device? It should be quite close to boston_mer_defconfig (https://github.com/KonstaT/sailfishos_kernel_jolla_msm8930/blob/master/arch/arm/configs/boston_mer_defconfig) but still not exactly.
According to this, there's also a tool for flashing partitions in the system.
https://github.com/KonstaT/sailfishos_kernel_jolla_msm8930/blob/master/scripts/flash-bootimg-sbj.sh
Edit. Oh wow, my posts are moderated before publishing for some reason. This message appearead here several days (~week?) later. Seriously, wtf?! If I've done something to deserve a post ban - then just issue one, but this is just ridiculous.
djselbeck
2013-12-20, 22:52
It is working now. I'm preparing an easy guide with an image.
As I'm typing this, I'm backing up my mmcblk0p* partitions.
The best thing, you don't even have to modify your recovery partition :)
I've written the guide here: https://wiki.merproject.org/wiki/Sailfish/Backup_Device#Using_prebuilt_image
As you can see I'm really not good at this kind of stuff. If some one with some skill in mediawiki wants to improve feel free. For questions use this thread or write me a pm.
Please be careful, I won't take any responsibility for your actions. This guide is for users who know what they are doing
Golden-Boy
2013-12-21, 08:17
Maybe you didn't understand when Stskeeps said that stay with developer mode and root.
Did you try as root to run: "dd if=recovery.img of=/dev/disk/by-partlabel/recovery" while beeing logged inside Jolla phone shell?
Hello rainisto
I am trying to contact you but do not have private message privileges on this forum for some reason. Can you please email me?
allegation at gmail.com
Thank you.
Thank you very much for the instructions. I was able to boot your image. I also added some missing details I discovered on the way to the Wiki.
For a real fastboot recovery image, I would appreciate support for ssh and also NFS. Then we could copy the files directly to the host instead of going through the SD card.
javispedro
2013-12-21, 22:17
I was able to dualboot mine, too.
Actually I booted the stock kernel but with a different rootfs, you do not need to do any changes to the kernel configuration since you can override the command line when mkbootimg'ing.
The stock kernel image, cmdline and initramfs are stored in /boot/boot.img (this is in mkbootimg format). There are several (Android) programs around to "unmkbootimg" this and get the raw kernel images et all. Also, the format is simple enough to decode manually. The stock kernel cmdline, stored in this file, is:
init=/sbin/preinit root=/dev/mmcblk0p28 rootfstype=btrfs rootflags=recovery noinitrd androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 maxcpus=2
(Presumably should match what you get on a live SbJ's /proc/cmdline)
Some comments to the wiki page https://wiki.merproject.org/wiki/index.php?title=Sailfish/Backup_Device that may be interesting if creating your own bootimgs:
You do not really need to edit CONFIG_CMDLINE or set CONFIG_CMDLINE_FORCE. Passing a valid cmdline (via --cmdline 'init=/linuxrc ...') to mkbootimg is enough and this is the way the builtin kernel does this. However, this is mostly personal preference.
You can use standard Linux tools to build the initramfs such as "cpio -H newc". It can be gzipped.
You do need to set the same offsets the stock boot.img uses to mkbootimg, i.e. ensure you pass the following to mkbootimg (along with kernel and ramdisk options): --base 0x00000000 --pagesize 2048 --kernel_offset 0x80208000 --ramdisk_offset 0x82200000 --second_offset 0x81100000 --tags_offset 0x80200100 --board '' " Otherwise you'll get instant reboot.
EDIT: I've now changed the above wiki page (section "Build your own image"). Waiting for feedback if you're trying to build your own images!
djselbeck
2013-12-22, 11:01
Hello,
I've tried building the bootimage with an extra ramdisk but so far only got instant reboot, so I decided to include it directly into the kernel.
Did you actually had success including a ramdisk with mkbootimg?
I think you need to specify an offset to the kernel, which declares the location of the image. Something like
initrd=0x02200000 but I had no time so far trying that out.
My first priority was to provide an fast solution to backup your device ;). Now I have some time and will look into it and include an ssh server for example.
Edit: Ramdisk inclusion with boot.img worked. I've no idea why it did'nt last time I tried. Perhaps because it was already very late and I'm tired ;) So this is clearly the preferred method over init inclusion in kernel image.
I think it would be interesting to know whether these partitions are actually the same for all devices or if they contain anything specific for each phone. So here are SHA1 checksums of my backups.
$ sha1sum mmcblk0p{1..27}.img
edd6071d386ed1d60a541a06e0eb081c381296b7 mmcblk0p1.img
ccb9f2c0184df67deff69df328a78d04ab0fd805 mmcblk0p2.img
a07548e01946ba3490d8d0898a7f2027890f2021 mmcblk0p3.img
41e2c4bbe9433b14dfa4c95b99e09245faf0c8e7 mmcblk0p4.img
31ebbbadb5686cf54d4f3760f7f39d007e87e501 mmcblk0p5.img
e904aa58289574f74753fa5a810551676ccdaefe mmcblk0p6.img
32507ad14ccec38defa20fa9261d9b612b6e39f9 mmcblk0p7.img
cfdf75b00346c48c7afd80647003f41e1d9fce0f mmcblk0p8.img
0b7620536530c70d3b7f7fca794a11b3ee3b560c mmcblk0p9.img
aff661e1c1b4b0bea1d71c6d6bc0ec67c4842d61 mmcblk0p10.img
4277b8ef0cd6e0e094b5d266a455555d56881c79 mmcblk0p11.img
e5da449e911e5109c07bd5790bba98b8e177e07d mmcblk0p12.img
ab7066450ff20db47b84a4c04d17234f1a2ee41e mmcblk0p13.img
4a2678e8344d53fea59bd884c5059808eff6c215 mmcblk0p14.img
9cb3b5879a41ec2807bcd348d7272b2c5810853b mmcblk0p15.img
16b918c87b4c88caaaf4141a8e9ffa07e2619f42 mmcblk0p16.img
edb50610c434463c34d454a45cb8ce60d19cbd7b mmcblk0p17.img
f6d80fcc3f4b0d6601c54d507e57a29a852628c1 mmcblk0p18.img
3fdbe058350c93e3f76c038f57165abb7f32f10f mmcblk0p19.img
cbc76425d05c9725640ce16246316babf0c68212 mmcblk0p20.img
e965227e6200655f4fbde5e74df13f2e10c3bbbe mmcblk0p21.img
5fde1cce603e6566d20da811c9c8bcccb044d4ae mmcblk0p22.img
5fde1cce603e6566d20da811c9c8bcccb044d4ae mmcblk0p23.img
4298f4bad2bae957adf2fe4034e82fdc85f40f77 mmcblk0p24.img
f9f05976f9056069c08c5dfca34c20f0ef69a4dd mmcblk0p25.img
03e6fb7a7034b064a876da4d0c8c88373849f0b5 mmcblk0p26.img
723302098b1e619e83bd6726096e15fcd6bd8402 mmcblk0p27.img
I left out partition 28, the root filesystem, because everyone has definitely made their own changes on that already.
Please let me know if yours differ from mine above.
djselbeck
2013-12-22, 14:35
Yep, actually a lot differ:
fd13511082820e36c0cada61862457152bc8483c mmcblk0p1
9fe01a1d7b38c861a80a5d4d9b583c3b83c35efc mmcblk0p2
f7f47d862fb74e4f955c0746f13e2ee585a02763 mmcblk0p3
e3d31adfd70df23fc32f464a5a60f34e59996e40 mmcblk0p4
82b5c51a77de9d7e10daae5eb8095d760dc5739e mmcblk0p5
e904aa58289574f74753fa5a810551676ccdaefe mmcblk0p6
32507ad14ccec38defa20fa9261d9b612b6e39f9 mmcblk0p7
0a2d9e671eb8d04994e76d31456262f12130304b mmcblk0p8
1a54de676c5131972d85a43e8c741805e0d40f37 mmcblk0p9
458b24477074c08ca267c1f7d0f7352373a7b5b7 mmcblk0p10
64accf1c268db9329c53641417c132cc45d5b343 mmcblk0p11
e5da449e911e5109c07bd5790bba98b8e177e07d mmcblk0p12
ab7066450ff20db47b84a4c04d17234f1a2ee41e mmcblk0p13
4a2678e8344d53fea59bd884c5059808eff6c215 mmcblk0p14
9cb3b5879a41ec2807bcd348d7272b2c5810853b mmcblk0p15
16b918c87b4c88caaaf4141a8e9ffa07e2619f42 mmcblk0p16
edb50610c434463c34d454a45cb8ce60d19cbd7b mmcblk0p17
f6d80fcc3f4b0d6601c54d507e57a29a852628c1 mmcblk0p18
342de6a26abfe7e09545f73d6aeba44d3e04cc53 mmcblk0p19
cbc76425d05c9725640ce16246316babf0c68212 mmcblk0p20
3ad9c7b30a8843f7bb40529f5ba648d821485599 mmcblk0p21
5fde1cce603e6566d20da811c9c8bcccb044d4ae mmcblk0p22
5fde1cce603e6566d20da811c9c8bcccb044d4ae mmcblk0p23
04d6bd9172e1885430fb533d6caf089a322df5c6 mmcblk0p24
c196035601266d43bf8dcb7f3d4add13fe58af99 mmcblk0p25
03e6fb7a7034b064a876da4d0c8c88373849f0b5 mmcblk0p26
f2434a34119e15865d101a350ae0da24216c4448 mmcblk0p27
So dissapointed with the wireless support (no monitor mode/injection)
Does anyone have a clue to which card is in the device ?
[nemo@localhost ~]$ sudo iw list
Wiphy phy0
Band 1:
Capabilities: 0x9030
HT20
Static SM Power Save
RX Greenfield
RX HT20 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
L-SIG TXOP protection
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7
Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (30.0 dBm)
* 2472 MHz [13] (30.0 dBm)
* 2484 MHz [14] (30.0 dBm)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps
* 5.5 Mbps
* 11.0 Mbps
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 9
max scan IEs length: 200 bytes
Coverage class: 0 (up to 0m)
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
* WPI-SMS4 (00-14-72:1)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
software interface modes (can always be added):
interface combinations are not supported
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* set_bss
* join_ibss
* set_pmksa
* del_pmksa
* flush_pmksa
* remain_on_channel
* action
* frame_wait_cancel
* set_channel
* connect
* disconnect
Supported TX frame types:
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
Device supports roaming.
djselbeck
2013-12-22, 14:57
I think it is some kind of Qualcomm Prima WCNSS module
I think it is some kind of Qualcomm Prima WCNSS module
kinda thought so, but
sudo dmesg | grep wcnss
doesnt reveal any outcome
and lsmod
[nemo@localhost ~]$ sudo lsmod
Module Size Used by
mysatroker 57477 2
wlan 2592759 0
cfg80211 144263 1 wlan
I upgraded, I guess thus two modules directories
/lib/modules/3.4.0.20131115.2/kernel/net/wireless
is empty
/lib/modules/3.4.0.20131118.1/kernel/net/wireless
contains cfg80211.ko and wlan.ko
javispedro
2013-12-22, 15:52
Did you actually had success including a ramdisk with mkbootimg?
Yes, the default offset is OK. Actually I should try which one of the "offsets" is actually mandatory, because them being mandatory makes no sense (but nothing on Android does, tbh).
Also, enabling NFS client is easy enough: just copy nfs.ko from rootfs (or enable as builtin if building your own kernel). Busybox's default mount is enough to connect to NFS as long as you pass -o nolock to disable dependency on localhost lockd/portmapper.
/lib/modules/3.4.0.20131118.1/kernel/net/wireless
contains cfg80211.ko and wlan.ko
Seems like tis may be similar to this other, freely licensed module (https://android.googlesource.com/kernel/msm.git/+/07d8c920a234e0d0a6ea2b0cbb63b605b1569190/drivers/staging/prima/CORE/HDD/src). Maybe you should open a new thread and try to figure out how to make that module work.
BTW. Another disappointment is that the stock kernel is tainted propietary by this module.
djselbeck
2013-12-22, 16:06
Yes, the default offset is OK. Actually I should try which one of the "offsets" is actually mandatory, because them being mandatory makes no sense (but nothing on Android does, tbh).
Also, enabling NFS client is easy enough: just copy nfs.ko from rootfs (or enable as builtin if building your own kernel). Busybox's default mount is enough to connect to NFS as long as you pass -o nolock to disable dependency on localhost lockd/portmapper.
Seems like tis may be similar to this other, freely licensed module (https://android.googlesource.com/kernel/msm.git/+/07d8c920a234e0d0a6ea2b0cbb63b605b1569190/drivers/staging/prima/CORE/HDD/src). Maybe you should open a new thread and try to figure out how to make that module work.
BTW. Another disappointment is that the stock kernel is tainted propietary by this module.
Yes thats right. Im trying to build prima module.
EDIT: I've build a version of prima wlan driver which seems to work which is good news I think. Needs to clean it all a bit up though.
Yes thats right. Im trying to build prima module.
EDIT: I've build a version of prima wlan driver which seems to work which is good news I think. Needs to clean it all a bit up though.
Good news indeed.
Did you check if monitor mode is working with your port?
djselbeck
2013-12-23, 09:51
Good news indeed.
Did you check if monitor mode is working with your port?
Does not seems so:
iw list
Wiphy phy0
Band 1:
Capabilities: 0x9030
HT20
Static SM Power Save
RX Greenfield
RX HT20 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
L-SIG TXOP protection
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps
* 5.5 Mbps
* 11.0 Mbps
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Capabilities: 0x9072
HT20/HT40
Static SM Power Save
RX Greenfield
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 3839 bytes
DSSS/CCK HT40
L-SIG TXOP protection
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7
Frequencies:
* 4920 MHz [-16] (disabled)
* 4940 MHz [-12] (disabled)
* 4960 MHz [-8] (disabled)
* 4980 MHz [-4] (disabled)
* 5040 MHz [8] (disabled)
* 5060 MHz [12] (disabled)
* 5080 MHz [16] (disabled)
* 5180 MHz [36] (disabled)
* 5200 MHz [40] (disabled)
* 5220 MHz [44] (disabled)
* 5240 MHz [48] (disabled)
* 5260 MHz [52] (disabled)
* 5280 MHz [56] (disabled)
* 5300 MHz [60] (disabled)
* 5320 MHz [64] (disabled)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 9
max scan IEs length: 255 bytes
Coverage class: 0 (up to 0m)
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP (00-0f-ac:4)
* WPI-SMS4 (00-14-72:1)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
software interface modes (can always be added):
valid interface combinations:
* #{ managed } <= 3, #{ AP } <= 1, #{ P2P-client, P2P-GO } <= 1,
total <= 3, #channels <= 2
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* set_bss
* join_ibss
* set_pmksa
* del_pmksa
* flush_pmksa
* remain_on_channel
* action
* frame_wait_cancel
* set_channel
* Unknown command (82)
* Unknown command (81)
* Unknown command (75)
* connect
* disconnect
Supported TX frame types:
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
Device supports roaming
Another problem is that alien dalvik VM seems to need some kernel support. With opensource version it goes nuts with "alien_init" because it cannot open /dev/mysatrokerServer. And crashes and reloads all the time :(.
Looks like the mysatroker module is missing:
filename: /lib/modules/3.4.0.20131118.1/kernel/mysatroker.ko
license: Proprietary.Copyright 2012-2013 Myriad Group AG. All Rights Reserved.
author: Myriad Group AG
description: MYriad Share Anything TROugh KERnel
depends:
vermagic: 3.4.0.20131118.1 SMP preempt mod_unload modversions ARMv7
The description alone gives me goose bumps as an engineer :/
@djselbeck
Well, the mysatroker module seems to be some myriad implementation of /dev/binder. Yet another propriatrairy implementation :(
(http://talk.maemo.org/showpost.php?p=1395396&postcount=718)
As for the wireless driver.
Wow, there are at least some points interresting there:
HT TX/RX MCS rate indexes supported: 0-7
Frequencies:
* 4920 MHz [-16] (disabled)
* 4940 MHz [-12] (disabled)
* 4960 MHz [-8] (disabled)
* 4980 MHz [-4] (disabled)
* 5040 MHz [8] (disabled)
* 5060 MHz [12] (disabled)
* 5080 MHz [16] (disabled)
* 5180 MHz [36] (disabled)
* 5200 MHz [40] (disabled)
* 5220 MHz [44] (disabled)
* 5240 MHz [48] (disabled)
* 5260 MHz [52] (disabled)
* 5280 MHz [56] (disabled)
* 5300 MHz [60] (disabled)
* 5320 MHz [64] (disabled)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
As well as a couple of unidentified function calls:
* Unknown command (82)
* Unknown command (81)
* Unknown command (75)
I call this improvement - despite that Myriad c.....
djselbeck
2013-12-23, 10:50
I doubt that the 5GHz channels can be activated.
But nevertheless it is good to have an own kernel running.
Hope an open whatsapp will be ported soon, so I can remove the alien piece of junk.
djselbeck
2013-12-24, 11:05
Hello again,
I've uploaded the updated kernel sources with integrated prima wlan driver. If someone wants to try it you should know that it currently doesn't read the correct MAC adress and generates an automatic one.
https://github.com/djselbeck/sailfishos_kernel_jolla_msm8930
Also you can prevent alien_init from going crazy if you replace
/opt/alien/system/genv/bin/{mysatroker_ressource_manager_server,mysatroker_au dio_server} with following bash script
#!/bin/bash
echo "DUMMY"
while :
do
sleep 3600
done
You loose audio support with that but at least you can use whatsapp with own kernel. PLEASE BACKUP YOUR OLD BINARIES
ggabriel
2013-12-25, 18:30
I've written the guide here: https://wiki.merproject.org/wiki/Sailfish/Backup_Device#Using_prebuilt_image
Thans for this, I've just backed up my Jolla just in case :-)
Question: is there any point in dd'ing (backig up) the beginning of the eMMC? I'm unsure as to whether there is anything useful there.
javispedro
2013-12-26, 17:19
Thans for this, I've just backed up my Jolla just in case :-)
Question: is there any point in dd'ing (backig up) the beginning of the eMMC? I'm unsure as to whether there is anything useful there.
Yes, the GPT . You may even just dd the entire mmc. I do not see any benefits on having backups on the individual partitions.
rainisto
2013-12-26, 21:59
Yes, the GPT . You may even just dd the entire mmc. I do not see any benefits on having backups on the individual partitions.
Benefit for seperate partition backup is that atleast one partition is read-only, so you will get write errors if you try to restore entire mmc.
javispedro
2013-12-26, 23:38
Benefit for seperate partition backup is that atleast one partition is read-only, so you will get write errors if you try to restore entire mmc.
So you can overwrite the GPT header, thereby bricking the device, but not one partition? :P
And in any case, it is trivial to skip write errors when restoring, as it is to extract individual partitions from a full eMMC image.
Less trivial (and possibly impossible) is to combine different partition images into a single image, because, among other things, you are now missing everything that wasn't within partition limits. Which I would say normally would not be a problem, as there should be no important data there, except when ...... manufacturers do weird things, like the above.
From the recent update to Sailfish, I think this package is intererresting:
flash-partition-0.2.9-10.12.1.jolla.armv7hl Tool for flashing platform images on device.
also
Interresting update to recovery mode
Recovery mode
If a factory reset cannot be performed or if the device has booting issues,
•Unplug USB cable and turn off device
•Press volume down and power on the device
•Plug in USB cable and using USB networking telnet to 192.168.2.15 or 10.42.66.66 and follow the instructionsFrom
https://together.jolla.com/question/3612/release-notes-software-update-2-1025/
djselbeck
2013-12-27, 19:48
Tested it, seems to be very limited :)
-----------------------------
Jolla Recovery v0.1
-----------------------------
Welcome to the recovery tool!
The available options are:
1) Reset phone to factory settings
2) Reboot phone
3) Exit
Type the number of the desired action and press [ENTER]:
djselbeck
2013-12-27, 20:02
GREAT, that update removed the ability to boot custom kernels directly from fastboot. I'm very angry, this was the best rescue possiblity from brick. :mad::mad::mad::mad:
fastboot -i 0x2931 boot boot.img
downloading 'boot.img'...
OKAY [ 0.378s]
booting...
FAILED (remote: access denied. need privilege!)
finished. total time: 0.381s
tiempjuuh
2013-12-27, 20:31
Okay, so that's a reason to be angry indeed. Why did they do this for God's sake?! Maybe an employee can explain it? :)
GREAT, that update removed the ability to boot custom kernels directly from fastboot. I'm very angry, this was the best rescue possiblity from brick. :mad::mad::mad::mad:
fastboot -i 0x2931 boot boot.img
downloading 'boot.img'...
OKAY [ 0.378s]
booting...
FAILED (remote: access denied. need privilege!)
finished. total time: 0.381s
hmmm
a few suggestions (dangerous I guess)
fastboot erase recovery
fastboot oem unlock ( I already did that one, so I will try if I can fastboot boot boot.img) !
EDIT: No, fastboot oem unlock does not help. I also now am unable to boot recovery kernel boot-telnet-initrd.img :(
djselbeck
2013-12-27, 20:32
I think they did it as a security measure. It is pointless to do some security not based on encryption if you can boot any kernel you want. Will unlock my bootloader if you can boot anything because it sucks hard for kernel development in this state.
I think they did it as a security measure. It is pointless to do some security not based on encryption if you can boot any kernel you want. Will unlock my bootloader if you can boot anything because it sucks hard for kernel development in this state.
No, no go, fastboot oem unlock gave same permission error when trying to boot :(
Come on Jolla, FIX this !
djselbeck
2013-12-27, 20:37
Thanks for trying. So this really sucks. Best thing for the moment is to replace your recovery with a better one so you can at least do some recovery.
You have to replace your recovery with dd in booted state
Thanks for trying. So this really sucks. Best thing for the moment is to replace your recovery with a better one so you can at least do some recovery.
You have to replace your recovery with dd in booted state
Tweeted JollaHQ and stskeeps with a link to your post, I hope to pay attention
djselbeck
2013-12-27, 20:40
This is a very evil attitude from Jolla. At least an unlocked bootloader should be able to boot our own images directly. :( one major disappointment follows another one
This is a very evil attitude from Jolla. At least an unlocked bootloader should be able to boot our own images directly. :( one major disappointment follows another one
should have kept my money for the neo900.
djselbeck
2013-12-27, 20:49
Perhaps we should reflash our backuped p17 which holds the bootloader. From previous posts you can see that sha-sums were identically between devices. But this involves a great risk which I'm at the moment not willing to do.
Wow, just noticed, that update LOCKED my bootloader again, and fastboot -i 0x2931 oem unlock no longer works.
Jolla just went from some-what-open to CLOSED!
Perhaps we should reflash our backuped p17 which holds the bootloader. From previous posts you can see that sha-sums were identically between devices. But this involves a great risk which I'm at the moment not willing to do.
I have a backup of my device as well
With this sh.. I really dont care if I brick this device
djselbeck
2013-12-27, 20:54
Than I recommend flashing the busybox telnet recovery to recovery and experiment with this recovery.
At the moment this is the only control we have at boot level.
djselbeck
2013-12-27, 21:04
No thats not right.
Bevor the update you COULD:
boot custom kernel with CMD: boot
unlock bootloader with CMD: oem unlock
Now you can't do these two things
just noticed booting vs writing at which it fails :/
I did (as root, in terminal)
mount my sdcard in /media
dd if=/media/mmcblk0p17 of=/dev/mmcblk0p17
And, my device is back in 'unlocked' state (oem unlock) I can fastboot boot custom kernel, and - the device boots and seems to work
rainisto
2013-12-27, 21:06
We are working on that future update will bring you better recovery image, which will allow dropping you into shell (if there is devicelock set, it queries the lockcode) where you can do the similar kind of dd etc commands like you did with your custom kernel image.
djselbeck
2013-12-27, 21:08
I don't want any better recovery image. I want the ability to boot what ever I want. Which a unlocked bootloader will do.
Why not give the possibility to unlock bootloader with device wipe, like google and sony do?
Gonna make MULTIPLE backups of mmcblk0p17 image for sure I dont want to loose that copy
Gonna make MULTIPLE backups of mmcblk0p17 image for sure I dont want to loose that copy
a factory reset doesn't bring it back? It was supposed to reset to 1.0.1.10 state so you had to update to 12 manually (and no info about such feature in .2.5 so expecting the same)
djselbeck
2013-12-27, 21:12
The reliance on boot security is plain stupidity. The only safe way to ensure data security is encryption. There will always be some kind of security holes in linux kernel
SO GIVE US AN UNLOCKED BOOTLOADER.
rainisto
2013-12-27, 21:15
I don't want any better recovery image. I want the ability to boot what ever I want. Which a unlocked bootloader will do.
Why not give the possibility to unlock bootloader with device wipe, like google and sony do?
In future there might come ability to do oem unlock with imei specific passport file, but there is no info yet about which update that will come if at all.
But you can still flash back your old p17 as we are _not_ going to prevent flaghing or downgrading from rootshell. But we are trying to protect normal end user against device theft and data theft. Thats why future revocery image will query your devicelock code if that has been set.
djselbeck
2013-12-27, 21:17
I would like to not flash my bootloader. This is the riskiest operation I could imagine.
I'm at the point where my loyalty for your platform comes to an end.
If you write openess on your flags you should deliver it.
I don't see why this bootloader update today was necessary.
Anyone who depends on data security for this BETA PLATFORM at the moment is mentally not clear.
My jolla goes in to the bay on sunday. If someone wants to make a good offer go ahead and PM me
I would like to not flash my bootloader. This is the riskiest operation I could imagine.
I'm at the point where my loyalty for your platform comes to an end.
If you write openess on your flags you should deliver it.
I don't see why this bootloader update today was necessary.
Anyone who depends on data security for this BETA PLATFORM at the moment is mentally not clear.
My jolla goes in to the bay on sunday. If someone wants to make a good offer go ahead and PM me
+1
10 freakin locked chars
rainisto
2013-12-27, 21:27
One of the rationales was that you have setup devicelock code with immediate lock, have company emails setup in your device, your company policy forces lockcode to protect company secrets.
"oem boot" allowed you to copy whole root partition without asking the lockcode. With this change copying root partition is only allowed after you have entered the devicelock code.
So hypotically if someone has option to follow mail for exchange security policy vs remove whole mfe support in future updates, which one has valid businesscase? Or if hypotically you can skip devicelock code query without any effort, would you trust your device any more?
You can say that you dont use mfe and dont care if people can steal your data easily, thats why there is still option to flash old bootloader back to device (or just make custom recovery image). But personally I use devicelock code on my device and have updated to latest bootloader and recovery partition (as I can always use recovery partition to get my device to match my latest rdiff backup that I have in a cloud).
djselbeck
2013-12-27, 21:31
As an owner of an Xperia Z from Sony I know how it could be done so don't give me wrong facts.
fastboot oem unlock 0xKEY would've been the perfect way. This would've given the geeks around here the possibility to do what they want. Now we can't do this.
If you were unable to implement this in time, you should provide the bootloader image yourself. Also a way you've not taken.
From an open company I expect this.
I'm done. I'm writing developer care right now to pull my app from your store and sell my device.
Good luck satisfying your MFE customers :p
One of the rationales was that you have setup devicelock code with immediate lock, have company emails setup in your device, your company policy forces lockcode to protect company secrets.
"oem boot" allowed you to copy whole root partition without asking the lockcode. With this change copying root partition is only allowed after you have entered the devicelock code.
So hypotically if someone has option to follow mail for exchange security policy vs remove whole mfe support in future updates, which one has valid businesscase? Or if hypotically you can skip devicelock code query without any effort, would you trust your device any more?
You can say that you dont use mfe and dont care if people can steal your data easily, thats why there is still option to flash old bootloader back to device (or just make custom recovery image). But personally I use devicelock code on my device and have updated to latest bootloader and revocery partition.
Then I guess Jolla made a decision when it comes to openess and a development friendly community device versus a closed, secure device.
Goodbye Jolla from me
rainisto
2013-12-27, 21:36
As an owner of an Xperia Z from Sony I know how it could be done so don't give me wrong facts.
fastboot oem unlock 0xKEY would've been the perfect way. This would've given the geeks around here the possibility to do what they want. Now we can't do this.
If you were unable to implement this in time, you should provide the bootloader image yourself. Also a way you've not taken.
From an open company I expect this.
I'm done. I'm writing developer care right now to pull my app from your store and sell my device.
Good luck satisfying your MFE customers :p
Like I said we are working on possibility of allowing "fastboot oem unlock 0xKEY" but updates take time to implement. I did not say that you never will be able unlock your fastboot. And this change was not done because of MFE, you should have read 'hypotically' part.
This is disappointing. :(
On the one hand Jolla encourages hacking of the device to developers (which are probably the sole user base at the moment?). On the other hand they now want to secure the device for the normal user and take away functionality we saw as a feature. I understand the security concerns here. However, without any way to easily reset the device by flashing an image, this makes me more cautious with any experiments…
At least it seems like the old mmcblk0p17 seems to be the same for everyone – the checksums published earlier in this thread matched.
djselbeck
2013-12-27, 21:41
Maybe updates take their time. But I'm not DDing my bootloader. No way.
Also I don't want to wait until the device is worthless on ebay. So goodbye jolla community for now.
SMPC will be pulled from harbour, development stopped.
MTBtracker development stopped.
This will be my last post. Goodbye everyone, this has been a great experience the last few weeks. Also a much better community than XDA for example.
rainisto
2013-12-27, 21:56
This is disappointing. :(
On the one hand Jolla encourages hacking of the device to developers (which are probably the sole user base at the moment?). On the other hand they now want to secure the device for the normal user and take away functionality we saw as a feature. I understand the security concerns here. However, without any way to easily reset the device by flashing an image, this makes me more cautious with any experiments…
At least it seems like the old mmcblk0p17 seems to be the same for everyone – the checksums published earlier in this thread matched.
This update also included recovery image (power+volumedown), which allows to factory reset your btrfs back out of box state. Which should make your experiments a bit safer. As you can use recovery image to get into bootable state, and you can use root-shell to recover for example your latest rdiff-backup to your device.
Maybe updates take their time. But I'm not DDing my bootloader. No way.
Also I don't want to wait until the device is worthless on ebay. So goodbye jolla community for now.
SMPC will be pulled from harbour, development stopped.
MTBtracker development stopped.
This will be my last post. Goodbye everyone, this has been a great experience the last few weeks. Also a much better community than XDA for example.
While I will stop my Jolla adventure. I will not stop on this community.
I will, hopefully, achieve my own goals with N9xx, or neo900 or ... But here, in this community is plenty of talents to support. Just wish Jolla would have acknowledged that
This update also included recovery image (power+volumedown), which allows to factory reset your btrfs back out of box state. Which should make your experiments a bit safer. As you can use recovery image to get into bootable state, and you can use root-shell to recover for example your latest rdiff-backup to your device.
You clearly dont understand the needs that some developers have. This is fine, but not for me.
rainisto
2013-12-27, 22:02
You clearly dont understand the needs that some developers have. This is fine, but not for me.
Yes I was stating what this update was offering. I do understand that kernel developers want to have full oem unlock command available, and we are working on providing solution for that in future updates. Unfortunately there is limited number of fixes and features that can be included per update. We dont have unlimited hours and manpower.
Yes I was stating what this update was offering. I do understand that kernel developers want to have full oem unlock command available, and we are working on providing solution for that in future updates. Unfortunately there is limited number of fixes and features that can be included per update. We dont have unlimited hours and manpower.
Like I previously wrote. That closeness is up to Jolla. I am not sure how many will appreciate it.
As for security. Honestly, that is a weak argument. I can break that any time as long as developer mode exists.
Protecting company data should be achieved by other means, If this is what you want.
From a company perspective this is understandable, but, considering whom supported the start-up by preorders, and considering other available options for companies. Is this a wise decision. I dont know, and I dont care. It is goodbye Jolla from me.
rainisto
2013-12-27, 22:12
I can break that any time as long as developer mode exists.
And how do you install developer mode on the device that you have stolen from someone which asks you devicelock code on the boot?
We are not even trying to protect the case where user has installed developer mode by himself, as he as dismissed the warranty may void dialogs and such.
djselbeck
2013-12-27, 22:15
Let's see, for example an security problem in your old frankenstein android kernel mix?
You can even install rpms as an normal user.
rainisto
2013-12-27, 22:19
Let's see, for example an security problem in your old frankenstein android kernel mix?
It is no higher art required to install local rpms as normal user?
And how do you get to install things as normal user? Settings devicelock code, immediate, 10 attempts, reboot.
True if you quess the lock code with those 10 attemps, you can do anything as normal user. But if you dont happen to quess the code, do you have some trick to bypass the code query with the latest release?
But yes if frankestein kernel has some remote tcp/ip drop to shell exploit, then everything is wide open.
djselbeck
2013-12-27, 22:20
Even if i had I wouldn't disclose them.
But that is not the point. Everybody who thinks their data is secure if it is not encrypted doesn't know much about computer security.
rainisto
2013-12-27, 22:24
Even if i had I wouldn't disclose them.
But that is not the point. Everybody who thinks their data is secure if it is not encrypted doesn't know much about computer security.
Nobody in right mind would think that their data is secure. Most people know that unix permissions dont give you real data security and that people can just remove microsd card.
It just means that its nice to have locks in your front door, even if burglar can break the window quite easily. And most people in the world keep their front door closed/locked, even when their houses have windows and they know that people can break in at any time.
But I can be wrong of course, some people might not lock their front doors when they go out.
Fuzzillogic
2013-12-27, 22:24
Correct me if I'm wrong, but all these lock-thingies will be slight bumps in the road for someone really interested in the data on your phone. Direct access to the flash chips is all you need. They only viable solution is encryption. What's the reason the Jolla doesn't use that, ootb?
While I'm not really into flashing custom kernels (my N9 runs stock kernel) I do find it disappointing to see I now have yet another device which is hard to hack, or at least harder to hack for the wrong reasons (i.e. trying to improve security, but ultimately failing at that. Just like my Samsung tv, which encrypts recording but helpfully puts the keys in a companion file.)
It might not affect many, but these kind of changes on a bug-fix update which will seriously hinder owner's ability to hack a supposedly open device should be noted in the release notes of that update.
rainisto
2013-12-27, 22:31
Its pretty easy to use fuse encryption layer for example on your microsd card or any custom folder/directory/mountpoint, so people who wants to have some of their data encrypted are free to do so (it will have performance impact and battery life is also affected). Some future update might even offer you to have your data encrypted.
Well that escalated quickly...
Fuzzillogic
2013-12-27, 22:38
If I want to do all the "pretty easy" things on my wish list, I wouldn't have time to poop.
Yes currently the spare tire is the care centers flashing stations. But update is coming soon, which gives you factory spare tire.
The thing which we protect is that if you have set devicelock code and someone steals your device, then he/she is not able to wipe it clean for selling it off by reflashing without knowning your lockcode.
I always thought that codes are to protect data and information and not hardware, it's not feature, it's totally bug. And people always asked why I whined when i was keeping to repeat that Jolla is mostly talking about FOSS and promises, but they still didn't fully proven to be trusted in any promised area.
Seriously guys, I don't see your problem.
As Jonni (rainisto) says, the device is still unlockable, you just need to use a different way to do it. And you can go back to a previous software release by resetting.
The rationale is also understandable: they wish to give some more protection to 99% of their users (that is, everybody who is not a kernel hacker).
They also said that the situation will improve with the next update. Seriously, it's a holiday right now, please have some patience. I bet you wouldn't like it if your boss/customers asked you to work in your holiday either.
Please respect the decision and have some patience.
If I want to do all the "pretty easy" things on my wish list, I wouldn't have time to poop.
With hwkb it should be quite easy to use that off-time for something productive.
Fuzzillogic
2013-12-27, 23:02
Seriously guys, I don't see your problem.
Closing/limiting the bootloader is an insufficient stop-gap for protecting the data on your stolen device. Closing/limiting the bootloader however is very effective for annoying tinkering owners. And I reckon that currently the percentage tinkerers of the Jolla is higher than the industry standard.
I was hoping security would be high, if not the highest on the priority list. Now it seems like an oversight which might or might not be fixed in a future update.
With hwkb it should be quite easy to use that off-time for something productive.
I'm quite productive when pooping. Just ask my toilet :D
rainisto
2013-12-27, 23:07
@Venamo: thanks, I will have 2 days of holidays between this August to next May, and today was one of those days. :-]
And I reckon that currently the percentage tinkerers of the Jolla is higher than the industry standard.
It is definitely, but the Jolla cannot survive on those. MfE (and any IS compliance it needs to implement) is something which might be worth tens of thousands of handsets sold to companies, tinkerers will find their way (with absurdly awesome helping hand from company itself, compare this to nokia TMO interaction, nokia what?), business users want lock code that works. If that passes test for compliance this is something Jolla has to have
It is definitely, but the Jolla cannot survive on those. MfE (and any IS compliance it needs to implement) is something which might be worth tens of thousands of handsets sold to companies, tinkerers will find their way (with absurdly awesome helping hand from company itself, compare this to nokia TMO interaction, nokia what?), business users want lock code that works. If that passes test for compliance this is something Jolla has to have
On the under hands, who would make applications for your platform if you annoy your tinkerers ? I don't think those business users would write their own apps themselves...
On the under hands, who would make applications for your platform if you annoy your tinkerers ? I don't think those business users would write their own apps themselves...
So back to the argument that having workable android apps is going to scare everyone... thought we did this one already. Android apps take care of business users if the phone is certified. (IF)
@Venamo: thanks, I will have 2 days of holidays between this August to next May, and today was one of those days. :-]
It only means that you do what you actually like as you keep working on day off, it's good, but it's your decision
rainisto
2013-12-28, 00:41
It only means that you do what you actually like as you keep working on day off, it's good, but it's your decision
Yes, work and hobby is mixed together, I'm not complaining, every day is an interesting day nowadays :)
richardski
2013-12-28, 02:11
Very disappointing behaviour by Jolla especially after all the publicly stated claims to support FOSS principles.
If you cannot have full and unfettered access to hardware that you have purchased you may as well throw it into the sea.
Locking the boot loader means it is harder to ensure that NSA, GCHQ or other snoopers are kept out of your system. Makes me wonder if there was any pressure applied to the Jolla team from interested parties like the Chinese to lock down these phones for the purposes of state control of users.
Just so glad I read this before updating my phone. Unless this policy is reversed then this will be the fastest self obsoleting piece of hardware I have ever purchased:(
Richard
javispedro
2013-12-28, 03:28
Ok, so, right after discovering a method to run what I want on the device, an update comes and breaks this method. And all we get is vague promises about a brighter future.
I am having Déjà vu. Lots of it.
They also said that the situation will improve with the next update. Seriously, it's a holiday right now, please have some patience. I bet you wouldn't like it if your boss/customers asked you to work in your holiday either..
Oh, I fully agree. In fact, I would really wish that whoever this "boss" is would stop asking these employees to ship, during Christmas, updates that actively cripple the device. That would have been much better.
"Cripple first, give explanations latter" was basically the Aegis motto during the early days.
And I'm not even saying that this update completely cripples the device. But, hey, as said, set your priorities straight. It has been mentioned in this thread for lots of pages that "annoying tinkerers" might not be in the best interests of the company. A few words instead of "future updates may or may not completely cripple the device" would be nice.
Look at Stskeeps' post: it was detailed, technical, mentioned future plans, and got a lot of karma. He obviously forgot to mention that locking the bootloader was so high on Jolla's TODO list that they would do that during Christmas and before other features such as, say, allowing this lock to be bypassed when there is no lock code were implemented. *cough*
But at least there were some words. As it stands now, it seems that we have another method, that may or may not last until the next update, which means we're back to a page#1-like panic again.
billranton
2013-12-28, 07:10
I understand that after the cloak-and-dagger way that Nokia ran things, people are a bit sensitive about these things, but I really wish people would stop having tantrums every time something like this happens.
This is still a long way from Aegis, and seems to be an emergency measure after what I assume was a stern telling off by some service provider that threatened to block Jolla devices otherwise. If the choice were between this and something like MfE stopping working, I'll take the locked-but-circumventable bootloader. The N900 was never supported by exchange servers that required provisioning, for exactly these kinds of reasons.
Jolla's intentions are to be open, but they also need to be commercially viable. Those two aims are often in conflict, but if they ignore the second then they'll end up in the same fringe Maemo was condemned to. They're also small, so we can't expect finely crafted, legally acrobatic, solutions from the start.
Give em time, and please stop throwing your Jollas in the sea. The Baltic has enough heavy metal in it already.
And how do you install developer mode on the device that you have stolen from someone which asks you devicelock code on the boot?
We are not even trying to protect the case where user has installed developer mode by himself, as he as dismissed the warranty may void dialogs and such.
Besides having the bootloader in an IMG file to play with ? Which, can be used across devices ? OH! security doesnt matter once developer mode is accepted ;) Right, so all an employee have to say is ' I dont care' and then you write off all responsibilities.
That will work surely, for all companies who might have considered a Jolla acceptable for a empoyee device, I am sure.
Jolla went wrong here when it comes to developers and an open device.
Mistakes happen, but come on, this whole process untill now have been compiled of nothing but closed communication, doing stuff and them telling.
The bootloader locking is just the latest example.
Not even in the changelogs was it mentioned that Jolla locked the bootloader.
Luckily, the first security flaw was discovered within hours to restore the unlocked bootloader.
But, even if I can hack the device to 'get around' Jollas attempts to protect, its not the point. I DONT WANT TO. I want the device open without having to spent MY time breaking it.
There are enough of these devices around.
Nokias being some.
joerg_rw
2013-12-28, 08:52
I just can say I 100% agree on NielDK's rationale and Javispedro's deja-vu induced concerns. Been there, suffered this before. The injuries still hurt. ~aegis
Hanlon's razor (http://en.wikipedia.org/wiki/Hanlon's_razor) definitely not applicable here. Maybe Grey's Law though.
For me not baltic sea but "will it blend" (http://www.youtube.com/watch?v=GAuhUTzNwiY)
its a crappy move from jolla, and its probably no coinscidence that they did it just when this thread started to move forward. But lets be patient and back off a little and we'll see what they'll do in the nearest weeks. Maybe they did it to prevent eager users to shoot their devices to junk during holiday even before they have had time to roll out their most critical updates.
Show a little patience and give this little company a break.
EDIT: joerg-rw: that video was hilarious. thx.
So much anger...it feels like i'm reading youtube comments.
Here's an official statement from Jolla:
There is no intention to lock down the device and disallow tinkering and we'll seek to remedy this regression when possible.
See this link (https://together.jolla.com/question/3612/release-notes-software-update-2-1025-edit-28122013/) for details.
ste-phan
2013-12-28, 09:58
So much anger...it feels like i'm reading youtube comments.
As a consumer I would expect Jolla to make me want to use Sailfish, then boot anything else from custom kernels to Linux forks.
But Sailfish + decent recovery first.
Has the security vacancy been filled in yet?
One of the software engineers on this forum might take the position to work at the root of evil and prevent it to consume itsself?
You are the person we are looking for, if you…
can prevent Jolla devices from being infected with rootkits
have practical experience in finding and fixing such problems
have the ability to document level of confidence in a component
can focus on improving, not complaining
have work experience in the security area
are a team player with can do -attitude
have good communication skills in English
are independent-minded, innovative and proactive in your work
joerg_rw
2013-12-28, 10:01
Here's an official statement from Jolla:
Quote:
There is no intention to lock down the device and disallow tinkering and we'll seek to remedy this regression when possible.
[endquote]
See this link (https://together.jolla.com/question/3612/release-notes-software-update-2-1025-edit-28122013/) for details.
There will be an openmode that allows you to do whatever you like with your HARMATTAN device (OWTTE) (actually eventually much much later that promise came true based on massive effort from community side, just it rendred the device pretty much useless due to the original OS getting locked down and not working as supposed anymore when that "open mode" got enabled. "Change device lock code" anybody?)
Everybody of the same guys doing Jolla now bashed me for being silly when I ranted about aegis being a terrible idea. X-Fade even stopped conversation with me completely from that very moment.
https://mg.pov.lt/maemo-irclog/%23maemo.2013-12-01.log.html#t2013-12-01T02:08:11
...
While I understand your concerns, I think this is a very different situation.
And remember, you can always go back to the older OS version that doesn't have this fix.
joerg_rw
2013-12-28, 12:07
While I understand your concerns, I think this is a very different situation.
And remember, you can always go back to the older OS version that doesn't have this fix.
AIUI you can't go back to *anything* once the device presents a "MALF" laughing at you. Or simply refuses to boot at all which is pretty much the same as a MALF. And just because selfdestruction not YET implemented doesn't mean you ever will get a way to recover from accidental destruction/damage to the system. And then you're back to what?
The difference between "you can't downgrade"(HARM) and "You can't flash at all"(Jolla) is marginal, with actually HARM being the less nasty concept here.
Sorry I'm out on this game, been there seen that.
...
I'm not sure what you mean.
You can do a factory reset which will restore the device to the version if came from the factory.
See here for details:
https://together.jolla.com/question/3904/when-performing-a-factory-reset-1005-always-present-afterwards/
djselbeck
2013-12-28, 12:22
I'm not sure what mean.
You can do a factory reset which will restore the device to the version if came from the factory.
See here for details:
https://together.jolla.com/question/3904/when-performing-a-factory-reset-1005-always-present-afterwards/
It will just reset the / partition. There is no mention of reflashing the bootloader (aboot partition)
Well, there's some thing that should be doable, really. Stskeeps did say previously;
* The bootloader of the Jolla is 'little kernel' ("lk (https://www.codeaurora.org/cgit/quic/la/kernel/lk/)") which speaks the typical Android fastboot protocol, which has a open source flasher (https://github.com/android/platform_system_core/blob/master/fastboot/fastboot.c).
So, if the boot loader is a linuxy bit, then it has to be open. Methinks I'll go and attempt to make my own bootloader, and include there an option to set up public-key ssh login for a maintanance mode, like I have on ubiboot. That should settle it, right?
djselbeck
2013-12-28, 12:33
No it has nothing to do with linux kernel. It is a small micro OS. Also I doubt that you can easily build your own lk. It has to be adapted to the jolla smartphone.
You can try it by reviewing the hardware adaption of linux kernel and try to adapt them to the LK bootloader. But this is very risky and not worth the risk.
Hope there will some open device soon which perhaps run mer/nemo/glaicer.
ggabriel
2013-12-28, 12:57
I blame Qualcomm for not allowing Jolla to distribute a proper image so that anyone can flash if the device is broken. I'd be happy to swap boot partitions (or any partition for that matter) if I had the ability to flash.
I sympathise with folks who want to get off ship now for economical reasons and maybe come back later if Jolla provides with better options.
I hope we get more competition in the SoC space so that we get better things. Somebody mentioned that perhaps Intel+open drivers will bring some happiness. Perhaps. Who knows.
I'll keep my Jolla for now, even if it isn't my main phone yet.
...
I'll repeat myself, maybe you'll read me this time:
Jolla has acknowledged that this is a bug and that this break was not intentional - they also officially said that they're working on fixing it. :)
djselbeck
2013-12-28, 12:59
I may keep my device also because I don't want to loose money. But my top priority is porting nemo/glacier on it.
wow people are quick to pull the trigger, i think its a pretty damn good idea for now, can't you guys wait a bit longer, usually beta to actual milestones change a lot, i understand its frustrating and that unless jolla will flash my device back to normal if i kill the bootloader i wouldnt do it either.
think people should stop overreacting.
First people whine because Jolla doesn't communicate. Then Jolla communicates clearly and on a detailed technical level, even during Christmas holidays, and people are too busy whining to even realize it...
joerg_rw
2013-12-28, 14:18
I realize that Jolla, while NOT providing any other way to recover from catastrophic failure in device firmware than just sending in the device to Jolla for getting it reflashed on my own expense, dares to roll out *very* delicate and risky updates to crucial parts of said system (here: bootloader) during xmas without any prior notice, and then says this update deployed a bug they didn't intend to get rolled out. While the rationale to get that update at all and particularly ASAP during holidays is what exactly? Getting a makeshift fix to a perceived security threat that nobody except Jolla actually can see it getting fixed by the approach taken by Jolla? While the threat itself is pretty much hypothetical since it only kicks in when somebody gets his device stolen during christmas.
Don't you too start to wonder what's the real motivation behind all that? Again, I have a hard time to apply Hanlon's razor here.
/j
It was already mentioned by somebody that this might be a requirement by some operators to sell Jollas. And it might be a requirement for Exchange provisioning as well.
Nokia never cared about business usability of their experimental phones N900 or N9, but Jolla appears to care.
javispedro
2013-12-28, 14:42
First people whine because Jolla doesn't communicate. Then Jolla communicates clearly and on a detailed technical level, even during Christmas holidays, and people are too busy whining to even realize it...
No, reread again. What has happened is that there was great communication, then, during Christmas, they partially reverse direction and do a move that can only be qualified of "surprising".
This is exactly what used to go on with Nokia. They'd fix a "security issue" (in this case Jolla calls it a "user privacy issue" -- but for me at least it still sounds the same as it's not "my privacy" they're fixing*), then argue with me that this is only temporary and that an open mode is coming. We all know how much later open mode did come and how crippled it was: I had problems convincing people to use it -- they preferred exploits!!
*that would be much better solved by allowing people to enable developer mode without pinging home at all or creating a account.
----
The problem is putting this "user privacy" so up in the priority list it stands in the faces of tinkerers. "Solving user privacy" by just locking the boot loader does not serve any visible purpose other than annoying tinkerers, specially when this is done before encryption is implemented (thereby it is useless for "government" guys), or the method to unlock it is developed (thereby annoying tinkerers). This should have either been delayed until the other pieces were in place, or at least explained with much consideration.
Is it hard to understand that I thought that with this device things (communication, openness, etc.) would be better than in N9 ages?
Yes, I still think that this device will end up being better (mainly because great people like Stskeeps are onboard), but it also seems that without some constant reminding things quickly go downhill.
javispedro
2013-12-28, 14:44
It was already mentioned by somebody that this might be a requirement by some operators to sell Jollas. And it might be a requirement for Exchange provisioning as well.
Nokia never cared about business usability of their experimental phones N900 or N9, but Jolla appears to care.
Nokia never care? Then I suppose Aegis was just purely for evil.
And the fact that Sailfish has things like "No DRM" on their FAQ are outright lies because they will bend over the moment a carrier asks for a DRM protected 30-second ringtone.
And here I though it was Jolla's benefit that they wouldn't be forced to following all the enterprisey requirements that as a Nokia-sized behemoth they were forced to follow... was I wrong?
Communication isn't the same, it's been VASTLY better*, I don't even know how anyone here can try to argue otherwise...
Has there been cock-ups? Most definitely. Has communication reverted to the "bad old Maemo 4-6x days?" Not even close. Could it get better? Most definitely.
*here's just one recent example amongst multitudes
http://talk.maemo.org/showthread.php?p=1401504#post1401504
Can someone from Jolla please clarify whether the full device reset reflashes reinstalls, refreshes, whatever terminology the bootloader, can the bootloader be filled with 00000s and the device can still be recoverable?
djselbeck
2013-12-28, 15:15
can the bootloader be filled with 00000s and the device can still be recoverable?
I highly doubt that :D.
Fuzzillogic
2013-12-28, 15:21
Communication isn't the same, it's been VASTLY better*, I don't even know how anyone here can try to argue otherwise...
I am indeed pleased to see they care and elaborate on the problems/issues they had and tradeoffs they took, without all the usual weasel words and marketing blabla. The one thing to improve would be to communicate more in advance, certainly in this case. We've seen people throwing fits, but after it was explained why Jolla did the things they did the mood cleared considerably. With this update, it seems like a repeat, only now we are much dependent on Jolla.
Also, even if these issues don't affect me directly, I do feel the need to be vocal about them. If I let them pass as "I don't care", at some point things will get worse, because companies think nobody cares. And then we end up with an Apple-ified device, which is in my view the total surrendering of customers to the company. So, by being vocal now, I hope to protect my future interests, before it is too late. (see what I did there? I communicated in advance! :D)
Speaking of apple... Aren't those newers iphones fully encrypted?...
Stskeeps
2013-12-28, 15:25
Can someone from Jolla please clarify whether the full device reset reflashes reinstalls, refreshes, whatever terminology the bootloader
On 1.0.2.5:
[carsten@vostro-localdomain SailfishOS-1.0.2.5-sbj]$ sudo fastboot -i 0x2931 boot recovery.img
[sudo] password for carsten:
< waiting for device >
downloading 'boot.img'...
OKAY [ 0.592s]
booting...
FAILED (remote: access denied. need privilege!)
finished. total time: 0.595s
After factory reset on 1.0.2.5, returning to 1.0.0.5:
[carsten@vostro-localdomain SailfishOS-1.0.2.5-sbj]$ sudo fastboot -i 0x2931 boot recovery.img
[sudo] password for carsten:
downloading 'boot.img'...
OKAY [ 0.591s]
booting...
OKAY [ 0.003s]
finished. total time: 0.594s
can the bootloader be filled with 00000s
and the device can still be recoverable?
Don't do that unless you want an expensive service repair. Power brings responsibility.
Nokia never care? Then I suppose Aegis was just purely for evil.
In the end it was kept for no apparent reason, right? The work on Aegis predates the Elop era, and that was a time where Nokia really cared about MeeGo. But the day the N9 was released, Aegis remained just an evil annoyance IMHO. Maybe it made some operators that sold the N9 happy. I don't know. It certainly didn't bring us more commercial software.
And the fact that Sailfish has things like "No DRM" on their FAQ are outright lies because they will bend over the moment a carrier asks for a DRM protected 30-second ringtone.
Sailfish as an OS has no DRM. Jolla as a Sailfish vendor may decide to "enhance" the product. If it means getting more commercial software, and more sales, it could actually be regarded as an enhancement by many.
And here I though it was Jolla's benefit that they wouldn't be forced to following all the enterprisey requirements that as a Nokia-sized behemoth they were forced to follow... was I wrong?
The moment you want to sell (and have to sell) you have to follow the rules of the market. And they're mostly dictated by the operators and the content industry nowadays. IMHO Jolla tries to find a compromise that makes both, the operators and the tinkerers happy. Step by step. The last step was probably to please operators (and users by providing a way to recover a bricked device), the next step might be to please tinkerers.
You cannot have it all at once, especially not with an update-early, update-often policy. It's the end result that counts.
Fuzzillogic
2013-12-28, 15:29
I highly doubt that :D.
Then I wonder... how do these devices get flashed the first time? Not by USB apparently, but by JTAG or something?
I had a pc mainboard once, during the Pentium 60-days, which had a flashable BIOS, but which also had a 4K bootloader in mask ROM, e.g. indestructible. Even if you managed to mess up during flashing a new BIOS, like overwriting it with zeros, you could always restore it by diskette, thanks to that 4K bootloader.
djselbeck
2013-12-28, 15:32
This would be cool and there are even today devices which have an read only bootloader. Ipod Classic for example has the DFU mode in ROM
Stskeeps
2013-12-28, 15:32
Then I wonder... how do these devices get flashed the first time? Not by USB apparently, but by JTAG or something?
We grow them in vats from stemcells in a remote farm in Taiwan. Pictures are flashed into their front cameras that load the conciousness onto them.
Seriously though: There's always ways to initialize a flash on a device, on N900/N9 it was called a cold flash from recollection.
We've seen people throwing fits, but after it was explained why Jolla did the things they did the mood cleared considerably. With this update, it seems like a repeat, only now we are much dependent on Jolla. Also, even if these issues don't affect me directly, I do feel the need to be vocal about them. If I let them pass as "I don't care", at some point things will get worse, because companies think nobody cares. And then we end up with an Apple-ified device, which is in my view the total surrendering of customers to the company. So, by being vocal now, I hope to protect my future interests, before it is too late. (see what I did there? I communicated in advance! :D)
Totally agree, some whining is good, I'm guilty of that in spades, I just hope they've all got thick skin, as it could get demoralising at times.
Speaking of apple... Aren't those newers iphones fully encrypted?...
Yup.
joerg_rw
2013-12-28, 15:54
Then I wonder... how do these devices get flashed the first time? Not by USB apparently, but by JTAG or something?
I had a pc mainboard once, during the Pentium 60-days, which had a flashable BIOS, but which also had a 4K bootloader in mask ROM, e.g. indestructible. Even if you managed to mess up during flashing a new BIOS, like overwriting it with zeros, you could always restore it by diskette, thanks to that 4K bootloader.
OMAP has a ROMBL, which is used in N[89]xx devices for coldflash: http://www.omappedia.org/wiki/Bootloader_Project. and my uneducated guess is that the SoC in Jolla is lacking a proper implementation or configuration of anything equivalent. So yep, it's probably JTAG (or UART) - or suffer and pay Jolla for recovering your device
On 1.0.2.5:
[carsten@vostro-localdomain SailfishOS-1.0.2.5-sbj]$ sudo fastboot -i 0x2931 boot recovery.img
[sudo] password for carsten:
< waiting for device >
downloading 'boot.img'...
OKAY [ 0.592s]
booting...
FAILED (remote: access denied. need privilege!)
finished. total time: 0.595s
After factory reset on 1.0.2.5, returning to 1.0.0.5:
[carsten@vostro-localdomain SailfishOS-1.0.2.5-sbj]$ sudo fastboot -i 0x2931 boot recovery.img
[sudo] password for carsten:
downloading 'boot.img'...
OKAY [ 0.591s]
booting...
OKAY [ 0.003s]
finished. total time: 0.594s
Don't do that unless you want an expensive service repair. Power brings responsibility.
Well the N900 allowed that if I remember rightly, and I think that's the level of freedom and "safety" (in not breaking the device) people expect.
So they want to sacrifice main contributors(pre-orders and future developers of native apps) and future customers as well for operators to sell a device?
Who they expect to buy a device and without community and tinkers how long it would take people to jump to next device, if there would be no freedom for them?
People still love N9 and harmattan(and i do) and it's hackable and there is still development, but you can't compare it to development we have for maemo. It's still there while HW is outdated with updates from community, updated kernels and so on.
My point that you can see that it's possible on any device even with aegis, but it takes more resources. Some people want to simply hack device and not crack/jailbreak it. That's why maemo development is still relevant even after a lot years, while harmattan is getting low to almost zero :(
So if they want to have those devices collecting dust at operators stores or people houses, good luck. They need to remember that as well for end user they want mostly to buy their devices, hw is less than middle, and for today's "just user" and android fan boys is what important...
Edit: typos from bb10 auto correct
I am wondering what if newer devices are shipped with the latest firmware from the start? I guess they won't have the chance to go back to an older factory snapshot…? I think all the anger here just comes from the fact that it would have been nice to wait with locking the bootloader until an unlock process was actually in place.
Anyway, I am confident people at Jolla learned from all this. I hope there will be a different flash or partition for the modem bits so a factory image can be distributed for future devices. :)
djselbeck
2013-12-28, 16:43
It is "quite easy" to flash the bootloader to an old version :D
Someone needs to upload it though.
AFAIUI there are flashing tools on board, and if you have Developer Mode, you can use them.
djselbeck
2013-12-28, 17:06
Yes, you can flash with dd and sha1sum afterwards. But you still depend that someone uploads an unlocked bootloader image. And that the partition remains readwrite in the future.
As stated somewhere in this thread, the possibility to mask partitions readonly exists.
several backups of bootloader unlocked version exists - mine included, if someone needs I can post a share link.
But, dd'ing bootloader can be fatal, it does do the job when done right.
People still love N9 and harmattan(and i do) and it's hackable and there is still development, but you can't compare it to development we have for maemo. It's still there while HW is outdated with updates from community, updated kernels and so on. That's why maemo development is still relevant even after a lot years, while harmattan is getting low to almost zero :(
Not to digress from your main point (which is somewhat of a digression itself), but do you use both devices heavily still?
ggabriel
2013-12-28, 17:49
It is "quite easy" to flash the bootloader to an old version :D
Someone needs to upload it though.
Can't you reset to factory settings, access with fastboot, dd the bootloader and then upgrade and do whatever?
djselbeck
2013-12-28, 17:50
Can't you reset to factory settings, access with fastboot, dd the bootloader and then upgrade and do whatever?
At the moment this should do the trick. But someone asked what if factory state will be updated to new bootloader
javispedro
2013-12-28, 17:55
In the end it was kept for no apparent reason, right?
I can tell you why it was keep: it was just more work to remove it. Which is what I fear with the "cripple first" approach. That when the time comes to actually make on the promises made, "there is no manpower"/"it is Christmas". But oh, there certainly was manpower to cripple it in the first place.
Sailfish as an OS has no DRM. Jolla as a Sailfish vendor may decide to "enhance" the product. If it means getting more commercial software, and more sales, it could actually be regarded as an enhancement by many.
(We'll never learn)
Please, let's not follow this. Because then I'll ask why are they not using Android in the first place, which is what the "rules of the market" call for. We're trying to define new rules of the market here. That's how one makes sales when they're the small newcomer.
Discussing this would bring too much OT on this thread, so let's keep it at that. I can open a new thread if desired.
You cannot have it all at once, especially not with an update-early, update-often policy. It's the end result that counts.
See above -- no one is demanding "all at once". Let's define groups of users A (tinkerers) and B (those who want a locked bootloader when a lock code is active). In the preChristmas situation group A was "pleased" while B was not. Jolla knows of a method to please both groups, but it involves some implementation cost (namely a way to unlock the bootloader).
Which one of the following options would you chose?
1) Tell group B to wait until the optionally-locks-bootloader update "which may or may not come". A is happy.
2) Annoy A by locking their bootloaders unconditionally. Tell group A to wait until the optionally-unlocks-bootloader update "which may or may not come". B is happy.
If you chose 2, then, well, it's a valid option, but you just shown your true colors. And obviously, you should expect rage from A.
i know this is OT, and many hates FB ....
https://www.facebook.com/photo.php?fbid=560615010659727&set=a.106829316038301.18404.104835316237701&type=1
Not to digress from your main point (which is somewhat of a digression itself), but do you use both devices heavily still?
My main phone is bb10 as harmattan started to lag and bb10 great screen and qt support as well as company support made me switch. But N900 I used till its last day(usb broke up second time after soldering), even when I had new iPhone 4 in the box (i took it as part of operator plan and planned to sell it). I even consider buying it again or neo900.
As we learned there are two kinds of support, one from company and one is from community and as you see not always go both ways. And it would be okay, but only if they do not go opposite ways by company making it's more difficult to community to support device.
You can see examples in android world when there are custom roms from community with newer firmware than last company released. Or even custom features with add-ons companies failed to bring. And while company try to sell you new phone every few months you can still use optimized supported by community rom for old one.
I feel that every new platform starting from maemo we go few steps forward and dozen backwards. Yes, they need to sell phones and make money, but when what is 'unlike' about? Is it about new UI and same crippled device as all others on market?
I can tell you why it was keep: it was just more work to remove it. Which is what I fear with the "cripple first" approach. That when the time comes to actually make on the promises made, "there is no manpower"/"it is Christmas". But oh, there certainly was manpower to cripple it in the first place.
I don't even want to think of what can happen when one of lead devs go to vacation without internet or ill? We can get aegis back one of those opportunities comes ;)
We grow them in vats from stemcells in a remote farm in Taiwan. Pictures are flashed into their front cameras that load the conciousness onto them.
Seriously though: There's always ways to initialize a flash on a device, on N900/N9 it was called a cold flash from recollection.
Would this be possible on a jolla device through usb?
Also I remember that for the nexus devices you had to run a script to retrieve the proprietary components and then build a rom. Would that not be possible here?
said you were thinking of ways of fixing the whole issue would it be too bad an idea to pull the proprietary bits off the device, and build the image on the users PC and then flash it, all behind the scenes obviously, like the Nokia Software Updater.
We grow them in vats from stemcells in a remote farm in Taiwan. Pictures are flashed into their front cameras that load the conciousness onto them.
I always assumed that the jollas grow on trees, and when the order status is "in picking" it means that it's when you pick them from the trees.
Some recent tweets concerning the topic:
@HarriHakulinen 6m
@SimoRuoho Factory reset will return you to original OS, including completely open setup if that is important for you in short notice.
@HarriHakulinen 8m
@SimoRuoho OEM lock change was poorly communicated, but the intention was to secure user data. We will provide unlocking tools asap.
PS. Harri Hakulinen is Chief engineer at Jolla.
It will just reset the / partition. There is no mention of reflashing the bootloader (aboot partition)
See what Stskeeps and Harri Hakulinen had to say about this. :)
djselbeck
2013-12-29, 17:30
It is good to see that Jolla is really listening.
Stskeeps
2013-12-29, 20:27
A good writeup by somebody not associated with Jolla:
http://blog.condi.me/blog/tinkerability/
djselbeck
2013-12-29, 21:08
I've just received an email answer from Marc Dillon and can ensure you that they are reacting to the critic of our userbase quite seriously.
It was a big surprise for me to see Marc answer me directly which definitely motivates me enough to continue working with sailfish and jolla in general.
Nonetheless I'm pulling my app from Harbour for the moment until Jolla opens up a bit. This means better kernel source publishing and more opensourcing of Sailfish core components. At the moment Silica qml libs and all required libs for running apps build with the sdk would be enough. I don't need the sources of every sailfish app like (musicplayer and so on)
richardski
2013-12-29, 22:26
It is reassuring to read that the howls of discontent are being heeded at Jolla but it does appear that this is a fire fighting response only.
Currently the Jolla can only be recovered by being reflashed at the factory or service centre which is not a long term acceptable solution.
This is a major hurdle but Qualcomm can be helpful as per the FOSS WLAN USB dongle as supplied by ThinkPenguin:
https://www.thinkpenguin.com/gnu-linux/penguin-wireless-n-usb-adapter-gnu-linux-tpe-n150usb
Using below chipset:
http://qca.qualcomm.com/wp-content/uploads/2013/11/AR9271.pdf
This device is accredited by the Free Software Foundation:
www.fsf.org/resources/hw/endorsement/thinkpenguin.
Please work towards the facility for owners to reflash the total system and enable owner controlled lock down and encryption. We need to keep thieves and government agencies’ out of our hardware.
Richard
joerg_rw
2013-12-29, 23:48
[...]
Please work towards the facility for owners to reflash the total system and enable owner controlled lock down and encryption. We need to keep thieves and government agencies’ out of our hardware.
RichardYou'll have a hard time keeping out government, given the hw design seems to share eMMC and RAM between the APE core and the modem-radio core, and modem radio stack is very hardly ever getting opened for at least review (and even when it was, it would only reveal that there's no way to make sure there's no OTA backdoor)
IOW: modem can access your data, you can't access (or control) modem. Not even cryptfs will help to fix this.
/j
It will just reset the / partition. There is no mention of reflashing the bootloader (aboot partition)
A factory reset actually reflashes the bootloader that is shipped in the kernel-adaptation-sbj package through the scripts in /var/lib/platform-updates. Most interestingly, these scripts actually appear to be run after the reboot…
joerg_rw
2013-12-30, 01:29
on a somewhat OT question, though it is linked to info disclosed in this thread:
What is the left-volume(+) & power boot? It gives me a several seconds of vibrator and nothing more than just that.
/j
Stskeeps
2013-12-30, 07:35
on a somewhat OT question, though it is linked to info disclosed in this thread:
What is the left-volume(+) & power boot? It gives me a several seconds of vibrator and nothing more than just that.
/j
Something used in factory for initial flashing. I don't really know much more than that.
Something used in factory for initial flashing. I don't really know much more than that.
Noticed that one, even before fastboot (Vol -) ;)
Still trying to figure out what that mode is, and, what it can be used for hehe
on a somewhat OT question, though it is linked to info disclosed in this thread:
What is the left-volume(+) & power boot? It gives me a several seconds of vibrator and nothing more than just that.
/j
Some information (from Windows, I am work ATM LOL)
\\?\storage#volume#_??_usbstor#disk&ven_linux&prod_file-cd_gadget&rev_0000#du3bu00638&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b (file:///?\storage#volume#_??_usbstor#disk&ven_linux&prod_file-cd_gadget&rev_0000#du3bu00638&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b)}
(file://\\?\storage#volume#_??_usbstor#disk&ven_linux&prod_file-cd_gadget&rev_0000#du3bu00638&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b)
Seems to be ADB interface ?
A few links that might be worth having a look at - and start searching QPST tool ;)
http://forum.xda-developers.com/showpost.php?p=22648011&postcount=47
http://forum.xda-developers.com/showpost.php?p=28637415&postcount=111
http://forum.xda-developers.com/showpost.php?p=48642782&postcount=153&nocache=1&z=6299363071261834
richardski
2013-12-30, 09:35
You'll have a hard time keeping out government, given the hw design seems to share eMMC and RAM between the APE core and the modem-radio core, and modem radio stack is very hardly ever getting opened for at least review (and even when it was, it would only reveal that there's no way to make sure there's no OTA backdoor)
IOW: modem can access your data, you can't access (or control) modem. Not even cryptfs will help to fix this.
/j
Fully agree with this bleak assessment of current SOCs, system boards and GSM/3/4/G modem integration. We need to "Make a Market" where the emphasis is customer security demonstrated by full and open access to the code running on hardware that is the property of the owner. Such market forces could create a profitable USP based on security and transparency for the next generations of SOCs.
The old "Trust in Me" we are a large corporate we will not spy on you for the benefit of our shareholders or governments, post Snowden, no longer works.
One thing Jolla did get right was a removable battery. No battery in the phone makes it very hard for the state to keep track of your location:)
Richard
Unfortunately QPST (Qualcomm Product Support Tools) seems to be some windows thingy. Would be nice to have that on Linux.
Unfortunately QPST (Qualcomm Product Support Tools) seems to be some windows thingy. Would be nice to have that on Linux.
Right. However, there are tools developed in Python which (might) be usable.
http://forum.xda-developers.com/showthread.php?t=2136738
ggabriel
2013-12-30, 10:51
Nonetheless I'm pulling my app from Harbour for the moment until Jolla opens up a bit. This means better kernel source publishing and more opensourcing of Sailfish core components. At the moment Silica qml libs and all required libs for running apps build with the sdk would be enough. I don't need the sources of every sailfish app like (musicplayer and so on)
Have you considered asking this in together.jolla.com so that people can vote and Jolla can react?
one thing I just don't understand in this discussion (not arguing, just don't understand). Why would the modem as a part of the SoC be a threat to the information integrity? I see it merely as a wcdma transport, if encrypted information goes in it just transfer it to the uplink, it goes over the rnc, to the downlink and to the modem of some other device. Sure, we don't know what goes on inside it, but if the data is encrypted it remains so the whole way. I suppose you say that there is a possibility or probability that it would relay the data to a third party (e.g. government)? In such case I suppose that weakness could be present through the whole chain, as usual. compromised servers etc. I don't get it. It's a passive component right? Are we making a hen of a feather? Trust me, I don't trust anybody or anything, but aren't we already out in the open?
one thing I just don't understand in this discussion (not arguing, just don't understand). Why would the modem as a part of the SoC be a threat to the information integrity? I see it merely as a wcdma transport, if encrypted information goes in it just transfer it to the uplink, it goes over the rnc, to the downlink and to the modem of some other device. Sure, we don't know what goes on inside it, but if the data is encrypted it remains so the whole way. I suppose you say that there is a possibility or probability that it would relay the data to a third party (e.g. government)? In such case I suppose that weakness could be present through the whole chain, as usual. compromised servers etc. I don't get it. It's a passive component right? Are we making a hen of a feather?
There are designs where the modem (and other parts of the system which run closed firmware blobs) is a separate HW entity which is connected to the main processing engine via a serial bus. In these cases you can treat it just as you describe, a black box that transmits your data up and down.
However, in some other designs the HW running closed blobs can directly access the flash&main memory of the device, and you have absolutely no guarantees on what it is reading/writing there (and when it does so)
The Qualcomm chipsets fall in the latter category :(
There are designs where the modem (and other parts of the system which run closed firmware blobs) is a separate HW entity which is connected to the main processing engine via a serial bus. In these cases you can treat it just as you describe, a black box that transmits your data up and down.
However, in some other designs the HW running closed blobs can directly access the flash&main memory of the device, and you have absolutely no guarantees on what it is reading/writing there (and when it does so)
The Qualcomm chipsets fall in the latter category :(
Well that sucks horseballs, in that case I guess it's a somewhat different story. Its another weakness, but probably even worse since it has unrestricted access to *anything*, regardless of on-disk encryption.
Guess there could be reasons that we have no idea about why they want their modem code closed.
Thanks for the explanation!
Guess there could be reasons that we have no idea about why they want their modem code closed.
Sure, if its compromised. Well, there you go, full access to whatever on a system-level.
This is what I want to achieve :P
To summarize possible ways to 'recover restore' Jolla:
1. We have images. Those can be restored using dd
a. On a working device in terminal. Allthough, this will give issues on some partitions, but, bootloader can be restored this way.
b. fastboot custom kernel with telnet access and using dd to restore backked up images.
2. Possibly using QPST tool (Windows, or perhaps Python script)
a. Not sure, but seems like images we have can be used restoring partitions. Windows only, unless Python tool can be used.
3. fastboot restoring images from SD-Card
a. There seems to be this option if entering fastboot mode without USB connected. We need to figure out what is expected on SD card here.
4. custom recovery
a. Jolla already made a simple recovery option to factory reset device. Can we create similar with backup/restore options etc.
ggabriel
2013-12-30, 13:47
Sure, if its compromised. Well, there you go, full access to whatever on a system-level.
This is what I want to achieve :P
Well, this is possible, but in modems of cheaper phones (dumbphones as they call it). You need some sort of kit though.
I guess the fact that the modem is locked down so much demonstrates how weak the cellular protocols are. I saw some nasty things being done with full access to a modem.
It does bother me, however, that the modem part can do whatever it wants. Time to move away from Qualcomm? :-)
The gsm/wcdma protocol stack is somewhat trusting in both ends. There are some messages and structures that have integrity protection but in general it is assumed that neither RAN nor UE is delibrately malicious.
For me not baltic sea but "will it blend" (http://www.youtube.com/watch?v=GAuhUTzNwiY)
Excellent idea to make your own blend.
Why not just keep the old bootloader to boot your image (factory reset) and for the the normal Jolla image, pinpoint which package that brings it in, modify it and share it ("ssu er unlockedboot").
djselbeck
2013-12-30, 14:14
Have you considered asking this in together.jolla.com so that people can vote and Jolla can react?
Hello,
good point, although I mailed it to jolla I created this two entries:
https://together.jolla.com/question/6778/request-publish-recent-kernel-sources-perhaps-even-with-git/
https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/
greetings
joerg_rw
2013-12-31, 10:03
Excellent idea to make your own blend.
Why not just keep the old bootloader to boot your image (factory reset) and for the the normal Jolla image, pinpoint which package that brings it in, modify it and share it ("ssu er unlockedboot").
I don't have the time and no interest in a device that's not "unbrickable" and needs hacks or even exploits to work with it. I already abandoned damn harmattan due to this.
I could sell the thing on fealbay when Jolla wouldn't delay the red TOH which will cause significant loss of money when not included in such purchase.
Jolla for Murphy award.
/j
i really hope this is not thegeneral attitude at Jolla
djselbeck
2013-12-31, 10:52
What is the context?
Update:
Got it, I'm not the twitter guro :D
i really hope this is not thegeneral attitude at Jolla
hmm.. JediTWang is not anyone with Jolla, he's the guy with nick @jayst here, I think?
joerg_rw
2013-12-31, 11:32
I sympathisze with djselbeck. but I don't get it at all. I refuse to use or learn that twitter slang. I even lack a clear indication this *is* twitter or what else it might be. I have no clue what all this is all about or what it meant to say. You completely lost me on the whole post consisting of a statement without context and a .png with pretty puzzling gibberish in it
ggabriel
2013-12-31, 11:32
hmm.. JediTWang is not anyone with Jolla, he's the guy with nick @jayst here, I think?
It's jalyst I think (I refuse to use the @ outside twitter), and it would be nice to get the context in full, given that this isn't twitter.
I'm unsure of what the issue is now that Jolla clarified their intentions and they are actively working on a solution for the bootloader.
djselbeck
2013-12-31, 11:35
I think for the moment we should all cool down a bit, celebrate new year and wait what will come.
As I've written Jolla IS working on a solution where the bootloader will be unlockable. Perhaps through the developer settings on the device it selfs.
So stay cool :) I'm outta here for this year :D
thedead1440
2013-12-31, 11:45
hmm.. JediTWang is not anyone with Jolla, he's the guy with nick @jayst here, I think?
Yup it's jalyst indeed and anyone who has read his posts would sympathise with Stefano... Asking for verification? Really? :facepalm:
i didnt a for clarification FYI jalyst did. But, I questioned Jollas liability given thelack of information and what they did so far.
Atually, I pointed put, that I hope they spend more time on a good soltion, rather than buggy quickfixes as they jst did.
rainisto
2013-12-31, 12:54
Here is a small spoiler for v0.2(*) that I've been working on...
-----------------------------
Jolla Recovery v0.2
-----------------------------
Welcome to the recovery tool!
The available options are:
1) Reset phone to factory settings
2) Reboot phone
3) Bootloader unlock [Current state: unlocked]
4) Shell
5) Exit
Type the number of the desired action and press [ENTER]:
*) Disclaimer: things can still change and features be added or removed before update hits your devices.
But the idea is that if devicelock code has been set, it will be queried, and you can unlock your bootloader and drop to root shell and do what ever you like with your device. And these actions may void the warranty just like developer mode (if your brick your device on purpose then its your fault).
djselbeck
2013-12-31, 12:57
Is the device code saved on rootfs or seperate partition? Just out of curiosity.
another question (i will try ad brick my device myself LOL)
It seems - from looking at bootloader - pssible to boot from SD card, even to restore an image from SD card.
Is this enabled in LK?
Yup it's jalyst indeed and anyone who has read his posts would sympathise with Stefano... Asking for verification? Really? :facepalm:
That's nice, why don't you read the entire thread before jumping to conclusions*...
I wasn't the one overacting in the discussion on Twitter (although I can understand Neil's frustrations), it's been resolved, by the way.
Oh, and a HNY to everyone & your loved ones, yeah!?!
*good luck with that on Twitter
i think those guys who have no choice but returning their devices, during holidays, are more frustrated. Yes, iam frustrated, that I cant help atm.
Reassurance have been given, also shows work is happening, during holidays.
Iam good with that . Also that it seems our loud voices is heard.
Happy New Year to you and all you have dear too,
bencord0
2013-12-31, 18:03
Here is a small spoiler for v0.2(*) that I've been working on...
[CODE]
3) Bootloader unlock [Current state: unlocked]
[...]
But the idea is that if devicelock code has been set, it will be queried, and you can unlock your bootloader and drop to root shell and do what ever you like with your device. And these actions may void the warranty just like developer mode (if your brick your device on purpose then its your fault).
Do you have a description/wiki page/blog post/source code about how this works?
It's my guess that it is possible to toggle this from software, since that's how the 1.0.2.5 update managed to lock it. I'm wondering what kind of script is required to undo the fastboot lockdown (or perhaps replace it with my own locking logic).
Do you have a description/wiki page/blog post/source code about how this works?
It's my guess that it is possible to toggle this from software, since that's how the 1.0.2.5 update managed to lock it. I'm wondering what kind of script is required to undo the fastboot lockdown (or perhaps replace it with my own locking logic).
Just flashing whole bootloader partition, methinks :D
richardski
2014-01-01, 00:08
Happy New Year to all with more freedom.
Richard
Just flashing whole bootloader partition, methinks :D
correct
i dd'ed a backup over the update and its back to unlocked state
bencord0
2014-01-01, 11:34
correct
i dd'ed a backup over the update and its back to unlocked state
Can you (and a few others) post a compressed dd dump of just that partition (with checksums)? Also which partition (under /dev/disk/by-partlabel/) is it?
Sorry for the paranoia, but I was foolish and didn't take a full image backup when I first got my Jolla. Executing random blobs from the internet etc.
Can you (and a few others) post a compressed dd dump of just that partition (with checksums)? Also which partition (under /dev/disk/by-partlabel/) is it?
Sorry for the paranoia, but I was foolish and didn't take a full image backup when I first got my Jolla. Executing random blobs from the internet etc.
sure, it is on my dropbox
https://www.dropbox.com/s/bwtrjndbfyzhakq/mmcblk0p17
(as name says, it is /dev/mmcblk0p17)
MD5 sum is 75e098788a7c8927debb10b1b12cccd0
richardski
2014-01-02, 01:08
Thanks for that image. Much appreciated
Richard
The stock kernel image, cmdline and initramfs are stored in /boot/boot.img (this is in mkbootimg format). There are several (Android) programs around to "unmkbootimg" this and get the raw kernel images et all.
I dared to unlock my bootloader again by restoring my saved mmcblk0p17. To verify that it works, I tried to boot the unmodified /boot/boot.img image by copying it over to my computer and then issue a fastboot sequence. However, that does not seem to work for me. The phone resets and I see the charging screen only.
However, the boot-telnet-initrd.img provided by djselbeck works fine.
What is going on here? Isn't the original image supposed to work over fastboot?
The phone resets and I see the charging screen only.
And right after I posted this I found out that it actually did work – I just wasn't aware of it. :-)
When the charging screen comes up, I need to press the power button long enough once to actually boot up the system.
Though having an overview of the partition layout on Jolla device will help. So, I compiled parted for Sailfish (it is on my openrepos)
┌(nemo@localhost)─(✗)─(08:31 PMMon Jan 06)
└─(/)─(46 files, 164Kb)─> sudo parted
GNU Parted 3.1
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: MMC MAG2GC (sd/mmc)
Disk /dev/mmcblk0: 15.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 17.4kB 4194kB 4177kB emgdload
2 33.6MB 67.1MB 33.6MB QOTP
3 67.1MB 71.3MB 4194kB Qfa
4 71.3MB 75.5MB 4194kB Qcfg
5 75.5MB 79.7MB 4194kB Qdlog
6 79.7MB 81.8MB 2097kB Qvariables
7 81.8MB 83.9MB 2097kB Qlogfilter
8 101MB 105MB 4194kB fsg
9 134MB 185MB 50.3MB ext4 Qglog
10 185MB 189MB 4194kB modemst1
11 189MB 193MB 4194kB modemst2
12 193MB 195MB 2097kB sbl1
13 195MB 197MB 2097kB sbl2
14 197MB 199MB 2097kB sbl3
15 199MB 201MB 2097kB tz
16 201MB 203MB 2097kB rpm
17 203MB 206MB 2097kB aboot
18 206MB 273MB 67.1MB fat16 modem
19 273MB 281MB 8389kB ext4 drm
20 281MB 294MB 12.6MB boot
21 294MB 306MB 12.6MB recovery
22 306MB 315MB 8389kB pad1
23 315MB 323MB 8389kB misc
24 323MB 856MB 533MB linux-swap(v1) swap
25 856MB 864MB 8389kB ext4 persist
26 864MB 864MB 8192B ssd
27 864MB 872MB 8389kB security
28 872MB 15.6GB 14.8GB sailfish
(parted)
joerg_rw
2014-01-06, 19:54
scary:
* lots of gibberish
* "drm"
* "security"
* why does this need to get done by a community member (kudos nieldk!)? Basically doing RE. Shouldn't such elementary fundamental stuff - including proper comments on purpose of each partition - be in the "Jolla 101" wikipage published by Jolla even before 1st device shipped? Dang, where's that URL to this wikipage? I seem to have lost it...¡
scary:
* lots of gibberish
* "drm"
* "security"
* why does this need to get done by a community member (kudos nieldk!)? Basically doing RE. Shouldn't such elementary fundamental stuff - including proper comments on purpose of each partition - be in the "Jolla 101" wikipage published by Jolla even before 1st device shipped? Dang, where's that URL to this wikipage? I seem to have lost it...¡
That crap is due to the Qualcomm chipset. The thing is built so that it needs all that hooba to boot up & work. Sad really :(
My next try :
Like, I believe Joerg_rw also found, is the 'secret mode' when pressing vol-up on power-on.
I believe this may be an entrance to a quick-recovery.
What I want to try (once I get around to buying a 16G SDcard)
This requires an unlocked bootloader.
insert 16Gb SD card
fastboot -i 0x2931 boot boot-telnet-initrd.img
telnet 192.168.42.17
dd if=/dev/mmcblk0 of=/dev/mmcblk1
power off
power-on - holding vol-up
And see if this will start a flash from SD card, now containing a proper partition layout, like the device.
Possibly, if it work, it is also doable to just create the partition layout on the SD card, and dd mmcblk0p17 to mmcblk1p17
What I was thinking the other day was a bit of similar thing that you have in mind;
I suppose it's possible to create a recovery kernel that actually swaps the mmcblk0 and mmcblk1 devices in the device so that if you have a copy of the filesystem on your external SD card you caould run the device fully on that.
I took an image of the entire /dev/mmcblk0 from the "fastboot rescue mode". This way I can view the partition layout with parted or gdisk on my computer without risking any damage by accidental modifications.
Not sure if there is anything useful in this, at least some of these have names that may reveal their function. I guess all those "Q*" partitions are something internal from Qualcomm and probably uninteresting. The bootloader chain would be "rpm" -> "sbl1" -> "sbl2" -> "sbl3" -> "aboot" according to some sources on other Qualcomm-based Android phones that turned up on a quick web search (sbl = secondary bootloader).
"persist" is mounted on /persist and appears to contain WLAN driver configuration, including MAC addresses. "drm" is mounted on /drm and it's currently empty despite the standard lost+found directory. No idea about "security" and some of the others, though.
I don't think these partitions are scary, this is just the way it is set up by Qualcomm as vendor. In defense of Jolla, what would be the purpose of documenting this publicly? I would even expect that the documentation provided by Qualcomm is under a NDA…
I suppose it's possible to create a recovery kernel that actually swaps the mmcblk0 and mmcblk1 devices in the device so that if you have a copy of the filesystem on your external SD card you caould run the device fully on that.
If you want to experiment with a different OS, you could just boot from fastboot with "root=/dev/mmcblk1pX" as kernel argument and run from the SD card.
For a clone of the "sailfish" partition, it would probably be a good idea to change the partition UUID to something different and change /etc/fstab accordingly to avoid mounting home or swap from the internal storage. Probably needs some more changes in /lib/systemd/system/*.mount for things like /firmware or /var/systemlog.
That list of partitions aren't necessarily all used (like drm and etc.), but are probably required for Qualcomm SoCs. Pretty weird layout if you ask me. Jolla should document that stuff in some hardware docs section. That would be community friendly. Unless Qualcomm forbids them to do it. No idea.
vBulletin® v3.8.8, Copyright ©2000-2025, vBulletin Solutions, Inc.