How did the decision making process for the OEM/chip set work?

Continuing the discussion from Replicant support:

As soon as I get more info on how the decision making process for the OEM/chip set worked, I will post it here. This is what I asked a while ago:

  1. I want to know how and why the current chipset was chosen and what the alternatives were and why they and the possible related OEMs where rejected. (How was everything rated? What was most important to find a OEM or a chipset?)

  2. I want to see how the contract with the OEM (or however you call the people really making the phone are called) looks like and how FP will interact with them codewise (short: Will enough code be shared so that the FP project can fix issues easily and for a long time)

  3. I want to understand what part of the OS FP codes and what the OEM does codewise (short: Is the FP project only doing the GUI through another company or do they also have people that can fix Android itself if needed. How does the contract look like?)

I also asked about the money. Some information is already out there since yesterday.

3 Likes

Links I’m aware of so far:

The “Key Objectives” for "Using open source as a strategy towards longevity"
x https://www.fairphone.com/projects/creating-a-developer-friendly-software-environment/

How “Hi p” was chosen as the OEM, but no details on how the hardware/chipset was chosen:
x https://www.fairphone.com/2015/02/19/the-path-to-finding-our-new-production-partner-hi-p/

The “What operating system (OS) will the Fairphone 2 run? How open is it?” FAQ:
x https://fairphone.zendesk.com/hc/en-us/articles/204642759-What-operating-system-OS-will-the-Fairphone-2-run-How-open-is-it-

None of those answered my questions regarding finding a good chip set to reach the “Using open source as a strategy towards longevity” key objectives. Were other alternatives discussed? What makes the QC chipset a good one? Less blobs, better source code availability? Please let us know!

Just that people understand me correctly, I’m all pro Fairphone. But I want to understand how decisions are made and what drives them. Talking about this will also help making fairer phones because they will last longer and will be more stable … maybe some fixes from here can also go back into Android or other OSs. That would also add to the longevity of other phones!

x Free Software vs Open Source: A lot people here have misconceptions about OSS because there are different “flavors” out there. A current SoC system will never be able to be 100% “free” and I’m currently not looking for this kind of freedom with the fairphone.

x Them against us Open Source on the Fairphone seems to be a “ingroup” vs “outgroup” thing on this board. I have the feeling that some people here think that even discussing this “over and over” would attack the core values of the fairphone project and weaken it.
I don’t think so. It’s true that most people talking about this do often know more about technology and are also often FP1 users, but that doesn’t make us less valuable contributors. We know how it feels not to be able to update ones phone, even if one technically knows that it is very important to get these patches. We don’t want this to happen again with the FP2. That is all. And I still think that QC could deliver enough code to get this done.

I try to explain the whole SoC software problem as carefully as possible here in this thread:

x Replicant support for FP2

3 Likes

I’ve posted in the topic that this came from, but I also think it worth posting here…

The chipset can’t be seen in isolation when it comes to the choices made by FP for the design. Going back to this [blog post][1] from Feb about Hi-P, licence agreements needs to be in place in order for a manufacturer to use chipsets, and Hi-P already had agreements in place with Qualcomm. The considerations that FP made when choosing their manufacturing partner is explained well in that blog and I think it needs saying that the choice of chipset isn’t at the top of FPs list their interests are in intervention in the social and environmental side of the production.

[quote=“Chris_R, post:3, topic:9951”] (…) licence agreements needs to be in place in order for a manufacturer to use chipsets, and Hi-P already had agreements in place with Qualcomm.
[/quote]

Is it possible to see these licence agreements? Do they explain how code is shared/can get fixed? I’m not taking about bugs in ARM, but in other parts that could make updates to newer Android versions harder. As far as I remember Qualcomm was trying to be more open awhile ago https://www.codeaurora.org/, but I’m not sure if this was ever discussed with the OEM in greater detail or if this would be beneficial for the FP2/801 users.

