configs: beaglebone: update kernel to 4.1.13 and u-boot to 2015.10

This patch is basically the cleaned-up version of Chris LaRocque's patch from his mail

"[PATCH 1/2] Updated the Beaglebone configuration, 01/03/2016 10:01 PM" and the cleanup followed Arnout's corresponding answers.
Changes to Chris' patches:
* dtc patches fetched from GH and placed in 'board/beaglebone/patches/dtc'
* BR2_GLOBAL_PATCH_DIR set accordingly
* added seperated kernel defconfig instead of patching the upstream defconfig
* cleanups in uEnv.txt
* fix u-boot version to 2015.10

The heavy-lifting was done by Chris here, the rest is mostly cosmetics. If anything els seems to be tweaked, please let us know.

 board/beaglebone/linux-3.12.config                 |  251 ---
 board/beaglebone/linux_4.1.13_bb.org_defconfig     | 2043 ++++++++++++++++++++

 ...comment-block-of-fdt_get_property_namelen.patch |   32 +
 .../0002-fdt-Add-a-function-to-count-strings.patch |  246 +++
 ...d-a-function-to-get-the-index-of-a-string.patch |  159 ++
 ...004-fdt-Add-functions-to-retrieve-strings.patch |  173 ++

 ...cache-flush-management-symbols-when-MULTI.patch |   34 -
 .../0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch   |  754 ++++++++

Zoltan,

On Wed, 13 Jan 2016 03:52:22 +0100, Zoltan Gyarmati wrote:

Quoted 4 lines

 ...comment-block-of-fdt_get_property_namelen.patch |   32 +
 .../0002-fdt-Add-a-function-to-count-strings.patch |  246 +++
 ...d-a-function-to-get-the-index-of-a-string.patch |  159 ++
 ...004-fdt-Add-functions-to-retrieve-strings.patch |  173 ++

I am not supper happy with the solution of having those DTC patches specifically for the BeagleBone platform. If I understand correctly, those patches are needed to get the DT overlay to work, right ?

We had the same problem for the C.H.I.P platform, so it would also be useful for us to have a overlay-capable DTC. You can see what my colleague Antoine T?nart did:

https://github.com/NextThingCo/CHIP-buildroot/commit/1a73b514d204d0c6e9100d53011a11d99fd8b778
https://github.com/NextThingCo/CHIP-buildroot/commit/f3334df58611ff3cae5fd62906423fdce3d80d24
https://github.com/NextThingCo/CHIP-buildroot/commit/c4457eba3099f5ca514c06bb35b42772178a151a

It is not ideal because it relies on a separate dtc-overlay package, which packages a different version of dtc, which Antoine has cooked on his own github repository.

We really need to find a solution that is acceptable in the upstream Buildroot, and applies to multiple platforms.

Quoted 4 lines · Thomas Petazzoni

Zoltan,

On Wed, 13 Jan 2016 03:52:22 +0100, Zoltan Gyarmati wrote:

[snip]

Quoted 5 lines

Quoted 4 lines

...comment-block-of-fdt_get_property_namelen.patch |   32 + 
.../0002-fdt-Add-a-function-to-count-strings.patch |  246 +++ 
...d-a-function-to-get-the-index-of-a-string.patch |  159 ++ 
...004-fdt-Add-functions-to-retrieve-strings.patch |  173 ++

Quoted 4 lines

I am not supper happy with the solution of having those DTC patches specifically for the BeagleBone platform. If I understand correctly, those patches are needed to get the DT overlay to work, right ?

I was the one suggesting that approach...

Quoted 7 lines

We had the same problem for the C.H.I.P platform, so it would also be useful for us to have a overlay-capable DTC. You can see what my colleague Antoine T?nart did:

https://github.com/NextThingCo/CHIP-buildroot/commit/1a73b514d204d0c6

Quoted 2 lines

Quoted 1 line

https://github.com/NextThingCo/CHIP-buildroot/commit/c4457eba3099f5ca

Quoted 3 lines

Quoted 5 lines

which packages a different version of dtc, which Antoine has cooked on his own github repository.

