Author Topic: Pocketpenguin Phone Rom (Read 20141 times)

Ferret-Simpson · « **on:** July 27, 2006, 05:28:09 pm »

So. What? Gonna be linux based, (Of course.) What will we need? I'm gonna guess this'll be based on the OpenEmbedded toolkit. A Bootstrap base? I can't see us needing a GUI on a phone emulator. . . So we'll need Stacks, and an interface to the iMX.

Things that are going to need alot of thinking:

The data protocol for the USB connection to the iMX. . . We have the Serial link for AT control, but 3G data, GPRS data, and videophone data will all need to go on the USB bus. . . What else? MMS's, Access to the data on the SIM card, (Own number, SIM-phonebook: Will need a tie in to our AddressBook in the PDA OS. . .)

The software that controls the RPU and DSP. . . Needed functions?

It's going to have to be able to wake the iMX so that the iMX can handle CallerID, send any required information to the twin displays and to bluetooth (And whatever else you guys route it to Caller log?)

Genii (Geniuses?) give me your opinion.

Da_Blitz · « **Reply #1 on:** July 27, 2006, 10:12:28 pm »

mmm the stack from freescale should cover all of this however if we need to do our own then

Serial drivers
Usb drivers (adapted from the iMX
DSP functions
EDGE layer
GSM layer
GPRS layer
GPIO drivers (not really but thats how we will trigger an interupt if we cant get the serial port to do it)

callerID will require some support in the chip but how it is handeled and how to decode that data is best left to the iMX3.

Bluetooth now there is an intresetig problem, i assume you have the data sheets handy, if it has an a2d anda d2a on it then we can get it to handel all audio and route it throgh the iMX3's audio routing segment (so we can chose the sink and source for the audio data without cpu intervention) if its digital data i guess we can still do the same, what will be annoying is if freescales firmware spits the data over usb but i would have to double check the data sheets to get a better idea of how they did it

display wise we will see, it depends on a couple of factors

i doubt that we will have linux running on this chip, more than likly just some interupt rivven C code and thats if we write our own firmware if we get it from freescale we get a nice blob of binary (i assume getting the source will cost us more money)

Ferret-Simpson · « **Reply #2 on:** July 28, 2006, 05:06:30 am »

You forgot the WCDMA layer. And as far as I know, their system involves a Linux kernel aswell. . . I'm not sure, but I think so. . . Isn't this the chip that the latest Moto Phones are based on?

Da_Blitz · « **Reply #3 on:** July 28, 2006, 06:49:28 am »

im hopping that it just acts like a seriat modem that follows the AT spec (not that thier is actually a spec to work from) wcdma would be a firmware thing and have nothing to do with linux in that case

Ferret-Simpson · « **Reply #4 on:** July 28, 2006, 11:19:05 am »

http://www.forum.nokia.com/info/sw.nokia.c...1_2_en.pdf.html

That's the commandset used by Nokia devices. . . I'm going to guestimate that they wouldn't differentiate too far from the standard AT structure. . .

http://linuxdevices.com/news/NS2710208789.html

This looks hopeful. . . .

Da_Blitz · « **Reply #5 on:** July 29, 2006, 12:06:07 pm »

mmm, firmwares still a problem as the binary is owned by someone so we cant just use it

Ferret-Simpson · « **Reply #6 on:** July 29, 2006, 01:03:36 pm »

I think we may need to look at coding our own stack. The datafiles for the MXC will probably be helpful, and that Nokia file should give us the basic AT structure that needs to be implemented (We can also check the other hundreds of documents around)

I just think that this could take a little ingenuity on the side of a coder. . . I've looked at several commercial stacks, but they all look to be in a corporate pricerange.

I think we need to implement this in stages. Once the hardware is done, then we've got a testing platform. For now we can build the modem interface, on the PDA side. When the hardware is done, I guess that's the time to start looking at a fully open source stack. If we can get (By reverse engineering etc etc) A basic GSM on Linux implementation, then the rest will follow I guess. . .

Da_Blitz · « **Reply #7 on:** July 30, 2006, 08:57:00 am »

funny thing is the AT structure is very loose from what i have read with each manufacturer implementing everything in a vendor specific way. i suppose thats good for us because we can get away with a thing or two or we could clean things up and standerdise the interface and allow for expansion in the protocal

i think that this needs design, not an organic approch. i intend to do this right the first time

Ok i guess we need gsm specs, anyone got any idea where to get them and how much it will cost us also do we have a DSP guy in the house?

Ferret-Simpson · « **Reply #8 on:** July 30, 2006, 01:20:59 pm »

Not me. I'm a pretty good fixer though (I say so myself.) So I can probably find most things.

dhns · « **Reply #9 on:** July 31, 2006, 05:59:05 am »

Quote

Ok i guess we need gsm specs, anyone got any idea where to get them and how much it will cost us also do we have a DSP guy in the house?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

You can get them at 3GPP: [a href=\"http://www.3gpp.org/specs/numbering.htm]http://www.3gpp.org/specs/numbering.htm[/url]

But - would you design your own transistor production process to develop a CPU for the PocketPenguin??? IMHO, this project traps in the most basic fault: it tries to do everything and achieves nothing...

I would recommend to forget about a GSM stack. Design around a GPRS module. They have AT commands similar to most phones and PCMCIA/CF GPRS cards. And, most important: you won't get your own GSM stack working without handling the network encryption. And to get that, you must pay Millions of $$...

-- hns

Ferret-Simpson · « **Reply #10 on:** July 31, 2006, 06:12:32 am »

Quote

Quote
Ok i guess we need gsm specs, anyone got any idea where to get them and how much it will cost us also do we have a DSP guy in the house?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]
You can get them at 3GPP: [a href=\"http://www.3gpp.org/specs/numbering.htm]http://www.3gpp.org/specs/numbering.htm[/url]

But - would you design your own transistor production process to develop a CPU for the PocketPenguin??? IMHO, this project traps in the most basic fault: it tries to do everything and achieves nothing...

I would recommend to forget about a GSM stack. Design around a GPRS module. They have AT commands similar to most phones and PCMCIA/CF GPRS cards. And, most important: you won't get your own GSM stack working without handling the network encryption. And to get that, you must pay Millions of $$...

-- hns
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137024\"][{POST_SNAPBACK}][/a][/div]

Erm. . . What?

We're using an iMX31 Chip from Freescale as a PDA CPU, I understand THAT'S not open source, but at least the company is open source friendly.

Well, We've been going something along the lines of a month or so, and are more doing Touch-ups to the specification than starting from scratch.

GPRS is out of date. It's useless for decent mobile web browsing, and is now a few years out of date. We want to code our own stack because currently there isn't one.

The phone ROM is flashable, so at any time during development, and even after the PDA's are in customers hands, we can change our minds and license a commercial stack. But there are open source Windows replacements, open source AmigaOS replacements, office replacements, UNIX replacements, MACosX replacememnts. . . Photoshop. . . 3DMAX. .

It's about time somebody made our communication a little more open.

The hardware is in essence separate from software, the hardware will remain unchanged no matter what stack we choose.

dhns · « **Reply #11 on:** July 31, 2006, 06:42:23 am »

Quote

The phone ROM is flashable, so at any time during development, and even after the PDA's are in customers hands, we can change our minds and license a commercial stack. But there are open source Windows replacements, open source AmigaOS replacements, office replacements, UNIX replacements, MACosX replacememnts. . . Photoshop. . . 3DMAX. .

It's about time somebody made our communication a little more open.

The hardware is in essence separate from software, the hardware will remain unchanged no matter what stack we choose.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=137026\"][{POST_SNAPBACK}][/a][/div]

Hm - I think we have different interpretations what we talk about with the word "stack" in this case.

My understanding - from the question about GSM specs - is that you are looking at kernel driver software that runs all the GSM (or choose a different standard) protocols that communicate between the application software and the RF transceiver so that you have a full phone in your hands.

There are two different concepts out there: a single-processor, where the phone stack as described runs on the same processor as the user interface.

And the connected-PDA concept where you have an embedded communication processor (which is a black box) and an open PDA platform. Both communicate through a serial line with AT commands.

So, to which context are you referring by "phone stack"? The low level GSM bits or application software (dialer, PPP driver, SMS manager etc.)?

-- hns

Ferret-Simpson · « **Reply #12 on:** July 31, 2006, 06:54:11 am »

I was in fact referring to the low level stuff.

And no, sorry that's wrong. There are in fact 3 concepts. The single-CPU, the Black-Box method you're talking about, involves the use of an all-in one box into which you plug in your audio. Such as the one we looked at on Sparkfun.

The third option we're using is similar, and is displayed neatly on the HTC Universal and well. . All the OTHER HTC phones. They have a separate communications processor, in their case a Qualcomm unit. However this embedded processor needs it's own OS to function, hence why on the XDA-Developers site you get links to "Phone ROM" and other variations on that theme. This phone rom is an Operating system and set of Stacks that runs on the Communications (Baseband) Processor, and provides an emulation of an AT modem for the PDA CPU.

That's how it works in the XDA, the Motorola A-Series, and how Freescale themselves (Manafacturer of both the chips we're using) have explained to me it works. So what we are talking about IS the low level kernel driver, but to run on the phone processor, which DOES need one to operate.

Da_Blitz · « **Reply #13 on:** July 31, 2006, 07:43:10 am »

GPRS is not out of date, thats like saying that computers are out of date 2 weeks after you buy them. they are still good for what the do at the very least

the gprs module will become a bit of a hot topic in the futre i belive, the DSP thing was kind of a joke (i wasn't sure if many would get it) for gsm the modulation is fairly simple and i am not sure how much DSP'ing we will have to do (need to read the phone chip docs)

ethire way short term i would like to buy a stack as a binary to keep costs down and make sure we have somthing that works and not "will work in +12 months

the stack we are refering to is low level and runs on its own processor, it presents a serial port to the host os which will obey the AT command set or simmilar, that way it should work with all oss modem stuff. it is a low level OS just like the qualcomm units, IT IS IN NO WAY A LOW LEVEL KERNEL DRIVER. after all how can it be when it runs on its own seperat hardware and communicates over a serial line

Da_Blitz · « **Reply #14 on:** August 05, 2006, 06:52:51 am »

found a link that could be handy: http://www.edaboard.com/ they even have an area for gsm and simmilar phone systems: http://www.edaboard.com/forum98.html

News:

Author Topic: Pocketpenguin Phone Rom (Read 20141 times)