Recently, I came across N900 that - as in title - doesn't have 3th battery pin, the one used by BMI. It looks like it was, literally, torn out - and took soldering pad away with it. Quite uncommon damage, huh?

Anyway, the sole purpose of this lacking pin is to be connected to battery - via ~100kOhm resistor, so BMI can be happy and let us live - otherwise, it shuts device down - or, in case of booting, getbootstate (IIRC) aborts booting quite early (which, indeed, is the case for that poor device).

Otherwise, AFAIK, device is in perfect condition. So, getting to the point, I'm wondering if there is a way to save it? Could someone fluent in reading N900's schematics tell me, if there is, somewhere, at least moderately accessible alternative soldering place available (I could glue BMI pin on it's place and connect it with alternative pad via thin soldered cable)?

I determined that micro SMD "object" (resistor? diode?) just next to BMI port was connected to it (by probing other, working device), but there is no way I could attach a cable to something so small, sadly, even using needle-thing tip for soldering iron. Tried it for way too much hours, already

Or, maybe, there is a way to tell BMI/getbootstate to fsck itself from software side? Fake detection? Maybe Pali's getbootstate clone could be used to my advantage here?

Thanks in advance for help,
/Estel

hi, Estel. It would be much more better if you could just show us a picture

@blood_falcon, are you sure that a picture would help you to answer Estel's question?

@Estel, if what you say is right and all that 3rd pin does is connect to the + terminal through a resistor, then you don't need the pin. Just the resistor (on the board instead of in the battery).

Absolutely true! That was my initial thought, although, there is one problem - I need to have a place on the board, to solder it to (one end of resistor goes to battery ground, and another one to BMI PIN). After all, it's the N900 that senses resistance between battery PIN and ground (unrelated note - Ohm meter "app" abusing it, anyone?).

That's why I need other place on board that act instead of BMI pin, as it was torn out completely, including it's soldering pad. I tried to look for one in N900's schematics to no avail - but I suxx at reading those, and I might have, as well, missed one. OTOH, I remember that some folks know a lot of things about this BMI pin (esp. Neo900 team), so I hope that this particular board isn't lost forever.
---

On a "curiosity" note - original getboostate assign different flags depending on resistance between BMI pin and ground - there are some for "lab desk" (aka fixed power supply) and other cases - it have pre-determined resistance ranges for all labels. No actual impact on device's functioning in sold units, thought, probably a leftover from prototypes.

Also, some users speculated, that BMI pin is shorter, to make it disconnect a split second *before* actual power +- pins disconnect, so device may turn completely unsafe power-off into one slightly safer. Joerg theorized, that few thousands of opcode can be executed in that split second time (of course, no seeks or such things).

Last but not least, if the resistance is in the "battery" range (aka ~100kOhm via resistor fixed in battery between BMI and ground pin), then it's used as one determining the so-called "design capacity". In theory, it should allow manufacturers to "hardcode" what battery's design capacity is,and rx51_battery module reads it, allowing to compare with actual calibrated capacity from b127x00_battery, etc.

In practice, no one producing batteries (except Nokia, and even they failed to introduce new resistors in some batches of new 1400 mAh BL-5J) use it, and any_random ~100kOhm resistor is just thrown into battery's head. This result in some irritating twirks when rx51_battery starts to get used by thing like BMI replacement (like, having displayed 1261 mAh available out of 856 mAh max ).
---

Not that I need any of those features, and in fact, this BMI thing seems like "another useless thing that may get damaged and make device unbootable for no solid reason". Like, even R&D mode doesn't allow to ignore that damn reading. That's what happened in case of this Mobo, and I'm trying to find a way to overcome it, either in hardware (soldering resistor "somewhere"), or in software.

/Estel

If you want to boot that device you need either a patched preinit or a patched getbootstate. If you had U-boot/recovery console/backup menu/etc installed you wouldn't be asking

So, how to patch a binary on a device that is not bootable?

I assume USB works (because you tried setting R&D mode), so you can flash it. One option would be to create a customized firmware (I always wanted to do this), with U-boot, backupmenu, recovery, patched preinit, patched getbootstate, ssh, etc. all built-in.

Also note that, assuming Pali's getbootstate matches Nokia's getbootstate behaviour, if the boot mode is set to either FLASH, LOCAL or TEST the bootstate will be set to the bootmode without even looking at BSI or R&D.

AFAIK LOCAL and TEST is effectively the same as USER (i.e. should be enough to boot), so you could use the flasher to boot with a customized kernel commandline.

Sorry no details for now (severe lack of time..) but hopefully this will get you going. Otherwise I think it's time (for me) to someday start with the patched, flashable, firmware.

Yea - sadly, device wasn't in my hands before (and during ) getting that damage, so no U-boot and friends there.

That would be awesome thing - if you ever release it, I hope I won't miss the achievement announcement thread

That's some very useful info, thanks! I'm just wondering - even if device boot without even looking at BSI, wouldn't lack of BMI PIN make it shutdown as soon as system loads? You know, some pesky check, that ensures device power down in absence of "battery" (as device seems to eprceive lack of input from BMI as lack of battery...) - do we know anything about such mechanism?

Well, I guess I'll be the one to find out, as soon as I'll manage to actually boot

/Estel