[U-Boot] [ANN] U-Boot v2019.07-rc4 released

[U-Boot] [ANN] U-Boot v2019.07-rc4 released

[Tom Rini]

Hey all,

It's release day and here is v2019.07-rc4.   At this point, I know we
have some regression fixes for i.MX that are coming, and I'm expecting a
fix to the build time failure for tinker-rk3288.

To repeat myself about DM migration deadlines, first, let me say again,
that DM is not required for SPL.  This comes up enough that I want to
say it again here.  Next, if there is active progress on converting
things, we'll keep from pulling the code out.  This is why for example,
we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
still in progress on being converted, so I need to update the series I
posted after the last -rc to remove still less drivers.

In terms of a changelog, 
git log --merges v2019.07-rc3..v2019.07-rc4
continues to improve in quality.  If you're sending me a PR, please
include a few lines or words in summary and I'll be sure to put it into
the merge commit.

As I mentioned with -rc3, with this cycle is coming closer to an end,
it's time to decide if we're going to keep this 3 month cycle or go back
to 2 months.  After the last release while I did get some feedback, the
overall balance is still in the 3 month bucket.

I'm planning on doing -rc5 on June 24th with the release scheduled on
July 8th.  Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190610/e6b9a846/attachment.sig>

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

[Marek Vasut]

On 6/11/19 3:31 AM, Tom Rini wrote:
> Hey all,
> 
> It's release day and here is v2019.07-rc4.   At this point, I know we
> have some regression fixes for i.MX that are coming, and I'm expecting a
> fix to the build time failure for tinker-rk3288.
> 
> To repeat myself about DM migration deadlines, first, let me say again,
> that DM is not required for SPL.  This comes up enough that I want to
> say it again here.  Next, if there is active progress on converting
> things, we'll keep from pulling the code out.  This is why for example,
> we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> still in progress on being converted, so I need to update the series I
> posted after the last -rc to remove still less drivers.
> 
> In terms of a changelog, 
> git log --merges v2019.07-rc3..v2019.07-rc4
> continues to improve in quality.  If you're sending me a PR, please
> include a few lines or words in summary and I'll be sure to put it into
> the merge commit.

Do you have a list of the platforms that are currently in the danger zone ?

> As I mentioned with -rc3, with this cycle is coming closer to an end,
> it's time to decide if we're going to keep this 3 month cycle or go back
> to 2 months.  After the last release while I did get some feedback, the
> overall balance is still in the 3 month bucket.

I vote for 3 months, I very much like it.

> I'm planning on doing -rc5 on June 24th with the release scheduled on
> July 8th.  Thanks all!

Great

-- 
Best regards,
Marek Vasut

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

[Tom Rini]

On Tue, Jun 11, 2019 at 04:56:24AM +0200, Marek Vasut wrote:
> On 6/11/19 3:31 AM, Tom Rini wrote:
> > Hey all,
> > 
> > It's release day and here is v2019.07-rc4.   At this point, I know we
> > have some regression fixes for i.MX that are coming, and I'm expecting a
> > fix to the build time failure for tinker-rk3288.
> > 
> > To repeat myself about DM migration deadlines, first, let me say again,
> > that DM is not required for SPL.  This comes up enough that I want to
> > say it again here.  Next, if there is active progress on converting
> > things, we'll keep from pulling the code out.  This is why for example,
> > we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> > still in progress on being converted, so I need to update the series I
> > posted after the last -rc to remove still less drivers.
> > 
> > In terms of a changelog, 
> > git log --merges v2019.07-rc3..v2019.07-rc4
> > continues to improve in quality.  If you're sending me a PR, please
> > include a few lines or words in summary and I'll be sure to put it into
> > the merge commit.
> 
> Do you have a list of the platforms that are currently in the danger zone ?

In what way?  Uncaught size overflow?  No, but I hope a lot of
maintainers take advantage of this new feature so we can catch this
problem and do something about the root cause.  DM migration stuff?
That doesn't cause the board to get dropped but to lose functionality.
It's too late in this cycle for the SPI conversion series now, but the
Freescale/NXP driver was updated, so it's not nearly as many boards as
it looked like before.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190611/158f34d3/attachment.sig>

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

[Marek Vasut]

