Droid 4 modem support in kernel & ofono
Hi!
Ok, so I got calls and smses somehow working in kernel&ofono ... which is really all I need.
I pushed the tree to [email protected]:pavelmachek/ofono.git , branch d4... But I had to do some "rather interesting" hacks. D4 modem expects packets and current kernel drivers rely on write() boundaries and flush(). .. which is a bit of problem for in ofonod, as it expects to work with bytestream with no explicit packet boundaries.
However D4 still uses normal AT commands, so... it would be good to be able to use AT parsing framework in ofono.
I believe easiest solution would be to automatically do the packet splitting in kernel, it should be as easy as splitting on \r and ^Z. (Currently packets are only generated when \r or ^Z is seen on write boundary, but that does not work well for ofono).
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 4 lines · Pavel Machek
Hi!
Ok, so I got calls and smses somehow working in kernel&ofono ... which is really all I need.
Nice :)
I think the SIM card reading and writing should be doable using dlci10 /dev/motmdm10 for AT+CRSM calls..
Quoted 6 lines
I pushed the tree to [email protected]:pavelmachek/ofono.git , branch d4... But I had to do some "rather interesting" hacks. D4 modem expects packets and current kernel drivers rely on
write()boundaries andflush(). .. which is a bit of problem for in ofonod, as it expects to work with bytestream with no explicit packet boundaries.
Quoted 7 lines
However D4 still uses normal AT commands, so... it would be good to be able to use AT parsing framework in ofono.
I believe easiest solution would be to automatically do the packet splitting in kernel, it should be as easy as splitting on \r and ^Z. (Currently packets are only generated when \r or ^Z is seen on write boundary, but that does not work well for ofono).
OK yeah it's worth trying. I hit that issue too with the flush needed for droid4-sms-tools scripts. And the traffic we're seeing is minimal and AFAIK there's no network port for ts27010. And SMS messages are PDU encoded anyways.
Hmm should we do it for \r\n and \r? Otherwise the \n will be left out of the packet :)
Regards,
Tony
Hi!
Quoted 7 lines
Quoted 2 lines
Ok, so I got calls and smses somehow working in kernel&ofono ... which is really all I need.
Nice :)
I think the SIM card reading and writing should be doable using dlci10
/dev/motmdm10for AT+CRSM calls..
Might be. Sorry, this is outside of my area of interest, because LTE would not be on usable frequencies, anyway.
Quoted 14 lines
Quoted 6 lines
I pushed the tree to git-9UaJU3cA/F/[email protected]:pavelmachek/ofono.git , branch d4... But I had to do some "rather interesting" hacks. D4 modem
expects packets and current kernel drivers rely onwrite()boundaries
andflush(). .. which is a bit of problem for in ofonod, as it expects
to work with bytestream with no explicit packet boundaries.Quoted 7 lines
However D4 still uses normal AT commands, so... it would be good to be able to use AT parsing framework in ofono.
I believe easiest solution would be to automatically do the packet splitting in kernel, it should be as easy as splitting on \r and ^Z. (Currently packets are only generated when \r or ^Z is seen on write boundary, but that does not work well for ofono).
Quoted 7 lines
OK yeah it's worth trying. I hit that issue too with the flush needed for droid4-sms-tools scripts. And the traffic we're seeing is minimal and AFAIK there's no network port for ts27010. And SMS messages are PDU encoded anyways.
Hmm should we do it for \r\n and \r? Otherwise the \n will be left out of the packet :)
I guess splitting on \n makes sense, yes.
Ofono normally uses just \r. Translating it to \r\n in kernel (ttys already do that) would be super nice, but I think this is easy enough to handle in ofono.
Thanks,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 5 lines · Pavel Machek
Hi!
Quoted 3 lines
Quoted 2 lines
Ok, so I got calls and smses somehow working in kernel&ofono ... which is really all I need.
Quoted 7 lines
Quoted 4 lines
Nice :)
I think the SIM card reading and writing should be doable using dlci10
/dev/motmdm10for AT+CRSM calls..Might be. Sorry, this is outside of my area of interest, because LTE would not be on usable frequencies, anyway.
Oh I did not mean LTE, I meant for general SIM access for ofono for pin codes etc. Anyways, if anybody needs the sim, it should be available at /dev/motmdm10.
Quoted 19 lines
Quoted 19 lines
Quoted 6 lines
I pushed the tree to [email protected]:pavelmachek/ofono.git , branch d4... But I had to do some "rather interesting" hacks. D4 modem expects packets and current kernel drivers rely on
write()boundaries andflush(). .. which is a bit of problem for in ofonod, as it expects to work with bytestream with no explicit packet boundaries.Quoted 7 lines
However D4 still uses normal AT commands, so... it would be good to be able to use AT parsing framework in ofono.
I believe easiest solution would be to automatically do the packet splitting in kernel, it should be as easy as splitting on \r and ^Z. (Currently packets are only generated when \r or ^Z is seen on write boundary, but that does not work well for ofono).
OK yeah it's worth trying. I hit that issue too with the flush needed for droid4-sms-tools scripts. And the traffic we're seeing is minimal and AFAIK there's no network port for ts27010. And SMS messages are PDU encoded anyways.
Quoted 8 lines
Quoted 2 lines
Hmm should we do it for \r\n and \r? Otherwise the \n will be left out of the packet :)
I guess splitting on \n makes sense, yes.
Ofono normally uses just \r. Translating it to \r\n in kernel (ttys already do that) would be super nice, but I think this is easy enough to handle in ofono.
Do you have some simple test case with printf?
This test case works just fine already:
$ printf "AT+CFUN=1\rAT+SCRN=0\r" > /dev/motmdm1
But maybe the modem behaves in a different way for different dlci.. So a minimal test case would be good to have :)
Regards,
Tony