On 7/3/19 6:22 PM, Troy Benjegerdes wrote:
On Jul 3, 2019, at 11:04 AM, Tom Rini trini@konsulko.com wrote:
On Wed, Jul 03, 2019 at 09:59:22AM -0600, Simon Glass wrote:
Hi Troy,
On Tue, 2 Jul 2019 at 10:04, Troy Benjegerdes troy.benjegerdes@sifive.com wrote:
On Jun 22, 2019, at 2:43 PM, Marek Vasut marex@denx.de wrote:
On 6/22/19 9:12 PM, Heinrich Schuchardt wrote:
On 6/22/19 8:15 PM, Simon Glass wrote: > Hi, > > On Sat, 22 Jun 2019 at 16:10, Andreas Färber afaerber@suse.de wrote: >> >> Hi Simon, >> >> Am 22.06.19 um 16:55 schrieb Simon Glass: >>> I'd like to better understand the benefits of the 3-month timeline. >> >> It takes time to learn about a release, package and build it, test it on >> various hardware, investigate and report errors, wait for feedback and >> fixes, rinse and repeat with the next -rc. Many people don't do this as >> their main job. >> >> If we shorten the release cycle, newer boards will get out faster (which >> is good) but the overall quality of boards not actively worked on >> (because they were working good enough before) will decay, which is bad. >> The only way to counteract that would be to automatically test on real >> hardware rather than just building, and doing that for all these masses >> of boards seems unrealistic. > > Here I think you are talking about distributions. But why not just > take every second release? > > I have certain had the experience of getting a board our of the > cupboard and finding that the latest U-Boot doesn't work, nor the one > before, nor the three before that. > > Are we actually seeing an improvement in regressions? I feel that > testing is the only way to get that. > > Perhaps we should select a small subset of boards which do get tested, > and actually have custodians build/test on those for every rc?
What I have been doing before all my recent pull requests is to boot both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via bootefi and GRUB. To make this easier I am using a Raspberry with a relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire) controlling the system under test, cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large What would be needed is scripts to automate the testing including all the Python tests.
It would make sense to have such test automation for all of our architectures similar to what Kernel CI (https://kernelci.org/) does.
So who's gonna set it up and host it ?
I just got the infrastructure going to do this for the HiFive Unleashed (RiscV port), but that’s only one board right now.
I’d propose that one of the responsibilities of being a custodian/ maintainer for a board and/or arch is a commitment to run a *simple* automated testing framework on a set of boards.
SGTM, and I feel we should work towards a shared solution ideally in the U-Boot tree to make this easy for people. Much exists already.
I’ve looked into KenrelCI enough to see that it seems rather complex to get up and running. We need a dead-simple setup (a few debian packages? A container? An SDcard image for a BeagleBone?) that can collect serial console output and power cycle a board.
Eventually maybe we should have a Tizen SDWire or something like that, however that requires some real money for board development since I can’t seem to find a source for where I can buy an SDWire.
Me neither.
So where can we buy this magic board?
You can't, exactly. It's up at https://wiki.tizen.org/SDWire and Heinrich might have a bit more to say, but it's one of those things that we may want to see how much a run, or two runs cost and have a US and EU person that can resell-at-cost.
-- Tom
What are the chances I can get KiCad sources for the board ;)
CAD files are available online at https://git.tizen.org/cgit/tools/testlab/sd-mux/tree/doc/hardware/SDWire
Adam Malinowski who designed the board is selling it currently at ca. 45.00 EUR incl. VAT.
If you have a suggestion for production in larger lot sizes, please, contact him.
Best regards
Heinrich