going

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?