On 6/11/19 1:15 PM, Tom Rini wrote:
> On Tue, Jun 11, 2019 at 04:56:24AM +0200, Marek Vasut wrote:
>> On 6/11/19 3:31 AM, Tom Rini wrote:
>>> Hey all,
>>>
>>> It's release day and here is v2019.07-rc4.   At this point, I know we
>>> have some regression fixes for i.MX that are coming, and I'm expecting a
>>> fix to the build time failure for tinker-rk3288.
>>>
>>> To repeat myself about DM migration deadlines, first, let me say again,
>>> that DM is not required for SPL.  This comes up enough that I want to
>>> say it again here.  Next, if there is active progress on converting
>>> things, we'll keep from pulling the code out.  This is why for example,
>>> we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
>>> still in progress on being converted, so I need to update the series I
>>> posted after the last -rc to remove still less drivers.
>>>
>>> In terms of a changelog, 
>>> git log --merges v2019.07-rc3..v2019.07-rc4
>>> continues to improve in quality.  If you're sending me a PR, please
>>> include a few lines or words in summary and I'll be sure to put it into
>>> the merge commit.
>>
>> Do you have a list of the platforms that are currently in the danger zone ?
> 
> In what way?  Uncaught size overflow?  No, but I hope a lot of
> maintainers take advantage of this new feature so we can catch this
> problem and do something about the root cause.  DM migration stuff?

Yes, DM migration stuff, would be nice to have a list of boards which
still generate warnings.

> That doesn't cause the board to get dropped but to lose functionality.
> It's too late in this cycle for the SPI conversion series now, but the
> Freescale/NXP driver was updated, so it's not nearly as many boards as
> it looked like before.
> 


-- 
Best regards,
Marek Vasut

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

[Lukasz Majewski]

Hi Tom,

> Hey all,
> 
> It's release day and here is v2019.07-rc4.   At this point, I know we
> have some regression fixes for i.MX that are coming, and I'm
> expecting a fix to the build time failure for tinker-rk3288.
> 
> To repeat myself about DM migration deadlines, first, let me say
> again, that DM is not required for SPL.  This comes up enough that I
> want to say it again here.  Next, if there is active progress on
> converting things, we'll keep from pulling the code out.  This is why
> for example, we haven't yet pulled out a lot of deprecated SPI code.
> Some of it is still in progress on being converted, so I need to
> update the series I posted after the last -rc to remove still less
> drivers.
> 
> In terms of a changelog, 
> git log --merges v2019.07-rc3..v2019.07-rc4
> continues to improve in quality.  If you're sending me a PR, please
> include a few lines or words in summary and I'll be sure to put it
> into the merge commit.
> 
> As I mentioned with -rc3, with this cycle is coming closer to an end,
> it's time to decide if we're going to keep this 3 month cycle or go
> back to 2 months.

I do prefer 3 months cycle. IMHO with 3 months cycle, we do have a time
to fix things and adding new code is done in merge window.

>  After the last release while I did get some
> feedback, the overall balance is still in the 3 month bucket.
> 
> I'm planning on doing -rc5 on June 24th with the release scheduled on
> July 8th.  Thanks all!
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190611/b22155b7/attachment.sig>

[U-Boot] Poplar broken in U-Boot v2019.07-rc4

[Andreas Färber]

Hello,

Am 11.06.19 um 03:31 schrieb Tom Rini:
> It's release day and here is v2019.07-rc4.   At this point, I know we
> have some regression fixes for i.MX that are coming, and I'm expecting a
> fix to the build time failure for tinker-rk3288.
> 
> To repeat myself about DM migration deadlines, first, let me say again,
> that DM is not required for SPL.  This comes up enough that I want to
> say it again here.  Next, if there is active progress on converting
> things, we'll keep from pulling the code out.  This is why for example,
> we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> still in progress on being converted, so I need to update the series I
> posted after the last -rc to remove still less drivers.

I've noticed that Poplar board is regressing with v2019.07-rc4 compared
to v2019.04. It doesn't even show a U-Boot version banner:

INFO:    Boot BL33 from 0x37000000 for 0 Bytes
NOTICE:  BL31: v2.1(debug):
NOTICE:  BL31: Built : 16:00:26, Jun 16 2019
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: InitINFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x37000000
INFO:    SPSR = 0x3c9

I'm using TF-A v2.1 with the pending eMMC fix from
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1230
but same issue without that patch.

I don't see any report or fix for this yet - is this related to DM?

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190616/7bf18848/attachment.sig>

[U-Boot] Poplar broken in U-Boot v2019.07-rc4

[Shawn Guo]

