cedar_ve driver not able to allocate memory

[ajellisuk]

Hello

I have been trying to make use of the h264 encoder by obtaining the source code for the cedar_ve driver from here:

https://github.com/uboborov/sunxi-cedar-mainline

I have successfully built the driver, but when I try and load it the driver fails with the error in the kernel log:

[  110.831285] sunxi-cedar 1c0e000.video-engine: could not assign reserved memory, ret: -22

I have checked the device tree to ensure that it is consistent with the sources in the above git repository.

I'm not sure why the driver is not able to allocate the needed memory. I have tried setting the CMA pool both from the boot parameters by adding:

setenv bootargs "${bootargs} cma=60M"

to boot.cmd and rebuilding before rebooting.


I have also tried adding this to my device tree:

Code:

    reserved-memory {
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;

                /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
                cma_pool: cma@44000000 {
                compatible = "shared-dma-pool";
                size = <0x6000000>;
                alloc-ranges = <0x4a000000 0x6000000>;
                reusable;
                linux,cma-default;
            };
        };

I updated the video engine entry in the deivce tree to that it referenced the cma_pool entry:

Code:

        ve: video-engine@01c0e000 {
                        compatible = "allwinner,sunxi-cedar-ve";
                        reg = <0x01c0e000 0x1000>,
                                <0x01c00000 0x10>,
                                <0x01c20000 0x800>;
                        memory-region = <&cedar_buf>;
                        syscon = <&syscon>;
                        clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
                                <&ccu CLK_DRAM_VE>;
                        clock-names = "ahb", "mod", "ram";
                        resets = <&ccu RST_BUS_VE>;
                        interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
                        allwinner,sram = <&ve_sram 1>;
                };

But I still get the same error.

Has anyone successfully managed to get the cedar_ve driver to work on a pine cube? Is there a set of instructions that someone could point me to that will help me resolce this issue.

Andrew

[cooler]

I've managed to install the driver.
But there are several things to consider and I'm not sure that resolved them correctly.

First, the shared memory pool required by the driver cedar_ve.ko is hardcoded to 80 Megabytes. We cannot spend so much RAM because there is about 128 onboard. So I've decreased hardcoded value to 16M and rebuilt the driver.

Code:

#if !defined(USE_ION)
    cedar_devp->ve_size = 16 * SZ_1M;  // was 80

I've also updated the device tree that way:

Code:

        reserved-memory {
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;

                /* Address must be kept in the lower 256 MiBs of DRAM for VE. */
            cma_pool: linux,cma {
                compatible = "shared-dma-pool";
                size = <0x2000000>;
                alignment = <0x2000>;
                /*alloc-ranges = <0x4a000000 0x6000000>;*/
                reusable;
                linux,cma-default;
            };

        };

...

Code:

syscon: system-control@1c00000 {
            compatible = "allwinner,sun8i-v3s-system-control","allwinner,sun8i-h3-system-control","syscon";
            reg = <0x01c00000 0x1000>;
            #address-cells = <1>;
            #size-cells = <1>;
            ranges;

            sram_c: sram@1d00000 {
                compatible = "mmio-sram";
                reg = <0x01d00000 0x80000>;
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0 0x01d00000 0x80000>;

                ve_sram: sram-section@0 {
                    compatible = "allwinner,sun8i-h3-sram-c1",
                     "allwinner,sun4i-a10-sram-c1";
                    reg = <0x000000 0x80000>;
                };
            };
        };

        ve: video-engine@01c0e000 {
            compatible = "allwinner,sunxi-cedar-ve";
            reg = <0x01c0e000 0x1000>,
                      <0x01c00000 0x10>,
                      <0x01c20000 0x800>;
                        memory-region = <&cma_pool>;
            syscon = <&syscon>;
            clocks = <&ccu CLK_BUS_VE>, <&ccu CLK_VE>,
                     <&ccu CLK_DRAM_VE>;
            clock-names = "ahb", "mod", "ram";
            resets = <&ccu RST_BUS_VE>;
            interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
            allwinner,sram = <&ve_sram 1>;
        };

Don't even ask about why I've done it that way, I know literally nothing about that device trees, I've just compiled several examples from Orange PI giving a heuristics about how little RAM we have 


dmesg output:

Code:

[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Reserved memory: created CMA memory pool at 0x45c00000, size 32 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool

....

Code:

[    8.063755] sunxi cedar version 0.1
[    8.063952] [cedar]: install start!!!
[    8.064021] cedar_ve: cedar-ve the get irq is 30
[    8.064046] sunxi-cedar 1c0e000.video-engine: assigned reserved memory node linux,cma
[    8.064345] [cedar]: Success claim SRAM
[    8.070282] systemd[1]: Finished Load Kernel Module configfs.
[    8.085820] [cedar]: memory allocated at address PA: 45D00000, VA: C5D00000
[    8.085835] [cedar]: install end!!!

and now I have

Code:

root@pinecube:/dev# ls -l
total 0
crw-r--r-- 1 root root     10, 235 Dec 14 08:13 autofs
drwxr-xr-x 2 root root         380 Dec 14 08:13 block
crw-rw---- 1 root disk     10, 234 Dec 14 08:13 btrfs-control
drwxr-xr-x 3 root root          60 Jan  1  1970 bus
crw-rw---- 1 root video   150,   0 Dec 14 08:13 cedar_dev         <----------
drwxr-xr-x 2 root root        2660 Dec 14 08:13 char
crw------- 1 root root      5,   1 Dec 14 08:14 console
crw------- 1 root root     10,  61 Dec 14 08:13 cpu_dma_latency

But... so what, how do we utilize this module to encode camera stream to video files then?

[cooler]

So far I've utilized hardware cedar encoder having ~8fps at 1280x720 and 2-3-4fps at 1920x1080 via gstreamer.
The hardware encoded video looks way better than pixelized software x264enc at recommended minimal settings.
Several system tunung was required including disabling ZRAM completely to reduce CPU consumption, adoption of shared buffer sizes, disabling services to decrease RAM consumption.
At the current setup it consumes <90% CPU with free ~6Mb of RAM while continiously encoding 1920x1080 video.
I am going to try this setup from the scratch on another SD card with clean Armbian installation and if succeded try to describe the main steps involved to run hardware camera video encoding

[tvall]

which kernel are you on? im running the 5.15.4 edge kernel, and when i load the module, all i get is "sunxi cedar version 0.1 " and nothing else from it.

[cooler]

which kernel are you on? im running the 5.15.4 edge kernel, and when i load the module, all i get is "sunxi cedar version 0.1 " and nothing else from it.

Code:

root@pinecube:~# uname -a
Linux pinecube 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l GNU/Linux

This is image fetched from https://redirect.armbian.com/region/AS/p...nt_minimal

I've faced the same problem. There are two main blocking things that disallow cedar module to start.
If it is the only message you see in dmesg, than "sunxi cedar version 0.1 " 

So the driver could not find the device in the device tree description. Refer to my first message in this thread. I can explain how to do this in details later.

When you update the device tree, it then it starts to initialize, but could not fetch as much as 80M of RAM that is probably hardcoded in that version that you are trying to run.

The full initialization at my setup looks like this:

Code:

[    7.986773] sunxi cedar version 0.1
------- this is the only message if tree does not contain "ve" node.
For now NO /dev/cedar_dev will exist.

[    7.986968] [cedar]: install start!!!
[    7.987035] cedar_ve: cedar-ve the get irq is 30
------- these are the only messages if requested RAM block is too large OR cma-pool is not setup
For now /dev/cedar_dev already WILL exist, but in inoperable state, don't try to run encoding.

[    7.987059] sunxi-cedar 1c0e000.video-engine: assigned reserved memory node linux,cma
[    7.987356] [cedar]: Success claim SRAM
[    8.050600] [cedar]: memory allocated at address PA: 45500000, VA: C5500000
[    8.050615] [cedar]: install end!!!
------- the full initialization.
/dev/cedar_dev exist and operable.

I can provide the tree config and modified cedar_ve.ko binary and you can play with it. It is compatible at least with armbian image that a posted above.

But the procedure of compilation took me a lot of time and I could not reproduce it fully.

---

PS. Device tree is the file /boot/dtb/sun8i-s3-pinecube.dtb

[tvall]

im guessing either i messed up the dts somehow, or something changed between 5.10 and 5.15 that requires more work. i just noticed the sram part seems to be failing earlier in boot, and im assuming without that the video engine part isnt being started

Code:

[    1.644739] sunxi-sram 1c00000.system-control: can't request region for resource [mem 0x01c00000-0x01c00fff]
[    1.644773] sunxi-sram: probe of 1c00000.system-control failed with error -16

care to share a diff of your dts changes vs stock? would make it a little easier to make sure i didnt miss something

[cooler]

im guessing either i messed up the dts somehow, or something changed between 5.10 and 5.15 that requires more work. i just noticed the sram part seems to be failing earlier in boot, and im assuming without that the video engine part isnt being started

Code:

[    1.644739] sunxi-sram 1c00000.system-control: can't request region for resource [mem 0x01c00000-0x01c00fff]
[    1.644773] sunxi-sram: probe of 1c00000.system-control failed with error -16

care to share a diff of your dts changes vs stock? would make it a little easier to make sure i didnt miss something

Sure. This is the only file that I modified in dtb sources

---

The size if shared pool is set to
size = <0x2800000> (40M)
I tried different values and ended up with this that makes stable simultaneous camera and encoder initialization.

[tvall]

the only difference i saw other than spacing was the cma pool size, and even making it 40mb instead of 32 didnt change anything, so im going with something related to sram changed between kernel releases.

[cooler]

the only difference i saw other than spacing was the cma pool size, and even making it 40mb instead of 32 didnt change anything, so im going with something related to sram changed between kernel releases.

Maybe you want to recheck how much shared RAM driver tries to allocate.

Code:

cedar_devp->ve_size = ??

I have had 80M hardcoded, but we only allocate 32 to 40M

[tvall]

yeah i had ve_size set to 16mb most tests. but ive tried several values between 12mb and 32mb and they all give the same result.