Docker Image Builder (Ubuntu/Debian/Custom Busybox, ARM,RISC-V)

I have created a new Docker builder. It pulls the latest duo-sdk, and makes modifications, based on provided templates.

image

You can create your own distros, and apply them to the latest duo sdk. It’s all menu driven.

Distro RISC-V ARM
Busybox :white_check_mark: :white_check_mark:
Ubuntu :white_check_mark: :x: (compile error)
Debian :white_check_mark: :x: (compile error)

Docker Image builder & SD/EMMC tools
GitHub - CrocNet/duo-docker-builder: Build Milk-V Duo Ubuntu images ARM64 & RISC-V

Optional Debian & Ubuntu Distro builder
GitHub - CrocNet/CrocNetDistro: Linux Distro builder

Image Console - chroot into .img file
GitHub - CrocNet/imgConsole

WiringXSharp - .NET library
GitHub - CrocNet/WiringXSharp: DotNet C# wiringX Wrapper DLL.

DUO Tools - .NET implementation of PinMux
GitHub - CrocNet/DuoTools: Milk-V Tools & Library

4 Likes

Amazing work! Thanks for making it available.

2 Likes

Wow this is amazing! Nice work!

2 Likes

What about arm version mate, is it build root v2 or v1

V2, ARM and RISC-V. Works week for the Busybox builds. May need some more work on the Ubuntu/Debian builds as I have noticed some possible networking issues.

Hoping to add in Zephyr support when that’s complete.

2 Likes

Great work, much appreciated!

2 Likes

Is it possible to invoke some of the buildroot menus like make menuconfig, make linux-menuconfig and busybox configuration menu. Also is it possible to configure for an overlay directory?
I love what you have done so far.

1 Like

If you add bash to the run command (./run.sh bash ) then before the build executes, you will be dropped into the duo-buildroot-sdk(-v2) directory.

make your changes, then do ./build.sh to continue.

You could do your busybox menuconfig here. Just make sure it’s placed into the correct board config at /duo-buildroot-sdk/buildroot-2024.02/configs

or copy your config, back to my tool duo-docker-builder, and create a new profile. Note that the busybox.conf found here appends, not replaces the original config. So default settings you don’t want need to be explicitly disabled. CONFIG_XXX=n

2 Likes

If you want to use your own forked sdk add the following to .ENV

export GITSDK=https://github.com/CrocNet/duo-buildroot-sdk-v2.git
2 Likes

Thank you for the update. I will try you suggestions.

1 Like

Hi,
I have been playing around with the code and was wondering what the intention of the logic around the rootfs.tar.gz is. Is that intended to be used as an overlay, or as a skeleton, or as a complete rootfs replacement. I am wondering if I can customise the contents of certain directories /etc /mnt for example in the same way one would do using buildroot’s overlay facility.
I was also wondering if there is way of doing an incremental build. .i.e just rebuilding the rootfs without having to rerun the entire build.

1 Like

rootfs.tar.gz is the optional rootfs created by the distro builder GitHub - CrocNet/CrocNetDistro: Linux Distro builder

Dockerfile adds this to the buildroot config.
BR2_ROOTFS_SKELETON_CUSTOM=y
BR2_ROOTFS_SKELETON_CUSTOM_PATH=

These are Debian based distros.

If you wanted to do something custom with Buszybox, take a look at the Busybox_BashSSH/post_build.sh script. This gets executed just prior to the image being built for the sd/emmc.
Create a new directory ../Busybox_Something and the menu system will find it.

2 Likes

Do you know if there is anyway of just rebuilding the rootfs or repackaging. If I change something in the overlay or turn on something in buildroot then I do not want to do an entire rebuild>
I have tried playing around with the build.sh script, but had little success in creating a more limited build that does not clean eveything before building. Many times the fundamental config will not change, Arm64 for SD card, for example, just some updates to packages. Any suggestions?

1 Like

Yeah, the build.sh script is unlikely to help. I went down that rabbit hole too, and you have to get to grips with buildroot. The manual is here The Buildroot user manual

Tip: Google Gemini 2.5 pro is quite knowledgeable on buildroot.

1 Like

I know buildroot very well and have used it for many years, but I am not sure that helps in this case because the milkv DUO use of buildroot is not at all conventional. It is wrapped in other layers that seem to override aspects of buildroots intended purpose. I use buildroot, for example, to build my raspbery PI images and there is no difficulty using skeletons and overlays for cusomization or doing partial builds. That is not possible with the DUO setup without a serious amount of tinkering.

2 Likes