On Sun, Jun 16, 2019 at 07:36:08PM +0200, Andreas Färber wrote:
> Hello,
> 
> Am 11.06.19 um 03:31 schrieb Tom Rini:
> > It's release day and here is v2019.07-rc4.   At this point, I know we
> > have some regression fixes for i.MX that are coming, and I'm expecting a
> > fix to the build time failure for tinker-rk3288.
> > 
> > To repeat myself about DM migration deadlines, first, let me say again,
> > that DM is not required for SPL.  This comes up enough that I want to
> > say it again here.  Next, if there is active progress on converting
> > things, we'll keep from pulling the code out.  This is why for example,
> > we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> > still in progress on being converted, so I need to update the series I
> > posted after the last -rc to remove still less drivers.
> 
> I've noticed that Poplar board is regressing with v2019.07-rc4 compared
> to v2019.04. It doesn't even show a U-Boot version banner:
> 
> INFO:    Boot BL33 from 0x37000000 for 0 Bytes
> NOTICE:  BL31: v2.1(debug):
> NOTICE:  BL31: Built : 16:00:26, Jun 16 2019
> INFO:    ARM GICv2 driver initialized
> INFO:    BL31: Initializing runtime services
> WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
> WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
> WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
> INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
> INFO:    BL31: InitINFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x37000000
> INFO:    SPSR = 0x3c9
> 
> I'm using TF-A v2.1 with the pending eMMC fix from
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1230
> but same issue without that patch.
> 
> I don't see any report or fix for this yet - is this related to DM?

Thanks for reporting, Andreas.  I just ran a git bisect which points to
commit below.

  3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to simple-bus driver")

I'm not sure this indicates above commit is problematic or Poplar
platform is buggy on DM support though.

Shawn

[U-Boot] Poplar broken in U-Boot v2019.07-rc4

[Bin Meng]

Hi,

On Mon, Jun 17, 2019 at 10:17 AM Shawn Guo <shawn.guo@linaro.org> wrote:
>
> On Sun, Jun 16, 2019 at 07:36:08PM +0200, Andreas Färber wrote:
> > Hello,
> >
> > Am 11.06.19 um 03:31 schrieb Tom Rini:
> > > It's release day and here is v2019.07-rc4.   At this point, I know we
> > > have some regression fixes for i.MX that are coming, and I'm expecting a
> > > fix to the build time failure for tinker-rk3288.
> > >
> > > To repeat myself about DM migration deadlines, first, let me say again,
> > > that DM is not required for SPL.  This comes up enough that I want to
> > > say it again here.  Next, if there is active progress on converting
> > > things, we'll keep from pulling the code out.  This is why for example,
> > > we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> > > still in progress on being converted, so I need to update the series I
> > > posted after the last -rc to remove still less drivers.
> >
> > I've noticed that Poplar board is regressing with v2019.07-rc4 compared
> > to v2019.04. It doesn't even show a U-Boot version banner:
> >
> > INFO:    Boot BL33 from 0x37000000 for 0 Bytes
> > NOTICE:  BL31: v2.1(debug):
> > NOTICE:  BL31: Built : 16:00:26, Jun 16 2019
> > INFO:    ARM GICv2 driver initialized
> > INFO:    BL31: Initializing runtime services
> > WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
> > WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
> > WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
> > INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
> > INFO:    BL31: InitINFO:    BL31: Preparing for EL3 exit to normal world
> > INFO:    Entry point address = 0x37000000
> > INFO:    SPSR = 0x3c9
> >
> > I'm using TF-A v2.1 with the pending eMMC fix from
> > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1230
> > but same issue without that patch.
> >
> > I don't see any report or fix for this yet - is this related to DM?
>
> Thanks for reporting, Andreas.  I just ran a git bisect which points to
> commit below.
>
>   3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to simple-bus driver")
>
> I'm not sure this indicates above commit is problematic or Poplar
> platform is buggy on DM support though.

Please increase CONFIG_SYS_MALLOC_F_LEN and have a try. The above
commits makes the simple-bus driver available before pre-relocation
which requires a little more memory.

Regards,
Bin

[U-Boot] Poplar broken in U-Boot v2019.07-rc4

[Shawn Guo]

