[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Tom Rini]

Hey all,

Today is the scheduled release date for v2015.10.  But as you can tell
from the list of patches I just merged, a lot of stuff needed to go in
still and while I'm "happy" it's all safe it's also too much to not do
another -rc.  So here we are and I'm expecting to do the release next
Monday.  So please, test this.  If you have a regression, speak up.  If
you have a bugfix, speak up.

And to the maintainers, if you want to start on your "next" branch now
so that you can just rebase it to master next week, that might not be a
bad idea.  I might even do that myself (but please keep your stuff based
on my master).  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151012/faff68dd/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Wolfgang Denk]

Dear Tom,

In message <20151012151845.GJ23893@bill-the-cat> you wrote:
> 
> Today is the scheduled release date for v2015.10.  But as you can tell
> from the list of patches I just merged, a lot of stuff needed to go in
> still and while I'm "happy" it's all safe it's also too much to not do
> another -rc.  So here we are and I'm expecting to do the release next
> Monday.  So please, test this.  If you have a regression, speak up.  If
> you have a bugfix, speak up.

Thanks.  Tarballs are available both on the FTP server and ACD.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never underestimate the bandwidth of a station wagon full of tapes.
                                -- Dr. Warren Jackson, Director, UTCS

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Heiko Schocher]

Hello Tom,

Am 12.10.2015 um 17:18 schrieb Tom Rini:
> Hey all,
>
> Today is the scheduled release date for v2015.10.  But as you can tell
> from the list of patches I just merged, a lot of stuff needed to go in
> still and while I'm "happy" it's all safe it's also too much to not do
> another -rc.  So here we are and I'm expecting to do the release next
> Monday.  So please, test this.  If you have a regression, speak up.  If
> you have a bugfix, speak up.

I just tested this and ubi on the aristainetos2 board and dfu on the
smartweb board seems fine.

As we talked on the U-Boot sumit about automated testsystems, I had
successfully setup my tbot [1] I talked, on my raspberry pi at my home.

I start it through buidlbot [2] also running on the raspberry. I use
buildbot, because it has fancy possibilities for triggering tests,
like nightly builds or if new git commits arrive in tree ...

Also it has a webinterface for presenting the results, see them for
my testdemonstration here [3] (maybe slow, because I have a slow internet
connection, and the raspberry pi is not the fastest machine ...).
There are 2 U-Boot tests:

ari_ubi:      ubi/ubifs tests on the aristainetos2 board
smartweb_dfu: dfu tests on the smartweb board

You can look into the logs and see, what is done in the tests,
currently very basic tests ...

I trigger the tests currently manually. The boards are in the denx vlab
in munich, while I am living in hungary ... So I tried in tbot to make
it easy to add new labs, which contains 1-n boards. So everybody who
has a board can add it, without the need to build up somewhere a big
testlab with all boards in it ...

bye,
Heiko
[1] https://github.com/hsdenx/tbot
[2] http://buildbot.net/
[3] http://xeidos.ddns.net/buildbot/waterfall
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Andreas Färber]

Hi Tom,

Am 12.10.2015 um 17:18 schrieb Tom Rini:
> If you have a regression, speak up.

For -rc4 I had reported that CONFIG_API is broken for sunxi among
others. I was told this was fallout of the new Driver Model. Has anyone
thought about how to fix this? Is that already a lost cause for 2015.10?

Improving test coverage for such off-by-default features will also be
helpful going forward. For instance, Simon's brand-new rk3288 code was
lacking some MMC define for CONFIG_API to build iirc - that part is
trivial to fix when actually build-testing. I'll see if I can polish
some of my fixes in time.

I had also tried building the qemu-ppce500 target and got lots of linker
errors with our native gcc 5.x on ppc (duplicate function definitions
with arch/powerpc/include/asm/byteorder.h). My first try of a ppc
target, haven't found time to investigate further yet, so not sure if a
regression or just compiler-dependent.

https://build.opensuse.org/package/live_build_log/home:a_faerber:u-boot:ppc/u-boot-qemu-ppce500/openSUSE_Factory_PowerPC/ppc

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)

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

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Tom Rini]