And yes, you are not the first person pointing out that “the choice of chipset isn’t at the top of FPs list” and I agree. But I hope you will also agree that nobody wants recreate the FP1 issues with mediatek. I just want to be sure this topic was checked and looked into. I don’t think that is too much to ask. And yes, I read all the articles linked above more than once. I also tried to explain how I think SoC “IP” works in the replicant thread.

It is precisely that which leads me to believe qualcomm are seen as a safer bet than Mediatek

As for licences, I doubt that the exact details will be shareable, however that’s between qualcomm and hi-p anyway… The agreements are probably standardised… perhaps there is info on here somewhere: https://www.qualcomm.com/invention/licensing

I looked into this roughly, but I wish the FP project would provide an answer. I can only guess (see the replicant thread)

In short my questions regarding the contract go like this:

  1. “Will Qualcomm share enough source code so that if there is an issue the FP project and other people interested can fix and compile the code themselves?”

  2. “For how long will the QC binary blobs be updated for newer Android versions if they are needed for core functions?”

  3. “What blobs/how many are we talking about?”

I think the only people that can offer you these answers would be to contact FP directly and see if they can give you an answer. We only know as much as they say/share.

They have said they will have a blog coming out shortly on the open/software side of things, so perhaps asking them now they can answer these or variations of these in their blog…

True, and so I did. I hope someone will post an answer soon. I think official answers to this could really bring the project and the current phone forward. It doesn’t look hopelessly bad … but the code up there is not very fresh, stalled since 2012? But maybe there are newer resources elsewhere. We will see, hopefully soon.

I tried digging around on the Qualcomm site for related information.
https://developer.qualcomm.com/download/software

For other things I only get “Access denied” followed by this text:

“Effective October 1, 2012, QUALCOMM Incorporated completed a corporate reorganization in which the assets of certain of its businesses, as well as the stock of certain of its subsidiaries, were contributed to Qualcomm Technologies, Inc. (QTI), a wholly-owned subsidiary of QUALCOMM Incorporated that was created for purposes of the reorganization.”

So it looks like something at Qualcomm has changed since 2012, but I don’t know what, maybe this doesn’t mean a thing and the site was just restructured. I guess we need some insider knowledge here.

Hello, @keesj, @anon41484458, and @ralf_xda could you maybe add some additional information here from your perspective?

FP1 vs FP2 and the questions mentioned on the top? Do you get enough info and Android sources from QC/Hi-P for supporting the FP2 device longtime? Have you been involved in the process? Is it possible to prevent the “MediaTek … has chosen not to release any of the Android source code” issue and reduce the number of blobs?

Will be using the msm Android code and the Kwamecorp sources be enough to build an image for the FP2 phone? Or is extra information from QC needed that is not as public (blobs, etc) or a all the blobs in the official google branch?

git clone https://android.googlesource.com/kernel/msm.git (not empty, they just don’t have a default master branch)
The FP “OS”:
https://github.com/Kwamecorp/Fairphone

Thanks.

2 Likes

See, now this is being constructive and I applaud the effort. I don’t have a problem with the topic per se, but the way most people went about it in a non-constructive manner.

On topic: how many phones with the same chipset have received custom ROMs (like Cyanogenmod)? Is that any indication for what we can expect from FP2?

3 Likes

As I said, I was not able to find most sources for this (=FP2) in the public repros.

This is still something else as just “CM” support. But I’m new to this, I never really cared much about the technical aspects of a phone. All this branding and marketing of the same stuff over and over annoys me, I just want long lasting support.

But here you go:
http://wiki.cyanogenmod.org/w/Bacon_Info


The only blobs mentioned (in android_device_oneplus_bacon) are only the camera and the NFC. That would be a good thing. But somehow I don’t think that will be all …

Also a “nice” read about bloody marketing & CM. For me this shows how important all these “soft” software issues still are:

OnePlus One (Opo1)
Platform: Qualcomm Snapdragon 801/MSM8974AC
CPU: 2.5 GHz quad-core Krait 400
GPU: Adreno 330
RAM: 3GB

FP2:
Platform: Snapdragon 801/MSM8974AB-AB
CPU: Krait 400
GPU: Adreno 330
RAM: 2 GB

Very similar also: HTC One M8

Other Android based QC smartphones with a 801:

3 Likes

Hi,

Quick answer:

The Fairphone team is working on a blog with information about Fairphone 2 software to be released soon (in the next weeks). The blog may answer some of your questions, so I’d ask your patience until the blog is published and we’ve been able to lay out our progress before we go deeper into discussion.

Cheers,
Joe

4 Likes

Thanks Joe,

honestly, as a “community” member I prefer a quick answer from one of the FP devs over a fine-tuned PR blog entry.

I assume that you do this to prevent rumors, but most of the misunderstandings here happen because FP blog entries and FAQs do not contain a lot of hard content in the end anymore. Nice to read, but no details. And this is what starts the rumors and the critical questions that often would not happen if people here would get a few more pieces of information more quickly.

Like “Hey, I understand but were are still discussing the use of XXX with the XXX for the XXX with the OEM.”

An orchestrated approach to everything is not always necessary, I trust the people here if they give me information. But of course I will wait, what else can I do? I just hope that some day I will get the full story why all this is so complicated and how you deal with the OEMs; like how much margin for discussion is there at all? And yes, this includes the use of “more fairer” materials and “more fairer” software for me. I know not 100%, but “more” than the others.

But after reading the “Cyngn vs OnePlus” story, I think that being able to be a brand that can maintain its owns devices software long term is way more important than most people think here.

Just adding in that, if “in the next weeks” is after 30th Sept., then it will be to late for the crowdfunding goal of 15,000 sold devices. I and many others would really like to see that blog post earlier than that date (plus for many it is the info they are awaiting before placing an order).

5 Likes

I hereby update my own article for the possible update paths I see just by looking at wikipedia.

It’s important to point out that I care more about the “blob list” (the stuff one cannot get) and about the ideas how the fairphone project will ensure an ongoing software support.

Also I would like to know more about details on how all this is communicated with the OEMs that themselves are only buyers/licensed for the SoC, that itself is bought/licensed together.

Possible update/alternative OS/software pathways (based on Snapdragon 801 support, see links below)
Snapdragon 801 -> Android
Snapdragon 801 -> Android -> Fairphone UI
Snapdragon 801 -> Mer -> Sailfish OS
Snapdragon 801 -> Nemo
Snapdragon 801 -> Tizen
Snapdragon 801 -> cyanogenmod

Blob list (based on Snapdragon 801 support, see links below)
There is open source support for the WiFi wireless and the graphics module for the SD8xx.

Possible future hardware updates
There could be snap-in replacements for the SoCs (SD801, 805, 808, 810 … 820), that would include upgrade paths to newer Android versions and other hardware upgrades.

Risks
Pro: Good for people that want the latest Android versions and experiment with other os software for a longer time. Lots of software possible supported, if given access to all the right blobs.
Cons: Binary blobs, Licence changes with newer SoCs and more blobs, still Qualcomm. I also assume that the full board will have to be exchanged for upgrades (DDR3->DDR4, eMMC).

Links (OS)
x https://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems
x https://en.wikipedia.org/wiki/Mer_(software_distribution)
x https://upload.wikimedia.org/wikipedia/commons/1/1b/Mer_and_mobile_operating_systems.svg (overview picture)

Links (Hardware)
x https://en.wikipedia.org/wiki/Adreno
x https://en.wikipedia.org/wiki/Qualcomm_Hexagon
x https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers
x https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_devices#Snapdragon_801
x https://www.qualcomm.com/products/snapdragon/processors/801
x https://www.qualcomm.com/documents/snapdragon-801-processor-product-brief (PDF: easier to read)

4 Likes