On Mon, Jun 17, 2019 at 10:19:14AM +0800, Bin Meng wrote:
> Hi,
> 
> On Mon, Jun 17, 2019 at 10:17 AM Shawn Guo <shawn.guo@linaro.org> wrote:
> >
> > On Sun, Jun 16, 2019 at 07:36:08PM +0200, Andreas Färber wrote:
> > > Hello,
> > >
> > > Am 11.06.19 um 03:31 schrieb Tom Rini:
> > > > It's release day and here is v2019.07-rc4.   At this point, I know we
> > > > have some regression fixes for i.MX that are coming, and I'm expecting a
> > > > fix to the build time failure for tinker-rk3288.
> > > >
> > > > To repeat myself about DM migration deadlines, first, let me say again,
> > > > that DM is not required for SPL.  This comes up enough that I want to
> > > > say it again here.  Next, if there is active progress on converting
> > > > things, we'll keep from pulling the code out.  This is why for example,
> > > > we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> > > > still in progress on being converted, so I need to update the series I
> > > > posted after the last -rc to remove still less drivers.
> > >
> > > I've noticed that Poplar board is regressing with v2019.07-rc4 compared
> > > to v2019.04. It doesn't even show a U-Boot version banner:
> > >
> > > INFO:    Boot BL33 from 0x37000000 for 0 Bytes
> > > NOTICE:  BL31: v2.1(debug):
> > > NOTICE:  BL31: Built : 16:00:26, Jun 16 2019
> > > INFO:    ARM GICv2 driver initialized
> > > INFO:    BL31: Initializing runtime services
> > > WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
> > > WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
> > > WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
> > > INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
> > > INFO:    BL31: InitINFO:    BL31: Preparing for EL3 exit to normal world
> > > INFO:    Entry point address = 0x37000000
> > > INFO:    SPSR = 0x3c9
> > >
> > > I'm using TF-A v2.1 with the pending eMMC fix from
> > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1230
> > > but same issue without that patch.
> > >
> > > I don't see any report or fix for this yet - is this related to DM?
> >
> > Thanks for reporting, Andreas.  I just ran a git bisect which points to
> > commit below.
> >
> >   3a7c45f6a772 ("simple-bus: add DM_FLAG_PRE_RELOC flag to simple-bus driver")
> >
> > I'm not sure this indicates above commit is problematic or Poplar
> > platform is buggy on DM support though.
> 
> Please increase CONFIG_SYS_MALLOC_F_LEN and have a try. The above
> commits makes the simple-bus driver available before pre-relocation
> which requires a little more memory.

Ah, thanks much for the input, Bin.  It worked!  I will send a fix for
it shortly.

Shawn

[U-Boot] [ANN] U-Boot v2019.07-rc4 released

[Simon Glass]

Hi Tom,

On Tue, 11 Jun 2019 at 02:33, Tom Rini <trini@konsulko.com> wrote:
>
> Hey all,
>
> It's release day and here is v2019.07-rc4.   At this point, I know we
> have some regression fixes for i.MX that are coming, and I'm expecting a
> fix to the build time failure for tinker-rk3288.
>
> To repeat myself about DM migration deadlines, first, let me say again,
> that DM is not required for SPL.  This comes up enough that I want to
> say it again here.  Next, if there is active progress on converting
> things, we'll keep from pulling the code out.  This is why for example,
> we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
> still in progress on being converted, so I need to update the series I
> posted after the last -rc to remove still less drivers.
>
> In terms of a changelog,
> git log --merges v2019.07-rc3..v2019.07-rc4
> continues to improve in quality.  If you're sending me a PR, please
> include a few lines or words in summary and I'll be sure to put it into
> the merge commit.
>
> As I mentioned with -rc3, with this cycle is coming closer to an end,
> it's time to decide if we're going to keep this 3 month cycle or go back
> to 2 months.  After the last release while I did get some feedback, the
> overall balance is still in the 3 month bucket.

I vote for 2 months. I find the current release disappears into a
black hole for a about a month, and patches sit on the list for what
seems like eternity. I have the option of doing a -next branch but it
seems that very few do this.

I'd like to better understand the benefits of the 3-month timeline.

Regards,
Simon

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

[Marek Vasut]

On 6/22/19 4:55 PM, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 11 Jun 2019 at 02:33, Tom Rini <trini@konsulko.com> wrote:
>>
>> Hey all,
>>
>> It's release day and here is v2019.07-rc4.   At this point, I know we
>> have some regression fixes for i.MX that are coming, and I'm expecting a
>> fix to the build time failure for tinker-rk3288.
>>
>> To repeat myself about DM migration deadlines, first, let me say again,
>> that DM is not required for SPL.  This comes up enough that I want to
>> say it again here.  Next, if there is active progress on converting
>> things, we'll keep from pulling the code out.  This is why for example,
>> we haven't yet pulled out a lot of deprecated SPI code.  Some of it is
>> still in progress on being converted, so I need to update the series I
>> posted after the last -rc to remove still less drivers.
>>
>> In terms of a changelog,
>> git log --merges v2019.07-rc3..v2019.07-rc4
>> continues to improve in quality.  If you're sending me a PR, please
>> include a few lines or words in summary and I'll be sure to put it into
>> the merge commit.
>>
>> As I mentioned with -rc3, with this cycle is coming closer to an end,
>> it's time to decide if we're going to keep this 3 month cycle or go back
>> to 2 months.  After the last release while I did get some feedback, the
>> overall balance is still in the 3 month bucket.
> 
> I vote for 2 months. I find the current release disappears into a
> black hole for a about a month, and patches sit on the list for what
> seems like eternity. I have the option of doing a -next branch but it
> seems that very few do this.
> 
> I'd like to better understand the benefits of the 3-month timeline.