On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas F?rber wrote:
> Hi Tom,
> 
> Am 12.10.2015 um 17:18 schrieb Tom Rini:
> > If you have a regression, speak up.
> 
> For -rc4 I had reported that CONFIG_API is broken for sunxi among
> others. I was told this was fallout of the new Driver Model. Has anyone
> thought about how to fix this? Is that already a lost cause for 2015.10?
> 
> Improving test coverage for such off-by-default features will also be
> helpful going forward. For instance, Simon's brand-new rk3288 code was
> lacking some MMC define for CONFIG_API to build iirc - that part is
> trivial to fix when actually build-testing. I'll see if I can polish
> some of my fixes in time.

I'm just not sure what to do about CONFIG_API some days.  I know one use
case is for GRUB but I'd like to move away from that if possible
(distros should be doing the generic distro bits and extlinux.conf).
After that, I'm only hazily aware of the real use-cases.

> I had also tried building the qemu-ppce500 target and got lots of linker
> errors with our native gcc 5.x on ppc (duplicate function definitions
> with arch/powerpc/include/asm/byteorder.h). My first try of a ppc
> target, haven't found time to investigate further yet, so not sure if a
> regression or just compiler-dependent.

It builds for me but I don't have a gcc 5.x compiler handy.  I probably
need to find the time to rectify that soon.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151014/87776d16/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Andreas Färber]

Am 15.10.2015 um 02:40 schrieb Tom Rini:
> On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas F?rber wrote:
>> Am 12.10.2015 um 17:18 schrieb Tom Rini:
>>> If you have a regression, speak up.
>>
>> For -rc4 I had reported that CONFIG_API is broken for sunxi among
>> others. I was told this was fallout of the new Driver Model. Has anyone
>> thought about how to fix this? Is that already a lost cause for 2015.10?
>>
>> Improving test coverage for such off-by-default features will also be
>> helpful going forward. For instance, Simon's brand-new rk3288 code was
>> lacking some MMC define for CONFIG_API to build iirc - that part is
>> trivial to fix when actually build-testing. I'll see if I can polish
>> some of my fixes in time.
> 
> I'm just not sure what to do about CONFIG_API some days.  I know one use
> case is for GRUB but I'd like to move away from that if possible
> (distros should be doing the generic distro bits and extlinux.conf).
> After that, I'm only hazily aware of the real use-cases.

The problem is that no other platform uses those. On x86_64, ppc64le,
s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
extlinux.conf or anything else, it'll require changes to distro tools
that end up being special-cased to 32-bit arm. With more and more server
vendors adopting UEFI and aarch64, that seems a waste of effort.

A boot.scr is easy to generate once for an installation image, and I see
Guillaume has been helping to make it usable where necessary, but as
long as that points to a single zImage / initrd / dtb (ext4 symlinks
pointing to the latest), after the user installs a new kernel package,
things might simply become unbootable for the average user. That's where
GRUB is handy in offering a selection of multiple kernels to go back to
a previously working state. I'm not particularly attached to CONFIG_API
myself - if the same can be achieved either in GRUB without CONFIG_API
or inside U-Boot with scripts and without GRUB, I'd be happy to hear
about it. :)

Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's
hardcoded RAM offsets), and I've found it to load unreliably, as if
there's garbage in memory. Might be our 2.02~beta2 is missing some
backports. bootz works fine, so I guess bootm is not to blame there.

Anyway, I think it's valid to say that we should either fix CONFIG_API
to build okay, or drop it completely, but not carry it around in
decaying state. ;)

BTW some api example failed to link for some targets, too. According to
my spec file, that was with snow, spring and odroid-xu3 (in -rc4),
running into an undefined memset (link order maybe?).

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N?rnberg)

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

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Wolfgang Denk]

Dear Tom,

In message <20151015004002.GX23893@bill-the-cat> you wrote:
> 
> I'm just not sure what to do about CONFIG_API some days.  I know one use
> case is for GRUB but I'd like to move away from that if possible
> (distros should be doing the generic distro bits and extlinux.conf).
> After that, I'm only hazily aware of the real use-cases.

