ReleaseEngineering/Projects/PandaBoards
What is the goal?
- To have a testing automation for Android 4.0
- To enable us to test NEON support (a graphics subsystem these cards have)
- To test a different chipset architecture than the tegras (Tegra is largely a dying platform in mobile space)
- To test on android 4.0
- To have a mobilie automation platform that is more reliable and easier to flash than the tegras (less IT management cost)
- To have a mobile platform that is faster than the tegras
What does mobile need/know?
What does the a-team need/know?
- How do we do flashing of these devices so that you can flash with all required software from the get-go
- Does it run through our test systems without dying?
- How much faster is it than a tegra?
What does IT need/know?
What does releng need/know?
Point of contact: armenzg
- a panda board
- hook up the panda-board to the automation
- know if the setup is the same as tegras (SUT agent, foopies)
- clint: Exact same setup.
- what suites are going to be run on it
- clint: Everything we run on the tegras
- imaging process
- Ateam to define
- ordering schedule
- how many boards?
- do we really know if the model we follow is scalable?? does the tegra model work?
- ordering these many boards is simply ridiculous for manufacturers
- do they have to be racked in haxxor?
- clint: No. These are wired devices, no reason to use haxxor for this.
Roadmap/Timeline
TBD