SoC: Back and forth!


Meanwhile, is there anything we can do to convince IT to open source PowerVR? Or at least for them to be more cooperative to RE efforts. Maybe an on-line petition or mass email campaign?
We could ask our hacker's friends to start real work on reverse engineering the PowerVR (the same as it was done for Mali). A FSF supported project is sitting around for a while and has collected information and some ideas how to proceed. But without manpower there is no progress.

And, RE can be done on the OpenPandora because every units has a SGX530 inside :)

Project link: http://powervr.gnu.org.ve/doku.php - there is also a mailing list

The good thing is that starting to do that does not depend on political decisions of others we could address with a petition. But without effort there will be no results (like with petitions).
 
Last edited by a moderator:
Well, that might be a good idea to start. Maybe we can at least find someone capable of doing that for a fee.
 
^ And? Nvidia still won't sell any SoCs to EvilDragon.
 
I meant to respond to ekianjo's comments that mass email petition to IT is not gonna work.  It may not work but "one never know until one tries".  I know Nvidia has already denied Ed.

Ed should be like Linus and give his middle finger to IT so they can opensource its drivers to us   :D
 
Last edited by a moderator:
Exciting news, thanks ED.

Regarding reverse engineering the GPU driver/blob; is this really something worth pursuing (genuine question)? I worry that the guys working on the closed source drivers are experts, and a lot of man power, sure bugs still end up existing, but it is likely that an open source driver is going to end up in a better state? I know the prospect of being able to tinker after official support has ended is nice, but I don't really have a good feel for whether an open source driver for the GPU has any real chance of being worth using over the official one? Plus if official driver updates are made that increase performance/unlock features/etc. then all that work is going to have to be duplicated/improved on the open source version.

I am looking forward to seeing how the Pyra continues to move forwards!
 
Ed should be like Linus and give his middle finger to IT so they can opensource its drivers to us :D
Let's make a video of at least 1000 board members giving the middle finger to IT.

...well, better not.
Yeah, we better not since OMAP5 is the only SoCs we can get.  Don't make them angry and they are the ones giving us the middle fingers :D
 
Last edited by a moderator:
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.
 
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).
 
Last edited by a moderator:
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.)
 
Last edited by a moderator:
At the risk of you(EvilDragon) giving me the stink eye (lol), can you try at Samsung one more time?
 
At the risk of you(EvilDragon) giving me the stink eye (lol), can you try at Samsung one more time?
What about getting the stink eye from gta04 whos already done a ton of the electrical design for the Pyra based around omap5 SoC already.
 
At the risk of you(EvilDragon) giving me the stink eye (lol), can you try at Samsung one more time?
What about getting the stink eye from gta04 whos already done a ton of the electrical design for the Pyra based around omap5 SoC already.
So the dev board without hardware acceleration and any optimization did run Ice Weasel, Gimp, Battle for Wesnoth and 2 x PSX emulator with the double resolution renderer on a 1080p display with the KDE 4 desktop in the background and had about 10-20% on each core left.

I think we should stop development.

It's not that powerful.

OMAP 5 sucks.

Don't think anyone would buy this device if it can't run 10 PSX emulators at once.
 
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?
 
Back
Top