Stability, with the 2 months cycle, there was no time to stabilize the
release and fix bugs, everyone was just cannonfodding patches upstream
all the time. The result was always a release which wasn't quite well
done, had rough edges, unfixed bugs and it wasn't something which you
could deploy.

Now we have 1 month window where we only accept bugfixes and where
things slow down. This removes some stress from the maintainers too.
And that lets us take a step back and think about the bigger project
questions, rather than just dealing with the onslaught of patches.

-- 
Best regards,
Marek Vasut

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

[Andreas Färber]

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.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

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

[Simon Glass]

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?

Regards,
Simon

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

[Andreas Färber]

Hi,

Am 22.06.19 um 20:15 schrieb Simon Glass:
> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
>> 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?

You're missing my point: What good is it to do a release when you
yourself consider it of such poor quality that you advise others not to
take it?

That has nothing per-se to do with who uses that release and whether you
build it in OBS or locally.

> 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 don't understand that question. The proposal, as I understood it, is
to shorten the release cycle by one month, doing six instead of four
releases. How could there be an improvement by leaving it as it is? My
fear is that the change will make it _worse_, i.e. no improvement but
rather risk of more regressions by switching to _two_ months.

In this very same -rc4 thread I reported one such regression, and
luckily a patch was quickly prepared to address it. It's not yet merged
despite tested - review also takes time.

> I feel that
> testing is the only way to get that.

Agreed. And my point was that testing takes time. Increasing the release
frequency shortens the time for testing of each release.

> Perhaps we should select a small subset of boards which do get tested,
> and actually have custodians build/test on those for every rc?

Many custodians are volunteers. You can't force them to test boards at a
pace you dictate to them. Also, more frequent releases also increase the
chances of a custodian/maintainer being on vacation during a release.

And a working, say, BeagleBone doesn't make the user of a random other
board any happier. ;-)

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

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

[Simon Glass]

Hi Andreas,

On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber@suse.de> wrote:
>
> Hi,
>
> Am 22.06.19 um 20:15 schrieb Simon Glass:
> > On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
> >> 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?
>
> You're missing my point: What good is it to do a release when you
> yourself consider it of such poor quality that you advise others not to
> take it?

Who said that?

Your point, I thought, was that people didn't have time to test it?

>
> That has nothing per-se to do with who uses that release and whether you
> build it in OBS or locally.
>
> > 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 don't understand that question. The proposal, as I understood it, is
> to shorten the release cycle by one month, doing six instead of four
> releases. How could there be an improvement by leaving it as it is? My
> fear is that the change will make it _worse_, i.e. no improvement but
> rather risk of more regressions by switching to _two_ months.
>
> In this very same -rc4 thread I reported one such regression, and
> luckily a patch was quickly prepared to address it. It's not yet merged
> despite tested - review also takes time.
>
> > I feel that
> > testing is the only way to get that.
>
> Agreed. And my point was that testing takes time. Increasing the release
> frequency shortens the time for testing of each release.
>
> > Perhaps we should select a small subset of boards which do get tested,
> > and actually have custodians build/test on those for every rc?
>
> Many custodians are volunteers. You can't force them to test boards at a
> pace you dictate to them. Also, more frequent releases also increase the
> chances of a custodian/maintainer being on vacation during a release.
>
> And a working, say, BeagleBone doesn't make the user of a random other
> board any happier. ;-)

Another question...how much do people care about the latest and
greatest features? Perhaps we should be merging patches frequently,
but creating a release branch separate from master?

The current process seems very very slow to me.

Regards,
Simon

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

[Andreas Färber]

Hi Simon,

Am 22.06.19 um 21:14 schrieb Simon Glass:
> On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber@suse.de> wrote:
>> Am 22.06.19 um 20:15 schrieb Simon Glass:
>>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
>>>> 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?
>>
>> You're missing my point: What good is it to do a release when you
>> yourself consider it of such poor quality that you advise others not to
>> take it?
> 
> Who said that?

You, quoted above. In response to my concerns about decreasing quality
you suggested to take only every second release. That doesn't improve
the quality of either. It implies that one may have such bad quality
that people should skip it and yet does nothing to improve the next.

> Your point, I thought, was that people didn't have time to test it?

Not quite, I was talking about the full build-test-report-fix cycle
taking its time. Bugs in one -rc don't necessarily get detected and
fixed in time for the next -rc.

