**** BEGIN LOGGING AT Sat Mar 26 02:59:58 2016 Mar 26 09:38:59 hi Mar 26 09:39:33 jonwil: hi! how's lego train going? Mar 26 09:39:41 My LEGO stuff is going great Mar 26 09:39:59 :) Mar 26 09:41:20 Next thing I need to build is a couple more sideshow games then I need to add people to my golf course and sideshow games Mar 26 09:42:58 I have quite a few vehicles already Mar 26 09:44:23 I have a police car, a taxi, a van for my SWAT team, a petrol tanker, a Ute, 4 different buses and 3 lamborghinis Mar 26 09:44:56 I still need to build a prisoner transport and a police helicopter Mar 26 09:45:16 plus a bunch of 2-wheel vehicles for my police (motorbikes and bicycles) Mar 26 09:47:26 my petrol station looks great, I even built a custom signboard for it (with actual petrol prices taken from a local petrol station on the day I was making the sign) Mar 26 09:47:50 In other news, it was my birthday on Thursday :) Mar 26 09:48:04 Going out to a nice steakhouse for dinner to celebrate tomorrow :) Mar 26 10:01:24 Pali: summan anna said they will send some patches related to IVA2, I am waiting to see what will be send and will decide what to do next after that Mar 26 10:01:43 ok Mar 26 10:02:06 Pali: in the meanwhile did you see that gadget oops I sent on the ML? Mar 26 10:02:23 now looking at it Mar 26 10:02:31 ok Mar 26 10:05:08 I see just your twl patches Mar 26 10:05:11 not gadget oops Mar 26 10:17:15 Pali: "Re: USB gadgets with configfs hang reboot" Mar 26 10:18:30 I'm not using configfs Mar 26 10:19:03 Pali: the same bug prevents reboot on n900 Mar 26 10:19:10 reboot and poweroff Mar 26 10:19:29 hm... Mar 26 10:19:37 onenand corruption Mar 26 10:20:03 Pali: if g_nokia is not used, the device reboots just fine, with it it hangs Mar 26 10:20:58 Pali: do you have "ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption" ? Mar 26 10:21:14 I think yes Mar 26 10:21:20 in linux-n900 tree Mar 26 10:21:40 yes, there is Mar 26 10:22:19 well, your onenand seem to be corrupted before that patch Mar 26 10:34:25 Pali: no much options but a reflash :( Mar 26 17:20:01 Pali: I dunno how many hours it took, but finally http://projects.goldelico.com/p/gta04-kernel/source/tree/master/ loaded and rendered Mar 26 17:20:20 password protected Mar 26 17:20:47 yeah, you need to register first, lightweight process Mar 26 17:25:58 anyway I *really* wonder ehat the heck this server is doing, takes literally hours to generate and send content Mar 26 17:26:30 projects.goldelico.com/p/gta04-kernel/source/tree/gta04-next-upstream-twl4030-madc/ is not a tad faster Mar 26 17:27:02 neither is projects.goldelico.com/p/gta04-kernel/source/tree/master/GTA04 Mar 26 17:27:58 the wonders of webgit? Mar 26 17:40:11 still loading - weird enough it gets no server timeout Mar 26 17:41:42 Pali: you said there's a generic MADS interface in /sys/? Mar 26 17:41:50 MADC actually Mar 26 17:42:34 or in /dev/ ? Mar 26 17:43:25 if yes, you could check bupbat voltage in MADCIN9 Mar 26 17:44:22 if charging is actually enabled, it should be significantly >0 even when bupbat broken Mar 26 18:06:23 keep in mind it might have been disabled for some reason Mar 26 18:12:47 DocScrutinizer05: maemo kernel has /dev/madc* device and you can ask for value for any adcin channel Mar 26 18:13:17 in upstream kernel is madc hwmon device (/sys/class/hwmon) but doing some conversion and does not return "raw" value Mar 26 18:45:48 Pali: (ask for value) how? Mar 26 18:46:31 IroN900:/dev# echo 9 >twl4030-adc Mar 26 18:46:32 bash: echo: write error: Invalid argument Mar 26 18:46:40 IroN900:/dev# cat twl4030-adc Mar 26 18:46:41 cat: twl4030-adc: Invalid argument Mar 26 18:48:54 some nasty ioctl? Mar 26 18:51:29 WOW, bot URLs loaded Mar 26 18:51:33 both* Mar 26 18:53:02 yes, ioct Mar 26 18:53:04 *ioctl Mar 26 18:53:37 DocScrutinizer05: see: https://github.com/community-ssu/getbootstate/blob/master/bsi-read.c Mar 26 18:53:51 ta Mar 26 18:53:58 this will read channel 4 (line 54: "par.channel = 4;") Mar 26 18:54:11 and also channel 12 (line 63) Mar 26 18:54:41 output is in "par.result" Mar 26 18:56:24 yes, I see. I wish I had a working scratchbox env to make a simple knockoff that does "par.channel = argv[1]" Mar 26 18:56:52 err Mar 26 18:57:15 "par.channel = str2i(argv[1])" Mar 26 19:00:57 strtol? Mar 26 19:05:17 strtol(argv[1], 0, 0) Mar 26 19:09:10 of course I could try binary patching the original executable, but... meh! Mar 26 19:11:40 DocScrutinizer05: argc == 2 && (channel = strtol(argv[1], &endptr, 10), *endptr == 0) && channel >= 0 && channel <= 10 Mar 26 19:11:58 <=14? Mar 26 19:12:06 you need to check if argv is really number Mar 26 19:12:11 maybe 14, do not know Mar 26 19:12:19 don't bother, it simply will segfault ;-) Mar 26 19:12:56 it will not segfault, strtol will return 0 Mar 26 19:13:05 even better, yes Mar 26 19:13:31 it will segfault when argv[1] doesn't exist I guess Mar 26 19:14:04 argv[1] should always exists :-) argv is terminated by NULL Mar 26 19:14:20 and when argv[0] exists, then argv[1] must be NULL Mar 26 19:14:30 but strtol does not check for NULL... Mar 26 19:15:19 that's no problem, it returns 0 then Mar 26 19:15:41 anyway this is completely fine behavior for my purpose Mar 26 19:15:57 you get what you asked for Mar 26 19:16:21 maemo-madc 555 --> segfault Mar 26 19:16:26 100% ok Mar 26 19:21:42 Pali: btw maybe argv[1] is a string at some address with argv[1][0] = NULL, but maybe argv[1] itself is NULL, I.E. the address pointer points to 0x0000 Mar 26 19:22:12 I'm not that much into c programming anymore Mar 26 19:22:38 DocScrutinizer05: one of the two things is impossible Mar 26 19:22:45 man strtol doesn't tell what happens when &nptr == 0 Mar 26 19:22:49 are we talking about argv as in the second argument to main()? Mar 26 19:22:55 yes Mar 26 19:23:05 argv[1][0] can't be equal to NULL Mar 26 19:23:08 without some pretty creative casting Mar 26 19:23:15 why? Mar 26 19:23:16 it can be 0 Mar 26 19:23:22 echo "" Mar 26 19:23:22 it can be 0 yes Mar 26 19:23:29 typeof argv[1][0] is char Mar 26 19:23:32 if argv is a char**, argv[1][0] is char Mar 26 19:23:32 not char* Mar 26 19:23:37 sure, sorry Mar 26 19:24:35 GOD c makes me dizzy Mar 26 19:25:25 ok actually Mar 26 19:25:47 i'm not at all sure that a comparison between a char and a void* should return a warning Mar 26 19:25:57 the thing is, though Mar 26 19:26:11 argv is a list of address pointers to strings, and that list is stored in memory, starting at the address value of argv. No? Mar 26 19:26:24 if argv[1][0] is anything but 0, i don't think it makes sense to consider it in a pointer context Mar 26 19:26:56 but NULL is quite literally just something that's a null pointer in pointer context Mar 26 19:27:02 kerio: yes, a string is null-terminated Mar 26 19:27:06 `#define NULL 0` is a thing Mar 26 19:27:17 means it has 0x00 as termination char Mar 26 19:27:29 even though it typically is something like ((void *)0) Mar 26 19:27:35 yes Mar 26 19:28:19 s/list/array/ Mar 26 19:28:33 DocScrutinizer05: yes, argv is a pointer to a NULL-terminated array of pointers to C strings Mar 26 19:28:36 NULL is (void *)0 Mar 26 19:28:47 Pali: you're assuming that the c standard makes sense Mar 26 19:28:49 :> Mar 26 19:29:34 oooh, the array is open and NULL terminated? so if no argv[1] exists, accessing argv[1] reads form address 0x00000000 ---> segfault Mar 26 19:29:56 DocScrutinizer05: argv[1] always exists Mar 26 19:30:05 how so? Mar 26 19:30:25 unless you're in a freestanding environment, posix requires argv[0] to be the program name Mar 26 19:30:33 yes Mar 26 19:30:41 which means that argv always has at least one string Mar 26 19:30:47 yes Mar 26 19:30:58 so argv[1] is always a constructible and dereferentiable pointer Mar 26 19:31:04 er Mar 26 19:31:07 &argv[1] Mar 26 19:31:08 huh? Mar 26 19:31:13 so argv[1] exists Mar 26 19:31:26 yes, it points to 0x00000000 Mar 26 19:31:36 DocScrutinizer05: don't say stuff like that Mar 26 19:31:44 kerio: C11 says that: The macros are NULL which expands to an implementation-defined null pointer constant Mar 26 19:31:46 you can't know the bit-by-bit of a null pointer Mar 26 19:31:48 section 7.19 Mar 26 19:31:59 but yes, it could be NULL Mar 26 19:32:25 Pali: yes, but 0 is a valid null pointer constant Mar 26 19:32:26 reading from a NULL pointer is a segfault by definitionem, no? Mar 26 19:32:31 reading from a null pointer, yes Mar 26 19:32:38 i said that argv[1] exists Mar 26 19:32:44 pointer type is e.g. void* Mar 26 19:32:46 not that *argv[1] exists Mar 26 19:32:49 Pali: lmao Mar 26 19:32:50 so what? Mar 26 19:32:54 couldn't the virtual memory at address 0 be allocated? Mar 26 19:32:59 the array is open and NULL terminated? so if no argv[1] exists, accessing argv[1] reads form address 0x00000000 ---> segfault Mar 26 19:33:07 IIRC it used to be allowed to mmap at NULL Mar 26 19:33:11 Luke-Jr: compiler don't care, compiler don't give a fuck Mar 26 19:33:22 or rather Mar 26 19:33:25 C standard don't give a fuck Mar 26 19:33:35 Luke-Jr: try cat /proc/kmem Mar 26 19:33:41 if you have implementation-defined tricks to actually read from something with a physical or logical address of 0, that's your problem Mar 26 19:33:47 DocScrutinizer05: yes, dereferncing argv[1] (if is NULL) cause segfault Mar 26 19:33:56 what I say Mar 26 19:33:56 kerio: doesn't the C spec allow the compiler to do literally anything in such circumstances? Mar 26 19:34:07 but you can write: if (argv[1]) ... and this will not segfault Mar 26 19:34:14 Luke-Jr: dereferencing a null pointer is undefined behaviour, yes Mar 26 19:34:20 hmm, prolly Mar 26 19:34:37 but like i tried to say to DocScrutinizer05, null pointer mustn't be all-bits-zero Mar 26 19:34:44 all-bits-zero is a null pointer Mar 26 19:34:58 but talking about the bits of pointers is kinda weird anyway Mar 26 19:35:04 I don't care if it's all zeroes or your birthday or full of gremlins Mar 26 19:35:04 they're not guaranteed to be inspectionable like that Mar 26 19:36:20 I don't inspect them, I pondered what happens when you feed NULL pointer for &nptr to strtol() Mar 26 19:37:12 If endptr is not NULL, strtol() stores the address of the first invalid character in *endptr. Mar 26 19:37:27 that's why I hate c. You can't write half a line of code without getting into arguments about what it really does Mar 26 19:37:38 why are you even passing argv[1] to strtol Mar 26 19:37:54 HUHH? Mar 26 19:38:09 it's not possible to feed into &nptr Mar 26 19:38:12 what else would you pass to it? Mar 26 19:38:20 not as the end pointer Mar 26 19:38:21 nptr is in a register, it has no address Mar 26 19:38:30 who says ENDpointer??? Mar 26 19:38:32 hold on what's nptr Mar 26 19:38:36 oh, str Mar 26 19:38:37 kerio: the first arg Mar 26 19:38:44 looks like when nptr is NULL, then behaviour is undefined Mar 26 19:38:52 C11 does not say anything about it Mar 26 19:39:00 ye if it's not specified then it's definetely UB Mar 26 19:39:01 (section 7.22.1.4) Mar 26 19:39:03 have fun discussing c, guys Mar 26 19:39:07 I'm afk Mar 26 19:39:14 if you specify NULL for nptr, you get baby kittens Mar 26 19:39:19 :3 Mar 26 19:40:14 from your CD-rom drive jump cat and eat your usb mouse :-) Mar 26 19:40:51 5 bucks on segfault Mar 26 19:41:25 DocScrutinizer05: segfault is not guaranteed Mar 26 19:41:27 which is totally fine with me for this particular purpose Mar 26 19:41:50 it is not defined what happen... Mar 26 19:41:53 Luke-Jr: if it was, I had risked a 1000 Mar 26 19:43:00 DocScrutinizer05: do you know if backup battery is charning on n900? Mar 26 19:43:19 no, that's why I would like to read out MADC9 Mar 26 19:43:22 you send that screen where is written that in some condition charning is turned off... Mar 26 19:43:44 should I provide some armel binary which will read madc9? Mar 26 19:43:44 ...and that kernel needs to turn it on, yes Mar 26 19:43:54 I have arm cross compilers Mar 26 19:43:55 yes, pretty please Mar 26 19:44:17 that's how this mad discussion started ;-) Mar 26 19:45:03 I'd even prefer a binary that allows argv[1] to tell the channel Mar 26 19:45:18 without any fancy tests Mar 26 19:46:24 and if you really wanna go fancy, allow argv[2] for numebr of average samples Mar 26 19:51:13 if argv2 isn't present, should default to 1 Mar 26 19:51:41 if argv1 isn't present, I'm happy with any (non defined) behavior Mar 26 19:52:15 program ready :-) going to check if on my n900 Mar 26 19:52:56 if you want to do excessive tests, spit out usage on argv1 missing and check argv1 for range 0<=argv<256 Mar 26 19:53:31 :-) Mar 26 19:53:53 also add --version and --help like GNU says Mar 26 19:54:02 bwahaha Mar 26 19:54:15 did you know that /bin/true from GNU coreutils can return nonzero? Mar 26 19:54:16 and interactive mode ;-P Mar 26 19:54:40 kerio: prolly when invoked with incorrect parameters? Mar 26 19:54:49 no, true is supposed to ignore parameters Mar 26 19:55:02 using it as a throwaway command in makefiles and stuff like that is a common unix idiom Mar 26 19:55:04 then how could it return non-true? Mar 26 19:55:14 because they actually parse the commands and react to --version Mar 26 19:55:20 and --version needs to allocate some memory Mar 26 19:55:22 which can fail Mar 26 19:55:29 hahahaha Mar 26 19:55:33 or something like that Mar 26 19:55:39 rotfl Mar 26 19:55:54 oh wait, even easier Mar 26 19:55:59 --help and --version output things Mar 26 19:56:05 ohmy Mar 26 19:56:16 which means that you'll get an error if stdout is closed or full Mar 26 19:56:26 /bin/true --version >/dev/full Mar 26 19:56:57 bash is sane ;-) true --help ==> NO help Mar 26 19:57:04 yeah that's the builtin Mar 26 19:57:13 "This version of true is implemented as a C program, and is thus more secure and faster than a shell script implementation, and may safely be used as a dummy shell for the purpose of disabling accounts." Mar 26 19:57:20 L Mar 26 19:57:20 M Mar 26 19:57:22 AYY Mar 26 19:57:23 O Mar 26 19:57:44 https://atrey.karlin.mff.cuni.cz/~pali/files/madc.tar.gz Mar 26 19:57:45 /bin/true --help|wc -l Mar 26 19:57:46 18 Mar 26 19:57:48 have fun! Mar 26 19:57:55 \o/ Mar 26 19:57:59 many rhanks! Mar 26 19:58:32 "Note also the claim that there is no warranty, which in this case presumably means that if the program actually does something, you can't sue them." Mar 26 19:58:38 from http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html Mar 26 19:58:41 source + armel binary (for linux kernel 2.6.8+) Mar 26 20:00:48 DocScrutinizer05: please check if backup battery is charging and if not, try to write some patch or something to enable it... Mar 26 20:01:03 sure thing :-) Mar 26 20:01:41 freebsd doesn't even have a /bin/true Mar 26 20:01:42 I prolly won't write a patch (my c foo is way too weak) but I'll check what such patch needs to do and when Mar 26 20:01:52 apparently you don't need it to boot, so it's in /usr/bin instead Mar 26 20:02:12 LOL Mar 26 20:02:54 https://svnweb.freebsd.org/base/head/usr.bin/true/true.c?view=markup Mar 26 20:02:57 bigass copyrights Mar 26 20:03:01 and then just a return 0, like it should be Mar 26 20:05:52 IroN900:/dev# madc 9 Mar 26 20:05:54 Channel 9: 709 Mar 26 20:06:51 DocScrutinizer05: hold on why didn't you use python for this Mar 26 20:06:53 http://maemo.cloud-7.de/maemo5/usr/local/sbin/madc Mar 26 20:07:16 because my python actually sucks more than my c Mar 26 20:08:34 /usr/bin/true Mar 26 20:08:42 any other volunteers for madc 9 ? Mar 26 20:09:12 why is it in /usr/bin... Mar 26 20:09:18 why not Mar 26 20:09:28 Channel 9: 706 Mar 26 20:09:42 so it seems it's charging Mar 26 20:10:14 otherwise your value should differ significantly from mine Mar 26 20:10:16 granted one would hope nobody would be writing boot scripts that depend on true/false but they may well be. Mar 26 20:10:31 ecc3g: yeah but Mar 26 20:10:33 if they're scripts Mar 26 20:10:40 then true and false are going to be the builtins Mar 26 20:10:54 unless braindamaged shell Mar 26 20:11:02 that's true for bash. but the original bourne shell, no Mar 26 20:11:06 or rather, false Mar 26 20:12:17 well, bsd may have quite different definitions for what we at linux call FHS Mar 26 20:12:23 DocScrutinizer05: is there way to check capacity of that backup battery? Mar 26 20:12:49 errr, yes. check how long it takes after battery removal until RTC loses time Mar 26 20:13:03 we should totally rebase fremantle onto freebsd Mar 26 20:13:05 or probe voltage with a meter Mar 26 20:13:07 so we can use zfs Mar 26 20:13:23 and have negative ram at boot time Mar 26 20:14:12 Pali: another way would be to completely deplete battery (several days without main battery, with good bupbat even several months) and then check how fast it charges Mar 26 20:16:10 Pali: charging of bupbat also is CC/CV controlled and not instantly, so from speed of voltage rise at / after bootup from 'no main battery' you can tell the capacity Mar 26 20:17:38 even when bupbat not completely empty, the delta-volt/time will be the higher the less total capacity the bupbat has Mar 26 20:19:56 please see http://www.ti.com/lit/an/swca025/swca025.pdf - it's only a humbe 8 pages of very good info Mar 26 20:30:27 anyway for more specific investigation of the whole issue, we need to readout and possibly even set the BB_CFG resgister in TWL4030 Mar 26 20:34:33 http://wstaw.org/m/2016/03/26/plasma-desktopHq2219.png http://www.ti.com/product/tps65950?qgpn=tps65950 Mar 26 20:34:54 https://www.mail-archive.com/linux-omap@vger.kernel.org/msg45338.html Mar 26 20:35:34 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/327115.html Mar 26 20:37:09 also look at this log: https://support.logicpd.com/Portals/0/Users/049/05/305/20150427 - Ethernet over USBOTG as Host.log.txt Mar 26 20:37:18 uboot print this line: "Enable battery backup charger (BB_CFG = 0x1c)" Mar 26 20:39:22 :-D Mar 26 20:39:52 going to investigate if upstream kernel set bb_cfg register or not Mar 26 20:39:54 let's see what that means in detail Mar 26 20:40:17 DocScrutinizer05: can you via i2c-get read bb_cfg register? Mar 26 20:40:27 and check if charger is enabled or not? Mar 26 20:40:51 NFC, prolly I could if I knew which address it is Mar 26 20:41:27 unless some nasty module has the I2C bus exclusively opened Mar 26 20:41:57 use --force Mar 26 20:41:59 seems I need to check the OMAP3530 TRM to find out about registers in TWL4030 Mar 26 20:44:35 http://lxr.free-electrons.com/source/drivers/power/twl4030_charger.c?v=3.14#L238 Mar 26 20:46:51 aaah SWCU050G Mar 26 20:47:24 or your sourcecode, yes Mar 26 20:51:36 anyway you'll '*love*' that: swcu050g.pdf on page 89 has RTC registers **for secure mode** and for **unsecure mode** Mar 26 20:53:57 looks like conversion formula for madc channel 9 (backup battery voltage is): (raw * BK_VOLT_STEP_SIZE) / BK_VOLT_PSR_R; Mar 26 20:54:03 #define BK_VOLT_STEP_SIZE 441 Mar 26 20:54:09 #define BK_VOLT_PSR_R 100 Mar 26 20:54:18 file twl4030_bci_battery.c in nokia kernl Mar 26 20:54:32 that one provides http://projects.goldelico.com/p/gta04-kernel/page/Power/ Mar 26 20:55:21 but because it is hardwired into twl4030_bci_battery.c driver (for twl4030 charger), bk_battery part cannot be used alone Mar 26 20:58:53 http://wstaw.org/m/2016/03/26/plasma-desktopyJ2219.png Mar 26 21:00:56 https://github.com/pali/linux-n900/blob/v2.6.28-nokia/drivers/power/twl4030_bci_battery.c Mar 26 21:01:05 search for twl4030backupbatt_voltage_setup Mar 26 21:01:20 PSR is PreScalerResistor or sth like that Mar 26 21:01:41 it set BBCHEN bit in BB_CFG register Mar 26 21:02:00 DocScrutinizer05: if BBCHEN bit is not set, then charging is disabled? Mar 26 21:02:10 err yes, aiui Mar 26 21:02:27 are you able to read that bit from userspace? Mar 26 21:02:49 if I can find out which I2C register that is, then yes Mar 26 21:03:08 ok, I will try to find it from kernel sources Mar 26 21:04:30 Address Offset 0x12-0x12 in 0x17 byte increments Mar 26 21:04:31 Physical Address 0x0000 006D-0x0000 006D Mar 26 21:05:05 http://wstaw.org/m/2016/03/26/plasma-desktopyJ2219.png Mar 26 21:09:55 http://wstaw.org/m/2016/03/26/plasma-desktopKY2219.png Mar 26 21:12:47 http://wstaw.org/m/2016/03/26/plasma-desktopar2219.png Mar 26 21:13:18 i2c bus: 0; i2c address: 0x4b (TWL_MODULE_PM_RECEIVER); register: 0x12 (BB_CFG); value 0x10 (BBCHEN) Mar 26 21:13:54 this is calling kernel driver twl4030_bci_battery.c (if I decoded it correctly) Mar 26 21:14:13 makes sense Mar 26 21:15:47 BBCHEN is bit4 in BB_CFG Mar 26 21:18:06 so call? $ sudo i2cget -f -y 1 0x4b 0x12 b Mar 26 21:18:36 if 0x14 from uboot is correct, it sets BBCHEN= 1, BBSEL= 0 1 = 3.0V, BBISEL = 0 0 = 25µA Mar 26 21:18:51 yes, that should work Mar 26 21:19:06 it is safe to call it? Mar 26 21:19:12 prolly yes Mar 26 21:19:15 are you going to call that command? :-) Mar 26 21:19:22 yes, will do Mar 26 21:19:44 IroN900:/dev# i2cget -f -y 1 0x4b 0x12 b Mar 26 21:19:46 0x00 Mar 26 21:19:52 :-( Mar 26 21:19:53 hm... Mar 26 21:20:13 secure mode? Mar 26 21:20:19 $ sudo i2cget -f -y 1 0x4b 0x12 b Mar 26 21:20:20 0x00 Mar 26 21:20:41 do you mean omap HS mode? Mar 26 21:21:29 if HS mode stop your command, you would see SIGBUS signal Mar 26 21:21:40 and pagefault message in dmesg Mar 26 21:21:44 no, seems twl4030 has some write protection, however registers should be readable any case Mar 26 21:22:11 maybe it is correct output, just charging is disabled Mar 26 21:22:16 yes Mar 26 21:22:25 i2cset and enable it :-) Mar 26 21:22:44 but which value for bbsel and bbisel? Mar 26 21:23:16 twl4030_bci_battery.c in twl4030backupbatt_voltage_setup() set 0x10 Mar 26 21:23:21 are you sure about I2Cbus 1? Mar 26 21:23:33 yes, 100% Mar 26 21:23:39 already tried i2cset ;-) Mar 26 21:23:50 look at /sys/bus/i2c/drivers/twl4030/ Mar 26 21:23:55 I have there 1-0048 Mar 26 21:24:00 which means bus 1 Mar 26 21:24:13 also look at /sys/bus/i2c/devices/ Mar 26 21:24:25 they are in format "busnum-address" Mar 26 21:24:30 IroN900:/dev# i2cset -f -y 1 0x4b 0x12 0x10 b Mar 26 21:24:31 IroN900:/dev# i2cget -f -y 1 0x4b 0x12 b Mar 26 21:24:33 0x10 Mar 26 21:25:00 maybe your backup battery starts working? o? Mar 26 21:25:29 no idea Mar 26 21:25:32 so 0x10 is 2.5V and 25uA Mar 26 21:25:45 IroN900:/dev# madc 9 Mar 26 21:25:47 Channel 9: 708 Mar 26 21:25:52 yes Mar 26 21:27:07 going to recheck if address/register is correct Mar 26 21:27:10 IroN900:/dev# i2cset -f -y 1 0x4b 0x12 0x1b b Mar 26 21:27:12 IroN900:/dev# i2cget -f -y 1 0x4b 0x12 b Mar 26 21:27:13 0x1b Mar 26 21:27:15 IroN900:/dev# madc 9 Mar 26 21:27:16 Channel 9: 710 Mar 26 21:28:51 do you know how long can work rtc in your n900 without main battery? Mar 26 21:28:52 .oO(???) Mar 26 21:29:07 no, not realy tested yet, not long Mar 26 21:29:38 try to let it enabled for a longer time Mar 26 21:30:06 my rtc loose time in few minutes without backup battery Mar 26 21:30:21 I can do this test to see if it increase time... Mar 26 21:30:53 if charging of backup battery was totally disabled it is really stupid from nokia... Mar 26 21:32:04 http://paste.opensuse.org/80296157 Mar 26 21:32:38 --> no visible effect Mar 26 21:36:48 http://paste.opensuse.org/37478659 Mar 26 21:37:19 Pali: my rtc dies pretty much instantly Mar 26 21:37:26 swapping battery is enough to reset the clock Mar 26 21:37:34 maybe I need more context. Mar 26 21:37:40 Wizzup: are you going to try it? :D Mar 26 21:37:41 * Wizzup reads up Mar 26 21:38:37 Wizzup: http://maemo.cloud-7.de/maemo5/usr/local/sbin/madc Mar 26 21:39:20 DocScrutinizer05: if it is truth that backup battery was never charged, and n900 just totally discharged it... it is possible to charge such "fully discharged battery"? Mar 26 21:39:33 do you know what type of battery is it? Mar 26 21:39:54 or discharging that battery makes it permanent damage and dead? Mar 26 21:40:09 it's most probably a LiMn Mar 26 21:40:41 it should be immune against deep discharge, somewhat Mar 26 21:41:34 but those cells are notorious for blowing chunks after max 12 to 18 months, seen exactly same with Freerunner Mar 26 21:42:40 however that the voltage as seen by madc 9 doesn't change _at all_ no matter what voltage I set and if BBCHEN = 1 or 0.... verrrrry suspicious Mar 26 21:43:07 battemp is ADCIN4, right? Mar 26 21:43:27 no Mar 26 21:43:33 ADCIN0 is temperature Mar 26 21:43:43 ADCIN4 is BSI Mar 26 21:44:06 right Mar 26 21:44:35 what's your madc 0, madc 4 ? Mar 26 21:44:56 Channel 0: 62 Channel 4: 469 Mar 26 21:45:06 channel0=55 channel4=465 Mar 26 21:45:18 currently charging my n900 via wallcharger Mar 26 21:45:24 your room temperature a tad to the low side? Mar 26 21:45:43 aaah wait, it's inverted, right? Mar 26 21:45:49 yes Mar 26 21:45:58 somewhere I have formula Mar 26 21:45:59 so yes, makes perfect sense Mar 26 21:46:15 nevermind formula Mar 26 21:46:23 TEMP = (1/(t1 + 1/298) - 273.15) Mar 26 21:46:23 Where t1 = (1/B) * ln((RAW_ADC_U * 2.5)/(R * I * 255)) Mar 26 21:46:33 R = 100, B = 3380, I = 0.00671 Mar 26 21:47:09 so right it is inverted Mar 26 21:47:36 http://paste.opensuse.org/37195031 Mar 26 21:48:23 afk Mar 26 21:48:52 holler if you can think of another way to nuke my device via cmdline ;-) Mar 26 21:51:30 I let charging enabled... will see what happen... Mar 26 21:51:56 zilch will happen, I've set it to 1mA and notching changed Mar 26 21:52:31 anyway, I'll set it to 3V 1mA again Mar 26 21:53:08 meh, I set it to 3V3 1mA Mar 26 21:55:14 recheck if 0x4b 0x12 is actually the right address Mar 26 21:55:20 please Mar 26 21:55:28 already did it Mar 26 21:55:51 compare to some register with well known content Mar 26 21:56:00 that uboot doing this: val |= 0x10; twl4030_i2c_write_u8(TWL4030_CHIP_PM_RECEIVER, val, TWL4030_PM_RECEIVER_BB_CFG) Mar 26 21:56:26 #define TWL4030_CHIP_PM_RECEIVER 0x4b Mar 26 21:56:56 #define TWL4030_PM_RECEIVER_BB_CFG 0x6D Mar 26 21:57:15 hmmm BB_CFG is 0x6D why? Mar 26 21:57:52 linux kernel define BB_CFG as 0x12 Mar 26 21:58:13 here is that uboot patch: http://repository.timesys.com/buildsources/u/u-boot/u-boot-2011.06/u-boot-2011.06-omap3logic-BSP-2.2-0-01-201210241030.patch Mar 26 21:58:17 search for function twl4030_enable_bb_charging Mar 26 21:59:59 static inline int twl4030_i2c_write_u8(u8 chip_no, u8 val, u8 reg) { return i2c_write(chip_no, reg, 1, &val, 1); } Mar 26 22:00:22 i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len); Mar 26 22:00:46 DocScrutinizer05: uboot uses 0x6D and BB_CFG Mar 26 22:00:54 s/and/as/ Mar 26 22:00:54 Pali meant: DocScrutinizer05: uboot uses 0x6D as BB_CFG Mar 26 22:06:38 $ sudo i2cget -f -y 1 0x4b 0x6d b Mar 26 22:06:38 0x1b Mar 26 22:10:09 0x1b would mean 3.1V/1mA Mar 26 22:11:33 yes Mar 26 22:13:20 http://paste.opensuse.org/6040681 Mar 26 22:17:08 I wonder what the heck means Physical Address 0x0000 006D-0x0000 006D Mar 26 22:19:11 IroN900:/dev# i2cget -f -y 1 0x4b 0x6d b Mar 26 22:19:13 0x1b Mar 26 22:20:59 oooh, you already said that Mar 26 22:24:55 WOW! Mar 26 22:24:58 IroN900:/dev# i2cset -f -y 1 0x4b 0x6d 0x1f b; i2cget -f -y 1 0x4b 0x6d b; madc 9 Mar 26 22:24:59 0x1f Mar 26 22:25:01 Channel 9: 735 Mar 26 22:25:02 IroN900:/dev# madc 9 Mar 26 22:25:04 Channel 9: 735 Mar 26 22:25:38 IroN900:/dev# i2cset -f -y 1 0x4b 0x6d 0x1b b; i2cget -f -y 1 0x4b 0x6d b; madc 9 Mar 26 22:25:39 0x1b Mar 26 22:25:41 Channel 9: 709 Mar 26 22:26:23 I guess it's time for a hard reset Mar 26 22:26:44 messed around with too many random registers of twl4030 Mar 26 22:28:04 can't even find what's "physical address 0x12" Mar 26 22:28:29 to make matters worse I also messed with 0x6b by typo Mar 26 22:29:43 IroN900:/dev# i2cset -f -y 1 0x4b 0x6d 0x00 b; i2cget -f -y 1 0x4b 0x6d b; madc 9 Mar 26 22:29:45 0x00 Mar 26 22:29:46 Channel 9: 0 Mar 26 22:29:50 my bupbat is a dummy Mar 26 22:30:43 ooh wait, the ADC only works when BBCHEN Mar 26 22:30:45 iirc Mar 26 22:35:04 http://paste.opensuse.org/64107729 Mar 26 23:04:07 so charging of backup battery is enabled by default Mar 26 23:06:32 looks like Mar 26 23:06:42 1c Mar 26 23:06:50 err 1b Mar 26 23:07:17 wait... I forgot Mar 26 23:07:30 1b, right Mar 26 23:07:52 and madc 9 clearly follows with zilch delay on my device Mar 26 23:08:08 which means zilch buffering from bupbat? Mar 27 00:52:16 DocScrutinizer05: any hope of Neo900 upgrading specs at all? **** ENDING LOGGING AT Sun Mar 27 02:59:57 2016