* Pavel Machek <pavel@xxxxxx> [190207 22:18]: > 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.. > > 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. > > > I pushed the tree to git@xxxxxxxxxx: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). > > > > 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. 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
