going

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?

@KlGrom This patch is for a different architecture. Maybe you want to tell me more details? HardWare Specification of Banana pi BPI-M2 Berry SocAllwinner A40i/R40/V40 ? What are you connecting to SPI. Master\Slave ? How was the verification carried out?

Please publish the output to a file under the spoiler: grep -n DMA /boot/conf*6.2.12-sunxi >> DEBUG-CONF.txt grep -n SPI /boot/conf*6.2.12-sunxi >> DEBUG-CONF.txt

Try using an external toolchain by setting variables as described in the documentation. https://docs.armbian.com/Developer-Guide_Build-Options/#hidden-options-for-advanced-users-default-values-are-marked-bold

Just tell the user how to properly install headers from this particular kernel. There is one core for the entire sunxi (arm) family. That's all he needs.

Is there a CPU H3 or H2 on your device? @Anthony Walter If I understand correctly, do you need a kernel with support for the Lima driver and headers for this kernel?

And what is the reason for this?

@Artem Shakirov Please publish the output of the command on your device: grep -n POWER_RESET_GPIO /boot/conf* I have a suspicion that the kernel is built without this gpio-poweroff module and you will see: config:3457:# CONFIG_POWER_RESET_GPIO is not set

The buttons on the device are designed for the system's response to external influences. The button was pressed and the system did something. This also applies to the power off button. The driver reads the pin status and, when it changes, sends a signal to the system to shut down. It is assumed that the pin should be configured as an input and a button connection scheme and a device that responds to pressing the button with a delay should be implemented in order to physically turn off the supply voltage. If the button is not pressed, but there will be a signal to the system to turn off the power (sudo poweroff), then the driver emulates pressing the button. I.e., it will switch the pin as an output on its own and change the state three times. To start debugging, check whether the driver has been loaded: lsmod | grep power dmesg | grep power dmesg | grep -i warn This functionality assumes the system's response to its internal state. The device is working the LED is on. You did everything right. This is not a workaround, but the right solution. In my opinion. I'll try to check on the weekend what I wrote here for you.

Good health! I think I may misunderstand because of the translation. Please state the problem in simpler phrases and only text, and give the overlay code that does not work for you in its entirety. That's before compilation. P.S. @Artem Shakirov Artem, The problem may be inversion. It is necessary to look at how the power button should be connected on the device.

@GoGerriko To get started, check out this patch: patch/kernel/archive/rockchip64-5.15/drv-spi-spidev-remove-warnings.patch And then do it by analogy with sunxi64