ReleaseEngineering/Projects/PandaBoards: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 34: | Line 34: | ||
== Roadmap/Timeline == | == Roadmap/Timeline == | ||
* ctalbert will build an Android 4.0 OS image and flash to panda board. Largely doing this to see what the steps are, ensure they are clear and repeatable (Brad already proved it's possible) and to see where we'd modify these steps in order to create an OS with our tools pre-installed. | |||
* Once ctalbert has the panda board running, he is going to do a quick sanity test run on the pandaboard to verify that it makes it through reftest/mochitest etc. | |||
* Once it runs through the tests without fizzling out, ctalbert is going to go rack it in haxxor so that the releng can put it into their staging environment and start doing preliminary tests on it to work through the changes that will be required in buildbot to handle another android device type reporting test results, as well as doing a true stability assessment. | |||
== Bugs/Links == | == Bugs/Links == | ||
* [http://pandaboard.org/content/buy http://pandaboard.org/content/buy] | * [http://pandaboard.org/content/buy http://pandaboard.org/content/buy] | ||
Revision as of 03:11, 8 February 2012
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
- ctalbert will build an Android 4.0 OS image and flash to panda board. Largely doing this to see what the steps are, ensure they are clear and repeatable (Brad already proved it's possible) and to see where we'd modify these steps in order to create an OS with our tools pre-installed.
- Once ctalbert has the panda board running, he is going to do a quick sanity test run on the pandaboard to verify that it makes it through reftest/mochitest etc.
- Once it runs through the tests without fizzling out, ctalbert is going to go rack it in haxxor so that the releng can put it into their staging environment and start doing preliminary tests on it to work through the changes that will be required in buildbot to handle another android device type reporting test results, as well as doing a true stability assessment.