going

It is ok. This entry says that an overlay will be accepted: sun7i-a20-spi-spidev.dtbo /_/-/ Replace the underscore with a dash Let's look at the source file: compatible = "armbian,spi-dev"; - This line will cause the spidev module to load into the kernel. But the /dev/spidev0.X interface will not be present because it is not enabled (status = "disabled"). It is necessary to register more overlays to include the necessary nodes spi0, spi1 or spi2. The source text of the file "sun7i-a20-spi0.dts": To include spi1 and spi2, the lines must be: ... fdtfile=sun7i-a20-bananapi-m1-plus.dtb overlay_prefix=sun7i-a20 overlays=spi-spidev spi1 spi2 ... In this case, three nodes will be added for control via the spidev driver and only two will be enabled. This can be bad if, for example, spi0 is planned to be used in some other way and another driver must be connected. You will have to rewrite the overlay yourself for a specific task and compile it. You can find all the source texts of the overlays in the kernel folder after all the patches have been applied before compiling. build/cache/sources/linux-kernel-worktree/6.1__sunxi__armhf/arch/arm/boot/dts/overlay/*

😢! What is the banana version? bananapim1plus - A20 SOC. The native reassembly of the kernel turns into eternity. Check the configuration: grep -nr CONFIG_SPI_SPIDEV /boot/conf* Maybe some details from you? What is connected via SPI?

Please show the link in the code: drivers/spi/spi-sun6i.c which deadlines do you think are working incorrectly. And please check the dtb on the working board. It may need to be fixed.

Check the git status in this repository if this folder is under git control. Add all the files and commit. Assign a tag to it. Step by step make your changes and commit git for each step. Extract all your commits in one move: mkdir userpatches/patch/kernel/sunxi-6.1/patches.spi KERNEL="cache/sources/linux-kernel-worktree/6.1__sunxi__armhf" ./tools/mk_format_patch $KERNEL Tag..HEAD userpatches/patch/kernel/sunxi-6.1/patches.spi I do not know how patches are applied today in the current version of the build system. But they will be applied every time the build system starts assembling the kernel. The order of assembly is determined by a single file: patch/kernel/archive/sunxi-6.1/series.conf Just add them to this place and write them in this file.

I think I misunderstood the translation of this. Will you be able to portray this as a flowchart?

Please decipher what you want to get in the end? You came up with the idea. And it is not included in my immediate plans. I just added your links to my browser bookmarks for the future. The idea is as follows: Today, in order to test the process of downloading a new image, I have to attach a UART-USB adapter cable to the device and to the desktop computer, run minicom in the terminal and read the running line. It seems to me it will be very convenient if the UART traffic from a specific device is routed to a specific Ethernet port and ends up in a log file.

Thanks for the links. This should be pretty easy to set up.

I understood. We can ask Alistair @ALIGMSTEN. He seems to have this device.

The first thing that came to mind was the DTB for this device. On the u-boot and kernel side.

I just put together an image with this new u-boot: linux-u-boot-bananapim64-edge (2023.07.02) The device is loading. The difference: 1) the build was done in my branch. My branch is in an unbalanced state, but it allows me to build almost any package. The assembly of images is unstable. 2) ATF : ATFBRANCH='commit:0cf5f08a205e4877c9daef5d90e1086643590226' - This v2.9.0 + 440 commits

No. On the contrary, we'll just fix the build process. I have found what needs to be done. @Gunjan Gupta I did not find in the build system the correct export of parameters when building with SCP: export SCP=/src/crust/build/scp/scp.bin and without using it. If SCP is not used, pass the parameter to ignore. export SCP=/dev/null It is necessary to add somewhere in this place or I do not know lib/functions/compilation/uboot.sh#L151

how-to-run-scripts-on-start-up run-script-boot-up-debian

In order for a doctor to make a diagnosis, he needs a patient. Tell us the build parameters. To narrow down the search, you need to know at least the version of the kernel that will be built.

Do you want to make an external power switch in this way? Do you want to send a signal to one of the pins of connector 40? Do you want the device to turn off? But at the same time, will the 5V power supply to the device be sold? There are pitfalls here. Are you interested in knowing them? And how will the external activation of the device be carried out?

I am a bad advisor in this kernel subsystem. But in dts from manufacturers, I have seen lines that reserve a certain amount of memory in a fixed region for a specific purpose. Check the processor's data sheet. Maybe it's a hardware limitation?

Maybe you can keep your blog here and interested people will join. I'm one of them.

What is the kernel version in ?

I didn't see any obvious crime in your changes. The question of why they are not applied is still open. The only assumption is that the dtb is already in the kernel or in initramfs. Show the contents of the file in the extlinux folder.

@Something Name The image you are using is something previously from the author Oleg @balbes150. This is some kind of early work. There is no support for allwinner D1 in the upstream kernel 5.19. Support starts with kernel version 6.3 riscv/boot/dts/allwinner/sun20i-d1-nezha.dts I don't think he will want to go back to the old images and support them. Try to use the last option on the 6.5 kernel: Nezha_D1/ArmbianTV/20230710-edge The author will be available soon. He's on vacation today. He will be able to help faster. By the way, it uses the extlinux mechanism to load the kernel. The /boot folder should have a directory of the same name with a boot configuration file.

Attach the archive of this received file to the message. highlight the changes with comments. I'll just look at it.

Are you trying to enable UART2? This is the source code: uart2: serial@2500800 { compatible = "snps,dw-apb-uart"; reg = <0x2500800 0x400>; reg-io-width = <4>; reg-shift = <2>; interrupts = <SOC_PERIPHERAL_IRQ(4) IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_UART2>; resets = <&ccu RST_BUS_UART2>; dmas = <&dma 16>, <&dma 16>; dma-names = "tx", "rx"; status = "disabled"; }; Somewhere at the bottom of the text of the dts you need to add something like this: &uart2 { pinctrl-0 = <&uart2_pb_pins>; pinctrl-names = "default"; status = "okay"; };

Describe in more detail the sequence of actions. Show what is in the /boot/armbianEnv file. Show under the spoiler the file before the changes, what has changed. And see how the dtb was applied directly on a working device: dtc --sort -I fs -O dts /sys/firmware/devicetree/base > $HOME/device_tree.txt

And please post your working overlay here when you finish successfully checking.

The overlay is not described quite correctly. Make in the image and likeness with this: This should be described in a separate fragment pinctrl-0 = <&spi0_pc_pins>; pinctrl-1 = <&spi0_cs0_pc_pin>;

Good! The driver is loaded. After you try to connect, no error messages appear in dmesg?