And I fail to see how your suggestion of skipping releases gives them
more time to test before the U-Boot release. That would rather be an
argument for slowing down the U-Boot release cycle beyond 3 months
(which I'm not asking).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

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

[Simon Glass]

Hi Andreas,,

On Sat, 22 Jun 2019 at 20:49, Andreas Färber <afaerber@suse.de> wrote:
>
> Hi Simon,
>
> Am 22.06.19 um 21:14 schrieb Simon Glass:
> > On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber@suse.de> wrote:
> >> Am 22.06.19 um 20:15 schrieb Simon Glass:
> >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
> >>>> 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?
> >>
> >> You're missing my point: What good is it to do a release when you
> >> yourself consider it of such poor quality that you advise others not to
> >> take it?
> >
> > Who said that?
>
> You, quoted above. In response to my concerns about decreasing quality
> you suggested to take only every second release. That doesn't improve
> the quality of either. It implies that one may have such bad quality
> that people should skip it and yet does nothing to improve the next.

Actually I did not say that I consider the release of such poor
quality. Nor did I advise others to take it. I suspect this is a
misunderstanding of "But why not just take every second release?".

My point was that if people don't have time to test every release,
then just put in the time to test every second release.

I am actually not sure how much a bit of extra time helps with
stability. Have the last two releases been more reliable on hardware,
since people have found time to test them using the 9-week -rc phases,
whereas the previous 6-week one did not?

>
> > Your point, I thought, was that people didn't have time to test it?
>
> Not quite, I was talking about the full build-test-report-fix cycle
> taking its time. Bugs in one -rc don't necessarily get detected and
> fixed in time for the next -rc.

That doesn't change unless the distance between rc's increases. But I
think your point is that there are more -rc releases so more time to
find and fix things.

>
> And I fail to see how your suggestion of skipping releases gives them
> more time to test before the U-Boot release. That would rather be an
> argument for slowing down the U-Boot release cycle beyond 3 months
> (which I'm not asking).

It would mean testing only every second release, which halves the time
you spend testing, a significant reduction in load. Just need to
schedule testing time over (say) 6 week, 3 times a year instead of 6
times.

I think an automated test setup is the best way to do this. Marek asks
who would run it? Perhaps people who have an interest in each board
and want to spend less time on manual testing? We already have the
technology to do this, with pytest and tbot.

Regards,
Simon

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

[Marek Vasut]

On 6/24/19 3:56 PM, Simon Glass wrote:
> Hi Andreas,,
> 
> On Sat, 22 Jun 2019 at 20:49, Andreas Färber <afaerber@suse.de> wrote:
>>
>> Hi Simon,
>>
>> Am 22.06.19 um 21:14 schrieb Simon Glass:
>>> On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber@suse.de> wrote:
>>>> Am 22.06.19 um 20:15 schrieb Simon Glass:
>>>>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
>>>>>> 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?
>>>>
>>>> You're missing my point: What good is it to do a release when you
>>>> yourself consider it of such poor quality that you advise others not to
>>>> take it?
>>>
>>> Who said that?
>>
>> You, quoted above. In response to my concerns about decreasing quality
>> you suggested to take only every second release. That doesn't improve
>> the quality of either. It implies that one may have such bad quality
>> that people should skip it and yet does nothing to improve the next.
> 
> Actually I did not say that I consider the release of such poor
> quality. Nor did I advise others to take it. I suspect this is a
> misunderstanding of "But why not just take every second release?".
> 
> My point was that if people don't have time to test every release,
> then just put in the time to test every second release.

So what about be the point of releasing the untested intermediate
release at all ? I'm sure people can just grab u-boot/master or -rc2
just fine.

[...]

-- 
Best regards,
Marek Vasut

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

[Simon Glass]

Hi Marek,


On Mon, 24 Jun 2019 at 11:10, Marek Vasut <marex@denx.de> wrote:
>
> On 6/24/19 3:56 PM, Simon Glass wrote:
> > Hi Andreas,,
> >
> > On Sat, 22 Jun 2019 at 20:49, Andreas Färber <afaerber@suse.de> wrote:
> >>
> >> Hi Simon,
> >>
> >> Am 22.06.19 um 21:14 schrieb Simon Glass:
> >>> On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber@suse.de> wrote:
> >>>> Am 22.06.19 um 20:15 schrieb Simon Glass:
> >>>>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber@suse.de> wrote:
> >>>>>> 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?
> >>>>
> >>>> You're missing my point: What good is it to do a release when you
> >>>> yourself consider it of such poor quality that you advise others not to
> >>>> take it?
> >>>
> >>> Who said that?
> >>
> >> You, quoted above. In response to my concerns about decreasing quality
> >> you suggested to take only every second release. That doesn't improve
> >> the quality of either. It implies that one may have such bad quality
> >> that people should skip it and yet does nothing to improve the next.
> >
> > Actually I did not say that I consider the release of such poor
> > quality. Nor did I advise others to take it. I suspect this is a
> > misunderstanding of "But why not just take every second release?".
> >
> > My point was that if people don't have time to test every release,
> > then just put in the time to test every second release.
>
> So what about be the point of releasing the untested intermediate
> release at all ? I'm sure people can just grab u-boot/master or -rc2
> just fine.

Because (I contend) these releases do actually attract testing effort
and are stable in most cases. I think this is the 90/10 rule - we are
adding a road-block in the project for the 10% of boards that are
super, super important...so important that no one can actually find
time to test them :-)

Regards,
Simon

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

[Heinrich Schuchardt]

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.

Regards

Heinrich

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

[Marek Vasut]

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 ?

-- 
Best regards,
Marek Vasut

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

[Tom Rini]

On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut 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 ?

My hope is that we can make use of the GitLab CI features to carefully
(!!!!) expose some labs and setups.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190624/3938baa9/attachment.sig>

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

[Neil Armstrong]

On 24/06/2019 17:29, Tom Rini wrote:
> On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut 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 ?
> 
> My hope is that we can make use of the GitLab CI features to carefully
> (!!!!) expose some labs and setups.

Yes, the Gitlab CI could send jobs to lava instances to run physical boot
tests, we (baylibre) are investigating this at some point, re-using our
kernelCI infrastructure.

Neil

> 
> 
> _______________________________________________
> U-Boot-Board-Maintainers mailing list
> U-Boot-Board-Maintainers at lists.denx.de
> https://lists.denx.de/listinfo/u-boot-board-maintainers
> 

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

[Tom Rini]

On Tue, Jun 25, 2019 at 01:10:26PM +0200, Neil Armstrong wrote:
> On 24/06/2019 17:29, Tom Rini wrote:
> > On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut 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 ?
> > 
> > My hope is that we can make use of the GitLab CI features to carefully
> > (!!!!) expose some labs and setups.
> 
> Yes, the Gitlab CI could send jobs to lava instances to run physical boot
> tests, we (baylibre) are investigating this at some point, re-using our
> kernelCI infrastructure.

That seems like overkill, possibly.  How hard would it be to have lava
kick off our test.py code?  In the .gitlab-ci.yml I posted, I migrated
the logic we have for travis to run our tests.  I wonder how hard it
would be to have test.py "check out" or whatever machines from lava?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190625/b359300c/attachment.sig>

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

[Matwey V. Kornilov]

25.06.2019 15:04, Tom Rini пишет:
> On Tue, Jun 25, 2019 at 01:10:26PM +0200, Neil Armstrong wrote:
>> On 24/06/2019 17:29, Tom Rini wrote:
>>> On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut 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 ?
>>> 
>>> My hope is that we can make use of the GitLab CI features to
>>> carefully (!!!!) expose some labs and setups.
>> 
>> Yes, the Gitlab CI could send jobs to lava instances to run
>> physical boot tests, we (baylibre) are investigating this at some
>> point, re-using our kernelCI infrastructure.
> 
> That seems like overkill, possibly.  How hard would it be to have
> lava kick off our test.py code?  In the .gitlab-ci.yml I posted, I
> migrated the logic we have for travis to run our tests.  I wonder
> how hard it would be to have test.py "check out" or whatever
> machines from lava?
> 

Isn't it possible to kick off the lava from gitlab webhooks?

> 
> _______________________________________________ U-Boot mailing
> list U-Boot at lists.denx.de https://lists.denx.de/listinfo/u-boot
> 

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

[Neil Armstrong]

On 30/06/2019 12:34, Matwey V. Kornilov wrote:
> 25.06.2019 15:04, Tom Rini пишет:
>> On Tue, Jun 25, 2019 at 01:10:26PM +0200, Neil Armstrong wrote:
>>> On 24/06/2019 17:29, Tom Rini wrote:
>>>> On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut 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 ?
>>>>
>>>> My hope is that we can make use of the GitLab CI features to
>>>> carefully (!!!!) expose some labs and setups.
>>>
>>> Yes, the Gitlab CI could send jobs to lava instances to run
>>> physical boot tests, we (baylibre) are investigating this at some
>>> point, re-using our kernelCI infrastructure.
>>
>> That seems like overkill, possibly.  How hard would it be to have
>> lava kick off our test.py code?  In the .gitlab-ci.yml I posted, I
>> migrated the logic we have for travis to run our tests.  I wonder
>> how hard it would be to have test.py "check out" or whatever
>> machines from lava?
>>
> 
> Isn't it possible to kick off the lava from gitlab webhooks?

Not sure, but you can totally generate and submits jobs to lava from
gitlab ci :
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/panfrost/ci/gitlab-ci.yml#L158
as collabora does for panfrost.

Neil

> 
>>
>> _______________________________________________ U-Boot mailing
>> list U-Boot at lists.denx.de https://lists.denx.de/listinfo/u-boot
>>
> 
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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

[Troy Benjegerdes]

> 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.

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.

With the HiFive Unleashed in SiFive’s test lab, we use OpenOCD
for JTAG, all I need is one USB cable and I can load U-boot via JTAG,
and boot a recovery image, and reload the SDcard, so the SDwire is
not really necessary for boards that have easy JTAG setup.

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

[Marek Vasut]

On 7/2/19 6:04 PM, Troy Benjegerdes 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.
> 
> 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.

My proposal would be that you take a few exceptionally weird, disparate,
boards and try to implement dead-simple CI around those. You'll start
hitting all kinds of weird issues in the process and the dead-simple
will quickly start turning into complicated :)

