Why rtems arm bsp do not set xn flag when config mmu device region?
Hi: Why rtems arm bsp do not set xn flag when config mmu device region?#define AARCH64_MMU_FLAGS_BASE \ ( MMU_DESC_VALID | MMU_DESC_SH_INNER | MMU_DESC_AF )#define AARCH64_MMU_DATA_RO_CACHED \ ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 3 ) | MMU_DESC_WRITE_DISABLE )#define AARCH64_MMU_CODE_CACHED AARCH64_MMU_DATA_RO_CACHED#define AARCH64_MMU_CODE_RW_CACHED AARCH64_MMU_DATA_RW_CACHED#define AARCH64_MMU_DATA_RO \ ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 1 ) | MMU_DESC_WRITE_DISABLE )#define AARCH64_MMU_CODE AARCH64_MMU_DATA_RO#define AARCH64_MMU_CODE_RW AARCH64_MMU_DATA_RW/* RW implied by not ORing in RO */#define AARCH64_MMU_DATA_RW_CACHED \ ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 3 ) )#define AARCH64_MMU_DATA_RW \ ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 1 ) )#define AARCH64_MMU_DEVICE ( AARCH64_MMU_FLAGS_BASE | MMU_DESC_MAIR_ATTR( 0 ) )ARM datasheet(ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition):Any region of memory that is read-sensitive must be marked as Execute Never, to avoid the possibility of a speculative prefetch accessing the memory region. For example, any memory region that corresponds to a read-sensitive peripheral must be marked as Execute Never.and linux mmu config: #define PROT_DEVICE_nGnRnE (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_DEVICE_nGnRnE)) #define PROT_DEVICE_nGnRE (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_DEVICE_nGnRE)) #define PROT_NORMAL_NC (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_NC)) #define PROT_NORMAL_WT (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_WT)) #define PROT_NORMAL (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL)) #define PROT_SECT_DEVICE_nGnRE (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE)) #define PROT_SECT_NORMAL (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL)) #define PROT_SECT_NORMAL_EXEC (PROT_SECT_DEFAULT | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL)) #define _PAGE_DEFAULT (_PROT_DEFAULT | PTE_ATTRINDX(MT_NORMAL)) #define _HYP_PAGE_DEFAULT _PAGE_DEFAULT #define PAGE_KERNEL __pgprot(PROT_NORMAL) #define PAGE_KERNEL_RO __pgprot((PROT_NORMAL & ~PTE_WRITE) | PTE_RDONLY) #define PAGE_KERNEL_ROX __pgprot((PROT_NORMAL & ~(PTE_WRITE | PTE_PXN)) | PTE_RDONLY) #define PAGE_KERNEL_EXEC __pgprot(PROT_NORMAL & ~PTE_PXN) #define PAGE_KERNEL_EXEC_CONT __pgprot((PROT_NORMAL & ~PTE_PXN) | PTE_CONT) Thanks! ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Question on rtems printf problem
It's just a random string testcase for printf.I know it's not a correct parameter for printf, but this lead to uart print space(ascii:0x20)0 forever.Maybe it's a newlib bug.So, I was wonder who encountered this proble, and how to solve this problem.-gro...@chichak.ca ׫д:-ÊÕ¼þÈË: tia...@sugon.com, "RTEMS List" ·¢¼þÈË: gro...@chichak.caÈÕÆÚ: 2022/12/20 ÏÂÎç01:49Ö÷Ìâ: Re: Question on rtems printf problemOn 2022-December-19, at 19:59, tia...@sugon.com wrote:Hi: I have a testcode, it will lead to uart print space forever.Demo code like this: Init() { create a task; start this task; printf("%*\n");while(1) { sleep() } }What are you expecting get? The * tells printf that there will be a parameter following that will give you the length of the subsequent parameter. Usually of the format %*s, length, string.I¡¯m pretty sure that you don¡¯t have a proper format string, it¡¯s missing the item that you should be specifying the length for and then you neither have the length nor the item to be printed.What are you trying to do?A
-Andrei Chichak
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Question on rtems printf problem
Hi: I have a testcode, it will lead to uart print space forever.Demo code like this: Init() { create a task; start this task; printf("%*\n");while(1) { sleep() } }This code lead to uart print space forever('SPACE' ascii is 0x20): 'SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE''SPACE'..zynq qemu backtrace:(gdb) bt#0 zynq_uart_write_polled (base=0x9000a8 , c=32 ' ') at ../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/shared/serial/zynq-uart-polled.c:197#1 0x008438b8 in zynq_debug_console_out (c=32 ' ') at ../../../../../../../../kernel/c/src/lib/libbsp/arm/xilinx-zynq/../../../../../../bsps/arm/xilinx-zynq/console/debug-console.c:41#2 0x0080af54 in rtems_putc (c=32 ' ') at ../../../../../kernel/c/src/../../cpukit/libcsupport/src/rtems_putc.c:34#3 0x00808a08 in _Console_simple_Write (iop=0x903dc0 , buffer=0x90ea30, count=1024) at ../../../../../kernel/c/src/../../cpukit/libcsupport/src/consolesimple.c:52#4 0x00845190 in write (fd=1, buffer=0x90ea30, count=1024) at ../../../../../kernel/c/src/../../cpukit/libcsupport/src/write.c:47#5 0x00844b00 in _write_r (ptr=0x902790 <_RTEMS_tasks_Objects+704>, fd=1, buf=0x90ea30, nbytes=1024) at ../../../../../kernel/c/src/../../cpukit/libcsupport/src/write_r.c:42#6 0x0083c2bc in __swrite (ptr=ptr@entry=0x902790 <_RTEMS_tasks_Objects+704>, cookie=0x904608 <__sf+128>, buf=buf@entry=0x90ea30 ' ' ..., n=n@entry=1024) at ../../../../../gcc-7.5.0/newlib/libc/stdio/stdio.c:94#7 0x00840da4 in __sflush_r (ptr=ptr@entry=0x902790 <_RTEMS_tasks_Objects+704>, fp=fp@entry=0x904608 <__sf+128>) at ../../../../../gcc-7.5.0/newlib/libc/stdio/fflush.c:224#8 0x00840eb8 in _fflush_r (ptr=ptr@entry=0x902790 <_RTEMS_tasks_Objects+704>, fp=fp@entry=0x904608 <__sf+128>) at ../../../../../gcc-7.5.0/newlib/libc/stdio/fflush.c:278#9 0x00842490 in __sfvwrite_r (ptr=0x902790 <_RTEMS_tasks_Objects+704>, fp=0x904608 <__sf+128>, uio=0x907610) at ../../../../../gcc-7.5.0/newlib/libc/stdio/fvwrite.c:232#10 0x00841e78 in __sprint_r (ptr=ptr@entry=0x902790 <_RTEMS_tasks_Objects+704>, fp=fp@entry=0x904608 <__sf+128>, uio=0x907610, uio@entry=0x907608) at ../../../../../gcc-7.5.0/newlib/libc/stdio/vfprintf.c:429--Type for more, q to quit, c to continue without paging--#11 0x00841e88 in __sprint_r (ptr=ptr@entry=0x902790 <_RTEMS_tasks_Objects+704>, fp=fp@entry=0x904608 <__sf+128>, uio=uio@entry=0x907608) at ../../../../../gcc-7.5.0/newlib/libc/stdio/vfprintf.c:405#12 0x0083cce4 in _vfprintf_r (data="" out>, fp=, fmt0=fmt0@entry=0x0, ap=..., ap@entry=...) at ../../../../../gcc-7.5.0/newlib/libc/stdio/vfprintf.c:1681#13 0x0083c110 in printf (fmt=0x8459e8 "k%*\n") at ../../../../../gcc-7.5.0/newlib/libc/stdio/printf.c:56#14 0x00805834 in Init (argument=) at ../../testsuites/memoryareatest/init.c:66#15 0x00822bdc in _Thread_Entry_adaptor_numeric (executing=0x9024d0 <_RTEMS_tasks_Objects>) at ../../../../../kernel/c/src/../../cpukit/score/src/threadentryadaptornumeric.c:25#16 0x0081eec0 in _Thread_Handler () at ../../../../../kernel/c/src/../../cpukit/score/src/threadhandler.c:139#17 0x00838368 in _Thread_Start_multitasking () at ../../../../../kernel/c/src/../../cpukit/score/src/threadstartmultitasking.c:64
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
[rtems priority problem]
Hi, I have some questions about rtems priority inherit policy. Question 1: Assuming that:task1(priority 7)、task2(priority 4)、mutex1（rtems mutex use inherit）.task1 and task2 using mutex1 for resources mutex. After get mutex1, task1 will temp change it's priority to 3 do something, and recover it's priority after things done. step1:task1 get mutex1 successfully; step2:task2 running attemp to get mutex1, it will promote task1's priority to 4 because of priority inherit policy; step3:task1 continue running with priority 4; step4:task1 call rtems_task_get_priority to get current priority, it will return 4, save as old priority; step5:task1 temp change(rtems_task_set_priority) self priority to 3; step6:task1 resume step4's priority(rtems_task_set_priority), it will set 4 to task1, rather than priority 7. So, i want to provide a intf function to get rtems task Real priority rather than current priority to solve this problem. Question 2: Assuming that:task1(priority 7)、task2(priority 4)、mutex1（rtems mutex use inherit）、semaphore1(use priority ceiling and it's priority is 6).task1 and task2 using mutex1 for resources mutex. After get mutex1, task1 will continue get semaphore1, however task2 will never attempt to get semaphore1. step1:task1 get mutex1 successfully; step2:task2 running and attemp to get mutex1, it will promote task1's priority to 4 because of priority inherit policy; step3:task1 continue running and attempt to get semaphore1(ceiling priority is 6), rtems_semaphore_obtain will return failed because of task1 priority is greater than semaphore1. So, occasionally task1 get semaphore1 failed.regards---Tianye Ye ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
【About rtems condition variable signal intf】
Hello rtems_condition_variable_broadcast call _Condition_Broadcast, like this: but in score level, there is a _Condition_Signal func, like this: Is it a bug? thanks! ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
