[U-Boot-Custodians] [U-Boot-Board-Maintainers] [U-Boot] [ANN] U-Boot v2019.07-rc4 released

[Heinrich Schuchardt]

On 7/3/19 6:22 PM, Troy Benjegerdes wrote:
>
>
>> On Jul 3, 2019, at 11:04 AM, Tom Rini <trini at 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 at sifive.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Jun 22, 2019, at 2:43 PM, Marek Vasut <marex at 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 at 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