We really need to find a solution that is acceptable in the upstream Buildroot, and applies to multiple platforms.

Just thinking out loud: we could add an option to the dtc package that selects the overlay version.

The canonical approach, however, would be to convert dtc to a virtual package with a dtc-kernel-org and a dtc-overlay implementation.

I looked into this a bit more:
* The u-boot doesn't need the host DTC (even though the BR2_TARGET_UBOOT_NEEDS_DTC is set in the patch i sent, something i'll need to fix in the next iteration)

* As the shipped .dtb files are built with the dtc version included in the linux tree from https://github.com/beagleboard/linux.git, which has the support for the overlays, so for merely getting a booting system, no need to hack the dtc package

* As the kernel build also installs this dtc version as 'output/host/usr/bin/linux-dtc', if one needs to compile overlays on the build host, s/he can use that one (although this need to be documented at least in the board's README)

So as far i can see the options are (and none of them is ideal):

1. Implementing a similar solution as Antoine with an additional dtc-overlay package with a custom upstream repo.

2. Stick to the current package and upstream, but introduce a config variable like "BR2_PACKAGE_DTC_SUPPORT_OVERLAY", and if it's set, the needed patchset is applied (or just using an other upstream)

3. Create a virtual package and 2 implementations as dtc-kernel-org and a dtc-overlay

4. Only add the needed patches on the boards where needed and patch dtc by setting BR2_GLOBAL_PATCH_DIR

5. Introducing custom repository/custom patch dir config options for the dtc package like for u-boot and linux (maybe also with an option to use the dtc source coming with the kernel tree?)

Zoltan,

Quoted 10 lines · Zoltan Gyarmati

I looked into this a bit more: * The u-boot doesn't need the host DTC (even though the BR2_TARGET_UBOOT_NEEDS_DTC is set in the patch i sent, something i'll need to fix in the next iteration)

* As the shipped .dtb files are built with the dtc version included in the linux tree from
https://github.com/beagleboard/linux.git, which has the support for the overlays, so for merely getting a booting system, no need to hack the dtc package

Quoted 4 lines

* As the kernel build also installs this dtc version as 'output/host/usr/bin/linux-dtc', if one needs to compile overlays on the build host, s/he can use that one (although this need to be documented at least in the board's README)

So in fact, for the purpose of the beaglebone defconfig itself, we don't need to package an overlay-capable DTC, right?

If that's the case, then I would suggest that we separate the problem in two parts: first get an updated beaglebone defconfig merged, then work on packaging an overlay-capable DTC.

Quoted 13 lines

So as far i can see the options are (and none of them is ideal):

1. Implementing a similar solution as Antoine with an additional dtc-overlay package with a custom upstream repo.

2. Stick to the current package and upstream, but introduce a config variable like "BR2_PACKAGE_DTC_SUPPORT_OVERLAY", and if it's set, the needed patchset is applied (or just using an other upstream)

3. Create a virtual package and 2 implementations as dtc-kernel-org and a dtc-overlay

Quoted 6 lines

4. Only add the needed patches on the boards where needed and patch dtc by setting BR2_GLOBAL_PATCH_DIR

5. Introducing custom repository/custom patch dir config options for the dtc package like for u-boot and linux (maybe also with an option to use the dtc source coming with the kernel tree?)

Do we really need to package the two variants of DTC ? The overlay-capable version is perfectly backward compatible with the mainline DTC. So why don't we simply include in package/dtc/ the patches needed to make DTC overlay-capable ?

Yes, this is moving away from our general rule of not including patches that add new features. But general rules are meant to have exceptions, and in this specific case, the upstream DTC project is so slow at integrating major changes such as overlays, and this feature is now being used so often (BeagleBone, Raspberry Pi, CHIP, etc.) that it makes sense to support it.

Arnout ? Antoine ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Thomas & All,

Quoted 51 lines · Thomas Petazzoni

Zoltan,

Quoted 10 lines · Zoltan Gyarmati

I looked into this a bit more: * The u-boot doesn't need the host DTC (even though the BR2_TARGET_UBOOT_NEEDS_DTC is set in the patch i sent, something i'll need to fix in the next iteration)

* As the shipped .dtb files are built with the dtc version included in the linux tree from
https://github.com/beagleboard/linux.git, which has the support for the overlays, so for merely getting a booting system, no need to hack the dtc package

Quoted 4 lines

* As the kernel build also installs this dtc version as 'output/host/usr/bin/linux-dtc', if one needs to compile overlays on the build host, s/he can use that one (although this need to be documented at least in the board's README)

So in fact, for the purpose of the beaglebone defconfig itself, we don't need to package an overlay-capable DTC, right?

If that's the case, then I would suggest that we separate the problem in two parts: first get an updated beaglebone defconfig merged, then work on packaging an overlay-capable DTC.

Quoted 13 lines

So as far i can see the options are (and none of them is ideal):

1. Implementing a similar solution as Antoine with an additional dtc-overlay package with a custom upstream repo.

2. Stick to the current package and upstream, but introduce a config variable like "BR2_PACKAGE_DTC_SUPPORT_OVERLAY", and if it's set, the needed patchset is applied (or just using an other upstream)

3. Create a virtual package and 2 implementations as dtc-kernel-org and a dtc-overlay

Quoted 6 lines

4. Only add the needed patches on the boards where needed and patch dtc by setting BR2_GLOBAL_PATCH_DIR

5. Introducing custom repository/custom patch dir config options for the dtc package like for u-boot and linux (maybe also with an option to use the dtc source coming with the kernel tree?)

Do we really need to package the two variants of DTC ? The overlay-capable version is perfectly backward compatible with the mainline DTC. So why don't we simply include in package/dtc/ the patches needed to make DTC overlay-capable ?

Quoted 9 lines

Yes, this is moving away from our general rule of not including patches that add new features. But general rules are meant to have exceptions, and in this specific case, the upstream DTC project is so slow at integrating major changes such as overlays, and this feature is now being used so often (BeagleBone, Raspberry Pi, CHIP, etc.) that it makes sense to support it.

Arnout ? Antoine ?

Sounds as Columbus' egg solution to me :)
In the meantime i tested u-boot 2016.01 with the eewiki patch [1],
and with kernel tag 4.1.15-ti-rt-r41 from [2], and so far it seems to be working well (i still need to look into the overlay loading though). If the community also think it makes sense, in the next iteration i'm happy to post a patchset which contains:

* adding the [3] patches for the current dtc package unconditionally
* beaglebone board config with patched u-boot 2016.01 and kernel 4.1.15-ti-rt-r41 with a saner defconfig

[1]
https://github.com/eewiki/u-boot-patches/blob/master/v2016.01/0001-am335
x_evm-uEnv.txt-bootz-n-fixes.patch
[2] https://github.com/beagleboard/linux
[3] https://github.com/pantoniou/dtc/commits/dt-overlays5

Regards
zgyarmati
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWmkdJAAoJEAGmEeeR8iVhEbMH/jG4onr2/MOVNAvTNZGFC86A lX1GQO52BHzXirBTL5uY9cwrJwvnmHx/ZVbUOm5MK/dkqMXQcNplyH3CHwcG+aa7 sBhG7jSvRsG+JzTVG01YZVizbBODFzmSyRzRgR+Wy8gtgi5lfVvdo0zXlOJbPZiI 0dNeTQx/2Bf+ulmqXpqplLnnzrW60w5k0xeHGoea8ZCWNDLgIxUqtUdxdOf7eBAr +grYBuAjJg6y9OpCtWTRf8OEDrj1hY1aFzx/BwYvJKc3ITLt+KMNwrf1oxZSprIG BMMKXkek8TaRRnpyRHEfEhuO3LI1baG5VcsmNgYxq/2ZonJwdBxv5CbjFWaoBXA= =df8M
-----END PGP SIGNATURE-----

Zoltan,

Quoted 2 lines · Zoltan Gyarmati

This patch is basically the cleaned-up version of Chris LaRocque's patch from his mail

Thanks for respining this patch.

Quoted 13 lines

"[PATCH 1/2] Updated the Beaglebone configuration, 01/03/2016 10:01 PM" and the cleanup followed Arnout's corresponding answers. Changes to Chris' patches: * dtc patches fetched from GH and placed in 'board/beaglebone/patches/dtc' * BR2_GLOBAL_PATCH_DIR set accordingly * added seperated kernel defconfig instead of patching the upstream defconfig * cleanups in uEnv.txt * fix u-boot version to 2015.10

The heavy-lifting was done by Chris here, the rest is mostly cosmetics. If anything els seems to be tweaked, please let us know.

Quoted 3 lines

board/beaglebone/linux-3.12.config | 251 ---
board/beaglebone/linux_4.1.13_bb.org_defconfig | 2043
++++++++++++++++++++

Looking at its size, this file looks like a full config file and not a defconfig. Please use a defconfig.

Or better: please use the defconfig that is inside the kernel tree, and if you need additional tweaks, use config fragments.

Quoted 4 lines

...comment-block-of-fdt_get_property_namelen.patch |   32 + 
.../0002-fdt-Add-a-function-to-count-strings.patch |  246 +++ 
...d-a-function-to-get-the-index-of-a-string.patch |  159 ++ 
...004-fdt-Add-functions-to-retrieve-strings.patch |  173 ++

I am not supper happy with the solution of having those DTC patches specifically for the BeagleBone platform. If I understand correctly, those patches are needed to get the DT overlay to work, right ?

We had the same problem for the C.H.I.P platform, so it would also be useful for us to have a overlay-capable DTC. You can see what my colleague Antoine T?nart did:

https://github.com/NextThingCo/CHIP-buildroot/commit/1a73b514d204d0c6e

https://github.com/NextThingCo/CHIP-buildroot/commit/c4457eba3099f5ca5

It is not ideal because it relies on a separate dtc-overlay
package, which packages a different version of dtc, which Antoine has cooked on his own github repository.

We really need to find a solution that is acceptable in the upstream Buildroot, and applies to multiple platforms.

Quoted 3 lines

...cache-flush-management-symbols-when-MULTI.patch | 34 -
.../0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch | 754
++++++++

This huge U-Boot patch is really ugly and mixes lots of stuff. Why do you need it?

configs/beaglebone_defconfig line 27

Quoted 8 lines

-# bootloader BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BOARDNAME="am335x_evm"
BR2_TARGET_UBOOT_CUSTOM_VERSION=y

configs/beaglebone_defconfig +2 -1

-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2013.10" 
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2015.10" 
+BR2_TARGET_UBOOT_NEEDS_DTC=y

So this is going to use the host-dtc package for U-Boot, but isn't the kernel still going to use its internal copy of dtc ? If so, how are your dtc patches useful for the kernel ?

Thanks!

Thomas

Signed-off-by Zoltan Gyarmati <[email protected]>

---

This patch is basically the cleaned-up version of Chris LaRocque's patch from his mail
"[PATCH 1/2] Updated the Beaglebone configuration, 01/03/2016 10:01 PM" and the cleanup followed Arnout's corresponding answers.
Changes to Chris' patches:
* dtc patches fetched from GH and placed in 'board/beaglebone/patches/dtc'
* BR2_GLOBAL_PATCH_DIR set accordingly
* added seperated kernel defconfig instead of patching the upstream defconfig
* cleanups in uEnv.txt
* fix u-boot version to 2015.10

The heavy-lifting was done by Chris here, the rest is mostly cosmetics. If anything els seems to be tweaked, please let us know.

Signed-off-by Zoltan Gyarmati <[email protected]>

---

This patch is basically the cleaned-up version of Chris LaRocque's patch from his mail
"[PATCH 1/2] Updated the Beaglebone configuration, 01/03/2016 10:01 PM" and the cleanup followed Arnout's corresponding answers.
Changes to Chris' patches:
* dtc patches fetched from GH and placed in 'board/beaglebone/patches/dtc'
* BR2_GLOBAL_PATCH_DIR set accordingly
* added seperated kernel defconfig instead of patching the upstream defconfig
* cleanups in uEnv.txt
* fix u-boot version to 2015.10

The heavy-lifting was done by Chris here, the rest is mostly cosmetics. If anything els seems to be tweaked, please let us know.