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

Troy Benjegerdes troy.benjegerdes at sifive.com
Wed Jul 3 16:22:23 UTC 2019



> 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 ;)



More information about the U-Boot mailing list