CI Failures due to CH32V307 HAL

[maxgerhardt]

Operating System

Windows 10

Board

Pico

Firmware

None involved

What happened ?

The inclusion of the CH32V307 hal in 949950e has caused a CI failure in Github Actions due to excessively long filenames, see here.

error: unable to create file Application/8_uarts_server/RT-Thread/uart_server_rtt/rt-thread/components/vmm/linux_patch-v3.8/0001-RTT-VMM-implement-dual-system-running-on-realview-pb.patch: Filename too long
error: unable to create file Application/8_uarts_server/RT-Thread/uart_server_rtt/rt-thread/components/vmm/linux_patch-v3.8/0002-arm-gic-correct-the-cpu-map-on-gic_raise_softirq-for.patch: Filename too long
fatal: Unable to checkout '17761f5cf9dbbf2dcf665b7c04934188add20082' in submodule path 'pico-sdk/lib/tinyusb/hw/mcu/wch/ch32v307'

How to reproduce ?

git clone --recursive https://github.com/hathach/tinyusb.git on a Windows system that does not have Win32 Long Paths and/or git long paths activated.

Debug Log as txt file

None needed.

Screenshots

None needed.

I have checked existing issues, dicussion and documentation

• I confirm I have checked existing issues, dicussion and documentation.

[maxgerhardt]

I want to avoid having to do extreme Github Actions hacking by editing the registry, putting the Github Actions Windows machine to sleep, waking it up, and resuming work like in appveyor/ci#3129 (comment). I don't think these folders ("Application") are needed in TinyUSB at all?

My users were also affected by this already per maxgerhardt/platform-raspberrypi#25

Same here at earlephilhower/arduino-pico#1278

[maxgerhardt]

I've managed to get CI running again by actually only needing to activate long paths in git in maxgerhardt/platform-raspberrypi@8e7f3fc.

      - name: Enable Long Paths
        run: |
          if [ "$RUNNER_OS" == "Windows" ]; then
            git config --system core.longpaths true
          fi
        shell: bash

Still, if it can be avoided, I'd love that users need to not do these modifcations.

[hathach]

I don’t see why it is a bug with tinyusb. Since you are working with rp2040, you shouldn’t clone other mcu dirver

[maxgerhardt]

Can you not consider cloning only a subtree of the CH32V307 HAL that excludes the application which is bursting through the max Windows path length? Better to fix it at the source than upstream. TinyUSB shouldn't need these application examples.

[hathach]

I would love to include a minimal mcu driver that is used by others and well maintained if you could suggest one.

[maxgerhardt]

I do host https://github.com/Community-PIO-CH32V/framework-wch-noneos-sdk which I always try to keep up-to-date. It contains the HAL for all CH32VXXX chips. No application code.

[hathach]

Thanks, let me check this out later. Maybe I should just get rid of submodules by implementing #1464

[hathach]

all submodules are removed now and replaced by an python script to manage dependency repos #1947

[hathach]

@maxgerhardt I started to use PIO for some sketch recently, it is indeed a pain to wait for all submodules clone. I am glad we finally remove them in tinyusb project.