The major use case (as I understand it) are the FreeBSD users
who need this API for booting.  I'm adding Rafal and Bartek to Cc:
as they should know best if this interface is still in wide use.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Software entities are more complex for their size  than  perhaps  any
other human construct because no two parts are alike. If they are, we
make  the  two  similar parts into a subroutine -- open or closed. In
this respect, software  systems  differ  profoundly  from  computers,
buildings, or automobiles, where repeated elements abound.
                                                   - Fred Brooks, Jr.

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Rafal Jaworowski]

Hi Wolfgang, Tom,

On Thu, Oct 15, 2015 at 9:28 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Tom,
>
> In message <20151015004002.GX23893@bill-the-cat> you wrote:
>>
>> I'm just not sure what to do about CONFIG_API some days.  I know one use
>> case is for GRUB but I'd like to move away from that if possible
>> (distros should be doing the generic distro bits and extlinux.conf).
>> After that, I'm only hazily aware of the real use-cases.
>
> The major use case (as I understand it) are the FreeBSD users
> who need this API for booting.  I'm adding Rafal and Bartek to Cc:
> as they should know best if this interface is still in wide use.

Indeed, it's actively and widely used by the FreeBSD [last stage] bootloader.

Thanks,
Rafal

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Tom Rini]

On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas F?rber wrote:
> Am 15.10.2015 um 02:40 schrieb Tom Rini:
> > On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas F?rber wrote:
> >> Am 12.10.2015 um 17:18 schrieb Tom Rini:
> >>> If you have a regression, speak up.
> >>
> >> For -rc4 I had reported that CONFIG_API is broken for sunxi among
> >> others. I was told this was fallout of the new Driver Model. Has anyone
> >> thought about how to fix this? Is that already a lost cause for 2015.10?
> >>
> >> Improving test coverage for such off-by-default features will also be
> >> helpful going forward. For instance, Simon's brand-new rk3288 code was
> >> lacking some MMC define for CONFIG_API to build iirc - that part is
> >> trivial to fix when actually build-testing. I'll see if I can polish
> >> some of my fixes in time.
> > 
> > I'm just not sure what to do about CONFIG_API some days.  I know one use
> > case is for GRUB but I'd like to move away from that if possible
> > (distros should be doing the generic distro bits and extlinux.conf).
> > After that, I'm only hazily aware of the real use-cases.
> 
> The problem is that no other platform uses those. On x86_64, ppc64le,
> s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
> extlinux.conf or anything else, it'll require changes to distro tools
> that end up being special-cased to 32-bit arm. With more and more server
> vendors adopting UEFI and aarch64, that seems a waste of effort.

That's a thing to ponder, yes.  There's nothing ARM32 centric about the
generic distro framework and it's on my TODO list now to poke Fedora
about enabling the extlinux.conf knob on x86 because there's a growing
number of platforms using U-Boot there.  And hikey does (and Juno
should/will) be doing it as well.

> A boot.scr is easy to generate once for an installation image, and I see
> Guillaume has been helping to make it usable where necessary, but as
> long as that points to a single zImage / initrd / dtb (ext4 symlinks
> pointing to the latest), after the user installs a new kernel package,
> things might simply become unbootable for the average user. That's where
> GRUB is handy in offering a selection of multiple kernels to go back to
> a previously working state. I'm not particularly attached to CONFIG_API
> myself - if the same can be achieved either in GRUB without CONFIG_API
> or inside U-Boot with scripts and without GRUB, I'd be happy to hear
> about it. :)

Well, that roughly is the point of the whole config_distro_defaults /
config_distro_bootcmd stuff is that the distro doesn't have to care what
board it's on, it can just boot.

> Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's
> hardcoded RAM offsets), and I've found it to load unreliably, as if
> there's garbage in memory. Might be our 2.02~beta2 is missing some
> backports. bootz works fine, so I guess bootm is not to blame there.
> 
> Anyway, I think it's valid to say that we should either fix CONFIG_API
> to build okay, or drop it completely, but not carry it around in
> decaying state. ;)

