CAmkES 3.7.0 bug?
Hi, I am porting an old application from CAmkES 2.x to CAmkES 3.7.0. But I am having an issue with a very large dataport. The data structure mapped between components needs to be about 25 MiB. I have defined the size of the connection to be 64 MiB. But compilation fails. Looking at the generated code for the shared data I see this struct { char content[ROUND_UP_UNSAFE(sizeof(ui_config_t), PAGE_SIZE_4K)]; } to_0_ui_configbuf_data ALIGN(16777216) SECTION("align_24bit") USED; extern typeof(to_0_ui_configbuf_data) to_0_ui_configbuf_data ALIGN(67108864) VISIBLE; static_assert(sizeof(to_0_ui_configbuf_data) <= 67108864, "typeof(to_0_ui_configbuf_data) size greater than dataport size."); static_assert(sizeof(to_0_ui_configbuf_data) % 16777216 == 0, "to_0_ui_configbuf_data not page-sized. Template bug in its declaration? Suggested formulation: `char to_0_ui_configbuf_data[ROUND_UP_UNSAFE(sizeof(...), PAGE_SIZE_4K)];`"); But compilation fails with projects/musllibc/build-temp/stage/include/assert.h:12:23: error: static assertion failed: "to_0_ui_configbuf_data not page-sized. Template bug in its declaration? Suggested formulation: `char to_0_ui_configbuf_data[ROUND_UP_UNSAFE(sizeof(...), PAGE_SIZE_4K)];`" The assert is looking for the buffer to be a multiple of 16MiB but the ROUND_UP_UNSAFE is only doing working to a multiple of 4KiB. PAGE_SIZE_4K is hard coded in the template but the alignment has changed from 12bit to 24bit so CAmkES is aware of the large data structure. I guess I could pad and align my data structure to a multiple of 16MiB. Also, having hard coded numbers in my top level CAmkES configuration for the dataport size is a bit of a maintenance nightmare. Being able to use a #define from the code base would be ideal but this doesn't work. It does work for paddr and irq_number specifications! Cheers, Zippy
Hi Zippy,
The assert is looking for the buffer to be a multiple of 16MiB but the ROUND_UP_UNSAFE is only doing working to a multiple of 4KiB. PAGE_SIZE_4K is hard coded in the template but the alignment has changed from 12bit to 24bit so CAmkES is aware of the large data structure.
I guess I could pad and align my data structure to a multiple of 16MiB.
Yes, you are right that CAmkES is aware of the large data structure but the generated C code is only working on a granularity of 4K pages. Hence the assertion failure occurs because the rounding causes the 'content' char array to be a multiple of 4K instead of 16MiB. So a solution would be to pad and align the data structure to be a multiple of 16MiB or you could declare the backing dataport to be a 64MiB sized buffer and then cast it to be whatever you want in the C source code. E.g. component Foo { dataport Buf(67108864) bar; }
Also, having hard coded numbers in my top level CAmkES configuration for the dataport size is a bit of a maintenance nightmare. Being able to use a #define from the code base would be ideal but this doesn't work. It does work for paddr and irq_number specifications!
You could include a C header file with a number of #defines and let the
C preprocessor process the CAmkES configuration file. To turn this
feature on, set the CMake option 'CAmkESCPP' to be 'ON' in the
component's 'CMakeList.txt' file, e.g.
set(CAmkESCPP ON CACHE BOOL "" FORCE)
and then in the CAmkES configuration file:
#include
I am porting an old application from CAmkES 2.x to CAmkES 3.7.0.
Just to let you know, we are working on a release of a newer version of CAmkES pretty soon so you may want to wait a bit. Hope this answers your questions. Sincerely, Damon
So a solution would be to pad and align the data structure to be a multiple of 16MiB or you could declare the backing dataport to be a 64MiB sized buffer and then cast it to be whatever you want in the C source code. E.g.
component Foo { dataport Buf(67108864) bar; }
We're going to be putting out a patch to be fixing this issue instead. The patch will change it so that instead of rounding up to a multiple of 4K all the time, it will be rounded up to a larger page size if the buffer's size is a multiple of that larger page size. Sincerely, Damon
participants (2)
-
Lee, Damon (Data61, Kensington NSW) -
Zippy Maniac