On 7/3/19 6:22 PM, Troy Benjegerdes wrote:
On Jul 3, 2019, at 11:04 AM, Tom Rini <tr...@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.benjeger...@sifive.com> wrote:
On Jun 22, 2019, at 2:43 PM, Marek Vasut <ma...@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 <afaer...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
