SoC: Back and forth!

[TrashyMG]

oops I ordered the EVM board while I was on the page..  not going to see if it blends

 

The TI site says:

Multicore ARM® Cortex™ processors

• Two ARM Cortex-A15 MPCore processors capable of speeds up to 1.5 GHz each

So did the Omap EVM on FOSDEM run at 1.5 or 1.7 GHz?

That's a good question.. if 1.5 then awesome! we can expect better of the 1.7Ghz model..

Edit2: Well looks the omap5432 data sheet claims up to speeds of 1.7Ghz my guess default is 1.5Ghz.. kind of like how the OMAP3 in the CC and Rebirth units default to 500Mhz and claim up to speeds of 700Mhz even though most people clock them at 800mhz - 1Ghz easily..

 

[Wrath Of Khan]

Oh yeah. Can we overclock the pyra like the pandora?

 

[Askarus]

Yes.

But was not tested how far it gets yet.

 

[Wrath Of Khan]

^^^^^Sweet.

 

[Hồng Thất Công]

I'll run mine at 2.0GHz 100% of the time

 

[Askarus]

Me too.

 

[hns]

What are the current plans for hooking up the optional baseband processor?


I'd really like to have GPS as an option in my Pyra and the ability to borrow someone's SIM card and get mobile data on occasion would also be nice (I'm Canadian. You have to mortgage your firstborn child for mobile data here), but I'd rather not have it at all if I can't be absolutely certain that it's powered off and dead to the world when not in use.


That means I need a hardware killswitch, a software killswitch paired with an indicator light that can't be mucked with in software, a baseband processor module that's easy for the end user to add/remove, or no baseband processor and USB dongles for GPS and/or LTE.

The module is connected through an internal USB port and presents itself as a simple tty for AT commands. There will be one GPIO to turn it on or off. And another GPIO that reports if it is currently powered on. This can very likely be hidden by a rfkill wwan.

There are AT commands for the 3G part and others for the GPS. Those commands are public.

Anyways, it needs a SIM card to be operated.

For LTE we will have to see if we can manage the antenna variants (there are different frequency ranges all over the world needing complex antennas to be as universal as possible). Currently we experiment with the Cinterion PHS8 (and PLS8) modules (the same as for the Neo900).

Well, having it as a USB device with a TTY interface definitely makes it a difficult target for exploits. (Well-tested transport-level driver (uhci/ohci/ehci), simple and well-understood higher-level API (tty+AT), no DMA, bus slave, etc.) Am I correct in understanding that the USB 5V line is the only power supply and the on/off GPIO's "off" state will result in no current flow when the chip is unpowered?

(Partly for security but primarily to avoid it being a drain on the battery during the 99% of the time I don't use it, I want the chip to be electrically dead when not in use and, if my understanding is correct, I should be able to accomplish that by turning the chip off via both rfkill wwan and the sysfs API for controlling USB device power allocation.)

Almost yes. The module is directly connected to the battery because such a module may draw high pulse currents. So it would not be wise to use a step-up converter for +5V.

If it is turned off it draws almost no current (39uA according to the data sheet).

And we did choose the USB/tty interface because we also refuse fully integrated modems (shared memory). Anyways there are no 3/4G modem modules on the market that don't have an USB/tty interface. You only get them as integrated baseband of some SoCs. This of course saves chips, interconnect and cost - but makes a lot of troubles to get the design certified. With a precertified module and an USB interface it is much simpler.

 

[ssokolow]

Almost yes. The module is directly connected to the battery because such a module may draw high pulse currents. So it would not be wise to use a step-up converter for +5V.
If it is turned off it draws almost no current (39uA according to the data sheet).

And we did choose the USB/tty interface because we also refuse fully integrated modems (shared memory). Anyways there are no 3/4G modem modules on the market that don't have an USB/tty interface. You only get them as integrated baseband of some SoCs. This of course saves chips, interconnect and cost - but makes a lot of troubles to get the design certified. With a precertified module and an USB interface it is much simpler.

Hmm. Obviously, anything that could be used to explicitly switch the battery line would waste power when it's running, so the question is whether I trust that the module is designed so that it's impossible, whether through incompetence or malice, for it to ignore the GPIO disable line and allow something like IMEI tracking sans-SIM.

 

[Granitehead]

Hmm. Obviously, anything that could be used to explicitly switch the battery line would waste power when it's running

How much power? I wouldn't expect it to be a lot at all.

 

[Askarus]

Hmm. Obviously, anything that could be used to explicitly switch the battery line would waste power when it's running

How much power? I wouldn't expect it to be a lot at all.

If it is turned off it draws almost no current (39uA according to the data sheet).

 

[Granitehead]

Hmm. Obviously, anything that could be used to explicitly switch the battery line would waste power when it's running

How much power? I wouldn't expect it to be a lot at all.

 

If it is turned off it draws almost no current (39uA according to the data sheet).

You misunderstood.

 

[Askarus]

I see.

 

[fusion_power]

I have no problem with closed Source Drivers for the GPU part as long as the drivers just WORK (so we can actualy USE them onto the Pyra for HW acceleration of all kind)  and are updated regulary by the Company. I mean like onto the PC where you also don't need open source divers for your Graphics Card because nobody could do these drivers better than the actual GPU companies at the moment (I have never heared of an open source graphics driver that is better than the official one).

I'm happy with my current PC GeFocre Driver and I know NVidia will update their drivers regulary. Let's hope that TI/Imagination also updates and maintains their drivers a little bit longer and more regulary than they did with the old OMAP3 where basicly not much happend anymore at the GPU driver front afaik. maybe the Pandora/Pyra community can at least report bugs or suggestions for driver improvements to TI? So if the community can't do anything there, TI may be which also would save alot of time that stunts like reverse enginering would cost.

 

[Grench]

What are the current plans for hooking up the optional baseband processor?


I'd really like to have GPS as an option in my Pyra and the ability to borrow someone's SIM card and get mobile data on occasion would also be nice (I'm Canadian. You have to mortgage your firstborn child for mobile data here), but I'd rather not have it at all if I can't be absolutely certain that it's powered off and dead to the world when not in use.


That means I need a hardware killswitch, a software killswitch paired with an indicator light that can't be mucked with in software, a baseband processor module that's easy for the end user to add/remove, or no baseband processor and USB dongles for GPS and/or LTE.

The module is connected through an internal USB port and presents itself as a simple tty for AT commands. There will be one GPIO to turn it on or off. And another GPIO that reports if it is currently powered on. This can very likely be hidden by a rfkill wwan.

There are AT commands for the 3G part and others for the GPS. Those commands are public.

Anyways, it needs a SIM card to be operated.

For LTE we will have to see if we can manage the antenna variants (there are different frequency ranges all over the world needing complex antennas to be as universal as possible). Currently we experiment with the Cinterion PHS8 (and PLS8) modules (the same as for the Neo900).

Well, having it as a USB device with a TTY interface definitely makes it a difficult target for exploits. (Well-tested transport-level driver (uhci/ohci/ehci), simple and well-understood higher-level API (tty+AT), no DMA, bus slave, etc.) Am I correct in understanding that the USB 5V line is the only power supply and the on/off GPIO's "off" state will result in no current flow when the chip is unpowered?

(Partly for security but primarily to avoid it being a drain on the battery during the 99% of the time I don't use it, I want the chip to be electrically dead when not in use and, if my understanding is correct, I should be able to accomplish that by turning the chip off via both rfkill wwan and the sysfs API for controlling USB device power allocation.)

Almost yes. The module is directly connected to the battery because such a module may draw high pulse currents. So it would not be wise to use a step-up converter for +5V.

If it is turned off it draws almost no current (39uA according to the data sheet).

And we did choose the USB/tty interface because we also refuse fully integrated modems (shared memory). Anyways there are no 3/4G modem modules on the market that don't have an USB/tty interface. You only get them as integrated baseband of some SoCs. This of course saves chips, interconnect and cost - but makes a lot of troubles to get the design certified. With a precertified module and an USB interface it is much simpler.

I think what they're asking for is one or more hard-line switches to 100% disable any element within the device usable for spying on them.  i.e. user accessible dip switches to disconnect all power lines individually to each radio (wifi 2.4ghz, wifi 5ghz, GPS, bluetooth, Cellular), microphone, speaker (could be reversed as mic) and camera module (if any).

Not just a 'device says it's turned off but still draws some negligible power', but actual manual throw switches that cut the power to the module.  An old SCSI style dip switch recessed in the case and accessible to the tip of the stylus would work.

A year ago I'd have said it was just paranoia.  Today it would be an awesome sales point.

 

[Klumpen]

I think what they're asking for is one or more hard-line switches to 100% disable any element within the device usable for spying on them.  i.e. user accessible dip switches to disconnect all power lines individually to each radio (wifi 2.4ghz, wifi 5ghz, GPS, bluetooth, Cellular), microphone, speaker (could be reversed as mic) and camera module (if any).

Not just a 'device says it's turned off but still draws some negligible power', but actual manual throw switches that cut the power to the module.  An old SCSI style dip switch recessed in the case and accessible to the tip of the stylus would work.

A year ago I'd have said it was just paranoia.  Today it would be an awesome sales point.

The Anti-NSA-Switch, nice idea.

 

[ssokolow]

I think what they're asking for is one or more hard-line switches to 100% disable any element within the device usable for spying on them.  i.e. user accessible dip switches to disconnect all power lines individually to each radio (wifi 2.4ghz, wifi 5ghz, GPS, bluetooth, Cellular), microphone, speaker (could be reversed as mic) and camera module (if any).

Not just a 'device says it's turned off but still draws some negligible power', but actual manual throw switches that cut the power to the module.  An old SCSI style dip switch recessed in the case and accessible to the tip of the stylus would work.

A year ago I'd have said it was just paranoia.  Today it would be an awesome sales point.

The GPS and cellular are part of the same chip so I seriously doubt there's any feasible way to effectively kill-switch them separately.

My main concern is that, if I go for the option to include a baseband processor for GPS support, I don't want to be opening additional avenues of attack when it's not in use. (Hence why it needs to be killswitch'd separately from WiFi which I use far more often.) If I don't trust it, I'll buy a Pyra without and order a USB GPS dongle.

However, the more kill switches, the merrier. Having one for the mic would definitely be nice since it can't be unplugged like my desktop's mic and camera.

 

[Granitehead]

I was also talking about kill switches, but I actually meant solid state switches controlled by the Pyra software. I don't like the idea of dedicating buttons to this kind of thing. And if you can't trust the Pyra OS to actually trigger the switches if you ask it to then you're lost anyway.

 

[Askarus]

I was also talking about kill switches, but I actually meant solid state switches controlled by the Pyra software. I don't like the idea of dedicating buttons to this kind of thing. And if you can't trust the Pyra OS to actually trigger the switches if you ask it to then you're lost anyway.

That's the best solution.

I don't think there is space for additional physical switches on the board.

 

[ssokolow]

I was also talking about kill switches, but I actually meant solid state switches controlled by the Pyra software. I don't like the idea of dedicating buttons to this kind of thing. And if you can't trust the Pyra OS to actually trigger the switches if you ask it to then you're lost anyway.

That's the best solution.

I don't think there is space for additional physical switches on the board.

Agreed. That's basically what I wanted to see. Something to fully kill-switch the baseband processor since it could potentially report an IMEI independent of Linux oversight and, if feasible, some sort of option to make toggling the microphone contingent on root authentication to mitigate exploits in un-privileged applications.

(That latter one is something I've been meaning to implement purely in software on my Pandora if I can find the time.)

 

[WizardStan]

I'm Canadian. You have to mortgage your firstborn child for mobile data here)

If you're in any of the major citieswhere Wind mobile operates use them. I have no complaints with service. $45 a month for unlimited everything with the only catch being that you're roaming outside of Wind zones, but I live in Kitchener, work in Waterloo, and occasionally go to Toronto so this isn't a problem for me and if it isn't for you either then you should give them a try. If it won't work for you but you have friends for whom it will I ask that you spread the word because the more customers they steal from Robelus the more likely they are to start pricing things more reasonably as well.
On that note...

The module is connected through an internal USB port and presents itself as a simple tty for AT commands.

I'd be interested in a lot more information about this. When I was investigating modules I found a few companies which produced modules across many bands making it really simple to use a different module depending on region. Is it safe to assume this is what you're doing? Specifically I want to know whether the UMTS IV band is going to be an option because if so then I will duct tape my current phone until the Pyra comes out. If not then as ssokolow mentions data plans from the major companies are quite ridiculous, so I'll just pick up a regular phone and continue tethering as I do my Pandora now.Also I'm assuming the module you're planning exposes the audio as either a USB composite device or on separate I2S lines but that could be a mistake. Is phone capability planned in there somewhere and if not why not?