So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be
taken here, but we need to cover things a lot better than we do today.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151015/31a1103c/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Peter Robinson]

On Thu, Oct 15, 2015 at 9:55 PM, Tom Rini <trini@konsulko.com> wrote:
> On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas F?rber wrote:
>> Am 15.10.2015 um 02:40 schrieb Tom Rini:
>> > On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas F?rber wrote:
>> >> Am 12.10.2015 um 17:18 schrieb Tom Rini:
>> >>> If you have a regression, speak up.
>> >>
>> >> For -rc4 I had reported that CONFIG_API is broken for sunxi among
>> >> others. I was told this was fallout of the new Driver Model. Has anyone
>> >> thought about how to fix this? Is that already a lost cause for 2015.10?
>> >>
>> >> Improving test coverage for such off-by-default features will also be
>> >> helpful going forward. For instance, Simon's brand-new rk3288 code was
>> >> lacking some MMC define for CONFIG_API to build iirc - that part is
>> >> trivial to fix when actually build-testing. I'll see if I can polish
>> >> some of my fixes in time.
>> >
>> > I'm just not sure what to do about CONFIG_API some days.  I know one use
>> > case is for GRUB but I'd like to move away from that if possible
>> > (distros should be doing the generic distro bits and extlinux.conf).
>> > After that, I'm only hazily aware of the real use-cases.
>>
>> The problem is that no other platform uses those. On x86_64, ppc64le,
>> s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
>> extlinux.conf or anything else, it'll require changes to distro tools
>> that end up being special-cased to 32-bit arm. With more and more server
>> vendors adopting UEFI and aarch64, that seems a waste of effort.
>
> That's a thing to ponder, yes.  There's nothing ARM32 centric about the
> generic distro framework and it's on my TODO list now to poke Fedora
> about enabling the extlinux.conf knob on x86 because there's a growing
> number of platforms using U-Boot there.  And hikey does (and Juno
> should/will) be doing it as well.

Sure, do you mean patches against the various boards or something in
the actual Fedora shipped components, either way both Dennis and I are
on the list.

>> A boot.scr is easy to generate once for an installation image, and I see
>> Guillaume has been helping to make it usable where necessary, but as
>> long as that points to a single zImage / initrd / dtb (ext4 symlinks
>> pointing to the latest), after the user installs a new kernel package,
>> things might simply become unbootable for the average user. That's where
>> GRUB is handy in offering a selection of multiple kernels to go back to
>> a previously working state. I'm not particularly attached to CONFIG_API
>> myself - if the same can be achieved either in GRUB without CONFIG_API
>> or inside U-Boot with scripts and without GRUB, I'd be happy to hear
>> about it. :)
>
> Well, that roughly is the point of the whole config_distro_defaults /
> config_distro_bootcmd stuff is that the distro doesn't have to care what
> board it's on, it can just boot.

And for the platforms that have it enabled it works really well :-)

>> Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's
>> hardcoded RAM offsets), and I've found it to load unreliably, as if
>> there's garbage in memory. Might be our 2.02~beta2 is missing some
>> backports. bootz works fine, so I guess bootm is not to blame there.
>>
>> Anyway, I think it's valid to say that we should either fix CONFIG_API
>> to build okay, or drop it completely, but not carry it around in
>> decaying state. ;)
>
> So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be
> taken here, but we need to cover things a lot better than we do today.
>
> --
> Tom
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Tom Rini]

