RSB error in MSYS2 MinGW
Hi,
I built arm compiler with "../source-builder/sb-set-builder
--dry-run --with-download 6/rtems-arm", and got the errors:
config: tools/rtems-gdb-head.cfg
error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags | awk
'BEGIN{FS=\" \"}/python/{for(i=1;i<>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Are there any operations may influence WFI instruction?
Hi, I run rtems6 on my imx6ull board, just initialize a GPT timer to flash a LED. I load rtems with barebox, after output some initialized messages, system enters shell and stalls, interrupt(GPT timer, arch7 timer for tick) do not happen again. Shell (connect to UART1,interrupt mode) still works, when I type something, the LED flashes. It seems that system only responses to UART1 interrupt, and triggers the other interrupts respones. I remove wfi instruction from idle task, system runs ok. And when I replace barebox with uboot, everything seems OK. I think maybe some initialized differences between barebox and uboot, but I haven't find any clues that may influence WFI. Any suggestion?___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
undefined reference to `z_inflateEnd'
Hi, When I try to call rtems_fdt_add_shell_command() to support device tree, some link errors occurs. I have added -lz in link command line, and I have tried to change the position of "-lz", but link errors still threre. error message: d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld.exe: D:/msys64/opt/rtems/5.1/arm-rtems5/xilinx_zynq_nsaboard/lib\librtemscpu.a(rtems-fdt.o): in function `rtems_fdt_load': D:\msys64\home\ZXJ\rtems-develop\build-rtems\arm-rtems5\c\xilinx_zynq_nsaboard\cpukit/../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:555: undefined reference to `z_inflateInit_' d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld.exe: D:\msys64\home\ZXJ\rtems-develop\build-rtems\arm-rtems5\c\xilinx_zynq_nsaboard\cpukit/../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:561: undefined reference to `z_inflateEnd' d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld.exe: D:\msys64\home\ZXJ\rtems-develop\build-rtems\arm-rtems5\c\xilinx_zynq_nsaboard\cpukit/../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:557: undefined reference to `z_inflateReset2' d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.4.1/../../../../arm-rtems5/bin/ld.exe: D:\msys64\home\ZXJ\rtems-develop\build-rtems\arm-rtems5\c\xilinx_zynq_nsaboard\cpukit/../../../../../rtems/c/src/../../cpukit/libmisc/rtems-fdt/rtems-fdt.c:559: undefined reference to `z_inflate' collect2.exe: error: ld returned 1 exit status make: *** [Makefile:82: rtems-nsa.elf] Error 1___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: undefined reference to `z_inflateEnd'
It works, thanks. -- Original -- From: "Sebastian Huber"http://lists.rtems.org/mailman/listinfo/devel___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re:[PATCH v2] libmisc/top: Fix the idle time and priorities on SMP
Hi, 1. "data->current_idle" and "data->idle" should be initialize (_Timestamp_Set_to_zero), or the " Load Average" will not be right. 2. On z7020 board, SMP mode, the RPRI and CPRI of idle seems not reasonable. ID | NAME | RPRI | CPRI | TIME | TOTAL | CURRENT +-+---+-+-+--^^ 0x09010001 | IDLE | 2147483647 | 2147483647 | 4.372973 | 53.157 | 99.998 0x09010002 | IDLE | 2147483647 | 2147483647 | 3.620072 | 44.005 | 99.862 0x0a010002 | WDOG | 3 | 3 | 0.28 | 0.000 | 0.000 0x0a010003 | QSPI | 100 | 100 | 0.228549 | 2.778 | 0.000 0x0a010004 | TIME | 98 | 98 | 0.002924 | 0.035 | 0.132 -- Original -- From: "Sebastian Huber"http://lists.rtems.org/mailman/listinfo/devel___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] libmisc/top: Fix the idle time and priorities on SMP
Agree. Patch v3 is ok except for IDLE's priority. The maximum_priority is defined by diffrent scheduler, scheduler CBS and EDF define it as INT_MAX, so the priority of IDLE is 2147483647 (0x7FFF). If normalise the priorities in unmap_priority(), we can get the expected results from _RTEMS_Priority_From_core. But the function rtems_scheduler_get_maximum_priority() return maximum_priority directly, contradictions? I also find a POSIX function _POSIX_Priority_Get_maximum() return maximum_priority-1, is it right? -- Original -- From: "Chris Johns"___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Problems about port to allwinner T3
Hi, I am trying to port RTEMS for allwinner T3 Soc(Quad cortex-A7 core)?? I start it from BSP imx. System runs just with one core and without MMU, So I have two problems: 1.when I enable MMU, system halt But uboot run ok with MMU and cache on, even I use the same ttb descriptor as uboot, system still halt at set TTBR0. I have turned off MMU and clean cache before initialized it. 2.When I define processor number to 2, system seems enter a infinite loops at _Per_CPU_Wait_for_job() Is there any notes about how to start 2nd core? I almost know nothing about start 2nd core. Any advices will be appreciated. Thanks!___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB build failed.
Hi, RSB failed when build gdb on MINGW64. error messages: D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ada-tasks.o: in function `memcpy': D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk' D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: arm-tdep.o: in function `memcpy': D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:202: undefined reference to `__memcpy_chk' D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: breakpoint.o: in function `strcpy': D:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:228: undefined reference to `__strcpy_chk' rsb-report-arm-rtems5-gdb-8.3-x86_64-w64-mingw32-1.txt Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Suggestion about libdl's cache size
Hi The caches size(RTEMS_RTL_ELF_SYMBOL_CACHE ...) now are just define in rtl.c. One of our project should increase the cache size, so I have to modify the kernel source file directly. I think if the cache size can be redefined maybe friendly. thanks. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Suggestion about libdl's cache size
-- Original -- From: "Chris Johns"___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB build failed.
Hi Chris Yes??It works??thanks?? iPhone -- Original -- From: Chris Johns https://git.rtems.org/rtems-source-builder/commit/?id=591deae6d7411af04fd31d2a68dee9520b33c657 > > ... however this option does not help. It is not clear to me what is wrong with > the links in the newlib tar file. > > I have raised a ticket to manage the issue ... > > https://devel.rtems.org/ticket/3868 > > > Chris > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Is there a way to modify PHY register in libBSD?
Hi, I used ukphy driver in project, now I want to tune some PHY registers. Is there a way to modify PHY registers like *phy_fixup in Linux? Or other ways? I think that modify the driver source directly is not a good way.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Problem about porting TCP/IP Stack
Hi all, Since rtems-libbsd is too heavy for our project, so I tried to port Lightweight TCP/IP stacks. First I tried lwip, it worked but crashed now and then. The PC pointed at function _Heap_Block_split()??I could not figure it out. So I tried cycloneTCP . It is more simple than lwip. But I encountered the same problem. System still crashed at _Heap_Block_split() sometimes (random), It made me crazy :( I tried on diffrent CPUs (zynq7020, sunxi-t3), the problem was still there. _Heap_Block_split() is a core function, It seems to have nothing to do with the stack. Attachments are error messages and disassembly code. Any advices? Thanks. crash_messages Description: Binary data disassembly_code.txt Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd build error on
HI, I compile the current libbsd (newest github version) use "--buildset=buildset/minimal.ini" , Error occurs on building "testsuit/debugger01". I found that the waf_libbsd.py file lost a link lib file "libdebugger.a". Would someone review and patch it. waf_libbsd.py.patch Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
ftp server upload filer error.
hi, I update libbsd to the github version, and when i upload a file, the upload process failed at the end, and the target shell stuck. I disconnect from the ftp client, shell print the msg debug: _bsd_sonewconn: pcb 0x15df2000: Listen queue overflow: 2 already in queue awaiting acceptance (1 occurrences) The target still respond the ping command.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: ftp server upload filer error.
sorry, this problem is nothing to do with libbsd. The rtems/cpukit/ftpd/ftpd.c
add a new function yield(),
this function makes the problem.
static void
yield(void)
{
/*
* If we build not for the legacy network stack, then we use the libbsd. In
* the libbsd there is no global network stack semaphore which provides round
* robin fairness for threads of equal priority.
*/
#ifndef RTEMS_NETWORKING
yield();
#endif
}
recursive invocation yield() make the function do not return. I use
rtems_task_wake_after(0) replace the yield,
ftp server works correctly.
-- Original --
From: "jameszxj";
Date: Fri, May 4, 2018 12:00 PM
To: "devel";
Subject: ftp server upload filer error.
hi,
I update libbsd to the github version, and when i upload a file, the upload
process failed at the end, and the target shell stuck.
I disconnect from the ftp client, shell print the msg
debug: _bsd_sonewconn: pcb 0x15df2000: Listen queue overflow: 2
already in queue awaiting acceptance (1 occurrences)
The target still respond the ping command.___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
question about rtc command
hi all, rtc command return the current time of day, it seems unreasonable. I think it should return the time of real time clock. Any other reasons to do so?___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Does RTEMS5.1 have a release plan?
Hi all: We use the master rtems5 version in our project, it works fine. In the next few months, we will release a project version, so we want to know if RTEMES5.1 has a release date?___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Link RAP file error on zynq BSP
HI,I run RTEMS on my xilinx z7k board and dynamic load application(RAP
format) from shell.
In recent update, i encount a link error when link the RAP file.
Here is the command and output message:
rtems-ld -n -e PT_Init --base rtems-nsa.elf wsp/build/nssys.elf
-o wsp/build/nssys.out
error: rap::object: Section index '65522' not found:
wsp/build/nssys.elf
At last I found the bsp_spec file has been modified, "*link:%{!qrtems:
%(old_link)} %{qrtems: -dc -dp -N}" was removed
from the bsp_spec file. Add this line to the file, ld is OK.
Why removed these lines?
Does the newest RTEMS support the loading of incrementally linked ELF files?
RAP format runs OK, but the link needs BSP image, this
make BSP's development and APP's development not so independent. a little pity,
:)___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Link RAP file error on zynq BSP
On 12/10/18 10:05 am, Joel Sherrill wrote:
>>
>>
>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj > <mailto:james...@gmail.com>> wrote:
>>
>> HI,
>> I run RTEMS on my xilinx z7k board and dynamic load application(RAP
>> format) from shell.
>> In recent update, i encount a link error when link the RAP file.
>> Here is the command and output message:
>> rtems-ld -n -e PT_Init --base rtems-nsa.elf
>> wsp/build/nssys.elf -o wsp/build/nssys.out
>> error: rap::object: Section index '65522' not found:
>> wsp/build/nssys.elf
>>
>> At last I found the bsp_spec file has been modified,
>> "*link:%{!qrtems:
>> %(old_link)} %{qrtems: -dc -dp -N}" was removed
>> from the bsp_spec file. Add this line to the file, ld is OK.
>>Why removed these lines?
>>
>>
>> The long-term goal is to remove the bsp_specs. I made a sweep making them
>> more
>> consistent and have a set of patches against gcc master which eliminates
>> them on
>> many architectures. Working so the details are implied by GCC.
>>
>> So let's look at the options and see which one has an impact which mattered
>> that
>> I didn't catch. This is the description of these options from ld's man page:
>>
>> -N
>>--omagic
>>Set the text and data sections to be readable and writable. Also,
>>do not page-align the data segment, and disable linking against
>>shared libraries. If the output format supports Unix style magic
>>numbers, mark the output as "OMAGIC". Note: Although a writable
>>text section is allowed for PE-COFF targets, it does not conform
>> to
>>the format specification published by Microsoft.
>>
>> -d
>> -dc
>>-dp These three options are equivalent; multiple forms are supported
>>for compatibility with other linkers. They assign space to common
>>symbols even if a relocatable output file is specified (with -r).
>>The script command "FORCE_COMMON_ALLOCATION" has the same effect.
>>
>> I'm going to guess that it is -dc/-dp but have no idea how this would impact
>> RAP
>> except to confuse the code.
>>
>> Can you try adding adding the options one at a time until you make it work?
>> Then
>> Chris can figure out why it breaks RAP.>
I have tried this,just add -dc/-dp do not make it work.
>I suspect there is a section that is present which is needed that is not being
>handled in the RAP toolkit code. That RAP format merges some sections in
>rtems-ld.>
Probably like this, and I just test it use just one simple source file,
uninitialized variable
cause this error. If I initialize the variable, link is fine.
>James, if you can make a test file that generates the error then create a
>ticket
>and attach the code I can take a look.>
>>
>>Does the newest RTEMS support the loading of incrementally linked ELF
>> files? RAP format runs OK, but the link needs BSP image, this
>> make BSP's development and APP's development not so independent. a little
>> pity, :)
>>
>> This is a Chris question.
>>
>James, if you do not provide a base image, ie no --base option, what happens?>
I am trying to figure out the problem, it maybe has sth. to do with the
--nostdlib option,
I need to do more tests. I shall describe the problem more clear later on.
>Chris___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Does RTEMS5.1 have a release plan?
OK, I know. Thanks for the working . -- Original -- From: "Chris Johns"; Date: Fri, Oct 12, 2018 10:21 PM To: "jameszxj";"devel"; Subject: Re: Does RTEMS5.1 have a release plan? On 11/10/18 9:01 pm, jameszxj wrote: > We use the master rtems5 version in our project, it works fine. In the > next few months, we will release a project version, so we want to know if > RTEMES5.1 has a release date? The RTEMS 5 process is long overdue and I thank you for asking. We all need to again focus on it especially me. The delays are some what technical as well as related to me and personal issues that were out of my control this year. The release work is unfunded and they take time to make, create and verify. You can view the outstanding tickets here: https://devel.rtems.org/milestone/5.1 Any one can help by taking a look at them and asking here or the ticket what you can do. The ticket https://devel.rtems.org/ticket/3537 is new and it is actually pretty critical effecting all releases of RTEMS, 4.10 and 4.11 will not build. I will be making a post about it soon. Chris___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Link RAP file error on zynq BSP
>
>On 12/10/18 10:05 am, Joel Sherrill wrote:
>>>
>>>
>>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj >> <mailto:james...@gmail.com>> wrote:
>>>
>>> HI,
>>> I run RTEMS on my xilinx z7k board and dynamic load application(RAP
>>> format) from shell.
>>> In recent update, i encount a link error when link the RAP file.
>>> Here is the command and output message:
>>> rtems-ld -n -e PT_Init --base rtems-nsa.elf
>>> wsp/build/nssys.elf -o wsp/build/nssys.out
>>> error: rap::object: Section index '65522' not found:
>>> wsp/build/nssys.elf
>>>
>>> At last I found the bsp_spec file has been modified,
>>> "*link:%{!qrtems:
>>> %(old_link)} %{qrtems: -dc -dp -N}" was removed
>>> from the bsp_spec file. Add this line to the file, ld is OK.
>>>Why removed these lines?
>>>
>>>
>>> The long-term goal is to remove the bsp_specs. I made a sweep making them
>>> more
>>> consistent and have a set of patches against gcc master which eliminates
>>> them on
>>> many architectures. Working so the details are implied by GCC.
>>>
>>> So let's look at the options and see which one has an impact which mattered
>>> that
>>> I didn't catch. This is the description of these options from ld's man page:
>>>
>>> -N
>>>--omagic
>>>Set the text and data sections to be readable and writable.
>>> Also,
>>>do not page-align the data segment, and disable linking against
>>>shared libraries. If the output format supports Unix style magic
>>>numbers, mark the output as "OMAGIC". Note: Although a writable
>>>text section is allowed for PE-COFF targets, it does not conform
>>> to
>>>the format specification published by Microsoft.
>>>
>>> -d
>>> -dc
>>>-dp These three options are equivalent; multiple forms are supported
>>>for compatibility with other linkers. They assign space to
>>> common
>>>symbols even if a relocatable output file is specified (with -r).
>>>The script command "FORCE_COMMON_ALLOCATION" has the same effect.
>>>
>>> I'm going to guess that it is -dc/-dp but have no idea how this would
>>> impact RAP
>>> except to confuse the code.
>>>
>>> Can you try adding adding the options one at a time until you make it work?
>>> Then
>>> Chris can figure out why it breaks RAP.>>
>I have tried this,just add -dc/-dp do not make it work.>
>>I suspect there is a section that is present which is needed that is not being
>>handled in the RAP toolkit code. That RAP format merges some sections in
>>rtems-ld.>>
>Probably like this, and I just test it use just one simple source file,
>uninitialized variable
uninitialized global variable
>cause this error. If I initialize the variable, link is fine.>
>
>>James, if you can make a test file that generates the error then create a
>>ticket
>>and attach the code I can take a look.>>
>>>
>>>Does the newest RTEMS support the loading of incrementally linked ELF
>>> files? RAP format runs OK, but the link needs BSP image, this
>>> make BSP's development and APP's development not so independent. a
>>> little
>>> pity, :)
>>>
>>> This is a Chris question.
>>>
>>James, if you do not provide a base image, ie no --base option, what
>>happens?>>
>I am trying to figure out the problem, it maybe has sth. to do with the
>--nostdlib option,
>I need to do more tests. I shall describe the problem more clear later on.>
I compile APP with --nostdlib option, link process need to resolve the symbols
through base iamge, so BSP image is needed.
And if I remove --nostdlib and add -lc -lm ... , I got a error message:
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld.exe:
wsp/build/nssys.elf section `.unexpected_sections' will not fit in region
`UNEXPECTED_SECTIONS'
collect2.exe: error: ld returned 1 exit status
>>Chris___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Link RAP file error on zynq BSP
From: "Sebastian Huber"; Date: Mon, Oct 15, 2018 02:43 PM To: "devel"; Cc: "jameszxj"; Subject: Re: Link RAP file error on zynq BSP On 15/10/2018 08:16, jameszxj wrote: >> d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld.exe: >> >> wsp/build/nssys.elf section `.unexpected_sections' will not fit in >> region `UNEXPECTED_SECTIONS' >> collect2.exe: error: ld returned 1 exit status >Please have a look at the linker map file to figure out what these >sections are. .unexpected_sections 0x00010x0 *(*) .tm_clone_table 0x00010x0 d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtbegin.o .tm_clone_table 0x00010x0 d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtend.o 0x0001__TMC_END__ END GROUP LOAD d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtend.o LOAD d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtn.o OUTPUT(wsp/build/nssys.elf elf32-littlearm) -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Link RAP file error on zynq BSP
>It should be fixed with this commit: > https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1 thanks, compile is ok. but rtems-ld still has a error outputter:application: wsp/build/nssys.out image::close: removing wsp/build/nssys.out error: rap::object: Section index '65522' not found: wsp/build/nssys.elf make: *** [Makefile:103: nssys.elf] Error 10 should rtems-ld be patch too? >-- >Sebastian Huber, embedded brains GmbH >Address : Dornierstr. 4, D-82178 Puchheim, Germany >Phone : +49 89 189 47 41-16 >Fax : +49 89 189 47 41-09 >E-Mail : sebastian.hu...@embedded-brains.de >PGP : Public key available on request. >Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re:GMP error when building aarch64-rtems-gcc on Mingw64
It has been there for a while. It is caused by the gmp configure parameter
(in gcc/makefile.in line 12644 )
I change "--host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}"
to "--host=${host_alias} --target=${host_alias}", the building succeeds.
-- Original --
From:
"Ryan Long"
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
rtems-libbsd link error.
Hello, In file freebsd/sys/kern/kern_intr.c function intr_handler_barrier() is exclude by #ifndef __rtems__ ... #endif But function intr_event_suspend_handler() and intr_event_resume_handler() reference it, this will lead to a link error.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-libbsd link error.
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld.exe: D:/msys64/opt/rtems/5.1/arm-rtems5/xilinx_zynq_nsaboard/lib\libbsd.a(kern_intr.c.16.o): in function `_bsd_intr_event_suspend_handler': D:\msys64\home\ZXJ\rtems-develop\rtems-libbsd\build\arm-rtems5-xilinx_zynq_nsaboard-minimal/../../freebsd/sys/kern/kern_intr.c:918: undefined reference to `intr_handler_barrier' d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.4.0/../../../../arm-rtems5/bin/ld.exe: D:/msys64/opt/rtems/5.1/arm-rtems5/xilinx_zynq_nsaboard/lib\libbsd.a(kern_intr.c.16.o): in function `_bsd_intr_event_resume_handler': D:\msys64\home\ZXJ\rtems-develop\rtems-libbsd\build\arm-rtems5-xilinx_zynq_nsaboard-minimal/../../freebsd/sys/kern/kern_intr.c:942: undefined reference to `intr_handler_barrier' collect2.exe: error: ld returned 1 exit status configuration: [general] name = minimal extends = default.ini [modules] crypto_openssl = off netinet6 = off fdt = off dev_nic_fxp = off dev_nic_re = off dev_nic_smc = off dev_usb = off dev_usb_controller = off dev_usb_controller_bbb = off dev_usb_input = off dev_usb_net = off dev_usb_quirk = off dev_usb_serial = off dev_usb_storage = off tests = off usr_sbin_tcpdump = off I searched the source files, thers is no any reference about intr_event_suspend_handler() and intr_event_resume_handler() So I just move #endif from line:902 to line:946 to avoid these errors. -- Original -- From: "Sebastian Huber"; Date: Tue, May 28, 2019 04:20 PM To: "jameszxj";"devel"; Subject: Re: rtems-libbsd link error. On 28/05/2019 10:14, jameszxj wrote: > Hello, >In file freebsd/sys/kern/kern_intr.c > function intr_handler_barrier() is exclude by > #ifndef __rtems__ > ... > #endif > > But function intr_event_suspend_handler() > and intr_event_resume_handler() reference it, this will lead to a > link error. What is the build log showing the link error? How did you configure libbsd? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RAP File load error
Hi , When I update RTEMS from HEAD:be50969881b97180bf4fc1e2975efd41169e08bb [be50969] to HEAD: b36c52097f52012f9a52dff6fc8393d63805158b [b36c520], the RAP file can not be loaded. dlerror() return nothing.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH]Re:RAP File load error
I found the problem is: rtems_rtl_elf_relocate_rel() change the return value, but rtl-rap.c:412 still check the return value as bool, so the RAP load failed. I make a patch about this. -- Original -- From: "jameszxj"; Date: Tue, Jun 11, 2019 09:18 AM To: "devel"; Subject: RAP File load error Hi , When I update RTEMS from HEAD:be50969881b97180bf4fc1e2975efd41169e08bb [be50969] to HEAD: b36c52097f52012f9a52dff6fc8393d63805158b [b36c520], the RAP file can not be loaded. dlerror() return nothing. rtl-rap.patch Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH]Re:RAP File load error
I commit and create a patch use sourcetree, is this ok? -- Original -- From: "Chris Johns"; Date: Wed, Jun 12, 2019 12:26 PM To: "jameszxj";"devel"; Subject: Re: [PATCH]Re:RAP File load error On 12/6/19 2:15 pm, jameszxj wrote: > I found the problem Awesome. > is: rtems_rtl_elf_relocate_rel() change the return value, > but rtl-rap.c:412 still check the return value as bool, so the RAP load > failed. > > I make a patch about this. The patch look good however I need a patch generated from a commit so I can acknowledge your contribution. Please commit the change and create a patch, the following may help ... https://devel.rtems.org/wiki/Developer/Git/Users#CreatingaPatch Thanks Chris rtl-rap.diff Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB build error (MSYS2)
Hi,
I tried to update the compiler to RSB master, and encountered an error.
command line:
../source-builder/sb-set-builder --dry-run --with-download 5/rtems-arm
error messgae:
config: tools/rtems-gdb-8.2.1-1.cfg
error: shell macro failed: sh -c "/mingw64/bin/python2-config --ldflags | awk
'BEGIN{FS=" "}/python/{for(i=1;i___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Problem about port cycloneTCP
HI, I met a strange problem when I port cycloneTCP on z7000 board. System crashed when a add or delete some codes, even if the codes have nothing to do with cycloneTCP. I trace the PC pointer, But it point to RTEMS core function, I think core function is impossible to have a problem. I guess it is a memory problem, but i have no idea to trace it. libBSD runs OK on this board. some advices? thx.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Run Time linker and relocation of multiple local labels
Hi, About issue #3740, I think maybe I found the cause of loading failed. In file libdl/rtl-elf.c line159-166, it says "STT_NOTYPE the symbol references a global symbol", But from arm-rtems-readelf information, local symbol .LC0 ...is STT_NOTYPE. And the of document IHI0044E_aaelf.pdf 4.5.2 describe So I change STT_NOTYPE to STT_FUNC. It runs OK on my z7000 board, and I try it in my project(origial use RAP foramt), it still work. About why PowerPC works, I analysed the ELF file compile by vxworks(I do not have ppc-rtems compiler on my computer), I found that PPC ELF use RELA to relocated, not REL . But I am not sure if it is the same as powerpc rtems. The patch works on my project, but I think it needs more tests. rtl-elf.diff Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Suggestions about rtems-ld
Hi, 1. option -e (--entry) In most cases, entry point is useless when use dynamic load. Default entry point "rtems" makes user must provid a entry point or provid "rtems" entry point. I think make default entry point to null is better, if user does not assign one. If it is acceptable, I'll submit a patch. 2. unresolved symbols Dynamically loader code should have unresolved symbols most time, but rtems-ld throws an error when encounters a unresolved symbol. Assign baseimage can solve part of the problems. When unresolved symbols scatter at 2 or more files, just one baseimage is not enough. If just print a warning, Maybe hundreds of warnings output, this still bothers the user. GNU ld does not print anything about it. Just print a warning or slient, I could't say which is better.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RSB do not build rtems-tools any more?
HI, I build from rtems-source-builder version(abbcc5d8c6b4de60f83aaece5a9f4feef4c251c9) on MSYS2, command is "../source-builder/sb-set-builder --log=l-arm.txt --prefix=/opt/rtems/5.1 5/rtems-arm" but rtems-tools was not build.___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RSB do not build rtems-tools any more?
I didn't notice any errors in commnad console. But you remind me, I search the log file , and I found the build is successful, maybe the install dir is mistaken.I cut out some related log lines, the whole log is too big. Thanks -- Original -- From: "Chris Johns"; Date: Sun, Sep 29, 2019 12:20 PM To: "jameszxj"; Cc: "devel"; Subject: Re: RSB do not build rtems-tools any more? On 29 Sep 2019, at 12:11 pm, jameszxj wrote: I build from rtems-source-builder version(abbcc5d8c6b4de60f83aaece5a9f4feef4c251c9) on MSYS2, command is "../source-builder/sb-set-builder --log=l-arm.txt --prefix=/opt/rtems/5.1 5/rtems-arm" but rtems-tools was not build. Can you please post an error log? Thanks Chris<> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libBSD and CPU Load display questions in SMP mode
Hi,
ask questions again,(◡‿◡)
Board infomation:
CPU:zynq z7020 RTEMS version: master version
SMP define:
#define CONFIGURE_MAXIMUM_PROCESSORS2
#if 1
#define CONFIGURE_MAXIMUM_PRIORITY 255
#define CONFIGURE_SCHEDULER_PRIORITY_SMP
#include
RTEMS_SCHEDULER_PRIORITY_SMP(a, CONFIGURE_MAXIMUM_PRIORITY + 1);
RTEMS_SCHEDULER_PRIORITY_SMP(b, CONFIGURE_MAXIMUM_PRIORITY + 1);
#define SCHED_A rtems_build_name(' ', ' ', ' ', 'A')
#define SCHED_B rtems_build_name(' ', ' ', ' ', 'B')
#define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
RTEMS_SCHEDULER_TABLE_PRIORITY_SMP(a, SCHED_A), \
RTEMS_SCHEDULER_TABLE_PRIORITY_SMP(b, SCHED_B)
#define CONFIGURE_SCHEDULER_ASSIGNMENTS \
RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \
RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL)
#endif
I am switching from AMP mode to SMP mode, and found 2 problems.
1. top command display message, Load is 100%, and Idle is almost 100% too.
Is it right? In fact,CPU is doing nothing.
Tasks: 25 Load Average: 100.510% Load: 100.966% Idle: 99.033%
Mem: 457M free 50M used 516K stack
ID | NAME| RPRI | CPRI | TIME| TOTAL
| CURRENT
+-+---+-+-+--^^
0x09010002 | IDLE| 510 | 510 | 4m9.328460 |
50.073 | 100.000
0x09010001 | IDLE| 510 | 510 | 4m7.319959 |
49.670 | 99.033
0x0a010002 | WDOG|6 |6 | 0.003674|
0.000 | 0.001
2.when I connect to RTEMS with ftp or telnet, system reset.
If just only define CONFIGURE_MAXIMUM_PROCESSORS，ftp and telnet is ok.
*** FATAL ***
fatal source: 10 (RTEMS_FATAL_SOURCE_SMP)
fatal code: 7 (0x0007)
RTEMS version: 5.0.0
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
d2d46786f113ed39d29deafa3feeb4d42ae94001, Newlib
d13c84eb07e35984bf7a974cd786a6cdac29e6b9)
executing thread ID: 0x08a010006
executing thread name: IRQS___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: libBSD and CPU Load display questions in SMP mode
thanks,
1.I read the c-use doc, but still confused about EDF SCHEDULER.
The doc said "All SMP schedulers included in RTEMS are priority based. "
Is that mean High priority task always piror low priority task just like
Priority SMP Scheduler.
But some doc from internet said EDF scheduler has a dynamic priority.
My system wants High priority task always piror low priority task, low priority
task can be delay or interrupt.
Does it means that we can not use EDF scheduler?
2.I create a patch about top usage to make the display messages look
reasonable, if someone have time to review it?
I notice that the top usage display 2 priority，RPRI and CPRI， they are the same
value , what's the diffrence?
On 16/10/2018 10:28, jameszxj wrote:
> Hi,
>ask questions again,(◡‿◡)
>
> Board infomation:
>
> CPU:zynq z7020 RTEMS version: master version
> SMP define:
> #define CONFIGURE_MAXIMUM_PROCESSORS2
>
> #if 1
> #define CONFIGURE_MAXIMUM_PRIORITY 255
>
> #define CONFIGURE_SCHEDULER_PRIORITY_SMP
The only SMP scheduler supported by libbsd is:
#define CONFIGURE_SCHEDULER_EDF_SMP
>
> #include
> RTEMS_SCHEDULER_PRIORITY_SMP(a, CONFIGURE_MAXIMUM_PRIORITY + 1);
> RTEMS_SCHEDULER_PRIORITY_SMP(b, CONFIGURE_MAXIMUM_PRIORITY + 1);
> #define SCHED_A rtems_build_name(' ', ' ', ' ', 'A')
> #define SCHED_B rtems_build_name(' ', ' ', ' ', 'B')
> #define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
> RTEMS_SCHEDULER_TABLE_PRIORITY_SMP(a, SCHED_A), \
> RTEMS_SCHEDULER_TABLE_PRIORITY_SMP(b, SCHED_B)
>
> #define CONFIGURE_SCHEDULER_ASSIGNMENTS \
> RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \
> RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL)
> #endif
>
>I am switching from AMP mode to SMP mode, and found 2 problems.
> 1. top command display message, Load is 100%, and Idle is almost 100% too.
> Is it right? In fact,CPU is doing nothing.
>
> Tasks: 25 Load Average: 100.510% Load: 100.966% Idle: 99.033%
> Mem: 457M free 50M used 516K stack
>
> ID | NAME| RPRI | CPRI | TIME |
> TOTAL | CURRENT
> +-+---+-+-+--^^
> 0x09010002 | IDLE| 510 | 510 | 4m9.328460
> | 50.073 | 100.000
> 0x09010001 | IDLE| 510 | 510 | 4m7.319959
> | 49.670 | 99.033
> 0x0a010002 | WDOG|6 |6 | 0.003674
> | 0.000 | 0.001
>
> 2.when I connect to RTEMS with ftp or telnet, system reset.
> If just only define CONFIGURE_MAXIMUM_PROCESSORS，ftp and telnet is ok.
>
> *** FATAL ***
> fatal source: 10 (RTEMS_FATAL_SOURCE_SMP)
> fatal code: 7 (0x0007)
This is:
SMP_FATAL_SCHEDULER_PIN_OR_UNPIN_NOT_SUPPORTED
> RTEMS version: 5.0.0
> RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
> d2d46786f113ed39d29deafa3feeb4d42ae94001, Newlib
> d13c84eb07e35984bf7a974cd786a6cdac29e6b9)
> executing thread ID: 0x08a010006
> executing thread name: IRQS
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
cpuusagetop.patch
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Executive vs. Kernel
I just used RTEMS for about 1 year, When I first met the word "executive" in the docs, It confused me. I think "kernel" is easier to understand, although it is not like the linux kernel. From this point of view, I think "kernel" is better. -- Original -- From: "Chris Johns"; Date: Wed, Jan 23, 2019 03:11 PM To: "Sebastian Huber";"joel";"Gedare Bloom"; Cc: "RTEMS"; Subject: Re: RTEMS Executive vs. Kernel On 23/1/19 5:50 pm, Sebastian Huber wrote: > On 22/01/2019 23:42, Chris Johns wrote: >> On 23/1/19 5:34 am, Joel Sherrill wrote: >>> I don't object. >> Is executive the right abstraction? Both terms are an abstraction because we >> have a single address space and literal or formal interpretation breaks >> down. I >> see the physical separation as an implementation detail. > > Real-Time Executive for Multiprocessor Systems or RTEMS already has executive > in > its name. The name has evolved over time. > I don't think that the kernel/user space separation and system calls > are an implementation detail. It is a hardware enforced feature which > characterizes a whole group of operating systems. The name kernel is quite > overloaded. It sure is. > I would like to avoid that someone thinks about RTEMS as a micro > kernel which would be totally wrong. I think there will always be a level of confusion. >> Which term is the better abstraction of what the rtems.git repo is? This is >> the >> critical piece to resolve. > > Ok, this is a different issue. The problem is that in rtems.git is a > collection > of different things. It contains the RTEMS executive (everything which deals > with threads, interrupts, synchronization and inter-thread communication), a > legacy network stack, file systems, device drivers, memory allocators, > compression libraries, hash libraries, shell, etc. I think calling this stuff > "kernel" is imprecise. It is imprecise but what is a precise single word or term to explain this? >> >> I have been using kernel as the reference to the 'rtems.git' repo. Using >> 'rtems' >> as a name to refer to the 'rtems.git' repo is not enough as the term 'rtems' >> has >> a much broader scope these days and it's meaning is ambiguous to new users. >> RTEMS OS is also too board and ambiguous. I selected the term 'kernel' >> because >> it represents a formal set of interfaces that RTEMS provides without being >> specific about a piece of provided functionality. It also follows the RSB >> build >> set name I created years ago. The single term is strategic, it is attempting >> to >> use a language that maps to the steps you need to take and repos you need to >> access. The Executable section of the User Manual outlines the stages: >> >> https://docs.rtems.org/branches/master/user/exe/index.html >> >> A key focus of this section is to show the steps a user needs to take to >> build >> an application. They are building the tools, building the "kernel", >> optionally >> building 3rd party packages and then building an application. I include >> libbsd >> as a 3rd party package to be consistent and to show to users the RTEMS >> operating >> system can also contain 3rd party packages and those packages can serve as >> examples for others. >> >> We sit in a middle state at the moment, we have things in the rtems.git repo >> that could be separate packages, the legacy networking stack, parts of >> libmisc, >> or we have packages like libbsd that could be part of rtems.git. I suspect in >> time removing packages from the rtems.git repo will aid certification because >> there is less code to audit or review and remove. This however means we need >> a >> strong package builder or these packages as well as external 3rd party >> packages. >> Hmm, maybe the term 3rd party packages is wrong and should be changed, but >> that >> is off scope for this thread. >> >> Joel and I have been reviewing the Eco-system and Executable section of the >> user >> manual using both terms and in a few spots "RTEMS operating system" should be >> used instead of 'kernel' so that language could be improved. In the >> Executable >> section the use of 'executive' seems to close to 'executable'. >> >> Note, the "Kernel" layer in the "Vertical Software Stack" figure should be >> expanded to be two layers, "Services" and "Executive". >> >> An important factor is the documentation needs to read well. >> >> For me the executive is the runtime thread management and control, I suppose >> the >> score set of files, and I think it would be awkward to group the shell as >> part >> of the executive. Referring to 'rtems.git' as the 'executive' repo somehow >> does >> not feel right. >> >> I am not sure there is a clear answer that perfectly defines what we have. >> There >> seems to be a lot of work to make this change including the RSB and I am >> wondering if it is worth the churn. > > I think it is worth the churn. If you don't name the important components > consistently
