chucklz

Members
  • Content Count

    8
  • Joined

  • Last visited

1 Follower

About chucklz

  • Rank
    Newbie

Recent Profile Visitors

423 profile views
  1. The code for those is mainlined from kernel 4.17. I suggest you compile a kernel with the i2c, csi interfaces and camera modules enabled using "next" branch of the latest version for your boards and build a distro. You may need to disable the option to auto build modules, in order to access the menus that include these drivers. Then you can modprobe the modules and test if they work with dmesg. You could do it on the board, but it would take longer. armbian-config lets you switch kernels and branches, then you can compile drivers natively. Until the boards have the existing drivers installed, there's not much I can dig around for. If you need a build for a board, and can't do it yourself, let me know which board and I can build a distro on aws ec2 and give you a link to download it.
  2. The current images of Armbian with kernels above 4.17 from this site work fine with a desktop over HDMI. The orangepi site is typically outdated or has bad links to poorly built images. HDMI at 4k is flickery and not useable, but it works well at 1080p.
  3. I have built a 5.60 Armbian with kernel 4.18.8 from source, running on an OPi Zero Plus2 H5. I notice it has v4l2-core built in. The ov56xx drivers seem to be integrated through i2c and i2c/soc, there is also camera driver code in the device-tree bindings. Could someone please explain the difficulty porting the gc2035 camera driver? Do we need VFE submodule at all, or can the gc2035 code use v4l2 calls from core? Or would the driver need complete rewrite using the same model as the ov56xx? I understand the ov5640 is better, but I have gc2035 hardware, time to kill and ARM driver coding experience that I wish to refresh and practise. Will an ov56xx connected through csi currently work out of the box with this kernel?
  4. Igor, Please could you link me to github source/patch/issue for the temporary driver, so I might be able to do some debugging on this. I'm having similar issues on pi zero+2-h5 and previously worked in Cambridge in one of the mali drivers teams, so can probably see whats going on at least and perhaps aim to contribute some driver code.
  5. How can I obtain the kernel sources for a specific image and build the modules the same as those installed? I am running into structure version differences when I build the mainline, then apply to my test system, and I don't want to run the test system on mainline, as I need the stability of the legacy kernel. I know there are certain options to build and ignore structure version differences as long as the structure is similar, but it would seem most pertinent to obtain the correct source for the kernel I am running, copy the .config to the build machine and then build the image. This then allows me to easily switch between different kernel modules that I am developing and testing.
  6. Thanks IgZero. After failing in every other direction I went, I accepted my fate, downgraded and followed your instructions. For the first time, my camera is visible to linux. Now I can finally start playing with the project I bought the damn orange for.. :-)
  7. What is the latest version of Armbian tested and proven working with a gc2035 camera module, please? I tried a few months ago and ran into so many issues, I gave up. Camera works in Android, didn't work in the Armbian I tried, and was eventually advised to try an earlier version that I couldn't easily find. I decided to defer the problem, but it is now more pressing. Thanks in advance for info and advice. Regards, Charlie
  8. I have the same problem, I haven't downgraded yet, as I am needing later kernel. I've looked at the camera/vfe source code and the drivers have constant, hardcoded addresses. I am wondering if anyone knows how the fex system affects these values? I have worked at ARM (symbian driver compatibility) and some issue fixes use post-build injection, but I do not know if that is how fex works? Thanks :-)