Dietpi Kernelconfig file

So this might seem like both a strange and a noob question, but bear with me please.

Is there a kernel config file in a running Dietpi installation, the kind usually created using make menuconfig when putting together your own (minimal) linux kernel? I need to include it in a report and while i could explain that it doesn’t exist, and include other files like /boot/config.txt, /boot/dietpi.txt and /boot/cmdline.txt, I would like to know that it doesn’t exist, so I don’t end up with egg on my face. Alternatively, if it exists, where is it?

Thanks in advance.

We do not add or remove kernel config files. They are based on hardware and pre-image we apply DietPi on.

On RPi it’s: /DietPi/config.txt (RAMdisk) or /boot/config.txt
On Odroids its /boot/boot.ini
On Sparky: /boot/uEnv.txt (or .ini)
On x86_64: /etc/defaults/grub respectively the based on this auto created grub.cfg in /boot/grub/ or something like this.

help out here…I put some links on where I have dug thru

Best place I have seen is GitHub - orangepi-xunlong/OrangePi_Build: The official build system for Orange Pi, support A64, RDA, RK3399

There is alot…but gotta get the u-boot stuff running…
Once I get that…I think I will be able to build stock “debian” installs that the will work on

repositories are here

Dig thru down to the kernel you want for what board…in the /kernel directory there is a config.c…that should have it for you I think

Debian on it’s network boot stuff has tons of .dtb files in the install\device-tree that cover a BUNCH of boards…but you have to take the stock

7.5 Device Tree Blob (Flat Device Tree)

One of the more challenging aspects of porting Linux (and U-Boot) to your new board is the recent requirement for a device tree blob (DTB). It is also referred to as a flat device tree, device tree binary, or simply device tree. Throughout this discussion, these terms are used interchangeably. The DTB is a database that represents the hardware components on a given board. It is derived from the IBM OpenFirmware specifications and has been chosen as the default mechanism to pass low-level hardware information from the bootloader to the kernel.

Prior to the requirement for a DTB, U-Boot would pass a board information structure to the kernel, which was derived from a header file in U-Boot that had to exactly match the contents of a similar header file in the kernel. It was very difficult to keep them in sync, and it didn’t scale well. This was, in part, the motivation for incorporating the flat device tree as a method to communicate low-level hardware details from the bootloader to the kernel.

Similar to U-Boot or other low-level firmware, mastering the DTB requires complete knowledge of the underlying hardware. You can do an Internet search to find some introductory documents that describe the device tree. A great starting point is the Denx Software Engineering wiki page. References are provided at the end of this chapter.

To begin, let’s see how the DTB is used during a typical boot sequence. Listing 7-13 shows a boot sequence on a Power Architecture target using U-Boot. The Freescale MPC8548CDS system was used for this example.