On Fri, Oct 16, 2015 at 01:50:47AM +0100, Peter Robinson wrote:
> On Thu, Oct 15, 2015 at 9:55 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas F?rber wrote:
> >> Am 15.10.2015 um 02:40 schrieb Tom Rini:
> >> > On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas F?rber wrote:
> >> >> Am 12.10.2015 um 17:18 schrieb Tom Rini:
> >> >>> If you have a regression, speak up.
> >> >>
> >> >> For -rc4 I had reported that CONFIG_API is broken for sunxi among
> >> >> others. I was told this was fallout of the new Driver Model. Has anyone
> >> >> thought about how to fix this? Is that already a lost cause for 2015.10?
> >> >>
> >> >> Improving test coverage for such off-by-default features will also be
> >> >> helpful going forward. For instance, Simon's brand-new rk3288 code was
> >> >> lacking some MMC define for CONFIG_API to build iirc - that part is
> >> >> trivial to fix when actually build-testing. I'll see if I can polish
> >> >> some of my fixes in time.
> >> >
> >> > I'm just not sure what to do about CONFIG_API some days.  I know one use
> >> > case is for GRUB but I'd like to move away from that if possible
> >> > (distros should be doing the generic distro bits and extlinux.conf).
> >> > After that, I'm only hazily aware of the real use-cases.
> >>
> >> The problem is that no other platform uses those. On x86_64, ppc64le,
> >> s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
> >> extlinux.conf or anything else, it'll require changes to distro tools
> >> that end up being special-cased to 32-bit arm. With more and more server
> >> vendors adopting UEFI and aarch64, that seems a waste of effort.
> >
> > That's a thing to ponder, yes.  There's nothing ARM32 centric about the
> > generic distro framework and it's on my TODO list now to poke Fedora
> > about enabling the extlinux.conf knob on x86 because there's a growing
> > number of platforms using U-Boot there.  And hikey does (and Juno
> > should/will) be doing it as well.
> 
> Sure, do you mean patches against the various boards or something in
> the actual Fedora shipped components, either way both Dennis and I are
> on the list.

With respect to Fedora, it would be pretty nice if I could install F23
on my Minnowboard Max and have it use config_distro_bootcmd stuff.  I
think I mentioned this to Hans at ELCE and he said I probably just need
to ask and x86 can have the same extlinux.conf generation stuff that ARM
has :)  I of course need to go whack the minnow config in U-Boot, but
that's on me..

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151015/8b43063b/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Peter Robinson]

>> >> >>> If you have a regression, speak up.
>> >> >>
>> >> >> For -rc4 I had reported that CONFIG_API is broken for sunxi among
>> >> >> others. I was told this was fallout of the new Driver Model. Has anyone
>> >> >> thought about how to fix this? Is that already a lost cause for 2015.10?
>> >> >>
>> >> >> Improving test coverage for such off-by-default features will also be
>> >> >> helpful going forward. For instance, Simon's brand-new rk3288 code was
>> >> >> lacking some MMC define for CONFIG_API to build iirc - that part is
>> >> >> trivial to fix when actually build-testing. I'll see if I can polish
>> >> >> some of my fixes in time.
>> >> >
>> >> > I'm just not sure what to do about CONFIG_API some days.  I know one use
>> >> > case is for GRUB but I'd like to move away from that if possible
>> >> > (distros should be doing the generic distro bits and extlinux.conf).
>> >> > After that, I'm only hazily aware of the real use-cases.
>> >>
>> >> The problem is that no other platform uses those. On x86_64, ppc64le,
>> >> s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
>> >> extlinux.conf or anything else, it'll require changes to distro tools
>> >> that end up being special-cased to 32-bit arm. With more and more server
>> >> vendors adopting UEFI and aarch64, that seems a waste of effort.
>> >
>> > That's a thing to ponder, yes.  There's nothing ARM32 centric about the
>> > generic distro framework and it's on my TODO list now to poke Fedora
>> > about enabling the extlinux.conf knob on x86 because there's a growing
>> > number of platforms using U-Boot there.  And hikey does (and Juno
>> > should/will) be doing it as well.
>>
>> Sure, do you mean patches against the various boards or something in
>> the actual Fedora shipped components, either way both Dennis and I are
>> on the list.
>
> With respect to Fedora, it would be pretty nice if I could install F23
> on my Minnowboard Max and have it use config_distro_bootcmd stuff.  I
> think I mentioned this to Hans at ELCE and he said I probably just need
> to ask and x86 can have the same extlinux.conf generation stuff that ARM
> has :)  I of course need to go whack the minnow config in U-Boot, but
> that's on me..

Ah, that's one for installer support so if it sees u-boot on x86 it
updates the appropriate bits of the bootloader. Those bits should be
relatively straight forward, it's on my list to investigate for
aarch64 too so I'll keep it in mine when I try to get around to doing
that.

