qws-user-1228 has quit [Read error: Connection reset by peer]
qws-user-1228 has joined #neo900
goiken_ has quit [Ping timeout: 260 seconds]
goiken_ has joined #neo900
galiven has joined #neo900
galiven__ has quit [Ping timeout: 260 seconds]
goiken_ has quit [Ping timeout: 244 seconds]
goiken_ has joined #neo900
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
neo900 has joined #neo900
Joerg-Neo900 is now known as Guest85232
neo900 is now known as Joerg-Neo900
Guest85232 has quit [Killed (tepper.freenode.net (Nickname regained by services))]
Oksana has quit [Read error: Connection reset by peer]
Oksana_ has joined #neo900
Oksana_ is now known as Oksana
goiken_ has quit [Ping timeout: 244 seconds]
treeman has quit [Ping timeout: 256 seconds]
goiken_ has joined #neo900
treeman has joined #neo900
goiken_ has quit [Ping timeout: 245 seconds]
goiken_ has joined #neo900
cybiko123 has quit [Quit: Leaving.]
goiken_ has quit [Ping timeout: 252 seconds]
goiken_ has joined #neo900
radekp has joined #neo900
jonsger has joined #neo900
goiken_ has quit [Ping timeout: 260 seconds]
goiken_ has joined #neo900
freemangordon_ has joined #neo900
cybiko123 has joined #neo900
cybiko123 has quit [Client Quit]
mzki has joined #neo900
trx has joined #neo900
trx has quit [Changing host]
trx has joined #neo900
jonsger has quit [Ping timeout: 268 seconds]
radekp has quit [Remote host closed the connection]
radekp has joined #neo900
jonwil has joined #neo900
qws-user-1228 has quit [Read error: Connection reset by peer]
qws-user-1228 has joined #neo900
goiken_ has quit [Ping timeout: 244 seconds]
goiken_ has joined #neo900
BeachBuggy has joined #neo900
<BeachBuggy>
Hi folks!
<BeachBuggy>
is there already any date set for the first delivery of the neo900? I'm waiting on mine ... and currently sourcing for my backup-unit the needed n900 case ..
SylvieLorxu has joined #neo900
<jonwil>
I cant comment on the hardware but I can tell you the software stack isn't as far along as it could be (although exactly how usable it is right now depends on what OS/platform you intend to run on the thing)
<Wizzup>
jonwil: I would think the hardware is the more risky part, I guess
<jonwil>
in particular I can tell you that if you intend to run the N900 Maemo software stack on it, the cellular connectivity, GPS and audio are all incomplete and not usable
<jonwil>
well actually the audio is incomplete and the GPS and cellular modem are non-existant
<jonwil>
I believe there are bits being worked on for the cellular modem and things but which platform they are in support of and what, if any, higher level software (dialer, messaging app etc etc) exists that would be able to use these bits when its finished I dont know
<Joerg-Neo900>
GPS is a nobrainer since maemo allows external GPS and for all that matters the GPS of Neo900 can get accessed exactly same way
<jonwil>
yeah GPS probably isn't a big thing
<Joerg-Neo900>
for cellular I suggested to use a telepathy adapter that simulates a SIP/RTP connection, or if you want it really cheap, just install asterisk
<Joerg-Neo900>
on the hardware side we try to kick off layout of proto_v2 right now
<jonwil>
Whats missing for maemo-on-N900 is the entire cellular stack
<jonwil>
voice calls
<jonwil>
modem management
<Joerg-Neo900>
not exactly correct, such stack exists, just not in maemo
<jonwil>
Thats why I said maemo-on-N900 is missing it
<jonwil>
It exists
<jonwil>
but not in a form maemo-on-N900 can use at this point
<Joerg-Neo900>
that's why I suggested to install asterisk which has such stack, and contact to it via SIP
<Joerg-Neo900>
dirty clumsy but simple solution
jonsger has joined #neo900
<jonwil>
That doesn't help for all the other things that the cellular services daemon does.
<jonwil>
at a minimum, some sort of replacement for the gprs cellular data blobs would be necessary
<jonwil>
Easiest way there is probably to simply replace libicd-network-gprs with a new libicd plugin that talks to the Neo900 modem
<jonwil>
Oh and would the Asterisk SIP solution work for SMS?
<jonwil>
I still maintain the
* Wizzup
awaits hw prototypes
<bencoh>
I wouldn't even try using asterisk for sms
<jonwil>
I still maintain the ultimate goal should be to replace the cellular services daemon with a daemon that exposes the same dbus interface but talks to the neo900 modem underneath
<bencoh>
I dunno what kind of support it has now for sms (it was pretty inexistant back then) but ... I really don't see any added value
<jonwil>
Most of the dbus interface exposed by the daemon has been reverse engineered or would be easy to reverse engineer (certainly the bits that are most important for a functional cellular stack)
<jonwil>
so for SMS support, we create something that looks just like com.nokia.csd.SMS
<jonwil>
The other alternative for SMS would be to create a plugin that makes SMS look to the system like an IM client
<jonwil>
although SMS and IM work so differently that I cant see it being an easy match (hence the suggestion that the easy option is to just clone the SMS interface)
<Joerg-Neo900>
SMS is dirt simple
* Joerg-Neo900
suggests having a close look into FreeSmartphoneOrg
<Wizzup>
I think jonwil's point is just the maemo integration
<jonwil>
Yes
<jonwil>
The issue isn't "
<jonwil>
isn't "how do we get a cellular stack on the Neo900"
<Joerg-Neo900>
you said it
<jonwil>
its "how do we get a cellular stack on the Neo900 and keep the higher level parts of Maemo working"
<jonwil>
like the dialer
<jonwil>
and the messaging app
<Joerg-Neo900>
>>the ultimate goal should be to replace the cellular services daemon with a daemon that exposes the same dbus interface but talks to the neo900 modem underneath<<
<Joerg-Neo900>
--> fso, just adapt the API
<jonwil>
and yes that should be the goal of the maemo-on-Neo900 effort
<jonwil>
And yes FSO as a base would make sense if their upper-level-apis are close enough to what the cellular services daemon exposes to be adaptable
<jonwil>
:)
<Joerg-Neo900>
the APIs are basically all very close
<Joerg-Neo900>
since it's always the same functionality underneath that needs to get controlled
<Joerg-Neo900>
fso uses dbus exclusively
<Joerg-Neo900>
write a janus layer that transforms the csd lib calls to dbus
<Joerg-Neo900>
or in case csd already has dbus API uplink and just talks ISI/whatever downlink, replace the csd stuff completely by fso
<jonwil>
Yeah that was my idea
<jonwil>
We take FSO or whatever and change its dbus API to expose something that is `100% compatible with com.nokia.phone.SSC, com.nokia.csd.Call, com.nokia.phone.net, com.nokia.csd.SMS etc starting with those interfaces necessary for the core parts of the system (telepathy-ring, rtcom-call-ui, rtcom-messaging-ui etc)
<jonwil>
That's the idea I have had all along :)
<Joerg-Neo900>
exactly :-)
<jonwil>
It just needs someone to actually reverse engineer those bits of the dbus interface that have yet to be figured out :)
<jonwil>
identify what all the numbers mean etc :)
<jonwil>
I went as far as I could with that myself
<Joerg-Neo900>
it's probably easiest to figure out by example (dbus-monitor)
<jonwil>
yeah :)
<jonwil>
and I documented whatever I could on maemo.org wiki
<Joerg-Neo900>
inplement fso, see what it expects, read dbus-mon log and spot the message that seems to provide the needed data
<Joerg-Neo900>
there night be a 10% intricate obscure messages, but 90% should be pretty obvious
<Joerg-Neo900>
s/night/might/
<Joerg-Neo900>
fso is vala but it's not _that_ bad, even I can read it ;-9
<Joerg-Neo900>
:-)
<Joerg-Neo900>
also fso supposed to have a pretty decent API documetation
<jonwil>
main thing that is needed for figuring out dbus interfaces from log is someone who has some knowledge of how cellular telephony works (since knowledge of how that stuff works will make it easier to spot different flags and other things in the dbus-monitor logs)
<Joerg-Neo900>
((some knowledge of how cellular telephony works)) reading the fso API docs should go a long way for that purpose
<jonwil>
Cell Broadcast SMS wont matter to me anymore in the not-to-distant-future :)
<jonwil>
Right now my carrier uses CBSMS for providing cell tower IDs
<jonwil>
which is why I wrote the CBSMS thing
<jonwil>
but that only comes on 2G GSM not 3G
<jonwil>
and my carrier is going to be shutting down 2G (to focus on 3G and 4G) soon
<Joerg-Neo900>
I just thought you might find this particularly informative since you know the maemo side of this segment
<Joerg-Neo900>
so you instantly can compare
<Joerg-Neo900>
you probably didn'T dive too deep into "how SMS works on network" for that
<jonwil>
no
<jonwil>
Although its been a while since I messed with that stuff so I would need to go back and look at it all again to remember how it worked :)
<Joerg-Neo900>
same for calls
<Joerg-Neo900>
generally the fso API is probably more sane than the maemo one
<Joerg-Neo900>
also note how fso is basically a holistic approach
<Joerg-Neo900>
I wish Nokia had adopted it from beginning, instead of impplementing own crap like MCE and whatnot
<Joerg-Neo900>
liblocation, well... ohmy
<jonwil>
I recon the Neo900 will be one of the few phones out there with no binary blobs of any kind on the main processor for the cellular radio (only the firmware in the radio module itself)
<jonwil>
Most Android phones (even those that run full open Android platforms) have a binary blob RIL
<Joerg-Neo900>
yep, I know
<bencoh>
apart from the tiny few ones that run replicant with a free RIL (a few samsung phones, like galaxy2)
<Joerg-Neo900>
and this is what e.g. sailfishOS also uses
<Joerg-Neo900>
I think replicant can do both, it uses closed blob RIL happily as well as preferring FOSS RIL when feasible
<jonwil>
The other thing I like about the Neo900 is that its hardware design means attacking the device via the network isn't going to work (the cellular modem has no access to the microphone, speakers, main RAM, main filesystem or anything running on the main OMAP cip.
<Joerg-Neo900>
yes
<Joerg-Neo900>
major design goal
<Joerg-Neo900>
even better: we have hardware that tells OMAP about any such attack going on on modem side
<jonwil>
Its not like all those Android devices running Qualcomm Snapdragon or Samsung Exynos where the NSA can use backdoors in the cellular firmware to turn on the microphone remotely and use the phone as a covert listening device or something.
<Joerg-Neo900>
definitely not
<Joerg-Neo900>
Qualcom (and prolly Exynos too) are basically running android as a VM in the modem frimware host
<Joerg-Neo900>
guess how protected the VM is against any arbitrary attacks from host
<jonwil>
Does the CPU in the Neo900 have that secret separate CPU (Arm TrustZone or whatever its called)?
<jonwil>
I dont think the OMAP line does
<jonwil>
but I could be wrong
<bencoh>
I still don't understand why you think of this whole thing as a "vm"
<bencoh>
and no, exynos doesn't always follow the same architecture
<bencoh>
(dunno about the latest chips, but ...)
<jonwil>
Although even if our chip does have Arm TrustZone or something, the way we build the hardware and software means we can totally avoid anything secret or unknown running on such hidden CPUs and we can be sure the only things with access to the main RAM and flash on the phone are things the user has control over.
<Joerg-Neo900>
bencoh: well, RING0 vs RING-N
<Joerg-Neo900>
jonwil: yes, exactly
<Joerg-Neo900>
I don't think the GP devices (3530, 3730) support TZ like the HS devices (3430, 3630)
<jonwil>
I dont think there exists a laptop made in the last decade that doesn't have some kind of hidden secret code running on it not in the control of the user.
<jonwil>
Anything x86 has Intel Management Engine secret bits
<jonwil>
or whatever AMD has
<jonwil>
and all the Arm laptops I know of all rock chips that aren't documented enough to be trustable (and may also have secret stuff running on TZ or whatever)
<jonwil>
Only reason I haven't yet bought into a Neo900 is that I have a usable N900 and mo money to replace it :)
<jonwil>
Otherwise I would be all over the Neo900
<Wizzup>
jonwil: anything after core2duo does
jonsger1 has joined #neo900
jonsger has quit [Ping timeout: 265 seconds]
jonsger1 is now known as jonsger
<BeachBuggy>
thanks for the answers on the NEO900. I'm fairly confident the software side will get worked out -- gives me some more time to source propper cases for my backup-unit (the primary unit was ordered as a complete unit ... not fussing around with your productivity tool :-) )
jonsger has quit [Ping timeout: 260 seconds]
Sicelo has quit [Ping timeout: 244 seconds]
jonsger has joined #neo900
jonsger has quit [Ping timeout: 245 seconds]
freemangordon_1 has joined #neo900
freemangordon_ has quit [Read error: Connection reset by peer]
freemangordon_ has joined #neo900
freemangordon_1 has quit [Ping timeout: 250 seconds]
jonwil has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.40/20160120202951]]