Jump to content

How to increase CMA max value in kernel configuration for H3?

RagnerBG

By RagnerBG
in Armbian build framework

 Share

Recommended Posts

RagnerBG

RagnerBG

Posted
Posted

Is there a way to increase/change CMA (contiguous memory alocator) reserved memory in kernel configuration for H3 devices? The value stays at default of 16Mb, but after kernel/image creation magically increase to some higher value like 160Mb for OpiOne (512Mb RAM), or 256Mb for OpiPC (1Gb RAM). Even if i try to change the value in kernel configuration, like i used to in A20, with:

KERNEL_CONFIGURE="yes"
FORCE_CHECKOUT="no"

in compile.sh , this have no effect for H3 and the above values of 160Mb/256Mb stays the same. So i guess it's defined somewhere else, patch maybe? Is there a way to change this?

I want to see if increasing the CMA value will help to get rid of "out of memory" messages for high resolution (4k) and bitrate videos and make it playable.

<
jernej

jernej

Posted
Posted

You should take a look at this kernel config:

CONFIG_ION_SUNXI_RESERVE_LIST="160M@0,256M@0,130M@1,200M@1"

 

CMA values are ignored.

 

BTW, depending what you want to do, values bigger than 256M may not work.

1
RagnerBG

RagnerBG

Posted
  • Author
Posted

Thank's a lot :).

Actually i want to increase CMA in OpiOne to 192 or 256Mb. Because some 4k files are playing fine in OpiPC, but failed with "out of memory" error, or something similar, in OpiONE. Of course most of 4k contents are unplayable and i don't know why (10bit x265, unsupported encoding options i guess), but there are some few working and i am curious.

jernej

jernej

Posted
Posted

Of course most of 4k contents are unplayable and i don't know why (10bit x265, unsupported encoding options i guess), but there are some few working and i am curious.

 

You are right 10 bit streams are not supported in HW (includes h264) on H3. Maybe there is some hope that H5 will support 10 bit streams.

zador.blood.stained

zador.blood.stained

Posted
Posted

@jernej

While we are on topic, do you know if ION is used by Mali or UMP?

 