Peter

[U-Boot] [ANN] U-Boot v2015.10-rc5 released

[Dennis Gilmore]

On Thursday, October 15, 2015 04:55:55 PM Tom Rini wrote:
> On Thu, Oct 15, 2015 at 03:52:08AM +0200, Andreas F?rber wrote:
> > Am 15.10.2015 um 02:40 schrieb Tom Rini:
> > > On Thu, Oct 15, 2015 at 02:28:34AM +0200, Andreas F?rber wrote:
> > >> Am 12.10.2015 um 17:18 schrieb Tom Rini:
> > >>> If you have a regression, speak up.
> > >> 
> > >> For -rc4 I had reported that CONFIG_API is broken for sunxi among
> > >> others. I was told this was fallout of the new Driver Model. Has anyone
> > >> thought about how to fix this? Is that already a lost cause for
> > >> 2015.10?
> > >> 
> > >> Improving test coverage for such off-by-default features will also be
> > >> helpful going forward. For instance, Simon's brand-new rk3288 code was
> > >> lacking some MMC define for CONFIG_API to build iirc - that part is
> > >> trivial to fix when actually build-testing. I'll see if I can polish
> > >> some of my fixes in time.
> > > 
> > > I'm just not sure what to do about CONFIG_API some days.  I know one use
> > > case is for GRUB but I'd like to move away from that if possible
> > > (distros should be doing the generic distro bits and extlinux.conf).
> > > After that, I'm only hazily aware of the real use-cases.
> > 
> > The problem is that no other platform uses those. On x86_64, ppc64le,
> > s390x, aarch64, etc. we always use GRUB2. Whether it's boot.scr,
> > extlinux.conf or anything else, it'll require changes to distro tools
> > that end up being special-cased to 32-bit arm. With more and more server
> > vendors adopting UEFI and aarch64, that seems a waste of effort.
> 
> That's a thing to ponder, yes.  There's nothing ARM32 centric about the
> generic distro framework and it's on my TODO list now to poke Fedora
> about enabling the extlinux.conf knob on x86 because there's a growing
> number of platforms using U-Boot there.  And hikey does (and Juno
> should/will) be doing it as well.

it is already there https://rhinstaller.github.io/anaconda/boot-options.html#boot-loader-options  add extlinux to the boot arguments on a x86 
install and it will use extlinux.


> > A boot.scr is easy to generate once for an installation image, and I see
> > Guillaume has been helping to make it usable where necessary, but as
> > long as that points to a single zImage / initrd / dtb (ext4 symlinks
> > pointing to the latest), after the user installs a new kernel package,
> > things might simply become unbootable for the average user. That's where
> > GRUB is handy in offering a selection of multiple kernels to go back to
> > a previously working state. I'm not particularly attached to CONFIG_API
> > myself - if the same can be achieved either in GRUB without CONFIG_API
> > or inside U-Boot with scripts and without GRUB, I'd be happy to hear
> > about it. :)
> 
> Well, that roughly is the point of the whole config_distro_defaults /
> config_distro_bootcmd stuff is that the distro doesn't have to care what
> board it's on, it can just boot.

yep :)

> > Regarding GRUB, I've mainly tested it on jetson-tk1 (adjusting grub's
> > hardcoded RAM offsets), and I've found it to load unreliably, as if
> > there's garbage in memory. Might be our 2.02~beta2 is missing some
> > backports. bootz works fine, so I guess bootm is not to blame there.
> > 
> > Anyway, I think it's valid to say that we should either fix CONFIG_API
> > to build okay, or drop it completely, but not carry it around in
> > decaying state. ;)
> 
> So as Wolfgang brought up, FreeBSD uses CONFIG_API so some care must be
> taken here, but we need to cover things a lot better than we do today.

the reason we did not look at grub was that it needed hard coded values, so 
you would need different grub builds for different boards. and a whole world 
of extra pain, and no one was actively working on the arm port of grub. u-boot 
had the extlinux support built in. though I need to find time to extend it a 
bit.

Dennis