You can, however, explore the U-Boot test.py, tbot, or whatever other
test frameworks there are and try to come up with some easy setup howto.

> 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.

Not all boards boot from SD cards though, some boot from hard-to-recover
non-replaceable boot media.

> With the HiFive Unleashed in SiFive’s test lab, we use OpenOCD
> for JTAG, all I need is one USB cable and I can load U-boot via JTAG,
> and boot a recovery image, and reload the SDcard, so the SDwire is
> not really necessary for boards that have easy JTAG setup.

btw booting from JTAG and cold-booting from boot media may trigger
different bugs. You most certainly want to install the bootloader and
try both cold and warm boot.

-- 
Best regards,
Marek Vasut

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

[Simon Glass]

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?

Regards,
Simon

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

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190703/21bd210c/attachment.sig>

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

[Troy Benjegerdes]

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

[U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] [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@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

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

[Heiko Schocher]

Hello Heinrich,

Am 22.06.2019 um 21:12 schrieb Heinrich Schuchardt:
> 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.

Yes ... my dream is also we have a lot of boards, on which we can test
automagically. My approach was tbot, with which I made weekly automated
commandline tests (u-boot and linux), see example results from my old
tbot version:

http://xeidos.ddns.net/tests/test_db_auslesen.php#987

(Intentionally link to latest good test, as I found no time yet to
  refresh my testsetup to new tbot, see later).

Above webpage is created through a tbot generator, which fills a
mysql database and the webpage is a simple php script. I also speculated
to write a generator to connect to kernel-ci ... but time is the missing
resource.

For the above example tbot and the webserver run on a raspberry pi,
also the raspberry pi is used as "Lab Host" which controlls the board
under test, so cheap hardware costs. It is easy to adapt tbot to your
hardware setup, see [2]

But tbot was a hack as my python skills are not the greatest, so
luckily Harald (added to cc) found time to rewrite it completly from
scratch (many thanks!), see [1] and [2]

Ok, missing here and there functionality from the old version, but
it is much more cleaner ... may you take a look at it, also it is
Open Source, feel free to help and improve tbot!

I use tbot for my daily work, as tbot has also an interactive mode [3],
with which you can use tbot for powering on your board and connect
to for example the u-boot command line). No need anymore to know where
your board is and how to power it on or how to connect to the console.
(Background I mostly have no real physical access to hardware I work
  on)

