norly has quit [Remote host closed the connection]
norly has joined #neo900
vakkov has quit [Ping timeout: 255 seconds]
xes has quit [Quit: Going offline...]
vakkov has joined #neo900
norly has quit [Ping timeout: 252 seconds]
P-G has joined #neo900
starseek1r has joined #neo900
starseeker has quit [Ping timeout: 245 seconds]
JoHnY has quit [Ping timeout: 245 seconds]
JoHnY has joined #neo900
trx has quit [Ping timeout: 244 seconds]
trx has joined #neo900
<DocScrutinizer05>
also in line with the general usecase/purpose of not allowing coldflash access to device in "normal" situation like charging phone in a pub or wherever
<DocScrutinizer05>
since we change the uSD "power cutout" switch from battery lid to a switch integrated into the uSD tray itself, it also doesn't defeat loading MLO from uSD when battery lid is off
<DocScrutinizer05>
makes perfect sense since generally you might have opened battery lid anyway to swap the "normal" uSD for one with the MLO on it
quatrox has quit [Quit: Leaving]
<DocScrutinizer05>
NB that anyway when OneNAND xLoader is defect, the boot sequence continues and next in sequence is USB. So when xLoader actually is defect, coldflashing will work as usual ( - on N900)
<DocScrutinizer05>
even without removing batt lid
<DocScrutinizer05>
with batt lid open, boot sequence will look at uSD first for xLoader, even when a working xLoader exists in OneNAND :-)
<DocScrutinizer05>
the more I thnk about this, the more I like it
<DocScrutinizer05>
all thanks to pabs3's question :-D
<DocScrutinizer05>
(well, deciding about sysboot was on the todo list anyway... but...)
SylvieLorxu has joined #neo900
Pali has joined #neo900
<kerio>
DocScrutinizer05: is there a way to bypass xloader anyway?
<DocScrutinizer05>
you need some sort of xloader that fits into SoC's internal SRAM
<DocScrutinizer05>
it's yet to be discussed if that xloader also needs to be validly signed even on GP devices
<DocScrutinizer05>
I think it doesn't
<kerio>
no i mean, for the purpose of coldflashing
<kerio>
or maybe i don't have the boot sequence clear in my mind
<DocScrutinizer05>
coldflashing works basically same as noral boot, just it loads xLoader not from permanent storage but from a data interface (USB, UART3)
<DocScrutinizer05>
maemo flasher procedure loads a special xLoader that chainloads a special NOLO to RAM and that special NOLO is doing the flashing of normal NAND xloader+NOLO part
<DocScrutinizer05>
after that you reboot device to normal xLoader+NOLO and do the flashing of rootfs
<DocScrutinizer05>
HTH
<kerio>
normal maemo flasher, or coldboot flashing?
<DocScrutinizer05>
sorry?
<DocScrutinizer05>
please elaborate
<kerio>
the normal flashing doesn't load any NOLO, does it
<kerio>
or maybe it does cuz you flash NOLO anyway
<DocScrutinizer05>
no, normal flashing usually doesn't flash NOLO
<DocScrutinizer05>
afaik
<kerio>
sure as shit i expect flashing everything to flash everything
<DocScrutinizer05>
anyway, it's basically irrelevant if and with which parameters (--nolo-only ?) flasher-3.5 is flashing NOLO during "normal" flashing
<DocScrutinizer05>
point of "normal" (vs coldflash) flashing is: it's using a working NOLO in NAND to do the actual flashing
<kerio>
well, can you flash NOLO while running it?
<DocScrutinizer05>
why not? NAND is no XIP
<kerio>
is it loaded to ram from NAND before being executed?
<DocScrutinizer05>
yes
<kerio>
i thought there was a way to execute from NAND
<DocScrutinizer05>
insane, NOR is way more expensive and not available in the size you'd want. Particularly it's not available as MCP for PoP combined with RAM, heck it's not available as PoP at all afaik. And I think OMAP doesn't even support it as boot storage
<DocScrutinizer05>
and I don't see why you'd want NOR anyway, XIP is not a benefit in itself for user
<kerio>
but i want NOR so i can put ubifs on it so files get compressed so you can't do XIP anyway
<kerio>
:>
<DocScrutinizer05>
hehe
<kerio>
well, XIP leads to a bit less used ram
<kerio>
because the text of the program isn't copied
<DocScrutinizer05>
yes
<DocScrutinizer05>
except in linux where there's no such concept like XIP
<DocScrutinizer05>
you'd need to patch a lot of stuff to teach it NOT to load program text to RAM before execution
<DocScrutinizer05>
and not to swap it out to free RAM
<DocScrutinizer05>
sorry nonsense, program text never gets swapped out
<DocScrutinizer05>
it's simply free'd and reloaded from storage when needed again
<DocScrutinizer05>
afaik
<DocScrutinizer05>
so yes, when you completely discard swap and you switch away from ELF to some .com-alike memroy-image-format that doesn't need linking and relocating and stuff on program load and you patch the loader that usually does all that to simply mmap the XIP where that .com image of the executable lives, yes then you could probably turn linux into a XIP environment
<DocScrutinizer05>
that's hardly linux then anymore, though
<DocScrutinizer05>
rather it's the anti-minix. Where minix didn't use a MMU, this system would *need* a MMU to do the virtual relocation stuff
modem has joined #neo900
modem has quit [Client Quit]
modem has joined #neo900
<DocScrutinizer05>
anyway, add another product specs point to Neo900: Safe against threats from rogue "chargers" which inadvertently hijack device by coldflashing attack vector. In particular, permitting coldflashing needs special user interaction (remove battery lid) which is very unlikely to get done in rogue environments during normal device charging
<DocScrutinizer05>
add: Users with exceptional demand for threat protection can change this behavior of device so not even removing of battery lid enables such attacks. It needs a disassembling of device and re-establishing the soldered jumper to allow coldflashing, so the device is safe against the "leave phone on table in pub while p**ing" attack vector
ecloud_wfh is now known as ecloud
<DocScrutinizer05>
freemangordon: Pali: how hard would it be to change maemo userland to use SYSBOOT5 second function GPIO for input instead of GPIO160 batt lid hallswitch?
<DocScrutinizer05>
we need to change GPIO160 anyway, since GPIO160 uSD card "remove"/umount/powerdown is already reassigned to the switch in uSD tray
<DocScrutinizer05>
well, actually that means that some of the semantics of GPIO160 change, but the umount-uSD semantics stays all the same. While the "battery lid opened" sensor function should be done by read of sysboot5
<DocScrutinizer05>
TBD: check for possibly needed polarity inversion
<DocScrutinizer05>
aka logic level negation
<DocScrutinizer05>
sysboot5 shall be 0 when batt lid closed. Hall switch might work exactly the other way around
<DocScrutinizer05>
note to self: make sure hall switch VDD is stable sufficient time *before* system comes out of POR
<DocScrutinizer05>
in N900 that switch is powered by V28 2V8 rail
<kerio>
please don't make it so that i can't open the battery cover without forcibly detaching the uSD
<DocScrutinizer05>
V28 is provided by a VAUX1 of TWL4030
<DocScrutinizer05>
kerio: that's exactly the plan :-)
<kerio>
yay
<DocScrutinizer05>
TBD: check POR power up sequence of TWL4030, if VAUX1 gets enabled on reset
<DocScrutinizer05>
kerio: the idea is that some userland process (daemon) gets a signal when batt lid gets removed and user can configure if that deamon then umounts uSD, shuts down complete system into suspend-to-swap so user can swap battery, or simply ignore the fact
<kerio>
suspend-to-swap to swap batteries is cheating
<DocScrutinizer05>
the hard unconditional shutdown and deferred lazy umount will only happen when user opens uSD tray
<kerio>
k
<kerio>
i didn't know there was a sensor for that
<DocScrutinizer05>
in Neo900 there is
<DocScrutinizer05>
in N900... not
<kerio>
k
<DocScrutinizer05>
since we're short on GPIO, I'm extremely happy with my nifty synergetic concept of using sysboot5 for the "new" sensor (batt lid open), while old GPIO160 will simply move from hall switch to uSD switch
<DocScrutinizer05>
this also is completely in line with what N900 does, regarding sysboot5, just that N900 doesn't use a hall switch but the charger chop's emergency charger "LED" signal (steady yellow) to enable cold flashing
<DocScrutinizer05>
so you just witnessed how I re-invented what Nokia engineers already did, regarding boot sequence and unbrickability
<DocScrutinizer05>
funny since I only noticed what I actually did, a 3 mintes ago
<Pali>
gpio numbers are defined in kernel
<Pali>
and also what it means
<Pali>
so I think no userland change is needed
<DocScrutinizer05>
Pali: thanks, I noticed maemo kernel and userland won't need *any* patches thanks to the huge similarity in design
drathir has quit [Ping timeout: 244 seconds]
<DocScrutinizer05>
what we may want (though not *need*) is that new daemon waiting for a batt lid open IRQ on sys_boot5 pin and then "asking user" what to do about it. Such daemon not existing is simply same as a virtual user config "ignore batt lid open"
drathir has joined #neo900
<DocScrutinizer05>
:-D
<DocScrutinizer05>
that's the way I like system architecture: new additional features that don't have any impact on how the "old" system works. Just add drivers for the new features if and only if you want to use them
<DocScrutinizer05>
here the now feature is "act on batt lid getting opened", while the N900 reaction on that event (umount uSD) simply moved to uSD tray by hw changes
<DocScrutinizer05>
s/now/new/
sparetire has quit [Quit: sparetire]
<DocScrutinizer05>
Pali: freemangordon: do you know if omap34xx-boot-order binary ready out _current_ state of SYS_BOOTx pins or somehow tells about the values those pins had during POR latch
<DocScrutinizer05>
s/ready/reads/
<Pali>
do not know
<DocScrutinizer05>
IroN900:~# omap34xx-boot-order
<DocScrutinizer05>
sys_boot[5:0]: 0x10
<DocScrutinizer05>
I *could* try to force bw24150 CHRG_IND to toggle, so I'd see if the value omap34xx-boot-order returns (0x10) is changing
<DocScrutinizer05>
I'd prefer somebody checking the sourcecode - or point me to such sourcecode so I could check what it does
<DocScrutinizer05>
anyway I _guss_ I just revealed another rationale why Nokia EE did this nifty CHRG_IND -> SYS_BOOT5 thing: boot process speedup, when booting from battery
<DocScrutinizer05>
might be silly, might not actually work at all like I think it may, but it would be a good reason for that stuff
<DocScrutinizer05>
there are still some funny little secrets to discover, in N900 ;-)
<DocScrutinizer05>
one of them: "how coldflashing actually works"
<DocScrutinizer05>
N900 is a really nifty device, from an EE's POV
<DocScrutinizer05>
a pity the EE didn't sign it with their names. Kudos anyway
<P-G>
Just do you know, I can barely follow some of the stuff you say but you make me want to study electrical engineering. Hanging out in this channel is a blast.
<DocScrutinizer05>
:-)
<Sicelo>
madness in the method, haha, or method in the madness
<DocScrutinizer05>
NB Nokia *could* have hardwired SYS_BOOT* to sys_boot5=0: sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1 and simply rely on ROMBOOT only allowing coldflashing when xLoader in NAND is borked
<DocScrutinizer05>
but they inplemented that ultra-nifty CHRG_IND -> SYS_BOOT5 thing
<DocScrutinizer05>
which allows overriding and thus reflashing NAND xLoader even when that xLoader works
<DocScrutinizer05>
but aiui only when powering the device with a "weak battery" that lits up "steady yellow" from charger chip's chrg_ind signal
<DocScrutinizer05>
so that's Nokia's "hardware switch" you need to "press" to allow coldflashing (when xLoader is _not_ defect): a weak battery
<DocScrutinizer05>
CHRG_IND (aka 'steady yellow indicator LED') toggles SYS_BOOT5, so boot sequence changes to sys_boot5=1: sys_boot[4:0]=0b10000 --> USB UART3 MMC1 OneNAND
<DocScrutinizer05>
aka "sys_boot[5:0]: 0x30" from omap34xx-boot-order
<DocScrutinizer05>
so at least we now know(=) N900 is a HS device?
<DocScrutinizer05>
I guess it's not EMU and for sure not 0b011 = GP
<Pali>
yes, n900 is HS device
<DocScrutinizer05>
that's fun
<DocScrutinizer05>
reading arbitrary bytes that is
<kerio>
read 0
<DocScrutinizer05>
haha
<kerio>
that's always fun
<DocScrutinizer05>
I usually reboot diferent way
<Pali>
see file arch/arm/mach-omap2/id.c in linux kernel
<kerio>
...what's in bit 0
<kerio>
?
<Pali>
also arch/arm/mach-omap2/soc.h
<kerio>
*byte
<DocScrutinizer05>
a big surprise!!
<Pali>
#define OMAP2_DEVICE_TYPE_TEST0
<kerio>
i mean, it's not like ram starts from 1
<Pali>
#define OMAP2_DEVICE_TYPE_SEC2
<kerio>
aren't we wasting one byte
<Pali>
#define OMAP2_DEVICE_TYPE_GP3
<Pali>
#define OMAP2_DEVICE_TYPE_BAD4
<Pali>
#define OMAP2_DEVICE_TYPE_EMU1
<Pali>
this is in soc.h
<kerio>
if byte 0 isn't 42, i'll be disappointed
<DocScrutinizer05>
TA
<Pali>
SEC = HS
<DocScrutinizer05>
kerio: your question is actually more funny than I originally thought
<DocScrutinizer05>
:-)
<kerio>
.-.
<kerio>
don't mock me
<DocScrutinizer05>
nah, it's good
<kerio>
ok, then answer
<DocScrutinizer05>
the sort of question that makes hackers think
<kerio>
SIGSEGV when accessing (void *)0 is a C thing, isn't it
<DocScrutinizer05>
it's not exactly trivial to find an answer
<kerio>
and you're only accessing byte 0 of your process's virtual memory
<DocScrutinizer05>
I doubt that
<Pali>
I think you will get SIGBUS
<Pali>
SIGSEGV is when you access memory which is not mapped
<DocScrutinizer05>
prolly the MMU mem mapping of &0x0000 points to an illegal page, so MMU throws exception no matter what tools you use to access it
<kerio>
k
<Pali>
DocScrutinizer05: is not there way how to test if memory 0xABCDEF... is readable?
<DocScrutinizer05>
you *could* do a warm reboot and then read out &0x0000 by some low level code
<DocScrutinizer05>
Pali: dunno
<kerio>
Pali: it's easier to ask for forgiveness than to ask for permission
<Pali>
I still do not believe that there is no way to test if aes is enabled or not...
<DocScrutinizer05>
the question rather is: can you access it, not if it's enabled
<Pali>
yes, if I have read (or write) permission
<DocScrutinizer05>
I think firewall will prevent any access
<Pali>
I think it is stupid: try it and you will either get reboot or it will work...
<DocScrutinizer05>
it's secure domain afaik
<DocScrutinizer05>
prolly even romboot already assigns AES and other such stuff to secure domain
<Pali>
also windows (C) systems show you message about permission problems, and does not reboot whole computer if you try to read administrator folder :D
<DocScrutinizer05>
unless you write and sign an xLoader that doesn't drop secure state to let whole system run in secure mode, you'll hardly ever get access to AES aiui
<DocScrutinizer05>
GOD I'm sooo happy we have a GP device
<DocScrutinizer05>
that HS stuff is simply nasty
<Pali>
yes, secure boot is stuff is not secure for *us*
<Pali>
and HS devices are some kind of UEFI secure boot on x86
<Pali>
and SMM is really what emulates PS/2 (if mouse is usb)
<DocScrutinizer05>
ugh, mixing SMM with that HP etc board controller
<P-G>
That's one of those things I wish I didn't know about.
<Pali>
SMM mode was some bugfix for BIOS/DOS based applications when interrupt was not enough...
<Pali>
specially in real mode where application was running until it decided to pause...
<Pali>
"A digital logic analyzer may be required to determine if the CPU has entered SMM (checking state of SMIACT# pin of CPU)." (from wiki)
<P-G>
Is this still used in modern architectures?
<Pali>
yes!
<P-G>
:(
<Pali>
how do you think is implemented USB mouse and keyboard support in SETUP menu?
<Pali>
and also in GRUB?
<Pali>
and other MS based bootloaders?
<P-G>
I don't know but it has always bothered me...
<Pali>
SMM just emulate PS/2
<P-G>
I thought it was related to EFI standards.
<P-G>
And it is basically never encrypted?
<Pali>
also some parts of EFI is running in SMM (that tasks which must be called periodically)
<Pali>
what encrypted?
<P-G>
Ugh.
<P-G>
You said AES is an option for some hardware?
<Pali>
AES is on n900 :-)
<DocScrutinizer05>
AES is largely unrelated
<Pali>
omap3 has HW support for AES, but it needs to be enabled in x-loader
<DocScrutinizer05>
though you could think of ROMBOOT as a similar concept
<P-G>
I don't know what Omap is. :p
<DocScrutinizer05>
secure domain ~= SMM
<DocScrutinizer05>
~omap
<infobot>
http://OMAP.com/ or Texas Instrument's OMAP Platform is comprised of high-performance, power efficient processors, a robust software infrastructure and comprehensive support network for the rapid development of differentiated internet appliances, 2.5G and 3G wireless handsets and PDAs, and other multimedia-enhanced devices. #ol
<P-G>
:O
<P-G>
So processor series?
<DocScrutinizer05>
yep
<DocScrutinizer05>
ARM based
<P-G>
And if it has hardware support for AES then SMM could at least be protected to some extent.
<DocScrutinizer05>
hmm? no
<P-G>
:(
<DocScrutinizer05>
there's no SMM on OMAP
<P-G>
Oh, none at all?
<P-G>
Well isn't that good?
<DocScrutinizer05>
there's TrustZone/Mshield on OMAP, dividing all system resources (RAM, peripherals, etc) into a secure domain and a non-secure domain
<DocScrutinizer05>
AES hw accel is in secure domain and thus cannot get used by "normal" software
<DocScrutinizer05>
only by calls to secure monitor which is slightly similar to SMM
<Pali>
(only if secure software enable it for nonsecure)
<P-G>
AES hardware acceleeration would be used for OS layer cryptography?
<Pali>
errr. no, aes is used directly (no secure monitor)
<DocScrutinizer05>
oooh?
<Pali>
yes, but x-loader (which is in secure mode) must enable L3 firewall
<DocScrutinizer05>
sure, then you could reassign AES to non-secure zone. But that's prolly not what it's supposed to do. The normal way would be via SMI call I think
<DocScrutinizer05>
calling secure monitor
<DocScrutinizer05>
so secure moni has control who's using AES and who must not
<P-G>
Yeah, this seems much better than that SMM alternative...
<DocScrutinizer05>
s/SMI7SWI/
<Pali>
from code which we have for aes, sha, md5 and des it is not using secure monitor call
<DocScrutinizer05>
s/SMI/SWI/
<DocScrutinizer05>
hmm
<Pali>
all access direct memory
<DocScrutinizer05>
depends on sw implementation I guess
<DocScrutinizer05>
ARM designers prolly had some concept in mind when they decided to assign AES to secure domain by default
<Pali>
but it is possible to register own secure monitor handler (from x-loader), so I think it could be possible to implement it in that way how you think...
<DocScrutinizer05>
yep, exactly
<Pali>
without signing keys of course impossible
<DocScrutinizer05>
yep :-/
<DocScrutinizer05>
well, we get a GP device so nevermind ;-)
<Pali>
there is no aes, right?
<Pali>
or do we have?
<DocScrutinizer05>
dunno, rumor has it that not
<Pali>
some panda boards (GP devices) have crypto support
<Pali>
cannot you ask reseller for details?
* DocScrutinizer05
reads p195 SPRUGN4R
<Pali>
and for wifi/bluetooth/gps/3g/etc chips which needs binary fimrware... who will provide it?
<Pali>
hw aes support is nice to have feature, because it allows you to use disk encryption without big CPU usage
<Pali>
and something like secure "phone" should have support for data encryption
<Wizzup>
otoh, you can easily do that in cpu too, especially since the IO load is not that high.
<DocScrutinizer05>
so sorry it seems 35xx/37xx doesn't have AES
<P-G>
Referencing through something like SMI seems more manageable but direct access to AES crypto shouldn't be a security risk, right? No risk of spoofing validation?
<DocScrutinizer05>
P-G: on a clean untainted system AES is no problem either in sw or in hw accel. It's on systems where you expect "rogue" processes to run that you don't want those rogue processes interfere or eavesdrop a good process using AES
<P-G>
Ok so they could read the validation sectors. :(
<DocScrutinizer05>
and such protection of "good" processes from inteference by "rogue" processes is what this TrustZone stuff is all about
<DocScrutinizer05>
stuff like AES hw accel is just luring in users who don't notice the nasty concept this whole thing implements
<Wizzup>
too bad trustzone is buggy and not secure in most current chips
<DocScrutinizer05>
sure AES accel by itself is no bad thing. But it's implemented in HS devices for a purpose
<DocScrutinizer05>
and that purpose is Trusted computing, aka Aegis
<DocScrutinizer05>
aka TrustZone/Mshiled
<P-G>
So trustzone is like a network DMZ where services in the DMZ are allocated memory from a specific sector range?
<P-G>
Something like that?
<DocScrutinizer05>
HS devices will not boot when xLoader (the first bit of software loaded from storage to CPU) is not signed
<DocScrutinizer05>
xLoader runs in secure mode. It will make sure that no "rogue" software can run in secure mode/domain, and that no software in non-secure domain has access to the secure resources and processes
<P-G>
I think I understand but they are still usable memory right? Trustzone protects them as well?
<P-G>
Or maybe not.
<P-G>
Diagrams are scary.
<DocScrutinizer05>
you partition the RAM into segments that are trusted and such that are "normal". When a process tries to access RAM, the hw sends a signal along with the access if the process is in secure or normal state
<DocScrutinizer05>
no normal process can access secure ram segments (simpligied picture)
<DocScrutinizer05>
xLoader is respinsuble for the initial partitioning of RAM into secure and normal segments
<DocScrutinizer05>
resonsible*
<P-G>
Oh, ok. This is all RAM. I was thinking embedded because of hardware accelerated AES. :p
<DocScrutinizer05>
generally only secure processes can do the segmentation
<P-G>
I would hope so!
<DocScrutinizer05>
hehe
<P-G>
Sounds good though. :)
<DocScrutinizer05>
every single little hw resource block can either be secure or normal access
<DocScrutinizer05>
I dunno if that goes down to single GPIO granularity
<DocScrutinizer05>
but prolly it actually does
<P-G>
So services/daemons are validated as trusted or normal as well?
<DocScrutinizer05>
the nasty bit is: a correctly implemented TrustZone/M-Shield doesn't allow users to run *any* process in secure mode
<Pali>
unless process is signed or what
<P-G>
Fine by me, as long as I can read the code I don't need to touch it while it's running. :p
<Pali>
also from insecure worl (normal process) you can hook and modify secure monitor
<DocScrutinizer05>
signed (by chip manuf) xLoader(bootloader) only loads a trusted (signed) kernel, which in turn doesn't grant permissions on secure stuff to normal userland processes
<Pali>
but what you want to load must be signed by some key which will be accepted by xloader
<P-G>
I mean, running processes have a validation/signed status that is referenced during memory access?
<Pali>
yes, but aegis allows you to run your own ELF binary
<DocScrutinizer05>
just aegis is more finegrained regarding which permissions it grants to a process
<Pali>
binary which do math and hello world...
<DocScrutinizer05>
yes, but nothing else
<DocScrutinizer05>
;-)
<Pali>
but that MS shit does not allow you to run even those binaries!
<DocScrutinizer05>
I'm neither interested in windows nor in a simple hello worls app ;-D
<Pali>
and you can expecting that something similar will be implemented on desktops too
<Pali>
uefi secure boot (which allows to run only signed bootloaders) is there
<DocScrutinizer05>
yes
<Pali>
and there is only small step to force starting only "trusted" kernels
<DocScrutinizer05>
industry wants to reclaim comtrol over "their" devices
<P-G>
I agree with only running signed bootloaders, I just don't agree with only their bootloaders being signed.
<Pali>
I do not agreee with only signed bootloaders
<DocScrutinizer05>
well, there starts the problem
<Pali>
why should I wait until some crappy slow SW verify some signature??
<DocScrutinizer05>
who's signing ?
<Pali>
at boot time?
<DocScrutinizer05>
and how?
<P-G>
Let the user sign if they want to.
<Pali>
I want to start my system as fast as possible
<Pali>
and asymetric cryptography is not easy and fast!
<DocScrutinizer05>
P-G: that would be a reasonable approach if every platform had their own keys
<Pali>
you should know that it is too compilicated
<P-G>
Yeah, I don't expect it to happen any time soon but that is what I would like. :(
<Pali>
and ordinary users cannot understand that full certificate hierarchy/etc...
<P-G>
I don't know a whole lot about this stuff but I think people should be allowed to break their hardware if they want to.
<P-G>
They don't need to understand it, just let them understand it if they want to.
<DocScrutinizer05>
actually such homemade signature isn't really adding any level of security we couldn't have without all that signature stuff
<Pali>
and bigest problems: if SW is more compilicated it must contains more compilicated bugs...
<Pali>
and debugging problems at boot stage is pain!
<P-G>
Yeah, homemade signature isn't better than unsigned but it puts the user in control.
<Pali>
I think that boot process should be as easy as possible
<DocScrutinizer05>
you want sign your bootloader? why? to make sure no rogue bootloader runs on your system, it's sufficient that you don't allow installation of bootloaders without you nodding off that action
<Pali>
nothing like big init daemon which does everything...
<P-G>
No, I meant services.
<P-G>
Well, I guess the principle is the same.
<P-G>
I can dream!
<Pali>
I would like to have mechanical based switch can turn disk sector where is stored bootloader to RO or RW mode
<Pali>
this allows me easy and 100% working solution for security problems
<Pali>
and no asymetric cryptography is needed
<P-G>
That would be cool.
<DocScrutinizer05>
Pali: I guess on neo900 you basically will have that
<DocScrutinizer05>
OneNAND can get locked afaik
<DocScrutinizer05>
just write an according xLoader that locks itself
<DocScrutinizer05>
you could flash such locked xLoader only via coldflashing
<Pali>
SW switch can have bugs! mechanical not
<DocScrutinizer05>
that's a moot point
<Pali>
and mechanical is less problematic
<P-G>
Reality check, right now my phone runs apps and services with all kinds of crazy permissions. I'm really looking forward to a fully functional Neo900 for at least 20 different reasons.
<DocScrutinizer05>
Pali: ... and for coldflashing I basically introduced that "hw switch" some 3h ago
<DocScrutinizer05>
it's called Hall sensor resp 0R jumper
<DocScrutinizer05>
depending on how hard you like it to operate that switch
<DocScrutinizer05>
unsolder the jumper and your xLoader should be fairly safe from ever get reflashed. Particularly by a rogue program or a physical attacker that has no more than 30 min of time to install the rogue stuff
<P-G>
And that's assuming they've read the schematics.
<DocScrutinizer05>
...since to "throw that switch to 'enable' position" you need to disassemble the device and solder the jumper back in
<DocScrutinizer05>
and who knows, maybe there's an option to drill a hole into the PCB on a precise position (via) and you never again can flash your xLoader
<P-G>
Yeah. Depending on how sensitive the pins are you might be able to bridge them with a paperclip or something. :p
<DocScrutinizer05>
if that's still not good enough, you actually need a HS device
<DocScrutinizer05>
P-G: on FPBGA? hardly :-P
<DocScrutinizer05>
yes, you can completely disassemble the device and read out NAND and other storage in a different platform
<DocScrutinizer05>
only HS would protect you from that sort of attack. Or a concept where user enters a password each time he boots up device
<DocScrutinizer05>
(by "completely disassemble" I meant "unsolder the chips")
<P-G>
Drive encrypted sub-system contains the real boot loader.
<P-G>
Complicated enough?
<P-G>
You could also just apply liquid silicone or something to the pins. That stuff is impossible to get off without damaging the board.
<DocScrutinizer05>
you cannot apply anythong to FPBGA pins
<P-G>
No, the jumper.
<P-G>
To prevent cold booting.
<DocScrutinizer05>
well, drilling out a via sound like it's hard enough to fix
<DocScrutinizer05>
sounds*
<DocScrutinizer05>
I mean, this is a 8layer PCB
<P-G>
Oh, wow.
<DocScrutinizer05>
good luck with contacting an inner layer trace when the via is gone
<P-G>
I don't think I'll be drilling mine out though. I'm not *quite* that paranoid.
<P-G>
Yet.
<DocScrutinizer05>
:nod:
<P-G>
I would totally log hardware intrusion though. I'm not too paranoid for that.
<DocScrutinizer05>
hmmm. Wondering how to implement a hw intrusion detection
<P-G>
Use the hall sensor.
<DocScrutinizer05>
we could disconnect the bupbat and reset the RTC
<DocScrutinizer05>
(Hall) how would I do that when device is off?
<P-G>
Well, normally hardware intrusion uses a dedicated circuit but that may not be good in a phone.
<P-G>
You're using grub?
<DocScrutinizer05>
what we can ponder is placing a secret into a volatile RAM (like in RTC) and that volitile RAM gets reset when somebody tampers with device
<P-G>
You want to know if someone tampers with it while it's off though, right? It's easy to turn it off or pop out the battery.
<DocScrutinizer05>
hm?
<P-G>
The secret would reset whenever the device is powered off even if it's not actually tampered with, right?
<DocScrutinizer05>
it's a bit problematic to protect the part that will read out and compare the secrit on power-on
<DocScrutinizer05>
no, since we have a backup battery for real time clock
<P-G>
Oh. Hm.
<P-G>
But the RAM.
<DocScrutinizer05>
the clock has cmos RAM
<P-G>
Oh.
<DocScrutinizer05>
(maybe)
<DocScrutinizer05>
many do
<P-G>
Yeah, that would work if you can code it. I certainly can't. ;(
<Pali>
DocScrutinizer05: will be backup battery on neo900 easy removable?
<DocScrutinizer05>
no
<P-G>
Backup battery?
<DocScrutinizer05>
but we hope for it being better quality than the N900 one
<P-G>
I know the design specs called for hot swappable battery. Is that actually happening?
<DocScrutinizer05>
well, we'll see how fast you need to be to swap battery without system going down
<DocScrutinizer05>
NB, not related to backup battery
<P-G>
Oh. Great news though.
<DocScrutinizer05>
it's all about buffer capacitors and shutting down greedy comsumers as soon as battery disconnected
<P-G>
That's a cool way of doing it. I imagined a custom chassis with two small batteries. :p
<P-G>
Probably better to avoid that...
<DocScrutinizer05>
the design goal still is to power all greedy consumers directly from battery so they go down when battery removed, but don't deplete the buffer capacitors that "back up" the core system
<bencoh>
I suspect buggy drivers that will panic when they see the device disappear :>
<DocScrutinizer05>
modem for example can resume after a brownout of <1s or somesuch
<bencoh>
(hello wl12xx)
<P-G>
One second is pretty tight.
<DocScrutinizer05>
bencoh: yeah, wl12xx might be a problem. but then I see resets and firmware reloads for that during normal operation as well ;-)
<Pali>
which camera chip is choosed? and do we have driver for it?
<bencoh>
DocScrutinizer05: yup
<ShadowJK>
On N900 kernel doesnt freak out even if modem goes away
<DocScrutinizer05>
Pali: we use the original N900 cam modules
<bencoh>
ShadowJK: did you actually removed it while running ? :D
<DocScrutinizer05>
Pali: well, N97
<Pali>
N97?
<Pali>
and drivers?
<DocScrutinizer05>
yes, N97 which is N900 plus a flat flex connector
<ShadowJK>
if running without automatic shutdown on low battery, the modem dies before cpu dies when voltage droos
<ShadowJK>
drops
<bencoh>
ooh, right, I experienced that when calibrating my battery
<bencoh>
(I had a "no sim" icon)
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
Pali: so drivers of N900 sure shall work
<Pali>
ok
<Pali>
et8ek8 chip?
<DocScrutinizer05>
which is one of the huge points why the thing needs to be N900 compatible so maemo can run
<DocScrutinizer05>
yep
<DocScrutinizer05>
front cam is all the same like N900
<Sicelo>
pity N900 front cam is almost inexistent .. need strong light to 'see' anything with it
<DocScrutinizer05>
yes
<bencoh>
yeah it's quite unusable (I tried it for the first time ....)
<bencoh>
I wonder how they could sell to be honest
<Sicelo>
lol. customer discovers at home :p
<Sicelo>
no takebacks
<bencoh>
right, but .... :/
<bencoh>
how did the skype users do with it ?
<Sicelo>
seems skype did something to the cam .. was muuch better with it than with any other way of using that cam.
<bencoh>
does it use gstreamer as well ?
<Sicelo>
skype? no idea
<Pali>
Sicelo, because there is no SW for auto adjust white balance...
<Pali>
Nokia did not finished front camera support :-(
<DocScrutinizer05>
duh!
<Pali>
and userspace for camera middleware is closed
<DocScrutinizer05>
didn't they do "something" about frontcam in PR1.2 or somesuch?
<Pali>
you can use it for video call :D but quality is quality
<Pali>
maybe you can use some undocumented gstreamer pipeline or omap3camd closed daemon to do something
<Pali>
but no documentation
<Pali>
so you will see just dark image...
<DocScrutinizer05>
yep, no docs at all
<DocScrutinizer05>
anyway I got a line in bash history:
<Pali>
its just classic gst pipeline for v4l2 device with some ffmpeg filers...
drathir has quit [Ping timeout: 252 seconds]
<Pali>
freemangordon: there is *old* version of omap crypto driver (only sha1 and md5) and it can bi found on internet as file: drivers/crypto/omap-sha1-md5.c
<Pali>
DocScrutinizer05: will you get binary drivers from TI for GPU in neo900?
<DocScrutinizer05>
dunno where from
<DocScrutinizer05>
TI doesn't support Neo900
<Pali>
because this can be problem... without opengl es support, maemo will not work :-(
<Pali>
so we need working drivers
<DocScrutinizer05>
that's why I suggest to use maemo as is
<DocScrutinizer05>
the GPU is sufficiently identical to the one in OMAP3430
<Pali>
some ex-nokians wrote blog post, that pvr drivers depends on specific version of microcode which is in HW
<freemangordon_>
Pali: (crypto drivers) so what? elaborate please.
<Pali>
and even same GPU can have different microcode which needs different drivers
<Pali>
and so every vendor needs own drivers :-(
<freemangordon_>
DocScrutinizer05: I don;t think it is. nevetheless we can try the drivers from nemo
<freemangordon_>
there are drivers for both rev 121 (n900) and 125 (iirc, for n9/50)
<Pali>
freemangordon_: trying to start that old version of driver if we get that kernel fail too
<Pali>
still there can be bug in kernel which cause crash
<freemangordon_>
oh, sure
<freemangordon_>
but,but... wouldn;t it be easier to try that on KP?
<Pali>
because if Mshield cause reboot then kernel could not have time to print that error message to console...
<Pali>
and to dmesg
<Pali>
and to nand (where is log)!
<DocScrutinizer05>
well, when we would need own driver, there must be a way to get that driver from TI, no?
<bencoh>
hmm
<freemangordon_>
well, there is public GPU SDK
<DocScrutinizer05>
but honestly, N9 is using absolutely same CPU/SoC
<freemangordon_>
it is different rev
<freemangordon_>
not to say it is 535 iirc
<freemangordon_>
not 530
<DocScrutinizer05>
ohmy
<freemangordon_>
ok, ok, the diff is in clocking, but still
<DocScrutinizer05>
you say OMAP3630 has a significantly different GPU than DM3730?
<DocScrutinizer05>
c'mon
<freemangordon_>
no idea about dm3730, but 3630 in N9/50 has sgx535 afaik
<freemangordon_>
while 3430 in n900 has sgx530. AFAIK :)
<DocScrutinizer05>
so?
<freemangordon_>
and there are different drivers in Nemo for those 2
<DocScrutinizer05>
then why can't you use the driver from harmattan?
<freemangordon_>
because it is coupled with kernl driver
<freemangordon_>
*kernel
<DocScrutinizer05>
honestly we discussed all this more than a year ago
<freemangordon_>
yeah
<freemangordon_>
not that I remember the details :)
<freemangordon_>
anyway, I am afk on my way home, bbl
<DocScrutinizer05>
and you said we'll get maemo working on Neo900
<freemangordon_>
yep, no difference here
<DocScrutinizer05>
so what's this rant now?
<freemangordon_>
just saying that GPU is not exactly the same
<freemangordon_>
rant?
<DocScrutinizer05>
[2015-02-11 Wed 16:20:15] <Pali> because this can be problem... without opengl es support, maemo will not work :-(
<Pali>
hildon-desktop and stuff around needs opengl es
<DocScrutinizer05>
do you think this is a great strategy to tell now that the main goal of the project is az peril?
<Pali>
you can use mesa SW implementation
<freemangordon_>
DocScrutinizer05: calm down
<Pali>
but it will be slooooow
<Pali>
or patching hildon-desktop to not use opengl es
<freemangordon_>
noone is saying there will be no gles support
<DocScrutinizer05>
Pali said exactly this
<freemangordon_>
Pali: gpu will work with nemo drivers
<DocScrutinizer05>
pali said maemo won't work
<Pali>
with maemo I mean that hildon-desktop
<freemangordon_>
yes, got that
<Pali>
our GUI
<DocScrutinizer05>
heck when maemo won't work, I'll head to the officials and announce Neo900 dead
<freemangordon_>
but we have binary blobs for sgx535
<freemangordon_>
== drivers
<Pali>
we can use open source SW implementation of opengl es
<freemangordon_>
Pali: why?
<bencoh>
DocScrutinizer05: hmm
<Pali>
it should work, but it would be slow
<Pali>
backup plan :-)
<freemangordon_>
Pali: tell that to doc before he had a heart attack :) (backup plan that is)
<freemangordon_>
DocScrutinizer05: see, I can't be 100% sure those blobs will work on neo900 before I have the device in my hands, but the percentage is near that value
<Pali>
anyway we even did not see that HW and tried available drivers (n900, n9, some TI SDK, nemo)
<bencoh>
is there any prototype with a screen ?
<DocScrutinizer05>
yes, BB-xM
<bencoh>
on which we could just try the drivers ?
<freemangordon_>
DocScrutinizer05: do you have the device in your hands?
<DocScrutinizer05>
???
<freemangordon_>
as we can try to boot it with SGX driver enabled in the kernel
b1101 has quit [Read error: Connection reset by peer]
b1101 has joined #neo900
b1101 has quit [Read error: Connection reset by peer]
b1101 has joined #neo900
b1101 has quit [Client Quit]
b1101 has joined #neo900
arcean has joined #neo900
vakkov has quit [Ping timeout: 245 seconds]
<freemangordon>
Pali: shall I do something specioal so the battery to be calibrated with bme replacement?
<freemangordon>
*special
starseek1r is now known as starseeker
trx has quit [Ping timeout: 265 seconds]
vakkov has joined #neo900
<Pali>
charge it to full, disconnect charger and use phone normally until MCE turned it off
<Pali>
then charge it again until MCE show battery full
<Pali>
nothing speciall
<Pali>
hald-addon-bme do everything what is needed and emit correct signals to MCE when needed
<DocScrutinizer05>
you patched that to have shutdown threshold lower EV1?
<DocScrutinizer05>
EDV1
<freemangordon>
Pali: ok, thanks
<Pali>
DocScrutinizer05: yes
<DocScrutinizer05>
great! :-)
<Pali>
+30-60s
<DocScrutinizer05>
Nokia originally set it so that modem won't bail out
<DocScrutinizer05>
which is too high for learning
<DocScrutinizer05>
now yu'll see the "ShadowJK effect"
<DocScrutinizer05>
but that's better than never learning
<Pali>
this reminds me another question: I read and heard lot of "facts" about Li-Ion batteries
<DocScrutinizer05>
ooops, bencoh effect
<Pali>
and one of that say that you should not discharge battery to empty
<Pali>
its myth or fact?
<freemangordon>
can't we turn the modem off *if* the battery is not calibrated and the voltage is too low?
<Pali>
we can send dbus message "turn modem off"
<freemangordon>
yep
<Pali>
no idea what it is really doing
<DocScrutinizer05>
well, discharging to EDVF is more livespan reducing than 2 times discharging to 50%
<freemangordon>
Pali: I guess it ends up at modem reset gpio
<DocScrutinizer05>
freemangordon: why shut off when it does that automatically?
<freemangordon>
hmm? iirc it was behaving unstable. or not?
<DocScrutinizer05>
no, it shuts down
<freemangordon>
oh, it is ok then
<DocScrutinizer05>
you need to disable and re-enable it to restart, afaik
<DocScrutinizer05>
which would be in line with the ususal "press power button for 2 s to start"
<DocScrutinizer05>
even when battery voltage comes back, modem needs a kick to wake up again, I think
<freemangordon>
what will happen if we connact a charger in the meanwile?
<DocScrutinizer05>
same
<DocScrutinizer05>
ooh you mean to learning cycle?
<freemangordon>
no, I mean the modem
<DocScrutinizer05>
modem off is modem off
<freemangordon>
the point is - bme can turn it off on on low voltage, but it can turn it back on if a charger is connected
<DocScrutinizer05>
I guess the GPIO wll get pulsed to power it up
<DocScrutinizer05>
and shutdown done via "at" command
<freemangordon>
yep, the learning is doomed, but at least you don;t need to reboot to have the modem back
<DocScrutinizer05>
you don't ned to reboot, entering flight mode and back should do afaik
<DocScrutinizer05>
never tested that though
<freemangordon>
not very user-friendly :)
<DocScrutinizer05>
well, Pali recommended to wait till device shutdown anyway
<freemangordon>
sure, but you know (l)users ;)
<DocScrutinizer05>
actually my calibrate script was a candidate for that
<freemangordon>
myself included, I really expect devices to behave in a sane way no matter what
<DocScrutinizer05>
heck, you need to start modem again anyway, incl all config and stuff
<freemangordon>
the stack will take care of it if someone tells it
<DocScrutinizer05>
when you want device to 2behave" you make it shut down on modem bailing out on low voltage
b1101 has quit [Quit: b1101]
<freemangordon>
well, that is I said *only if the battery is not calibrated*
<freemangordon>
*is why
<DocScrutinizer05>
I'd not consider a follow-up problem of an initial non-conclusive behavior fix-worthy
<freemangordon>
and who is the SW guy here? :P
<DocScrutinizer05>
how about blocking charger when low voltage and modem already down?
<freemangordon>
I don;t think you can
<DocScrutinizer05>
sure I can
<freemangordon>
well, maybe this is better
<freemangordon>
and when you are going to enable charger again?
<DocScrutinizer05>
after device shutdown
<freemangordon>
which is again the same - you need to reboot to enable modem (and charger)
<DocScrutinizer05>
so what?
<freemangordon>
it is pretty obvious that *I* need my device right now, without a reboot
<freemangordon>
that is why I connected a charger
<freemangordon>
get it?
<DocScrutinizer05>
Pali said you need that to complete learning cycle anyway. There's no other reason to even even enter that pathological state
<bencoh>
hmm
<bencoh>
you dont need to turn it off iirc
<DocScrutinizer05>
you won't get your device *right now* even when you connect a charger
<freemangordon>
the learning cycle is screwed as soon as you connect a charger, aiui
<freemangordon>
bencoh: not of, but reboot
<bencoh>
CI flags was already set to 0 before n900 turned off
<bencoh>
-s
b1101 has joined #neo900
<DocScrutinizer05>
meh
<DocScrutinizer05>
I'm out
<DocScrutinizer05>
this is serious over-engineering introducing more bugs than fixes
<bencoh>
(I mean, "just before", I dunno how long)
<freemangordon>
DocScrutinizer05: and yes, I'll have my device right now on charger connected if the modem was shut down by bme, it simply has to turn it on again
<freemangordon>
modem starts in a matter of few seconds
<DocScrutinizer05>
aha and what makes you think the battery voltage will jump up by 0.5V or something in no time?
<freemangordon>
you think the modem is not connected to VBUS?
* freemangordon
checks
<DocScrutinizer05>
*sigh*
<DocScrutinizer05>
o/ afk
<freemangordon>
bencoh: the point was - because of the low voltage, the modem turned itself off, but mce still does not shut the device down, because the battery voltage is not *that* low. So, if a charger is connected at this time, you should somehow bring the modem up again.
<DocScrutinizer05>
which actually might happen automatically as soon as batt voltage is high enough for modem
<bencoh>
it might just be brought back up as it is, I dont know
<freemangordon>
yep, could happen
<bencoh>
DocScrutinizer05: :)
<freemangordon>
needs to be tested
<bencoh>
(I dont really want to go through a full discharge cycle again tbh - I dont have a devel device)
<DocScrutinizer05>
my lab PSU only has 0.1V granularity :-/
<bencoh>
PSU ? cheater :)
<DocScrutinizer05>
bencoh: check out my calibration script. It disables charger until learning cycle complete, then re-enables charging automatically
<bencoh>
the i2c thing ?
<DocScrutinizer05>
dunno if it also works with bme-replacement
<freemangordon>
btw, freshly flashed n900, KP53, cssu-thumb, connected to 3G and wifi, sitting on my desk, so far 3 days 6h with one charging
<Pali>
call i2cget with force
<Pali>
for bq27x200 it is safe
<Pali>
in kernel there is mutex for i2c bq27200 operations
<freemangordon>
does it use regmap?
<Pali>
no
<DocScrutinizer05>
cheers folks
<freemangordon>
hmm, maybe we should migrate it someday
<Pali>
but year (or two?) I checked source code and it is safe
<freemangordon>
DocScrutinizer05: hmm?
<DocScrutinizer05>
afk
<DocScrutinizer05>
RL
trx has joined #neo900
trx has joined #neo900
<DocScrutinizer05>
errrr, HD restarted (seen screen flicker and menu bar vanish and then show up again), on Feb 11 19:29:49 IroN900 browser[2134]: GLIB CRITICAL ** hildon-1 - hildon_window_get_is_topmost: assertion `HILDON_IS_WINDOW (self)' failed
<DocScrutinizer05>
no other logs in syslog
<DocScrutinizer05>
strange
<arcean>
any steps to reproduce?
<DocScrutinizer05>
few. a playing with gstreamer a few hours ago. And connecting device to charger some 2 minutes before. Possibly happened on screen dimming/locking which is enabled while charging
<DocScrutinizer05>
even the GLIB CRITICAL of browser seems all but unique
<DocScrutinizer05>
s/all but/not exactly/
<arcean>
hmm interesting
<ShadowJK>
Pali; Li-ion self destructs at too low voltage and at too high voltage. In extreme cases, the self destruct sequence will also destroy the thing it's in, and set fire to other things nearby.
<ShadowJK>
Pali; the manufacturer set voltage specifications are set as narrow as needed for the battery to wear out before it explodes
<ShadowJK>
Many RC people (or newbies) ignore it, and the hardware doesn't enforce it, so they end up with frquent battery fires :D
<DocScrutinizer05>
please don't spread scaring. N900 batteries *cannot* get deep discharged. They have built-in protective circuit that cuts out at ~2.5V or somesuch. No risk of fires or anything
<ShadowJK>
I claimed no such thing
<DocScrutinizer05>
discharge to shutdown voltage of OMAP system which iirc is 3V0 will not create any particular risk, it just will cause increased wear of cell
<DocScrutinizer05>
aah well, we probably understood Pali's question differently
<ShadowJK>
The manufacturer of the cell has specified absolute minimum and maximum of 2.5 and 4.2, the battery manufacturer has added a protection chip which cuts off somewhere between 2.5 and 2.8, and the phone itself shuts down around 3V
<DocScrutinizer05>
:nod:
<ShadowJK>
But if you were to use the battery down to 0V, you don't want to use it again
<DocScrutinizer05>
yes, absolutely
<ShadowJK>
Storing the battery below 3.5V makes it "crap" faster than when cycling it in a phone in daily use, in my experience..
<Pali>
ok, thanks!
<DocScrutinizer05>
protective circuit allegedly permanently shuts down when cell voltage drops significantly below those 2V5. And somebody suggested "kickstarting such batteries with a short pulse at 30 or 40V" - HIGHLY DEPRECATED!
<Pali>
and what about myth/fact which says that new battery should be first fully discharged and then fully charged (repeated 4-5 times)?
<ShadowJK>
false
<Pali>
it is really needed? or it cause shorted life?
<DocScrutinizer05>
that's urban legend
<DocScrutinizer05>
from times of NiMh or even NiCad batteries
<DocScrutinizer05>
it's about GTA01/02 batteries, but several of the facts in there are generally applicable
<ShadowJK>
It might be true for oldstyle NiMh and NiCd, but for the reinvented LSD NiMH type, attempts to quantify the benefit of doing 4-5 "forming cycles" has shown the benefit, if anything, is smaller than statistical variance
<DocScrutinizer05>
ShadowJK: :nod:
<DocScrutinizer05>
I guess it was for NiCd actually
<DocScrutinizer05>
NiMh had (/have) no memory effect
<ShadowJK>
memory effect is something alltogether different, and immediately reversible
<DocScrutinizer05>
well, it's about formation of cell chemistry
<DocScrutinizer05>
which - in sligthly different form - I guess is what happens on that "drive-in" of fresh NiCd
<ShadowJK>
Overcharging causes in nicd and nimh loss of water, and the plate material starts changing into a material with higher internal resistance and lower emf potential..
<DocScrutinizer05>
I admit I have no good info about what happens during "drive-in"
<ShadowJK>
.. which is what people usually referred to when saying "memory effect", their batteries had been cooked by shitty chargers
<DocScrutinizer05>
overcharging? not related to memory effect
<ShadowJK>
Memory effect is *hard* to reproduce
<DocScrutinizer05>
nah, memory effect is loss of capacity that never gets used
<Pali>
and what are ideal contitions for laptop Li-Ion batteries? periodically discharge/charge battery? or let charger connected (even for 5 days) when laptop does not move to another location?
<ShadowJK>
voltage depression due to overcharging is easy to reproduce, and is what normal people thought was "memory effect"
<DocScrutinizer05>
when you always discharge NiCd to 80% and then charge to 100%, they eventually don't want to "give away" the remaining 80%
<ShadowJK>
DocScrutinizer05; that's true, but it's actually hard to reproduce
<DocScrutinizer05>
that's what I recall as memory effect and you should discharge NiCd every 6 or 12 months completely to avoid it
<ShadowJK>
Pali; heat is worst
<DocScrutinizer05>
and I guess that urban legend about several full c<cles needed on fresh batteries even on LiIon is from that
<ShadowJK>
NiCd, and to some degree old NiMh, was a bit like that, yeah
<DocScrutinizer05>
Pali: yes, heat is definitely what kills LiIon. Keeping them chaged fully is way less critical, when a good smart charger circuit is used
<ShadowJK>
Nobody actually *knew* how NiMH worked until around 2006 or so, long after its use was declining :)
<DocScrutinizer05>
haha
<DocScrutinizer05>
nice
<bencoh>
:D
<ShadowJK>
It was more or less random trial and error mixing of materials until some Sanyo researchers figured they should try figure out exactly how it all works, before they can improve it
<ShadowJK>
The result was eventually a new type of NiMH, where self discharge was eliminated, cycle life extended to near 2000, higher voltage and lower internal resistance. Serious battery gurus think it's wrong to call NiMH, as it's so different from "normal" NiMH :)
<DocScrutinizer05>
Pali: recommendations for LiIon laptop batteries: keep them in device when for shart periods like one week. For long periods of operation from powersupply you should charge them to 60..90% and store them at a cool dry place
* ShadowJK
nods
<ShadowJK>
My samsung has a "battery extender" or whatever, it sets max charge level to 80
<ShadowJK>
I usually have that enabled, and only unlock full 100 if I'm going somewhere with laptop
<DocScrutinizer05>
some say "store in frige, or even freezer". I discourage to do the latter and doubt the former is doing _much_ benefit compared to simple shelf storage
<Pali>
ok
<Pali>
and when I'm not moving notebook, should I connect charger and stay it connected ?
<Pali>
or discharge battery when battery is full?
<DocScrutinizer05>
particularly in fridge you need to pack the battery in sealed bag, with silica gel. Annoying inconvenient
<DocScrutinizer05>
nah, don't worry about battery charge state as long as it's >60%
<DocScrutinizer05>
simply remove battery pack when you plan to operate the laptop for a month or longer from power supply only
<DocScrutinizer05>
if your laptop allows doing that
<DocScrutinizer05>
some don't work without battery
<kerio>
>remove battery
<kerio>
ew no
<kerio>
don't do that
<DocScrutinizer05>
why?
<kerio>
if you remove the battery you're at the mercy of the charger
<DocScrutinizer05>
sure
<kerio>
i guess it's not a big deal if it's the original charger
<kerio>
but if it's like, a chinese one
sparetire has joined #neo900
<DocScrutinizer05>
hmm
<ShadowJK>
my monster laptop wouldnt like it
<ShadowJK>
probably
<kerio>
that, too
<kerio>
my old laptop had a 95W battery and a 85W charger
<kerio>
not sure about this one
<ShadowJK>
it can pull more power than 180W charger can provide :)
<DocScrutinizer05>
sorry what?
<DocScrutinizer05>
a 95W battery? what's that?
<kerio>
a battery that can provide 95W
<DocScrutinizer05>
I doubt that
<kerio>
superior fruit technology
<DocScrutinizer05>
no battery ever has a Watt rating for what it can provide
<DocScrutinizer05>
maybe you mixed it with Wh
<ShadowJK>
45Wh battery wouod have no trouble with supplying 90W
<kerio>
mh maybe i'm dumb
<DocScrutinizer05>
max "providing power" of a batt is rated in Ampere, but hardly ever written on the battery or the manual
<DocScrutinizer05>
even more common is "C" which is no real Si unit but means Ah minus the "h"
<DocScrutinizer05>
or in other words: 1C load will discharge battery in 1h
<DocScrutinizer05>
usually LiIon batteries can do at least 2C
<kerio>
isn't that 1A
<DocScrutinizer05>
most can do 10C
<DocScrutinizer05>
no, for a battery that has 5Ah 1C == 5A
<kerio>
k
<DocScrutinizer05>
charging LiIon batteries usually done at 0.7..1C
<DocScrutinizer05>
some can take 2C
<DocScrutinizer05>
initial max current, on a CC-CV charger
<ShadowJK>
btw, battery deller batteryspace is now also selling li-ion manufacturing lineds, in case someone wants to make their own battery cells.
<DocScrutinizer05>
o.O
<ShadowJK>
they have videos of manual ewuipment used to seal pouch cells :)
<kerio>
can we get a BL-5J with at least 512mb of ram? :>
<ShadowJK>
surely drdk or i forgethisname can do that
mvaenskae has joined #neo900
<DocScrutinizer05>
hey, I can build such battery for you :-) it would actually work on Neo900, you however wouldn't like the bandwidth on HDQ 1wire protocol ;-)
<bencoh>
kerio: :D
<kerio>
but we've got three wires!
<DocScrutinizer05>
yes, GND, VDD and data
<kerio>
it's perfect
<kerio>
power means the bit is 1
<bencoh>
VDD/GND modulation :>
<kerio>
no power means the bit is 0
<DocScrutinizer05>
GTA02 battery comes with something like 1 or even two byte of RAM
<bencoh>
all you need is a "HF" (compared to DC) signal :>
<DocScrutinizer05>
carrier-over-powersupply?
<DocScrutinizer05>
aka powerline?
<bencoh>
yeah something like that, but way simpler
<DocScrutinizer05>
the awesome thing about HDQ is: Neo900 already _has_ it on BSI
<DocScrutinizer05>
so you could build your own smart batt, like GTA02 battery
<DocScrutinizer05>
hacker friendly device, you know? ;-)
<kerio>
:D
<DocScrutinizer05>
that's why I offered to add a 512MB RAM on there
<DocScrutinizer05>
but that battery would cost you more than a device
<DocScrutinizer05>
way more, since I need to build only one and make my living for the R&D from selling it
<kerio>
LOL
<kerio>
but think of the flexibility
<kerio>
you're also adding a battery to a 512mb ram module
<DocScrutinizer05>
yeah, you could use it in all Neo900 devices
<DocScrutinizer05>
and you actually could do that nonvolatile RAM
<kerio>
exactly!
<DocScrutinizer05>
almost as awesome as a small uSD
<DocScrutinizer05>
aaaaalmost
<kerio>
nobody understands my GENIUS
<DocScrutinizer05>
and for sure way more exclusive
<DocScrutinizer05>
anyway, afk again. Should start my day
b1101 has quit [Ping timeout: 245 seconds]
vakkov has quit [Ping timeout: 265 seconds]
<mvaenskae>
hm, anyone in here a wireless expert? :)
<mvaenskae>
specifically wondering if someone can tell me how bad -70 and lower for wireless lan is :)
<DocScrutinizer05>
I guess you're talking about dBm SNR. This doesn'tmean a thing as long as you don't know the noise floor
<DocScrutinizer05>
the receiver itself should work down to at least -90
<mvaenskae>
i don't know what the noise floor is as i sadly don't have any equipment to measure that :(
<DocScrutinizer05>
some receivers do measure noise floor themselves
<DocScrutinizer05>
particularly WLAN
<mvaenskae>
i am basically wondering if i need to purchase a better router for the shared flat i am in
<DocScrutinizer05>
generally signal quality is more useful than SNR
<mvaenskae>
hm, linux wireless seems to have it included; what snr-levels are usable?
<DocScrutinizer05>
your signal level shall be well (at least 6dBm) above noise floor
<DocScrutinizer05>
but even then...
<mvaenskae>
oh, actually my wireless adapter doesn't include noise :(
<DocScrutinizer05>
correlated noise could interfere without showing up in significantly increased noise floor
<DocScrutinizer05>
meast meter for WLAN link quality is the bandwidth used
<DocScrutinizer05>
best*
<mvaenskae>
hmpf... not really sure what to do now :/ personally i prefer another isp as it has 1/1 Gb/s speeds for approx 64-75 chf a month as opposed to 30/30 for 50 chf...
norly has joined #neo900
<mvaenskae>
but the gbit requires a hardware purchase
<mvaenskae>
but if there is a new router needed anyways to send data to even the very last room i am feeling a lot better to recommend the quicker internet
<mvaenskae>
annoyingly i cannot test either router before purchase D:
<DocScrutinizer05>
get the fast internet link and use ethernet cables
<mvaenskae>
the gbit internet?
<DocScrutinizer05>
max link speeds on WLAN are mere theory anyway
<DocScrutinizer05>
and you won't see that much of a difference in WLAN AP performance nowadays on new devices
<DocScrutinizer05>
I mean, they all have to implement the same standards and are subject to same limitations
<DocScrutinizer05>
and for real *speed* and reliability you want wired ethernet anyway
<mvaenskae>
and ethernet cabling is not erm... theoretically it should have been in for every room but i might be able to pull it into every room myself and then just have a cheaper non-wlan router which then connects to a hub which sends it to each room's personal router
<DocScrutinizer05>
rouers per room? why that? why not use switch?
<mvaenskae>
how does one put a lan cable inside their droids?
<DocScrutinizer05>
you could use one AP per room. Or at least two or three at distant ends of your flat
<mvaenskae>
getting two routers would easily solve the problem, but housing regulations disallow pulling loose cabling through the rooms (also doors won't close anymore that way)
<DocScrutinizer05>
you want APs, not routers
<mvaenskae>
DocScrutinizer05: well, one router is needed :)
<DocScrutinizer05>
yes, the one connecting to the internet
<mvaenskae>
and then from where the router is attached one possible switch and then 2 wireless APs
<DocScrutinizer05>
:nod:
<mvaenskae>
and who foots the bill? :)
<mvaenskae>
but true, having two APs seems to be the correct solution to have 100% coverage
<DocScrutinizer05>
or a powerline adaper and another powerline-2-WLAN-AP at other end of flat, while the router might come with a WLAN built in
<mvaenskae>
i have no idea how secure the powerline will be in the end
<DocScrutinizer05>
secure? prolly sufficiently
<DocScrutinizer05>
stable? questionable
<DocScrutinizer05>
one way to find out: test it
<mvaenskae>
i rather get 2 APs :)
<DocScrutinizer05>
I thought about the cable needed to connect them
<DocScrutinizer05>
you could use WLAN repeaters but those more than halve the bandwidth
<mvaenskae>
the house should in theory allow for lan to the rooms
<DocScrutinizer05>
since every ping and stuff needs to go over two hops instead one, back and forth
<mvaenskae>
i could gather information on how one moves the cables from the switchboard to the rooms and then i can connect via a switch the APs with the router
<mvaenskae>
i will have to ask a fellow tennant of the house if he will be pulling in cables and if so how he did it
<DocScrutinizer05>
well, I think woice calls on N900 worked since "ages", under mer/nemo, SHR, even replicant? What wasn't working was integration of FOSS voice into maemo's closed blob audio architecture
<DocScrutinizer05>
and decent quality
<bencoh>
I'm not sure about "decent quality" but yeah it used to work in nemo
<mvaenskae>
can we get a voice-sample of the quality? :)
paulk-collins has quit [Quit: Quitte]
<Sicelo>
is nemo still available for N900? or abandoned?
<DocScrutinizer05>
the problem with audio seems mainly that the BB5 has no audio buffer at all for upstream, but rather expects a 50(?)ms chunk of samples for each GSM timeslot the tower requests data for
<DocScrutinizer05>
so aiui the modem sends some timing info via the phonet socket, telling the libcmtspeech whether to spped up or slow down with next chunk of data
<DocScrutinizer05>
a really nasty concept
<DocScrutinizer05>
anyway we don't see similar nasty concept on any of the modems we use in GTA04*
<Oksana>
^ Does it mean that 3G video call will work within NeoFreemantle?
<DocScrutinizer05>
all those modems are rather sort of "codec chip" and you send audo data to them like you would to any arbitrary soundcard
<Sicelo>
were there any particular reasons for Nokia to use 'nasty concept'?
<mvaenskae>
they had access to sauces
<DocScrutinizer05>
well, the BB5 modem isn't made for the usecase. It's rather meant to be the PCM master and directly connect to digital microphone etc. Linux otoh is not built to use external master (==clock) for audio, particularly not on a software (=network link) level
<DocScrutinizer05>
what BB5 does is "audio streaming over network" where the *receiver* is the clock source for sampling speed
<DocScrutinizer05>
compare that to any arbitrary normal audio streaming like e.g. SIP/RTP, where *always* the sender is clock master
<DocScrutinizer05>
our Cinterion modem can do PCM slave
<DocScrutinizer05>
no network streaming, no syncing of CPU audio "card" to external clock
<DocScrutinizer05>
(though even that would work for a PCM interface on OMAP. Just not for network streaming like RTP)
<DocScrutinizer05>
I guess that audio streaming via a virtual channel of a network-alike link like SSI was just an afterthought in BB5 invented specially for N900
<mvaenskae>
will there be documentation on how the audio channel will be set up?