search

balena-os / balena-beaglebone

Balena support for Beaglebone boards
https://www.balena.io/os/
Apache License 2.0
20 stars 18 forks source link

Adding beagleplay support #659

Closed delhiryder closed 5 months ago

delhiryder commented 6 months ago

Rolled up PR, with representative checkins showing which logical components were changed. Built and tested locally. Ready to be added to the test automation.

resin-jenkins commented 6 months ago

Can one of the admins verify this patch?

floion commented 6 months ago

@resin-jenkins ok to test

floion commented 6 months ago

@delhiryder please redo the git commit logs. <component> is just a placeholder which should be replaced with the actual component name that the commit modifies. Have a look at examples of commit logs in this repository or any other balena boards repositories. There are plenty to take inspiration from. As a quick example https://github.com/balena-os/balena-beaglebone/pull/544/commits

floion commented 6 months ago

@delhiryder balena-yocto-scripts, contracts, meta-balena submodules do not need to be updated manually because they get automatically updated. Please remove them from this PR

delhiryder commented 6 months ago

@delhiryder balena-yocto-scripts, contracts, meta-balena submodules do not need to be updated manually because they get automatically updated. Please remove them from this PR

Understood. What about the meta-ti, meta-arm and meta-openembedded submodules ? These still need to be updated to the versions in the master branch, right ?

delhiryder commented 6 months ago

@delhiryder balena-yocto-scripts, contracts, meta-balena submodules do not need to be updated manually because they get automatically updated. Please remove them from this PR

Understood. What about the meta-ti, meta-arm and meta-openembedded submodules ? These still need to be updated to the versions in the master branch, right ?

Also, the poky submodule was also updated between my feature branch creation last year and the latest PR date. So these should be part of the PR, right ?

delhiryder commented 6 months ago

@delhiryder balena-yocto-scripts, contracts, meta-balena submodules do not need to be updated manually because they get automatically updated. Please remove them from this PR

Understood. What about the meta-ti, meta-arm and meta-openembedded submodules ? These still need to be updated to the versions in the master branch, right ?

Also, the poky submodule was also updated between my feature branch creation last year and the latest PR date. So these should be part of the PR, right ?

Also, the commit hash that my branch's meta-balena submodule used to point to appears to have been removed (or at least is no longer available) - see the section of the failure logs in the the Flowzone/Versioned source test below:

 Error: fatal: remote error: upload-pack: not our ref ba96a9ea69aa82f84eb792a503c66ec16cf6f142
  Error: fatal: Fetched in submodule path 'layers/meta-balena', but it did not contain ba96a9ea69aa82f84eb792a503c66ec16cf6f142. Direct fetching of that commit failed.
  Error: The process '/usr/bin/git' failed with exit code 128
floion commented 6 months ago

@delhiryder balena-yocto-scripts, contracts, meta-balena submodules do not need to be updated manually because they get automatically updated. Please remove them from this PR

Understood. What about the meta-ti, meta-arm and meta-openembedded submodules ? These still need to be updated to the versions in the master branch, right ?

Also, the poky submodule was also updated between my feature branch creation last year and the latest PR date. So these should be part of the PR, right ?

Unless you need a poky update, let's not update it. The poky submodule also get automatic updates

floion commented 6 months ago

@delhiryder balena-yocto-scripts, contracts, meta-balena submodules do not need to be updated manually because they get automatically updated. Please remove them from this PR

Understood. What about the meta-ti, meta-arm and meta-openembedded submodules ? These still need to be updated to the versions in the master branch, right ?

The meta-openembedded also gets automatic updates. Do you need to have the BSP (meta-ti and meta-arm) updated for this board?

delhiryder commented 6 months ago

Also, the commit hash that my branch's meta-balena submodule used to point to appears to have been removed (or at least is no longer available) - see the section of the failure logs in the the Flowzone/Versioned source test below:

 Error: fatal: remote error: upload-pack: not our ref ba96a9ea69aa82f84eb792a503c66ec16cf6f142
  Error: fatal: Fetched in submodule path 'layers/meta-balena', but it did not contain ba96a9ea69aa82f84eb792a503c66ec16cf6f142. Direct fetching of that commit failed.
  Error: The process '/usr/bin/git' failed with exit code 128

@floion, I have reverted my local feature branch's submodules to the ones from the time I checked out my branch (July 2023). However, I am unable to update my layers/meta-balena to the exact commit hash ba96a9ea69aa82f84eb792a503c66ec16cf6f142 because it appears to have been removed from the meta-balena repository.

missing-meta-balena-releases

Here is what my local command prompt prints out:

ubuntu@ip-172-31-16-228:~/git-debugging/balena-beaglebone$ git submodule update --init --recursive -- layers/meta-balena
fatal: remote error: upload-pack: not our ref ba96a9ea69aa82f84eb792a503c66ec16cf6f142
fatal: Fetched in submodule path 'layers/meta-balena', but it did not contain ba96a9ea69aa82f84eb792a503c66ec16cf6f142. Direct fetching of that commit failed.
fatal:

My submodules are otherwise correctly pinned to the versions they had last July (see below):

ubuntu@ip-172-31-16-228:~/git-debugging/balena-beaglebone$ git submodule
 0008306e565a95aa51d04a8a0fcc318df3df59a2 balena-yocto-scripts (v1.19.41)
 8dfe06b57576e15e8579d4083bb316c9c7671488 contracts (v2.0.91)
 c39bb4ce3b60b73d35c5fb06af012432e70d6b38 layers/meta-arm (4.0.2-1-gc39bb4ce)
+069243961adb123830eb4073a6245b2fa1e6f8b3 layers/meta-balena (v5.1.49)
 4da92ed9be41734f6ced46b981958e2e868cbff2 layers/meta-openembedded (4da92ed9b)
 1ccba22923b1c0ce3558075f3de3846ba983155c layers/meta-ti (09.00.00.008)
 471318ae2f6b3c142822001f4a18e2fed8c78f1a layers/poky (yocto-4.0.11-65-g471318ae2f)

Should use the next latest release tag (from my branch point in July, 2023) this would appear to be v4.1.6 or something else entirely ?

Let me know.

Thanks,

Sidd

delhiryder commented 6 months ago

@floion - I found and used the following meta-balena submodule commit 3df341 (v 3.1.3). It is from August 2023. All other submodule updates commits have been removed.

delhiryder commented 5 months ago

Reproducing some questions from the zulip chat here:

@Sidd Gupta (guest) what need is for the second machine, the beaglebone-play-k3-r5? what is the difference to beaglebone-play?

@floion - This was the only way for me to get the so called Multiconfiguration (MC) build to succeed. My understanding is that think the beaglebone-play has two MCUs on it, and both targets need to be build simultaneously.

second question, why do we declare the machine conf files here? https://github.com/balena-os/balena-beaglebone/pull/659/commits/3786a3ec932083f21f535e5516d015220e27c456

@floion - I chose at the time to create a beaglebone-play machine type, to be consistent with the rest of the naming conventions (e.g. beaglebone-black etc). This required setting up the beaglebone-play machine type(s) as an alias for beagleplay, which is indeed set up in the meta-ti layer.

delhiryder commented 5 months ago

@floion - I have changed the MACHINE type from beaglebone-play to beagleplay. Please take a look.

delhiryder commented 5 months ago

Closing this pull request, in favor of the much newer and shinier https://github.com/balena-os/balena-beaglebone/pull/666.