So you can work while developing with tbot, and at the end you have
immediately an automated setup you can integrate into your CI. As
tbot is a commandline tool, this is mostly easy to do.

Also it is possible to call pytest framework [4] from u-boot,
and of course you can call this out of tbot [5].

bye,
Heiko

[1] https://github.com/Rahix/tbot
[2] https://rahix.de/tbot/
[3] https://rahix.de/tbot/getting-started.html#interactive
[4] 
http://git.denx.de/?p=u-boot.git;a=blob;f=test/README;h=4bc9ca3a6ae9de0e3ed6ff420c5edfe6027ad2c6;hb=77f6e2dd0551d8a825bab391a1bd6b838874bcd4
[5] result from pytest framework called from tbot
     http://xeidos.ddns.net/tbot/id_985/test-log.html

> 
> Regards
> 
> Heinrich
> _______________________________________________
> U-Boot-Custodians mailing list
> U-Boot-Custodians at lists.denx.de
> https://lists.denx.de/listinfo/u-boot-custodians

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de

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

[Matwey V. Kornilov]

22.06.2019 22:12, Heinrich Schuchardt пишет:
> 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.

Is it possible to buy SDwire somewhere?

> 
> It would make sense to have such test automation for all of our
> architectures similar to what Kernel CI (https://kernelci.org/) does.
> 
> Regards
> 
> Heinrich
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot