Use u boot bb.org

[perezmeyer]

The current default bootloader in meta-ti for the BBAI64 seems to be lagging behind, so try switching to u-boot-bb.org.

[perezmeyer]

@acostach @floion this "seems" the way to go for being able to boot from the eMMC, but I am still finding issues compiling it.

[perezmeyer]

It also has some changes fro u-boot-ti-staging as I first tried upgrading meta-ti, which we need non the less... I do expect that, at some point, meta.ti uses just "the right" bootloader... whichever it is.

[resin-jenkins]

Can one of the admins verify this patch?

[acostach]

@resin-jenkins test this please

[floion]

@acostach @floion this "seems" the way to go for being able to boot from the eMMC, but I am still finding issues compiling it.

How do you know this would be able to boot from eMMC?

[perezmeyer]

@acostach @floion this "seems" the way to go for being able to boot from the eMMC, but I am still finding issues compiling it.

How do you know this would be able to boot from eMMC?

Richard C Nelson himself maintains it and makes it work on the Debian based OS. More info on Zulip.

[perezmeyer]

@floion also I have discussed this with Robert himself on Discord. Seems there was an issue on some embedded memory that was used to properly detect the board, and that ought to be solved in u-boot proper, which is what BeagleBone's u-boot provides. Sadly something is getting in the middle with the TI-provided configurations on meta-ti, so... not there yet.

[floion]

When you say ought to be solved in u-boot proper you mean it's been already fixed in upstream u-boot or you mean they need to be fixed in upstream u-boot?

[perezmeyer]

When you say ought to be solved in u-boot proper you mean it's been already fixed in upstream u-boot or you mean they need to be fixed in upstream u-boot?

[acostach]

@resin-jenkins retest this please

[floion]

It now fails to build:

ERROR: linux-bb.org-6.1.69+gitAUTOINC+bc76b5d278-r0 do_patch: Applying patch '0001-Enable-CRYPTO_DM-by-default.patch' on target directory '/work/build/tmp/work/beaglebone_ai64-poky-linux/linux-bb.org/6.1.69+gitAUTOINC+bc76b5d278-r0/git'
CmdError('quilt --quiltrc /work/build/tmp/work/beaglebone_ai64-poky-linux/linux-bb.org/6.1.69+gitAUTOINC+bc76b5d278-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch 0001-Enable-CRYPTO_DM-by-default.patch
patching file arch/arm64/configs/bb.org_defconfig
Hunk #1 succeeded at 763 (offset -11 lines).
Hunk #2 succeeded at 2879 with fuzz 2 (offset 134 lines).
Hunk #3 FAILED at 2840.
Hunk #4 FAILED at 2852.
2 out of 4 hunks FAILED -- rejects in file arch/arm64/configs/bb.org_defconfig
Patch 0001-Enable-CRYPTO_DM-by-default.patch does not apply (enforce with -f)

stderr: ')
ERROR: Logfile of failure stored in: /work/build/tmp/work/beaglebone_ai64-poky-linux/linux-bb.org/6.1.69+gitAUTOINC+bc76b5d278-r0/temp/log.do_patch.123677
NOTE: recipe linux-bb.org-6.1.69+gitAUTOINC+bc76b5d278-r0: task do_patch: Failed
ERROR: Task (/work/build/../layers/meta-ti/meta-ti-bsp/recipes-kernel/linux/linux-bb.org_git.bb:do_patch) failed with exit code '1'

Can you remind me why that patch was added in the first place? I can't find any info in the git log as to why it was needed

[perezmeyer]

It now fails to build:

ERROR: linux-bb.org-6.1.69+gitAUTOINC+bc76b5d278-r0 do_patch: Applying patch '0001-Enable-CRYPTO_DM-by-default.patch' on target directory '/work/build/tmp/work/beaglebone_ai64-poky-linux/linux-bb.org/6.1.69+gitAUTOINC+bc76b5d278-r0/git'

Right, patch required an update or removal... and in this case a removal is enough.

Can you remind me why that patch was added in the first place? I can't find any info in the git log as to why it was needed

Yes: back at the time when we started doing this work I had a WARNING message about CONFIG_DM_CRYPT missing. If I remember correctly (that was more than 6 months ago...) the warning was produces with something like do_kernel_resin_checkconfig so my guess at that time was that I needed to include it. Now if the patch is not applied things seems to work.

I am doing a build right now.

[floion]

Some typos in the git log. Should be something like:

beaglebone-ai64: Switch to u-boot-bb.org to enable booting from eMMC

The current u-boot-ti-staging does not allow booting from eMMC so
we switch provider to an u-boot-bb.org release which can boot from eMMC.

This also requires adding two new recipes coming from poky which are not
yet on kirkstone.

Clear TI_TMPDIR_APPEND so that the files for both archs are in the same
path and we can install them.

Change the path to where the device trees are, there is no ti
subdirectory in u-boot-bb.org.

This required a meta-ti update, so updating patches too. Interestingly
enough CONFIG_DM_CRYPT is not a warning anymore if
0001-Enable-CRYPTO_DM-by-default.patch is not used, so removing this patch.

Changelog-Entry: beaglebone-ai64: Switch to u-boot-bb.org to enable booting from eMMC
Signed-off-by: Lisandro Pérez Meyer <lpmeyer@ics.com>

Also make sure you commit changes with a Signed-off-by entry for each of the commits, I only saw a Changed-by in this PR

[perezmeyer]

Some typos in the git log. Should be something like:

beaglebone-ai64: Switch to u-boot-bb.org to enable booting from eMMC

The current u-boot-ti-staging does not allow booting from eMMC so
we switch provider to an u-boot-bb.org release which can boot from eMMC.

This also requires adding two new recipes coming from poky which are not
yet on kirkstone.

Clear TI_TMPDIR_APPEND so that the files for both archs are in the same
path and we can install them.

Change the path to where the device trees are, there is no ti
subdirectory in u-boot-bb.org.

This required a meta-ti update, so updating patches too. Interestingly
enough CONFIG_DM_CRYPT is not a warning anymore if
0001-Enable-CRYPTO_DM-by-default.patch is not used, so removing this patch.

Changelog-Entry: beaglebone-ai64: Switch to u-boot-bb.org to enable booting from eMMC
Signed-off-by: Lisandro Pérez Meyer <lpmeyer@ics.com>

Also make sure you commit changes with a Signed-off-by entry for each of the commits, I only saw a Changed-by in this PR

Fixed

[floion]

@resin-jenkins test this please