We are still facing an issue with Mali on boards with 2GB RAM (https://github.com/ssvb/lima-memtester/issues/2), and now this code (ion_mem.start calculation specifically) looks strange to me: 

	if((IS_ENABLED(CONFIG_CMA) && is_cma) || ((!IS_ENABLED(CONFIG_CMA) || force) && !is_cma))
	{
		select = ion_reserve_select();
		i = (mem_size<=SZ_512M)?0:1;
		if(ion_reserve[select][i])
		{
			ion_mem.size = ion_reserve[select][i];
			ion_mem.start = (mem_size==SZ_1G)?(mem_start + SZ_512M - ion_mem.size):(mem_start + mem_size - ion_mem.size);
		}
		early_printk("%s: ion reserve: [0x%x, 0x%x]!\n", __func__, (int)ion_mem.start, (int)(ion_mem.start + ion_mem.size));
	}
jernej

jernej

Posted
Posted

OpenELEC also crashed on OPi Plus 2E board at first. I tried many things to no avail. I also thought that it was a Mali issue (r4p0 Mali driver). However, the issue is now gone and I'm not sure what caused it and what fixed it. This is the commit which supposedly fixed everything, which doesn't really make sense.

 

BTW: ION is used only for acquiring continous memory region from userspace. CMA, or better said, coherent DMA would be used in drivers.

1
zador.blood.stained

zador.blood.stained

Posted
Posted

OpenELEC also crashed on OPi Plus 2E board at first. I tried many things to no avail. I also thought that it was a Mali issue (r4p0 Mali driver). However, the issue is now gone and I'm not sure what caused it and what fixed it. This is the commit which supposedly fixed everything, which doesn't really make sense.

To me this looks like either a kernel issue (in parts modified by Allwinner) or Mali/UMP driver issue since limiting memory size "fixes" the issue on OPi+2E and boards with lower memory size are not affected at all on same OS image. So something somewhere allocates memory wrong (owerflow? some kind of boundary? HighMem?) and mali hardware fails to use it.

 

What kernel do you use now so I can look through the patches (or maybe you did switch kernel source repository)?

jernej

jernej

Posted
Posted

To me this looks like either a kernel issue (in parts modified by Allwinner) or Mali/UMP driver issue since limiting memory size "fixes" the issue on OPi+2E and boards with lower memory size are not affected at all on same OS image. So something somewhere allocates memory wrong (owerflow? some kind of boundary? HighMem?) and mali hardware fails to use it.

 

I went through CMA allocation memory reservation for CMA code and I couldn't find any issue, which, of course, doesn't mean that it is ok.

 

 

What kernel do you use now so I can look through the patches (or maybe you did switch kernel source repository)?

 

This source: https://github.com/jernejsk/linux

Those patches: https://github.com/jernejsk/OpenELEC-OPi2/tree/openelec-7.0/projects/H3/patches/linux

 

EDIT: Clarification about CMA.

1
zador.blood.stained

zador.blood.stained

Posted
Posted

BTW: ION is used only for acquiring continous memory region from userspace. CMA, or better said, coherent DMA would be used in drivers.

Well, Mali drivers version r3p0 use UMP to transfer data between userspace and kernel, and kernel part of UMP uses dma_alloc_coherent() to allocate memory region(s) for some purposes.

jernej

jernej

Posted
Posted

Well, Mali drivers version r3p0 use UMP to transfer data between userspace and kernel, and kernel part of UMP uses dma_alloc_coherent() to allocate memory region(s) for some purposes.

 

Are you sure that UMP buffers are used in userspace by default? I think usual use case is that driver allocate some memory for GPU and then GPU operates on it. At the end, it is somehow displayed through the framebuffer (didn't yet find out how those buffers are connected exactly. They may be the same).

 

Anyway, you can try with r4p0 to see if there is any difference.

zador.blood.stained

zador.blood.stained

Posted
Posted

Are you sure that UMP buffers are used in userspace by default? I think usual use case is that driver allocate some memory for GPU and then GPU operates on it. At the end, it is somehow displayed through the framebuffer (didn't yet find out how those buffers are connected exactly. They may be the same).

As far as I understand this, Mali binary driver uses UMP library to handle data to the GPU.

I compiled mali driver with debugging enabled, and debug logs show that dma_alloc_coherent is used:

 Mali<3>: Page table virt: 0xf219c000 = dma_alloc_coherent(size:262144, phys:0xee3a9da4, )

then some memory is allocated in chunks like this:

 Mali<7>: Mali<7>: Ioctl received 0xC0048204 0xB5A40DF8
 Ioctl received 0xC0048208 0xBEC9C9D8
 Mali<7>: Ioctl received 0x80048300 0xBEC9CA18
 Mali<4>: MMap() handler: start=0xB5202000, phys=0x40000000, size=0x00040000
 Mali<6>: Partial page table allocation found, using page offset 6
 Mali<4>: Page table allocated for VA=0xF21A2000, MaliPA=0x70D1B000
 Mali<6>: Allocating page array of size 256 bytes
 Mali<7>: Mapping phys 0xFFFFFFFF length 0x00001000 at offset 0x00000000
 Mali<7>: Process map: mapping 0xFFFFFFFF to process address 0xB5202000 length 0x00001000
 Mali<7>: Mapping phys 0x6FD47000 length 0x00001000 at offset 0x00000000 to CPUVA 0xB5202000
...

then UMP memory is mapped in chunks like this:

 Mali<7>: Ioctl received 0x80048402 0xBEC9CA78
 Mali<7>: Ioctl received 0x80048402 0xBEC9CA68
 Mali<7>: Ioctl received 0xC0048308 0xBEC9C914
 Mali<3>: Requested to map ump memory with secure id 3 into virtual memory 0x40100000, size 0x000E1000
 Mali<4>: In ump_memory_commit
 Mali<4>: Have 225 blocks
 Mali<4>: Mapping in 0xafd9d000 size 4096
 Mali<7>: Mapping phys 0x6FD9D000 length 0x00001000 at offset 0x00000000
 Mali<7>: Mapping phys 0x6FD9D000 length 0x00001000 at offset 0x00000000 to CPUVA 0x00000000
 Mali<7>: Mali map: mapping 0x6FD9D000 to Mali address 0x40100000 length 0x00001000
...

then starting "job"

 Mali<3>: Mali GP: Starting job (0xedaf1e40) on core Mali-400 GP with command 0x00000003

immediately results in page fault interrupt (hardware) from Mali in case of 2GB RAM boards

 Mali<2>: Mali MMU: Page fault detected at 0x40006180 from bus id 7 of type read on Mali-400 MMU for GP

Full debug logs are available in the issue I linked previously

 

Anyway, you can try with r4p0 to see if there is any difference.

Are there any platform-specific bits (like clocks setup that r3p0 has) that I should use or does it work out of the box?

 

Edit:

	/* dma_alloc_* uses a limited region of address space. On most arch/marchs
	 * 2 to 14 MiB is available. This should be enough for the page tables, which
	 * currently is the only user of this function. */
	virt = dma_alloc_coherent(NULL, size, phys, GFP_KERNEL | GFP_DMA );

	MALI_DEBUG_PRINT(3, ("Page table virt: 0x%x = dma_alloc_coherent(size:%d, phys:0x%x, )\n", virt, size, phys));

so this memory is used only for page tables, other memory comes from kmalloc() 

jernej

jernej

Posted
Posted

Well, libUMP is not used in userspace by the driver, at least acording to "objdump -p libMali.so". But driver might obtain memory through other means. Anyway, that is not important for this issue.

 

Are there any platform-specific bits (like clocks setup that r3p0 has) that I should use or does it work out of the box?

 

Just copy driver from my kernel tree. Everything is taken care of. Userspace lib can be obtained here.

zador.blood.stained

zador.blood.stained

Posted
Posted

Well, libUMP is not used in userspace by the driver, at least acording to "objdump -p libMali.so". But driver might obtain memory through other means. Anyway, that is not important for this issue.

➜  ~  % strings sunxi-mali/lib/mali/r3p0/armhf/x11/libMali.so | grep '^ump'
ump_switch_hw_usage_secure_id
ump_reference_add
ump_open
ump_mapped_pointer_get
ump_close
ump_handle_create_from_secure_id
ump_mapped_pointer_release
ump_secure_id_get
ump_cache_operations_control
ump_size_get
ump_reference_release
ump_cache_operations_control
ump_switch_hw_usage_secure_id
ump_secure_id_get
ump_handle_create_from_secure_id
ump_reference_release
ump_mapped_pointer_get
ump_open
ump_close
ump_reference_add
ump_mapped_pointer_release
➜  ~  %

➜  ~  % strings sunxi-mali/lib/mali/r3p0/armhf/x11/libMali.so | grep -i 'libUMP'
libUMP.so
libUMP.so.3
libUMP.so.3
➜  ~  %

Just copy driver from my kernel tree. Everything is taken care of. Userspace lib can be obtained here.

OK, thanks, I'll try when I have some free time.

jernej

jernej

Posted
Posted 
➜  ~  % strings sunxi-mali/lib/mali/r3p0/armhf/x11/libMali.so | grep '^ump'
ump_switch_hw_usage_secure_id
ump_reference_add
ump_open
ump_mapped_pointer_get
ump_close
ump_handle_create_from_secure_id
ump_mapped_pointer_release
ump_secure_id_get
ump_cache_operations_control
ump_size_get
ump_reference_release
ump_cache_operations_control
ump_switch_hw_usage_secure_id
ump_secure_id_get
ump_handle_create_from_secure_id
ump_reference_release
ump_mapped_pointer_get
ump_open
ump_close
ump_reference_add
ump_mapped_pointer_release
➜  ~  %

➜  ~  % strings sunxi-mali/lib/mali/r3p0/armhf/x11/libMali.so | grep -i 'libUMP'
libUMP.so
libUMP.so.3
libUMP.so.3
➜  ~  %

 

Ok, I didn't test it on r3p0. It seems that those two versions are pretty different.

zador.blood.stained

zador.blood.stained

Posted
Posted

Just copy driver from my kernel tree. Everything is taken care of. Userspace lib can be obtained here.

I tried to test r4p0:

First, the archive you linked contains fbdev version of r4p0 binary from https://github.com/WhiteWind/sunxi-mali-proprietary, and it won't help us since we are interested in X11 version.

I tried test/test with this version, but all I got was

Mali<2>: Session started
Mali<2>: No handler for ioctl 0xC0048205 0x<random address>
Mili<2>: Session has ended

in dmesg and EGL/GL parameters output by test app (it didn't display anything, just exited right after printing details).

 

I tried to test X11 binaries too, but they require different UMP library version - kernel driver was of version 2 and userspace library was of version 3, if I remember correctly. And objdump says that X11 libMali.so requires libUMP, compared to framebuffer one.

jernej

jernej

Posted
Posted

Sorry, I forgot about X11 binaries. Yes, that explains why would be UMP issues visible on Armbian and not on OpenELEC. I'm out of ideas...

 

Just for clarification, you tried with X11 version?

zador.blood.stained

zador.blood.stained

Posted
Posted

Sorry, I forgot about X11 binaries. Yes, that explains why would be UMP issues visible on Armbian and not on OpenELEC. I'm out of ideas...

 

Just for clarification, you tried with X11 version?

I tried both - X11 one won't load until I find matching libUMP, framebuffer one doesn't work with "test" from sunxi-mali repository, so I'll try to find some lightweight EGL/GLES application that is designed to work in framebuffer mode.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept