
Hi Tom,
On 2025/1/26 23:59, Tom Rini wrote:
On Sun, Jan 26, 2025 at 03:13:46PM +0800, ZHANG Yuntian wrote:
Hi Tom,
On 2025/1/25 02:23, Tom Rini wrote:
On Fri, Jan 24, 2025 at 02:05:28PM +0800, ZHANG Yuntian wrote:
Hi Tom,
On 2024/11/19 01:18, Tom Rini wrote:
On Mon, Nov 18, 2024 at 12:16:18PM -0500, Raymond Mao wrote:
Hi Tom,
On Mon, 18 Nov 2024 at 11:41, Tom Rini trini@konsulko.com wrote:
> On Mon, Nov 18, 2024 at 11:27:06AM -0500, Raymond Mao wrote: >> Hi Tom, >> >> On Mon, 18 Nov 2024 at 10:37, Tom Rini trini@konsulko.com wrote: >> >>> On Mon, Nov 18, 2024 at 10:24:32AM -0500, Raymond Mao wrote: >>>> Hi Tony, >>>> >>>> On Sat, 16 Nov 2024 at 02:39, Tony Dinh mibodhi@gmail.com wrote: >>>> >>>>> Hi Raymond, >>>>> >>>>> On Fri, Nov 15, 2024 at 1:55 PM Raymond Mao < > raymond.mao@linaro.org> >>>>> wrote: >>>>>> >>>>>> Hi Tony and Tom, >>>>>> >>>>>> On Fri, 15 Nov 2024 at 16:35, Tony Dinh mibodhi@gmail.com > wrote: >>>>>>> >>>>>>> Hi Tom, >>>>>>> Hi Raymond, >>>>>>> >>>>>>> On Fri, Nov 15, 2024 at 1:09 PM Raymond Mao < > raymond.mao@linaro.org >>>> >>>>> wrote: >>>>>>>> >>>>>>>> Hi Tony >>>>>>>> >>>>>>>> On Fri, 15 Nov 2024 at 15:32, Tony Dinh mibodhi@gmail.com >>> wrote: >>>>>>>>> >>>>>>>>> Hi Tom, >>>>>>>>> >>>>>>>>> On Fri, Nov 15, 2024 at 11:27 AM Tony Dinh < > mibodhi@gmail.com> >>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Tom, >>>>>>>>>> >>>>>>>>>> On Fri, Nov 15, 2024 at 6:17 AM Tom Rini < > trini@konsulko.com> >>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Thu, Nov 14, 2024 at 08:26:33PM -0800, Tony Dinh > wrote: >>>>>>>>>>>> Hi Tom, >>>>>>>>>>>> >>>>>>>>>>>> I am on 2025.01-rc2, and I am trying to commit some > files. >>> The >>>>> error >>>>>>>>>>>> seems to indicate this framework directory might need > some >>>>>>>>>>>> modification. Did I miss something? >>>>>>>>>>>> >>>>>>>>>>>> error: 'lib/mbedtls/external/mbedtls/framework' does > not >>> have >>>>> a commit >>>>>>>>>>>> checked out >>>>>>>>>>>> fatal: updating files failed >>>>>>>>>>> >>>>>>>>>>> That's odd. You didn't happen to try out some of the > previous >>>>> lwIP >>>>>>>>>>> iterations on that tree did you? >>>>>>>>>> >>>>>>>>>> No, I did not. The tree is clean with "make mrproper" and > on >>> the >>>>>>>>>> master branch. I just did a git pull and worked on it. >>>>>>>>>> >>>>>>>>>> I went and looked at > https://github.com/Mbed-TLS/mbedtls.git. >>> The >>>>>>>>>> framework directory is pointing to a specific commit. >>>>>>>>>> framework @ 3867faa >>>>>>>>>> >>>>>>>>>> I'll stash and repeat it on another clean tree. >>>>>>>>> >>>>>>>>> I have the same commit error on a brand new tree. >>>>>>>>> >>>>>>>> I think you are talking about the test framework of MbedTLS's >>>>> original testsuite, >>>>>>>> am I right? >>>>>>>> MbedTLS was ported into U-Boot as a git subtree and that >>> framework is >>>>> a git >>>>>>>> submodule of original MbedTLS repo which was not included in > the >>>>> porting >>>>>>>> of U-Boot since U-Boot has its own testsuite. >>>>>>> >>>>>>> Here is what I found. >>>>>>> >>>>>>> git clone https://github.com/u-boot/u-boot.git > u-boot-master-test >>>>>>> cd /usr/src/u-boot-master-test/ >>>>>>> patch -p1 < >>> ../builds-u-boot-marvell/sheevaplug/sheevaplug_bootstd.patch >>>>>>> git add . >>>>>>> git commit . -m "arm: kirkwood: Enable bootstd and remove jffs2 > for >>>>>>> Sheevaplug board" -e >>>>>>> >>>>>>> The git commit above gave out this error: >>>>>>> >>>>>>> error: 'lib/mbedtls/external/mbedtls/framework' does not have a >>> commit >>>>>>> checked out >>>>>>> fatal: updating files failed >>>>>>> >>>>>>> So I tried to commit only the specific files, and it works OK. >>>>>>> >>>>>>> git commit configs/sheevaplug_defconfig > include/configs/sheevaplug.h >>>>>>> -m "arm: kirkwood: Enable bootstd and remove jffs2 for > Sheevaplug >>>>>>> board" -e >>>>>>> [master 47de8cff2d] arm: kirkwood: Enable bootstd and remove > jffs2 >>> for >>>>>>> Sheevaplug board >>>>>>> 2 files changed, 17 insertions(+), 19 deletions(-) >>>>>>> >>>>>>> I think it must be what Raymond said above. So perhaps during > Tom's >>> PR >>>>>>> pull, the framework directory was created. But "git commit ." > does >>> not >>>>>>> like the empty lib/mbedtls/external/mbedtls/framework directory. >>>>>>> >>>>>> Under the native MbedTLS git repo, by default it has a > "framework" >>>>> pointing to >>>>>> its git submodule. >>>>>> Maybe we should mark it in the gitignore. >>>>> >>>>> I've tried .gitignore but could not make it work (my Gitfu is > pretty >>>>> lousy). Can you suggest how that should be done? >>>>> >>>>> You can use the command without the '.' : git commit -m > "<commit_msg>", >>>> this >>>> should work. >>>> >>>> @Tom Rini trini@konsulko.com Shall we remove both >>>> "lib/mbedtls/external/mbedtls/.gitmodules" and >>>> "lib/mbedtls/external/mbedtls/framework"? I can submit a patch if you >>> agree. >>> >>> Can we do that and not make a problem for the next resync? >>> >>> Hmmm, no, this cannot be pulled back to the MbedTLS upstream so still a >> problem >> when resync. >> Another option is to include that git submodule into the U-Boot project, >> this needs >> to revert the commit of introducing the library and redo the git subtree >> after the >> submodule is updated, but it does not seem to be a good choice as we > don't >> use >> that test framework in U-Boot at all. >> Right now I don't have a perfect solution, maybe we can accept using git >> commit >> without the '.'? > > Hmm. Maybe we just delete the .gitmodules / directory and it shouldn't > be too hard to deal with on updates. I have to do some small fixups with > the device tree ones anyhow sometimes. > > How about checking and deleting this in the subtree update script? Then we can skip manually doing this each time. I can make a patch for it if you feel fine.
Is it possible for us to reconsider this option? I'm not aware of any obvious reasons for rejection here.
I really want to explore all possible solutions before declare this as won't fix in documents.
Lets worry about that if it's a problem when we resync next.
I'm currently working with Jonas Karlman's Rockchip fork[1] which is based on a416d9e680718de1c76c4196e1db77e3ca07662f. The fork is included as a git submodule so we can provide distro packaging[2] that are unrelated to U-Boot. We build our package with GitHub Action, and this issue currently blocks us from checking out the code at all with the following workflow snippet:
- name: Checkout uses: actions/checkout@v4 with: submodules: recursive
Related error logs are here:
|> Fetching submodules /usr/bin/git submodule sync --recursive /usr/bin/git -c protocol.version=2 submodule update --init --force --recursive Submodule 'src/rkbin' (https://github.com/rockchip-linux/rkbin.git) registered for path 'src/rkbin' Submodule 'src/u-boot' (https://github.com/Kwiboo/u-boot-rockchip.git) registered for path 'src/u-boot' Cloning into '/home/runner/work/u-boot-kwiboo/u-boot-kwiboo/src/rkbin'... Cloning into '/home/runner/work/u-boot-kwiboo/u-boot-kwiboo/src/u-boot'... Submodule path 'src/rkbin': checked out '0f8ac860f0479da56a1decae207ddc99e289f2e2' Submodule path 'src/u-boot': checked out 'f3231571f4f9c3f72dcb6458aaa2de2462c605df' Error: fatal: No url found for submodule path 'src/u-boot/lib/mbedtls/external/mbedtls/framework' in .gitmodules Error: fatal: Failed to recurse into submodule path 'src/u-boot' Error: The process '/usr/bin/git' failed with exit code 128
This issue potentially breaks all projects who include the recent U-Boot as a git submodule in their GitHub Workflow.
1: https://github.com/Kwiboo/u-boot-rockchip/tree/rk3528-2025.04-wip 2: https://github.com/radxa-pkg/u-boot-kwiboo/actions
What if instead of "submodules: recursive" you use a run statement? https://github.com/marketplace/actions/checkout-submodules
We can certainly work around it in many different ways. But the point is that U-Boot is currently a broken repository in regard to git submodule operations, and require special treatments to integrate with existing pipelines. This was not the case before.
Unfortunately if I recall things correctly there's not a good way for us to solve the problem in our tree since bringing in the problematic submodule via subtree just grows our codebase with things we don't use.
Perhaps you could provide a patch to doc/build/source.rst with an example of how you're working around the problem so that it's easier for others when they run in to this problem? Thanks!