It'll probably never happen according to
<http://wiki.maemo.org/Why_the_closed_packages#Specific_reasons_for_packages>,
but you never know so here goes:

> What component(s) or source packages/etc is the licensing change request
> about? 

bme-rx-51 on Fremantle, in initfs (not packaged) on Diablo.

> What component area is the component in if you know? 

System sw/dsm

> What is the current licensing of the component?

bme-rx-51 debian/copyright:

Copyright (C) 2004 - 2008 Nokia Oyj

Confidential.  You are not free to do anything with this package,
unless you have permission from Nokia Oyj.

> What licensing would you like it to be and why?

Open source, under (since the reporter mentions kernel integration) a
GPLv2-compatible licence.

> What project(s) would have benefit from this licensing change request?

Mer I guess, but you are more qualified to say :-)

> What technical purpose do you/your project(s) have for wanting the licensing
> change?

My personal itch is bug 6206 (since Nokia won't look at it).  Maybe it's
possible to move the sensitive parts into a library and open the daemon
(although that doesn't satisfy the reporter's request)?

(In reply to comment #1)
> It'll probably never happen according to
> <http://wiki.maemo.org/Why_the_closed_packages#Specific_reasons_for_packages>,
> but you never know so here goes:

It states "Battery Management Entity: Security. A misuse of the could lead to
serious battery damages that could result in liabilities for Nokia."
I see no logic behind this argument. Where do the relevant liability laws make
any distinction between ARM code and C code?

> > What is the current licensing of the component?
> 
> bme-rx-51 debian/copyright:
> 
> Copyright (C) 2004 - 2008 Nokia Oyj
> 
> Confidential.  You are not free to do anything with this package,
> unless you have permission from Nokia Oyj.

Worth noting: I have never copied BME (beyond what fair use allows me to), so
no copyright was infringed; however, nothing stops me from legally modifying
and reverse engineering the ARM code that shipped to me on my purchased
product.

> > What project(s) would have benefit from this licensing change request?
> 
> Mer I guess, but you are more qualified to say :-)

Pretty much any operating system that wants to run on Nokia products. This
includes at least Mer and Gentoo, to my knowledge. Another obvious beneficiary
project would include a forked BME with potential improvements.

Also, a note for whatever lawyers might review this... I'm a lot more likely to
make something explode if I need to blindly reverse engineer BME than if I had
documented code to work with. The changes I intend to make should be fairly
safe, but since Nokia is (currently) forcing me to reimplement everything to
achieve them, there is a higher risk that something might go wrong. With an
openly licensed BME, I could simply make the minor safe changes I want and
rebuild, without risking changing the rest. Therefore, the potential
"liability" concerns, if any at all, are greater for a closed BME.

Comment 4 Carsten Munk 2010-03-15 13:11:02 UTC

Evaluation:

Verification not a duplicate request: NOT OK, but I'm letting this one through
as it's time to have a sane discussion about it.

From
http://wiki.maemo.org/Why_the_closed_packages#Specific_reasons_for_packages
bme - Battery Management Entity: Security. A misuse of the could lead to
serious battery damages that could result in liabilities for Nokia.
hald-addon-bme is a related package, also closed. 

and https://bugs.maemo.org/show_bug.cgi?id=1584

Technical purpose: 

- Define a standard interface for battery charging (possibly moving BME code
into the Linux kernel)
- Change "battery critical" condition behaviour
- Change charging algorithms (trickle-charge if it's likely to be on AC
overnight anyway?)

OK, a relicensing to open source would help this. I will however note that this
kind of work requires expert knowledge. BME isn't a simple algorithm and
experiments may prove harmful - http://www.youtube.com/watch?v=YCWdnjLqVWw
(lipo fire) comes to mind.

Evaluating for priority.

No open source replacements existing: Positive, none exists that can provide
battery charging for Nokia 770/N8x0(W)/N900.

Aiding open source replacements: Positive, but a open source replacement

Closed package reasoning: 

Brand: Positive, no brand involved beyond behaviour. However, due to security
issues mentioned below it might damage brand.

Differentiation: Negative, there are probable Nokia patents in there. However,
BME is only useful on Nokia devices in binary form. In source form the
information may be used to interface with Nokia batteries and charging IPR.

Legacy: Negative on N8x0, positive on RX-51 (for now)

IPR & licensing issues: Negative, see above about differentiation and no idea
if there's third party code involved.

Security: Negative: Already noted as an issue.

Third party: Uncertain about third party code. BME code is an ancient beast and
may have many different third party contributors.

Relicensing reasons: 

   1. Fixing a bug: Positive, Might help fixing BME bugs
(https://bugs.maemo.org/show_bug.cgi?id=6206)
   2. Nurturing application development: none that I can see, except for
hardware hacks. 
   3. Spread of Maemo driven technologies to other platforms: Negative
   4. Community maintenance: Positive, may help community maintence
   5. Better architecture: Positive, userland process that covers a very
important component in the hardware interface

One or more projects: Mer, MeeGo, Gentoo, maybe even Maemo itself.

OK, so, conclusion:

To say it in a gentle way, BME is a can of worms. I will recommend against
reverse engineering it as this is not your grandfather's simple charging
algorithms and there is severe risk of blowing up things. There's a bunch of
patents and other things involved as well. While Nokia and Maemo may be happy
allow you to shoot yourself in the foot metaphorically, it may not be happy to
help injuring yourself physically :)

However, let us look at this in a practical way. The biggest issue currently
for all non-Maemo systems is redistributability of a very core component, the
charging and checks which without most OS'es actually would risk driving
battery below sane limits. I don't think this should be open source but I do
think we should be able to integrate it into our systems in a sane manner.

If there's bugs in BME, report them and let's see what we can do about them.
It's a critical enough component that we might be able to get bug fixing
support for the older devices too.

I'm proposing the following:

Priority MEDIUM since it's not a blocker, but I propose placing BME under a
license that allows binary redistribution and having that as goal. It's up for
discussion though if there's better ideas, keeping all the above in mind.

(In reply to comment #4)
> Priority MEDIUM since it's not a blocker, but I propose placing BME under a
> license that allows binary redistribution and having that as goal. It's up for
> discussion though if there's better ideas, keeping all the above in mind.

(Disclaimer: I know very little about how charging works). Would it be
technically feasible to split off the safety-critical functions to a separate
binary module that imposes appropriate checks, limits etc and open the code of
the daemon wrappers around that?  I'm thinking of something along the lines of
the old Atheros HAL, if that makes sense.

(In reply to comment #5)
> Would it be technically feasible to split off the safety-critical functions to
> a separate binary module that imposes appropriate checks, limits etc and open
> the code of the daemon wrappers around that?  I'm thinking of something along
> the lines of the old Atheros HAL, if that makes sense.

This would be infringement on the terms of the GNU General Public License v2.
Let's not encourage that.

(In reply to comment #6)
> This would be infringement on the terms of the GNU General Public License v2.
> Let's not encourage that.

Uhm, why?  BME is not linked to the kernel or any other GPLv2 code, and if it
was it would already be infringing.

(In reply to comment #7)
> (In reply to comment #6)
> > This would be infringement on the terms of the GNU General Public License v2.
> > Let's not encourage that.
> 
> Uhm, why?  BME is not linked to the kernel or any other GPLv2 code, and if it
> was it would already be infringing.

I'm assuming the case of being implemented in mainline Linux with that comment.
Sorry if it was unclear.

(In reply to comment #8)
> I'm assuming the case of being implemented in mainline Linux with that comment.

Right, sorry for missing the point.

Full GPLv2 would be great, though I can see why Nokia might reject that.  In
that case I think a partial opening should still be considered as a fallback
option, especially since it ties in nicely with Casten's preferred solution for
bug 7019.

As I understand it, the only safety concern in BME is that it currently acts
like a userspace driver to the bq24150 chip.
This can be configured in hardware for a 4.44V battery charging voltage - which
is unsafe.

The user already can if they choose to (or malicious software) overvoltage
their battery - simply kill bme, and use various i2c tools to do so.

However - a kernel bq24150 driver would make it more difficult to accidentally
damage the hardware - as the safety limit could be enforced there. 
As indeed it is for the LED flash drivers.

This would eliminate the possible safety impact of opensourcing BME - as the
kernel driver would enforce any safety limits.

Appreciating both the GPL idea and Nokia's interest in keeping the device safe,
I'd like to support Lucas' line of thinking as a rational compromise
(especially given that the component seems to be crucial in attempts to get
N900 hostmode running).

I don't see a real liability of Nokia for safety issues after replacement of
the official component, but I can appreciate the concern for their reputation. 
A scope reduction of the closed source component to something performing sanity
checks therefore sounds like the best way out.

Are there technical (hardware) concerns with such a solution, or is it a pure
licensing issue? 
Also I've read (in the forum, link not at hand right now - sorry) that while
BME would remain closed in MeeGo, Nokia would try to enable development around
it... does that mean that Nokia is considering such a compromise?

Comment 12 Quim Gil 2010-08-20 20:27:10 UTC

Hi, rephrasing feedback from my colleagues at Nokia working on BME and the
MeeGo Core architecture:

In Harmattan, the architecture of BME/Battery management has changed a bit from
what is was in Fremantle: more stuff has moved into kernel (bq24xxx chip
control) and that is planned to be opened. Charging state machine, battery
capacity calculation etc. is still going to be closed.

Architecture-wise, energy management is outside MeeGo and a probable scenario
is that we are going to see closed charging systems on many other HW platforms
too. This is one of the critical areas of commercial differentiation in high
end mobile devices and this is one of the reasons why Nokia prefers to keep its
development closed.

Still, if the chips used have an open datasheet (like in our case) in principle
someone could develop an open source alternative to BME.

One direction to look at is the Linaro project. They have a power management
team, maybe they can provide some information?
https://wiki.linaro.org/EngineeringTeam#Power%20Management

Leaving this enhancement request still open just in case there are still
questions to address.

(In reply to comment #12)
> Charging state machine, battery
> capacity calculation etc. is still going to be closed.

FAIL.

Comment 14 Quim Gil 2010-08-21 01:21:22 UTC

This is not a forum or some kind of microblog. If you disagree with the
decision please provide your arguments and recommendations to move forward.

The case has been explained, including what is being opened and why there are
parts that stay closed.

Will MCE be opened?

It (and it's clients) are battery eaters now.

(In reply to comment #14)
> This is not a forum or some kind of microblog. If you disagree with the
> decision please provide your arguments and recommendations to move forward.
> 

I argue that we should move forward by firstly offering the "basic" support for
which I paid 550$. By basic I mean that god awful Flash 10.1 that every
300-400$ android can enjoy (yes I'd be happy with unofficial too because
although only "some" devices have it, anyone can install&use it).

So my recommendation here is to focus on the closer and more logical things at
hand that at least "used" to work when we bought the device.

So maybe after the browser is actually working and the answer/reject buttons
stop jumping around the screen during an incoming call, we can pass from
Nokia's policy regarding BME to shall we say why the component that controls
the volume buttons is still closed [gotta check qwerty12's last "post" to
precisely know what my drift is].

Comment 17 Graham Cobb 2010-08-21 02:00:08 UTC

(In reply to comment #14)
> This is not a forum or some kind of microblog. If you disagree with the
> decision please provide your arguments and recommendations to move forward.

While I agree that comment 13 is not useful, I do agree with the sentiment. 
Nokia's view that battery management is a commercial differentiator and hence
it can (and will) keep it closed is not acceptable in an OS that wishes to be
considered open.  This is exactly the sort of thing that encouraged many of us
to become free software supporters in the first place: if Nokia want our
support, they should realise they are expected to contribute clever technology
like that back to the community.  If you want the benefits of open source you
need to learn that you differentiate on hardware, and service, not software.

As this is a decision that seems unlikely to change soon, a compromise that may
be acceptable to some members of the community (and not others) would be for
Nokia to contribute, and support, a usable open battery manager -- good but not
as great as the one with their own secret sauce.  So, my second recommendation
is that Nokia do that.

Comment 18 Quim Gil 2010-08-21 02:10:33 UTC

If Nokia wants to develop alone its own battery management software, why would
duplicate resources and efforts to develop an open alternative at the same
time? This approach would only result in two not-so-good solutions, missing the
original point. Remember that this is a business that has to pay salaries of
developers.

Apart from pressing Nokia, have you asked Linaro about their plans? Have you
asked in the MeeGo or Linux community whether other developers are interested
in the development of an open alternative? What about other Linux OS or device
vendors developing power management software?

(In reply to comment #18)
> Remember that this is a business that has to pay salaries of developers.

and the open source "advocates"!

thanks alot guys for making another bug next to useless with ridiculous amount
of noise.

Battery level measurement isn't exactly a walk in a park. Any value between
empty and full could be completely wrong because of voltage measurement
accuracy, ambient temperature and characteristics of li-ion cell. I see this
similar hw to display chip or any other internal component. Nokia has made
years of research and now it must be given freely to competitors?

Face it, there are no big corporations behind fully open systems (which
business model isn't baased to selling support...). You need to have some
secrets or Chinese bulk copypasters will make the money with your product.

And btw OP must be one helluva rich guy or own a battery factory (and lexan
cube for the device in case if battery casing cracks) if he affords to trickle
charge li-ion....

(In reply to comment #18)
> If Nokia wants to develop alone its own battery management software, why would
> duplicate resources and efforts to develop an open alternative at the same
> time? This approach would only result in two not-so-good solutions, missing the
> original point. Remember that this is a business that has to pay salaries of
> developers.
> 
> Apart from pressing Nokia, have you asked Linaro about their plans? Have you
> asked in the MeeGo or Linux community whether other developers are interested
> in the development of an open alternative? What about other Linux OS or device
> vendors developing power management software?
> 

So lemme get this straight
The call buttons bounce., Mic cant function properly *Other guy on the phone
cant hear a s**t I'm sayin'* for lord knows what reason, the speaker's volume
is reduced *coulda sworn it was "ok" in pr1.1.1*, and now, the drivers remain
closed.
Maemo by all means is a fail. *Heck, any "smartphone" after N95 series is a
fail*
and no drivers means porting OS is next to impossible.
and if Maemo is the only OS for N900, ultimately N900 is a fail too.
and oh, btw, i coulda sworn one of samsung's smarthpones went open source with
the drivers.
I seem to wonder samsung will face the same "issues" as nokia will.
What a waste of money.
"Score One For Nokia"

> So lemme get this straight
> The call buttons bounce., Mic cant function properly *Other guy on the phone
> cant hear a s**t I'm sayin'* for lord knows what reason, the speaker's volume
> is reduced *coulda sworn it was "ok" in pr1.1.1*, and now, the drivers remain
> closed.
> Maemo by all means is a fail. *Heck, any "smartphone" after N95 series is a
> fail*
> and no drivers means porting OS is next to impossible.
> and if Maemo is the only OS for N900, ultimately N900 is a fail too.
> and oh, btw, i coulda sworn one of samsung's smarthpones went open source with
> the drivers.
> I seem to wonder samsung will face the same "issues" as nokia will.
> What a waste of money.
> "Score One For Nokia"
> 

how does this relate to BME relisencing? pleas use talk.maemo.org for stupid
ranting.

As a general comment, let's please keep this discussion focused on BME and
avoid draging unrelated issues into it. Thank you :-)

(In reply to comment #12)
> Still, if the chips used have an open datasheet (like in our case) in principle
> someone could develop an open source alternative to BME.

FYI some people are already working on that (on N900 at least, previous devices
are apparently a lost cause precisely because they didn't use a documented
chip), see thread starting at
<http://talk.maemo.org/showthread.php?p=786833#post786833> (usual safety
disclaimers apply).

> Leaving this enhancement request still open just in case there are still
> questions to address.

Thanks.  The thing is, battery charging is a critical component without which
the device is just an expensive brick.   If opening the BME source is not on
the table let's see if there's anything else that can be done to improve the
current situation.  From my point of view (though not the original reporter's)
the reasons for the request are a) being able to run an alternative
distribution on the device and b) bug fixing.  

a) could be satisfied by a binary-only licence to distribute and run BME on
Nokia devices.  Is something like that possible at all?

As for b), to be honest I have no burning desire to dive into the code and try
to fix it and would be more than happy if Nokia did it and actually /released/
the fix.  Is there a way we could have the unreleased BME from bug 3144
released as non-free in the community SSU?

Comment 24 Andre Klapper 2010-08-21 13:06:08 UTC

Please note: Anybody abusing this once again as a forum to bitch about
unrelated issues instead of staying on-topic can easily get his/her Bugzilla
account disabled. You have been warned, more than once.

With regards to comment 20.
"Battery level measurement isn't exactly a walk in a park. Any value between
empty and full could be completely wrong because of voltage measurement
accuracy, ambient temperature and characteristics of li-ion cell. "

This is almost completely incorrect, and typical of what many people seem to
think.

http://focus.ti.com/docs/prod/folders/print/bq27200.html

This chip - http://wiki.maemo.org/N900_Hardware_Charge_Meter - is built into
the phone.
It is quite accurate at measuring the charge state of the phone, if BME allows
it to do its job.
With the stock software, BME shuts off at exactly the point the chip would
learn the cell capacity.

The charging algorithm also isn't magic.
Apply a charge current that does not cause the external power draw to exceed
maximum (1.?A for charger, 500/...mA for host), as long as the temperature is
under Xc and the cell voltage is under max.
Once cell voltage has hit maximum - keep it at this level for an hour, and then
let it drop naturally.

There are complications here - what happens if the battery is disconnected on
charge, how do old batteries react differently, has the user changed battery.
But this is not fundamentally complicated or interesting code.

I - for one - utterly do not care about relicencing this bit of BME.

It can stay as a closed blob - fine.

The bits I care about are the interfaces to this binary blob, especially
interfaces to other binary blobs that are undocumented.

For example.

As root type stop BME.

A number of bad things happen.
The battery meter applet stops working.
It stops doing anything when USB is plugged in.
...

There are a number of things that BME needs to know, and tell other bits of
software.

For example - how do I tell the phone subsystem 'emergency calls only' - I
might want this if temp >70C.

Conversely - how do I tell if there is an emergency call in progress - so that
I don't shut down normally on low battery.

How does BME inform the rest of the system as to battery state - over what
interface, ...

Hacking the charge part of BME has a number of potentially interesting to some
reasonable and safe use-cases.

For example - altering maximum battery charge state can improve battery
longevity, especially in the case of high temperatures.

http://batteryuniversity.com/partone-12.htm
http://www.thinkwiki.org/wiki/Maintenance#Battery_treatment and the thinkpad
windows software 'Battery MAXimiser.

Another example would be to allow for much larger batteries to work properly,
and proper support for changing batteries.

In short.
Re-licensing BME to get at all of the shiny nokia IP is
_COMPLETELY_UNINTERESTING_.

All that's wanted by those working on this problem are the interfaces that it
uses to talk to other closed parts of the phone.
Both hardware - Rupyama - and software.

Unrelated components aside, I think comment 21 made a very good point. Nokia is
"differentiating" their products by forcing them to suck (in this respect). BME
on N810 doesn't work outside Maemo (it runs and even forced shutdown on battery
low, but won't /charge/ the battery) and since it is closed nobody can fix it.
I'm not saying differentiation is a valid excuse (it certainly isn't a valid
reason) for closed blobs, but does Nokia *really* want their differentiation
hallmark to be "it doesn't work"? Because "it doesn't work" is realistically
the only thing that keeping BME closed forces.

Alternate licensing: how about a proprietary "for use only on Nokia devices"
source release?

(In reply to comment #20)
> Battery level measurement isn't exactly a walk in a park. Any value between
> empty and full could be completely wrong because of voltage measurement
> accuracy, ambient temperature and characteristics of li-ion cell. I see this
> similar hw to display chip or any other internal component. Nokia has made
> years of research and now it must be given freely to competitors?

If they are going to sit and claim they are doing an "Open Source" phone and
such, yes. That is what got many people to be drawn to the phone, hence why so
many people are pissed at Nokia. Compare Nokia with Intel. Intel surely has
done years of research, yet provide drivers for *all* hardware they create. 

Red Hat, Inc. is able to have it's developers work on "open source", yet not
run into the pay issues Quim states force Nokia to write closed software.

Also, the fact that these comments (not just here) go on is because Nokia gives
the illusion that if you just follow their opening queue process (or sprint
or...), that something will be done about it. "Just be patient" is the Maemo
slogan. I am not aware of anything being opened via the open licensing queue.

Comment 28 Quim Gil 2010-08-21 20:20:45 UTC

If we get the discussion at the technical level like e.g. Comment #25 then I
can point the URL to the BME developers for them to reply also in technical
terms.

If the discussion goes down to "business terms" on what Nokia should do, or it
goes plainly on forum level rant, then no developer will be happy having any
discussion at all. Neither myself, to be honest.

If someone doesn't understand this then probably doesn't understand either the
implications of this bug report. If that is your case please stay at
talk.maemo.org. We can continue the forum discussion there. Thank you.

For reference, this bug was opened specifically with regard to N810 (and
possibly N800) BME. N900 BME probably should get a new bug. The technical
problems with each are very different:

N810 BME:
- Runs from initfs before OS loads, so has all its dependencies in place there.
- Forces a shutdown at low battery, possibly undesirable.
- Doesn't charge the battery outside Maemo.
- Doesn't support standard Linux battery reporting mechanisms (sysfs)

N900 BME:
- Doesn't have an initfs, so only runs inside a Maemo OS install.
- Not practically usable outside Maemo due to daemon runtime dependencies.

Do note that forementioned bq27200 chip is supported by Linux since before
2.6.28, and only needs some minor platform glue to work, INCLUDING the
"special" battery charge level and other details. I have source for a kernel
module adding this glue if anyone wants it, and recently submitted a patch to
mainline adding it directly to the board file.

The hardware details for N8x0 and N900 are also very different. With N900 we
can do charge&monitoring easily from userspace with sh script and i2ctools. 

The hardware on N900 does all the work if you just tell it to "go". I'm
actually most of the time running my N900 without bme, using a set of scripts I
wrote for my own use so that bme wouldn't overcharge the mugen 2400mAh battery,
and so that I can get accurate charge level readings. No way to tell the rest
of Maemo 5 what's going on though, as comment #25 says.

The hardware on N8x0 has no public specs or datasheets available, and from
observing it in action, it seems to be entirely different from N900 and
slightly insane. There's some scarce information avaible on the internet if you
search hard. IIRC, the register for PWM of the charge is known. However,
without information on how to actually read back currents and voltages, knowing
how to set the PWM register essentially gives you a "Engage self destruct"
level of control of the hardware. Fun for fireworks or retiring your tablet
with style, I guess :-)

(In reply to comment #29)
> For reference, this bug was opened specifically with regard to N810 (and
> possibly N800) BME.

I see no (previous) indication it was opened only for the N8XX series. The OS
version in the report is 5.0/(3.2010.02-8) which is for N900.

Fixed.

Hm... just a Idea: 
If Nokia would release a BME module ported for all common OS including
documented API on all maemo/meego devices relased by NOKIA the most wouldn't
have a problem with the fact that this part is closed source.

So at example: If NOKIA would release a BME Module for Nitroid, Harmattan and
Meego 1.1 everything would be fine. Correct?

Quim, is this imaginable or totally impossible?

I doubt we have this kind of contact with Nokia.

(In reply to comment #33)
> So at example: If NOKIA would release a BME Module for Nitroid, Harmattan and
> Meego 1.1 everything would be fine. Correct?

No, it wouldn't. It still leaves us minority OS users in the dark (I use
Gentoo), and stifles new OS, including anything based on new versions of GCC
breaking binary compatibility (such as 4.3 to 4.4 or 4.4 to 4.5).

Just a side note:
All those people who voted thought that was a bug for N900's BME (or even
better BME in general). Well, is there anyway to remove my vote, because I also
thought that was for N900?

Sorry, but it's not my fault. The bug had a Maemo version for N900... Blame the
reporter.

Blame the person who changed it (aklapper@openismus.com). In my understanding,
N900 BME is trivial to replace, so not really important to have opened. Opening
N8x0 BME solves real problems, and gets the BME interfaces documented at the
same time.

(In reply to comment #37)
> Blame the person who changed it (aklapper@openismus.com). In my understanding,
> N900 BME is trivial to replace, so not really important to have opened. 

This is incorrect.
The charging functionality of N900 BME is - nearly - trivial to replace.
The undocumented interfaces to phone, ... are not, and this stops a replacement
BME being used with the default maemo software stack without extensive reverse
engineering.

(In reply to comment #38)
> The undocumented interfaces to phone, ... are not, and this stops a replacement
> BME being used with the default maemo software stack without extensive reverse
> engineering.

What does BME do with the phone? If it's just turning components on/off, then
reverse engineering it should be trivial too (and already begun with my GPS
driver...)

(In reply to comment #37)
> Blame the person who changed it (aklapper@openismus.com). In my understanding,
> N900 BME is trivial to replace, so not really important to have opened. Opening
> N8x0 BME solves real problems, and gets the BME interfaces documented at the
> same time.
> 

did that long ago

(In reply to comment #39)

> What does BME do with the phone? If it's just turning components on/off, then
> reverse engineering it should be trivial too (and already begun with my GPS
> driver...)

The phoneUI, not the hardware.
BME interacts with - at least - the charge meter, the CAL area of flash, BME,
MCE, dsme, HAL and the phone stack.
Most of these interactions are over undocumented interfaces.

Some are hard or potentially risky to reproduce.
For example - what does the phone do when heated to 70C?

(In reply to comment #41)
> (In reply to comment #39)
> 
> > What does BME do with the phone? If it's just turning components on/off, then
> > reverse engineering it should be trivial too (and already begun with my GPS
> > driver...)
> 
> The phoneUI, not the hardware.
> BME interacts with - at least - the charge meter, the CAL area of flash, BME,
> MCE, dsme, HAL and the phone stack.

Most of these components (that is, only the last one) have nothing to do with
the Phone app. What does BME do with the phone stack? The rest, for the most
part, should be part of the N8x0 BME source as I mentioned-- no need for N900
BME code to implement that.

> Most of these interactions are over undocumented interfaces.

strace works pretty well for any simple interfaces.

> Some are hard or potentially risky to reproduce.
> For example - what does the phone do when heated to 70C?

Now we're back to the hardware... why would the phone part ever reach 70C, and
why would BME have anything to do with it?

(In reply to comment #42)
> (In reply to comment #41)
> > (In reply to comment #39)
> > 
> > > What does BME do with the phone? If it's just turning components on/off, then
> > > reverse engineering it should be trivial too (and already begun with my GPS
> > > driver...)
> > 
> > The phoneUI, not the hardware.
> > BME interacts with - at least - the charge meter, the CAL area of flash, BME,
> > MCE, dsme, HAL and the phone stack.
> 
> Most of these components (that is, only the last one) have nothing to do with
> the Phone app. What does BME do with the phone stack? The rest, for the most
> part, should be part of the N8x0 BME source as I mentioned-- no need for N900
> BME code to implement that.

My above comments were based on the initial bug description, as it applied to
the N900.
I do not see how the n8x0 BME source is related here.
> 
> > Most of these interactions are over undocumented interfaces.
> 
> strace works pretty well for any simple interfaces.
> 
Sure.

> > Some are hard or potentially risky to reproduce.
> > For example - what does the phone do when heated to 70C?
> 
> Now we're back to the hardware... why would the phone part ever reach 70C, and
> why would BME have anything to do with it?

Because the users house is on fire.
Normally, shutting off the phone, if the temperature exceeds a given value is
sensible - say the phone has been left in a hot car.

If the user is making an emergency call - then it must not shut off.

(In reply to comment #25)
[...]
> In short.
> Re-licensing BME to get at all of the shiny nokia IP is
> _COMPLETELY_UNINTERESTING_.
> 
> All that's wanted by those working on this problem are the interfaces that it
> uses to talk to other closed parts of the phone.
> Both hardware - Rapuyama - and software. 
> 

There's really few left to say, as this post has basically all the points.
I explained to Carsten Munk several times about the security concerns regarding
exploding LiIon cells are moot for N900, due to bq24150 charger chip.

I've been watching BME for several weeks now - both controlling the USB Vbus
intake current and logging registers of bq24150 and bq27200 - and there's no
indispensable secret algo inside BME doing charging in a so much smarter way
than what bq24150 (a *dedicated* LiIon charger chip with own 'CPU' and
carefully designed algo to treat LiIon cells gently) would do. Even if there
were - we are not interested in it.

A few people understanding about bq24150 have charged their battery over and
over again by `stop bme` and using (slight modifications of) a ridiculously
simple shell script http://talk.maemo.org/showthread.php?p=658278#post658278,
thus proving there's no magic in BME we can't do without.

It's the - non existing - 'API' and requirement specs / abstract description of
BME basic operation principles and system integration that's a show stopper
here (Rapuyama, USB-core, PHY chip, ENUM, CPU clock / charge/discharge(!)
throttling, etc pp). I talked about that topic to Nokia guys (IRC #meego, Hah
and others), asking about such requirement spec and even offering they contract
me to create the needed specs from BME original sources while keeping all
presumed IP inside bme, with proper NDA and all. Reaction: basically "Nokia
doesn't have the human resources to look into it, and also there's legal issues
even with publishing a requirement spec" - go figure.

Now from this ticket we learn next kernel (whenever that's supposed to come)
will have sysnodes for bq24150 - fine. But that's really not even half way to
where we need to get. And, looking at e.g. LP5523 driver for an example how
kernel drivers get crippled and bult to specs including the bare minimum needed
for what Nokia thinks is sufficient, I'm seriously concerned these sysnodes
offer all the functionality offered by bq24150 and needed for e.g. hostmode
VBus boost, or jrbme.

is the decision final this bug is only about bme of N8x0?
How to remove a vote, or please remove the "N8x0" part as it was originally.

When I voted, I thought it is also about N900´s BME, which concerns me. Mugen
2400 mAh battery would be more usable if bme could be fixed. Nokia won´t
provide bigger battery, but seems also it won´t support 3rd party bigger
battery, although N900 IMO really needs one to be more usable.

(In reply to comment #45)
> is the decision final this bug is only about bme of N8x0?
> How to remove a vote, or please remove the "N8x0" part as it was originally.
> 
> When I voted, I thought it is also about N900´s BME, which concerns me. Mugen
> 2400 mAh battery would be more usable if bme could be fixed. Nokia won´t
> provide bigger battery, but seems also it won´t support 3rd party bigger
> battery, although N900 IMO really needs one to be more usable.
> 

click on vote for this bug
then you'll see the list of things u voted for
jus cancel the vote u made for this bug

(In reply to comment #45)
> When I voted, I thought it is also about N900´s BME, which concerns me.

I think everybody did, including the two people who reviewed the proposal back
in February and March: comment 1 talks about rx-51 (N900), and Carsten Munk
(one of the main players in all this) mentions N900 in his review in comment 4.
Why Luke decided to pop the "it's only for N8xx" issue up in August, well, I
guess only he knows.

Someone could go through the hoops of starting a similar bug for rx-51/n900,
but it sounds like Nokia will never open this.

Meh, since everyone else seems to have assumed this was for N900, I'll go ahead
and retroactively make it for N900 BME. :(
I'd open a new bug for N8x0 BME since that's much more needed to be open, but I
don't want to waste my time when Nokia's not going to budge anyway...

Comment 49 Quim Gil 2010-08-23 21:19:04 UTC

Please let's keep the subject at "Relicense BME". I will ask furthers the
owners of this component. First I want to check if there are chances to have
the new fresh development open (MeeGo-Harmattan). Based on the answer I will
check with Fremantle and Diablo.

If you have new technical arguments to explain in the context of this report,
please go ahead. Otheerwise please use talk.maemo.org.

Comment 50 Quim Gil 2010-08-24 00:12:32 UTC

On a sidenote, BME is being uploaded to the MeeGo repositories to ease the
distribution of MeeGo Handset images for the N900. This, in turn, eases the
distribution of BME as part of any community images for the N900.

We are waiting a fix for http://bugs.meego.com/show_bug.cgi?id=5622 to see the
actual rpms published, but in MeeGo Trunk:non-oss there now exists a package
bme-rx-51-bin with the following license:

"Copyright (c) Nokia Corporation 2010
All Rights Reserved.

This material, including documentation and any related computer programs, is
protected by copyright controlled by Nokia Corporation. All rights are
reserved. Modifying, adapting and/or translating, any or all of this material
requires the prior written consent of Nokia. Distribution for commercial
purposes not allowed without prior written approval from Nokia."

(Thanks Carsten for the pointer)

(In reply to comment #50)
> "Copyright (c) Nokia Corporation 2010
> All Rights Reserved.
> 
> This material, including documentation and any related computer programs, is
> protected by copyright controlled by Nokia Corporation. All rights are
> reserved. Modifying, adapting and/or translating, any or all of this material
> requires the prior written consent of Nokia. Distribution for commercial
> purposes not allowed without prior written approval from Nokia."

This implies (perhaps?) that non-commercial distribution is permitted. It
doesn't state that clearly though. Is it? For instance, can I mirror and
re-distribute it? What provision grants that?

Comment 52 Carsten Munk 2010-08-24 08:35:02 UTC

(In reply to comment #51)

> This implies (perhaps?) that non-commercial distribution is permitted. It
> doesn't state that clearly though. Is it? For instance, can I mirror and
> re-distribute it? What provision grants that?
> 

Jebba, a valid question I wondered myself.

While I'm not a lawyer nor a Nokia one, the premise of the license is to allow
non-commercial distribution from repo.meego.com and it's mirrors (not all
associated with MeeGo). Perhaps premise is that distribution isn't
traditionally disallowed by default or that by specifying commercial is not
allowed, the opposite (non-commercial) is allowed?

Since these servers the bits are supposed to be hosted on are not owned by
Nokia but LF/Intel/whoever, this license would have to imply this or the
licensing is useless for our purpose.

Quim, to clarify it might be good to ask Patrik if the license implies
non-commercial distribution is OK, so we have a record of this.

Comment 53 Quim Gil 2010-08-24 21:31:27 UTC

> Quim, to clarify it might be good to ask Patrik if the license implies
> non-commercial distribution is OK, so we have a record of this.

I just sent the question to him.

Comment 54 Quim Gil 2010-08-24 23:24:19 UTC

I just got confirmation that any Nokia software component with the following
license can be distributed for non-commercial purposes.

> "Copyright (c) Nokia Corporation 2010
> All Rights Reserved.
> 
> This material, including documentation and any related computer programs, is
> protected by copyright controlled by Nokia Corporation. All rights are
> reserved. Modifying, adapting and/or translating, any or all of this material
> requires the prior written consent of Nokia. Distribution for commercial
> purposes not allowed without prior written approval from Nokia."

I'm confused now - I removed my vote as I read that the bug has been changed
(reverted?) to N800-only, but now I read that it'll be retroactively re-changed
to N800 & N900 (which I'd still support)
Please clarify :)

at the moment, its universal
as in it represents both, N8X0 and N900

In harmattan is BME still closed, see:
http://harmattan-dev.nokia.com/pool/harmattan-beta/non-free/b/bme/

On meego gitorious is something related to BME open:
http://meego.gitorious.org/meego-device-adaptation/n900_libbme

Can somebody comment this?

n900_libbme is just a library for talking to BME, its got nothing to do with
BME itself which is still closed in Fremantle, Harmattan and MeeGo (on N900,
N950 and N9)

I just want to point out that the main reason why most people have argued in
favor of a re-licensed BME has not had to do with redistribution - while that
is a pleasant step forward, the greatest issue people in the comments have
expressed with BME is that how BME interfaces with other closed source blobs is
completely obscure and opaque, and all the difficulties that that causes.

Comment 61 Andre Klapper 2012-03-21 18:07:00 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia, hence resetting the ASSIGNED
status to NEW/UNCONFIRMED as nobody is working on this.

Note that very likely any feature requests for Maemo5 will not receive fixes
(WONTFIX) - I might mass-set this status in the future. There is a very small
chance for issues in open source components that contributed patches could be
included in the Maemo 5 CSSU Community updates - see http://wiki.maemo.org/CSSU
for more information.


For completeness (as Harmattan is mentioned in some reports), MeeGo 1.2
Harmattan used for the N9 and N950 is handled in
http://harmattan-bugs.nokia.com/ which has recently been closed for new bug
report entry [1].

[1]
http://www.developer.nokia.com/Community/Blogs/blog/n9-developer/2012/03/08/harmattan-bugzilla-closed-for-new-bugs