going

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?

This is an interrupt for SPI But I don't see the mcp251x driver here. This line should cause the driver to load. Check the presence of the module in the kernel: grep -n CONFIG_CAN_MCP251X /boot/conf* Check the correct application of the overlay in the dts: dtc --sort -I fs -O dts /sys/firmware/devicetree/base > $HOME/device_tree.txt

OV5640_datasheet.pdf support for output formats: RAW RGB, RGB565/555/444, CCIR656, YUV422/420, YCbCr422, and compression maximum image transfer rate: QSXGA (2592x1944): 15 fps 1080p: 30 fps 1280x960: 45 fps 720p: 60 fps VGA (640x480): 90 fps QVGA (320x240): 120 fps And if you change the frequency, it is possible to increase the resolution. And how to do it?

Check the kernels available for installation directly on the device sudo apt update apt search linux-image | grep sunxi

Just build EDGE or install the EDGE kernel ready to confirm or refute my assumptions. P.S. BRANCH=edge Today it is the core v6.4.8

@Gunjan Gupta The problem may already be solved on the latest kernels. It may be enough to pull down some patches from megouse. Compare: megous-linux> gitk -100 origin/cam-6.1 megous-linux> gitk -100 origin/cam-6.4 And accept compliments in your address. You work very carefully. I adore.

Thanks, I saw it. 48 fixes or 148 is a small difference. The main thing in switching to the series is the ease of maintenance, there are a large number of small patches (several thousand) of the code. I think people are used to something different. They are used to experiencing the torment of processing several dozen patches, and we say that there will be 1000 patches and it will be easier to maintain, they just don't believe it.

Please describe briefly the problem that you managed to solve in order to make HDMI work P.S. @jock Or just let me take a look at the changes in the git repository.

git checkout -b test c6e450189f140db5ffc0167b035dfbec6304fabb @pierre-pret Will a working image be assembled on this commit?

Allwinner processors in the kernel do not have their own driver, but a common one is used. This driver doesn't exactly match the hardware implementation. Resetting the GPIO level and then returning to the initial state in some situations is a fixed fact. But you write that all GPIOs change the level when the device is rebooted. This should be taken into account when developing your composite device and either include various interconnected devices in a certain sequence. Or provide a communication relay and turn on the connection when all transients on the pins of the device have ended.

See doc: ******************************************************************************** https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt ******************************************************************************** sudo apt install gpiod libgpiod2 See manual: +++++++++++++++++++++++++++++++++++++++++++++ * gpiodetect - list all gpiochips present on the system, their names, labels and number of GPIO lines * gpioinfo - list all lines of specified gpiochips, their names, consumers, direction, active state and additional flags * gpioget - read values of specified GPIO lines * gpioset - set values of specified GPIO lines, potentially keep the lines exported and wait until timeout, user input or signal * gpiofind - find the gpiochip name and line offset given the line name * gpiomon - wait for events on GPIO lines, specify which events to watch, how many events to process before exiting or if the events should be reported to the console

Are these your final changes? I saw them in the pull request. @Gunjan Gupta You have removed the patches for the kernel that were previously. Are they bringing in bad things?

Anyway, thanks for your work.

To be honest, I don't know much about this controller. Then a long time ago I tried to figure out this incorrect behavior and got stuck. There wasn't enough free time. Today, when you implemented this, I assumed that you are a greater specialist and I want to ask you about how you can check the frequency of the controller. Maybe it is possible in the "crust" debugging console?

The built-in ARISK controller can control the power supply and its own frequency independently. If, for the debugging period, you manage to get it to report its status regularly to the UART, for example, this line: AR1000: F=50 Mhz U=0.9 CPU0: F= 0 Mhz U=0 V T0=28 C then I can check the performance on A64 and A83T processors. When the system goes to sleep or shuts down as a result of system services or pressing a button, the built-in controller must lower its own frequency to the minimum and turn off the power to the CPU. When you press the PWR button, it should increase its frequency and supply voltage to the CPU and something else to resume the system. Why do I pay attention to this? A few years ago, a very bad effect was observed. When the "poweroff" command was given, the system turned off, the LED on the board went out, but the processor chip housing began to warm up intensely. The temperature rose from 35 C to 50 C.

I agree with this statement @Gunjan Gupta You should not make changes to these files: config/sources/arm64.conf config/sources/armhf.conf This is only needed by sunxi \ sunxi64.

@royk I already realized that this is not your snapshot of the test. I am reading this post listed in the link. Rod wrote about my repository. This is currently in development and not finished. In the final version, this branch will collect an image with a real-time kernel and linuxcnc + a certain number of libraries and settings necessary for work. All in one build system. When I am ready, I will join your company on the linuxcnc forum. It looks like the truth.

Hi. I'll try to clarify. Did you get this result by applying using remote desktop (VNC)? What will be the result if you connect HDMI and the XFCE desktop is installed?

Most likely, it's not about the direction of the log output. It looks like you've done two things. For example, we updated the kernel and\or u-boot packages and then changed the output for u-boot. This is loading from the memory on the board. Write the image to the SD card and boot from it. Mount the device memory to the /mnt folder and mount the dev, proc, sys folders there leo@bananapim64:~$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 199M 3,3M 196M 2% /run /dev/mmcblk0p1 7,2G 982M 6,2G 14% / tmpfs 994M 0 994M 0% /dev/shm ..... leo@bananapim64:~$ ls /dev/mmc* /dev/mmcblk0 /dev/mmcblk0p1 /dev/mmcblk2 /dev/mmcblk2boot0 /dev/mmcblk2boot1 /dev/mmcblk2p1 leo@bananapim64:~$ sudo mount /dev/mmcblk2p1 /mnt leo@bananapim64:~$ sudo mount --bind /dev /mnt/dev leo@bananapim64:~$ sudo mount --bind /proc /mnt/proc leo@bananapim64:~$ sudo mount --bind /sys /mnt/sys leo@bananapim64:~$ sudo chroot /mnt /bin/bash root@bananapim64:/# Next, make the necessary correction. In this case, reinstall the kernel package. Or to begin with, try to return the original state of the file /boot/armbianEnv.txt I just did this and the download went fine. leo@bananapim64:~$ cat /boot/armbianEnv.txt verbosity=7 bootlogo=false console=serial .......

This is a simple check on the kernel source code. See if the necessary driver is compiled? grep -n 'FB_TFT_SSD1306' /boot/conf* grep -n 'DRM_SSD130X' /boot/conf* If the necessary drivers are present in the kernel, it remains for you to correctly write the overlay for the device tree. You can use the existing code from the search as a basis: > grep -nri SSD1306 arch/arm/boot/dts/* arch/arm/boot/dts/am335x-icev2.dts arch/arm/boot/dts/imx28-cfa10036.dts In order for the driver to be loaded automatically, there must be a line in the described node: compatible = "solomon,ssd1306" When your work is successful and you have a properly working overlay, just post it here and call me @going. I will add this overlay for everyone in the Armbian patches. If you need more help, try looking for it in similar topics on the forum. Well good luck. P.S. Your question is not related to a specific Banana Pi. This is rather a general question of connecting the device via the SPI to the board. Maybe it makes sense to rename the name to attract interested users?