I saw that yesterday as well. Pretty exciting!
What are your thoughts on then piping that through the video encoder? Is that a binary blob or does it also need a separate effort by our kernel hacking heros?
Different topic: on the boot device.
We will want a device for storing the OS and our user application, and a separate SD card for storing user data, that can be easily removed.
For the boot device, we could do either SPI flash or a separate internal SD card (on a different SDIO bus) that is not designed to be removed.
SPI flash would be preferable, but I’m concerned about available capacity.
Any recommendations on approach? I have to re-research SPI flash devices - but do you know of the upper limit available and support for this chip?
Thanks. Getting a bit more excited on the prospects of using the V3s for our application
You could use the MX25L12835F which has 128Mb space.
Or the GD5F4GQ4UAYIG.
I found them in the example schematic for a “dashcam” you can find it here.
I’m also working on a new development board for the V3s featuring many interfaces as possible.
Have a look at my github page.
EDIT: Which camera are you planning to use? I think the OV2640 is great. Has 2MP and a parallel output.
I guess the BSP pin doesn’t really exist.
We are working on a SoC module which will be used with some different mainboards in our projects. This module will replace an old, less powerful one we have been using for years.
How are you managing the kernel?
A standard kernel which features support for every interface of the V3s would be very nice.
Could you upload your kernel here to help other people?
Actually, we will be using our own embedded OS because we need to support some application code written for it. (We need to port our OS to V3s, of course…)
Did anyone found the sources for the parallel CSI V3s driver?
It seems they are ready.
They even made it DT compatible. Nice
I can’t find it in the mainline kernel sources and not in the sunxi sources? Or I’m just blind?
EDIT: I found it, it is only a patch which you can apply to the mainline kernel.
It is amazing what you can do with that new feature. You could theoretically hook up a HDMI to RGB converter, like the ADV7611 and you can capture HDMI. Amazing.
I think it would be better to connect P5 CT line also to 3V3 and pull-ups used to be 49R9 1%, instead of 51R.
I have used the schematic of the lichee pi zero dock as reference, since they were no information from Allwinner at all. I used 51R, because my local shop didn’t have the 49R in stock.
The ethernet works fine and I tested the interface with iperf and nearly hit the maximum limit of 100mbits ethernet. Which effects does your suggestion do? Better EMI performance?
It could work with CT at GND, depending of the PHY input circuit, because it is a differential line and, for signals, pull-up or pull-down give the same impedance (the capacitors in power supply are short-circuit for signals).
It is a common practice to use the same voltage to RX and TX signals. It is also common practice that if you have the PHY 3V3 power supply available, use that for CT (with a small ferrite) and if you don’t have it (for example using a module) use a capacitor to GND for both.
You should have in mind that Ethernet cables are specified to also work with long lines (up to 100m).I usually test that running iperf with a long bobin, in new designs. The mismatch in impedance (51R vs 49R9 1%) could limit that.
For Ethernet pcb lines there are also requirements to keep differential lines of the same length, without stubs, and with an impedance of 100ohms differential and 50ohm single. You could calculate it with Saturn PCB Toolkit. See NXP application note AN4215: “i.MX28 Layout and Design Guidelines” for more information.
It is also convenient to add a surge supressor circuit, like SPLV2.8-4 between PHY and transformers, specially in this case that the PHY is integrated in the CPU.
Hope this helps.
@petit_miner - that’s exciting news on the camera driver. Naturally, the next question is - would we have access to the h.264 encoder? That would make the camera actually useful, end-to-end.
I’ll be doing my best to implement our software + system as much as possible on the LicheePi Zero dev board I have now to prove it will work before I design fresh hardware. Normally I’m very bad at this, wanting to jump ahead and design the hardware before proving it will work in software.
Unfortunately there isn’t any hardware support for the Video Engine (VE), yet.
But Allwinner provided software called CedarX.
I ordered the OV7670 and some more connector stuff to test the CSI parallel interface.
The new driver doesn’t support the master clock needed for the camera, so I will have to use an Arduino to output 8Mhz and feed it into the XCLK pin of the OV7670 module. I know it is a poor workaround
XCLK driving (from CPU MCLK) do not depend on CSI , it’s independent and could be defined for camera itself.
MCLK output could be used and it work. There is some “problems” like it don’t work at first video device open, but it work globally.
Ok good to know. Could you please tell me how can I do that?
I’m not an expert in terms of kernel / devicetree.
For your camera Device Tree configuration you could find Documentation in Linux Tree:
in it define clock as:
clocks = <&ccu CLK_CSI1_MCLK>
But before you need to define that pin in pin controller with it function “csi”
This pin also be used in camera DT .
And my advice is to use clock rate for camera : 24000000 as it’s equal to main clock.
Ah, thanks - so it looks like the partially open source CedarX at least can be used for encoding. Will be exciting to see it working with the camera!
I’m having a hard time to get the camera to work.
I’m only getting errors so far:
probe of sunx6i csi failed with error -2
sunxi6 csi failed to init register map
And no /dev/video
Building the camera driver as module and then inserting into the Kernel:
[ 336.598606] sun6i_csi: Unknown symbol vb2_dma_contig_memops (err 0)
[ 336.605189] sun6i_csi: Unknown symbol v4l2_async_notifier_parse_fwnode_endpoints (err 0)
[ 336.614791] sun6i_csi: Unknown symbol vb2_dma_contig_memops (err 0)
[ 336.621227] sun6i_csi: Unknown symbol v4l2_async_notifier_parse_fwnode_endpoints (err 0)
[ 812.788536] sun6i_csi: Unknown symbol vb2_dma_contig_memops (err 0)
[ 812.795121] sun6i_csi: Unknown symbol v4l2_async_notifier_parse_fwnode_endpoints (err 0)
[ 812.804718] sun6i_csi: Unknown symbol vb2_dma_contig_memops (err 0)
[ 812.811156] sun6i_csi: Unknown symbol v4l2_async_notifier_parse_fwnode_endpoints (err 0)
I don’t even know where I can find the newest patch, all information I can find is on these mailing list.
Where can I get Patch v9? It is a bit weird.
For some time, those patches available from :
there is v9 patch too.
Also check that you have updated DeviceTree .
Thanks for the help
The error message doesn’t appear anymore.
Now I have to wait for my ordered camera.
Could you tell me how I can drive the XCLK pin of the camera? I tried your advice, but I don’t get any waveform on that pin. Although the dtc compiles without any issues.