Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
It is a good starting place to handle the crash problem. Especially the records could be packed to send to a host computer using TCP/IP. One of the question for us is there is no network interface. But we have a flash disk. So we should modify the send flow using file system instead of network. Moreover, we need expand the recorded data to get more information of the crash. small...@aliyun.com From: Sebastian Huber Date: 2020-09-18 00:00 To: small...@aliyun.com; devel Subject: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors? Hello, On 15/09/2020 12:58, small...@aliyun.com wrote: > I am developing applications in rtems 5.1. As we know, my application > and rtems kernel are both in the same address space. > So if my application access an invalid address or encounter other > fatal errors, I want the kernel not just being hunging, but create a > core dump file. > This file contains the whole contents of memory and I could use a > debuger to analyse the file to handle the bug. > The question arise because I do not want always debug rtems in the bsp. in addition to dumping the current state of the application, you can use the event recording to get a bit of the dynamic behaviour before the crash: https://docs.rtems.org/branches/master/user/tracing/eventrecording.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
Flash disk is used in our normal procedure. We use qspi interface to read and write data from/to a flash disk in order to record our logs. The flash disk is parted to several parts. In such case, a new part could be allocated to save the crash data. small...@aliyun.com From: Sebastian Huber Date: 2020-09-18 12:42 To: small...@aliyun.com; devel Subject: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors? On 18/09/2020 03:24, small...@aliyun.com wrote: > It is a good starting place to handle the crash problem. Especially > the records could be packed to send to a host computer using TCP/IP. > One of the question for us is there is no network interface. But we > have a flash disk. So we should modify the send flow using file system > instead of network. > Moreover, we need expand the recorded data to get more information of > the crash. Saving crash data to a flash disk is normally a bit too complex and involves interrupts and DMA. I would save the crash data to a volatile memory area which survives a soft reset. After the soft reset, check if crash data is available and save it to the disk. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
Hi, all I compile rtems 5.1 with bsp xilinx-zynqmp. The single core mode is ok. But I can not use 2 or 3 or 4 cores of this bsp. After analysing the source code, I found there is no code to address smp condition. Does rtems 5.1 indeed not support smp mode for xilinx-zynqmp bsp? small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
The board is Ultra96 board with JTAG boot. And yes, there is a bspsmp.c in rtems-5.1\bsps\arm\xilinx-zynqmp\start\ small...@aliyun.com From: Gedare Bloom Date: 2020-10-06 00:16 To: small...@aliyun.com CC: devel Subject: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp It should, I believe. The bsp has bspsmp.c file. How did you configure (../rtems/configure)? What board/target do you run it on? On Mon, Oct 5, 2020 at 2:24 AM small...@aliyun.com wrote: > > Hi, all > I compile rtems 5.1 with bsp xilinx-zynqmp. The single core mode is ok. > But I can not use 2 or 3 or 4 cores of this bsp. > After analysing the source code, I found there is no code to address smp > condition. Does rtems 5.1 indeed not support smp mode for xilinx-zynqmp bsp? > > ________ > small...@aliyun.com > ___ > 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
Re: RE: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
I think the key problem is the bsp_start_hook_0 function which will be executed
in all cores.
However, this function does not distinguish each core. It means all four cores
run the same code.
The right procedure is core 0 run the init code while other cores wait for it
to complete.
BSP_START_TEXT_SECTION void bsp_start_hook_0(void)
{
uint32_t sctlr_val;
sctlr_val = arm_cp15_get_control();
sctlr_val |= ARM_CP15_CTRL_CP15BEN;
arm_cp15_set_control( sctlr_val );
/*
* Current U-boot loader seems to start kernel image
* with I and D caches on and MMU enabled.
* If RTEMS application image finds that cache is on
* during startup then disable caches.
*/
if ( sctlr_val & (ARM_CP15_CTRL_I | ARM_CP15_CTRL_C | ARM_CP15_CTRL_M ) ) {
if ( sctlr_val & (ARM_CP15_CTRL_C | ARM_CP15_CTRL_M ) ) {
/*
* If the data cache is on then ensure that it is clean
* before switching off to be extra carefull.
*/
arm_cp15_data_cache_clean_all_levels();
}
arm_cp15_flush_prefetch_buffer();
sctlr_val &= ~ ( ARM_CP15_CTRL_I | ARM_CP15_CTRL_C | ARM_CP15_CTRL_M |
ARM_CP15_CTRL_A );
arm_cp15_set_control( sctlr_val );
}
arm_cp15_instruction_cache_invalidate();
/*
* The care should be taken there that no shared levels
* are invalidated by secondary CPUs in SMP case.
* It is not problem on Zynq because level of coherency
* is L1 only and higher level is not maintained and seen
* by CP15. So no special care to limit levels on the secondary
* are required there.
*/
arm_cp15_data_cache_invalidate_all_levels();
arm_cp15_branch_predictor_invalidate_all();
arm_cp15_tlb_invalidate();
arm_cp15_flush_prefetch_buffer();
}
small...@aliyun.com
From: Kinsey Moore
Date: 2020-10-06 21:56
To: j...@rtems.org; small...@aliyun.com
CC: Gedare Bloom; devel
Subject: RE: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
Is it possible that the application was only started on the first core instead
of all cores? Is it possible to check the execution state of the other cores?
Kinsey
From: Joel Sherrill
Sent: Tuesday, October 6, 2020 08:11
To: small...@aliyun.com
Cc: Gedare Bloom ; devel ; Kinsey Moore
Subject: Re: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
Maybe Kinsey has an idea.
On Tue, Oct 6, 2020 at 1:29 AM small...@aliyun.com wrote:
The board is Ultra96 board with JTAG boot.
And yes, there is a bspsmp.c in rtems-5.1\bsps\arm\xilinx-zynqmp\start\
small...@aliyun.com
From: Gedare Bloom
Date: 2020-10-06 00:16
To: small...@aliyun.com
CC: devel
Subject: Re: I can not run rtems 5.1 smp correctly on bsp xilinx-zynqmp
It should, I believe. The bsp has bspsmp.c file.
How did you configure (../rtems/configure)?
What board/target do you run it on?
On Mon, Oct 5, 2020 at 2:24 AM small...@aliyun.com wrote:
>
> Hi, all
> I compile rtems 5.1 with bsp xilinx-zynqmp. The single core mode is ok.
> But I can not use 2 or 3 or 4 cores of this bsp.
> After analysing the source code, I found there is no code to address smp
> condition. Does rtems 5.1 indeed not support smp mode for xilinx-zynqmp bsp?
>
> ____
> small...@aliyun.com
> ___
> 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
Does anybody have the source code of rtems tools
The main page is this: http://rtemscentre.edisoft.pt/index.php?module=Content&func=display&ceid=13&meid=-1 My main target tool is "Core File Generation Tool" in "RTEMS Other Support Tools". The source code is open source, but it needs register and login to download code. After sending the register email for days, I get nothing reply. So does anybody download the tool previous? Would you like to share a copy with me ? Thank you very much! RTEMS/Support Tools The RTEMS/Support Tools developed in the scope of the RTEMS Centre are: RTEMS Other Support Tools Core File Generation Tool: This tool can generate a core file, from the contents of a raw memory dump, which will then be loaded into GDB and show the user where the application crashed. Remote Debug Monitor Tool: This tool is an intrusive debugger (i.e., interrupts the normal code execution in order to execute debug code) that acts like a server while running on the target board and provides the means for software based debugging over a serial line. PROM Image Builder Tool: This is a tool that encapsulates the user application in an image file that is ready to be burned into a boot PROM of an ERC32 or LEON system. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-5.1 source code test coverage failed
hi, all I want test source code coverage in qemu. There are some questions I met. 1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute. 2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error - File format not ELF or archive. Is there a tutorial introducing how to get rtems-5.1 source code test coverage? Thank you very much! small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: rtems-5.1 source code test coverage failed
Thanks joel. I google the Couverture-Qemu and find many useful document about rtems test coverage. The conventional approach will compile source codes to create *.gcno files. But the Couverture-Qemu method needn't. In the final report, the Couverture-Qemu method will create an annotated.html file in which the instructions are listed as "NOT EXECUTED" or executed. The main different is only assembly language is used, while the conventional approach will list the souce code in C language. small...@aliyun.com From: Joel Sherrill Date: 2020-10-22 23:49 To: small...@aliyun.com CC: devel Subject: Re: rtems-5.1 source code test coverage failed On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com wrote: hi, all I want test source code coverage in qemu. There are some questions I met. 1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute. 2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error - File format not ELF or archive. Is there a tutorial introducing how to get rtems-5.1 source code test coverage? We don't do coverage that way. Some simulators can directly produce gcov data. I think tsim can do that for example. gcov foundationally assumes that it can run, collect data, and write it to a file at program exit. That model doesn't work on embedded targets. There are some write ups on the net of people forcing gcov data to be written sporadically and magic to get it off target. But this isn't how RTEMS has done coverage. We depend on simulators that write trace logs and a utility called covoar which can correlate multiple trace logs with the program executables and product a unified report. Remember that the same function may be in two RTEMS executables but they will not be at the same physical address. The trace/log execution information produced by the simulators will be in terms of which physical addresses are executed. The RTEMS Tester has support for running coverage and hopefully the documentation is good at explaining that. The qemu couverture project (a separate repo from regular qemu), sis, and tsim all produce trace/coverage info for an executable that covoar should be able to process. FWIW there is at least one known issue with covoar right now. Sometimes the reported size of a method differs between two executables. Historically, this has been due to padding after a method so the next adjacent method in memory is cache line aligned. covoar will reject information when a method has different sizes in different executables. But can adjust if it is nop padding to ignore at the end. No one has produced a reproducible test case to investigate for this latest one. Given two executables where function X appears to be different sizes, it is usually easy to see by hand what the program is missing. But you need that test case. --joel Thank you very much! small...@aliyun.com ___ 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
Re: Re: rtems-5.1 source code test coverage failed
Thank you once again. Your reply is very very fast. small...@aliyun.com From: Joel Sherrill Date: 2020-10-23 10:03 To: smallphd CC: devel Subject: Re: Re: rtems-5.1 source code test coverage failed Hit send too soon On Thu, Oct 22, 2020, 8:59 PM Joel Sherrill wrote: On Thu, Oct 22, 2020, 8:53 PM small...@aliyun.com wrote: Thanks joel. I google the Couverture-Qemu and find many useful document about rtems test coverage. The conventional approach will compile source codes to create *.gcno files. But the Couverture-Qemu method needn't. In the final report, the Couverture-Qemu method will create an annotated.html file in which the instructions are listed as "NOT EXECUTED" or executed. The main different is only assembly language is used, while the conventional approach will list the souce code in C language. The reports from covoar include the source code. The reports are from a developer perspective and we haven't had any feedback from iv&v folks. If the reports don't match what you need, there is always the source code . :) This is an area where feedback, contributions, and supporting developers is really appreciated. And there is an RSB recipe for couverture qemu which should make it easier to build. I'd love to see this area of our tooling and ecosystem get love and grow. :) --joel small...@aliyun.com From: Joel Sherrill Date: 2020-10-22 23:49 To: small...@aliyun.com CC: devel Subject: Re: rtems-5.1 source code test coverage failed On Thu, Oct 22, 2020 at 4:02 AM small...@aliyun.com wrote: hi, all I want test source code coverage in qemu. There are some questions I met. 1. If compiling without -ftest-coverage, the test only produce a percent coverage, no *.gcov file which is important to recognize which lines not execute. 2. If compiling with -ftest-coverage, *.gcno are created in the same directory with *.o and these *.gcno file are included in xilinx_zynq_a9_qemu-symbols.ini. However this ini file could only include *.o. So the execution will raise error - File format not ELF or archive. Is there a tutorial introducing how to get rtems-5.1 source code test coverage? We don't do coverage that way. Some simulators can directly produce gcov data. I think tsim can do that for example. gcov foundationally assumes that it can run, collect data, and write it to a file at program exit. That model doesn't work on embedded targets. There are some write ups on the net of people forcing gcov data to be written sporadically and magic to get it off target. But this isn't how RTEMS has done coverage. We depend on simulators that write trace logs and a utility called covoar which can correlate multiple trace logs with the program executables and product a unified report. Remember that the same function may be in two RTEMS executables but they will not be at the same physical address. The trace/log execution information produced by the simulators will be in terms of which physical addresses are executed. The RTEMS Tester has support for running coverage and hopefully the documentation is good at explaining that. The qemu couverture project (a separate repo from regular qemu), sis, and tsim all produce trace/coverage info for an executable that covoar should be able to process. FWIW there is at least one known issue with covoar right now. Sometimes the reported size of a method differs between two executables. Historically, this has been due to padding after a method so the next adjacent method in memory is cache line aligned. covoar will reject information when a method has different sizes in different executables. But can adjust if it is nop padding to ignore at the end. No one has produced a reproducible test case to investigate for this latest one. Given two executables where function X appears to be different sizes, it is usually easy to see by hand what the program is missing. But you need that test case. --joel Thank you very much! small...@aliyun.com ___ 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 test all case in real bsp automatically?
hi, all Recently, I was testing rtems-5.1 in xilinx bsp. There are many test cases which need compile and burn to bsp each time. If I test 100 cases, I need compile and burn 100 times manually. This is boring. Is there a way to test 100 cases in one compilation and burning ? Thanks very much. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Planning for RTEMS 6 Branch
Hi, joel Our team is developing a pcie card running rtems. The stability is very important for us. Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as bug fixes, new features, etc. "aarch64 on real hardware and SMP" is what we really wanted. Does this feature will be supported by rtems 5.x ? small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 03:39 To: rtems-de...@rtems.org; David Edelsohn Subject: Planning for RTEMS 6 Branch Hi It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see any reason getting from 5 to 6 should be such a long period of time. It seems as if we focus on a few major changes and see what happens while those go in. Right now, I'd be prone to say 6 is ready to branch from a feature perspective if we get the following: + Waf switchover complete + NFSv4 + aarch64 on real hardware and SMP I would expect all of this to be available in early 2021. There are already new BSPs (stm, etc), tool updates, etc. that are a normal part of RTEMS moving forward. These don't really play into my thoughts. They show up when they show up and we can delay branching a very short time if something is on the cusp. But they don't drive release planning. In my opinion, the big question is addressing RTEMS for EPICS. Most of the BSPs I know that are used for EPICS are still only supported by the legacy stack. I'm ignoring some known BSP regressions that will get fixed as a normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, that's OK. But I'd like to move the legacy stack to its own repository. Downgrading the legacy stack that way while BSPs used by EPICS users haven't been updated to libbsd is not a good thing. I expect motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near future but that leaves other EPICS BSPs. We need to include EPICS considerations in our roadmap. This means the legacy stack can't be moved out without considering them. And we need to figure out how to bring them up to date. This needs to be part of release planning. The other big work is the qualification effort. It would be nice for it to be complete but I don't see that as a blocker for RTEMS 6. It could be the driving factor for RTEMS 7 if the timeline doesn't work out. Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to address the legacy stack. Each of these still has major user facing considerations. Let's just be quicker. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: Planning for RTEMS 6 Branch
Hi,joel Your reply is helpful and fast as usual. Thanks very much! small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 08:44 To: smallphd CC: devel; David Edelsohn Subject: Re: Planning for RTEMS 6 Branch On Wed, Dec 16, 2020, 6:38 PM small...@aliyun.com wrote: Hi, joel Our team is developing a pcie card running rtems. The stability is very important for us. Currently we are using rtems 5.1. Are there plans for rtems 5.x ? Such as bug fixes, new features, etc. "aarch64 on real hardware and SMP" is what we really wanted. Does this feature will be supported by rtems 5.x ? RTEMS release branches are considered feature complete and the focus is on bug fixes. Currently the master has aarch64 (64 bit ARM) support that is not on the 5 branch and won't be added. The only BSP at this time is for qemu. The libbsd networking support for aarch64 is being tested now. The next step is to verify it on a Xilinx reference board. After that SMP support for that architecture. I hope this helps. Bug fixes in release branches and features added on master working to the next release. small...@aliyun.com From: Joel Sherrill Date: 2020-12-17 03:39 To: rtems-de...@rtems.org; David Edelsohn Subject: Planning for RTEMS 6 Branch Hi It took a long time to get from 4.10 to 4.11 and then on to 5. I don't see any reason getting from 5 to 6 should be such a long period of time. It seems as if we focus on a few major changes and see what happens while those go in. Right now, I'd be prone to say 6 is ready to branch from a feature perspective if we get the following: + Waf switchover complete + NFSv4 + aarch64 on real hardware and SMP I would expect all of this to be available in early 2021. There are already new BSPs (stm, etc), tool updates, etc. that are a normal part of RTEMS moving forward. These don't really play into my thoughts. They show up when they show up and we can delay branching a very short time if something is on the cusp. But they don't drive release planning. In my opinion, the big question is addressing RTEMS for EPICS. Most of the BSPs I know that are used for EPICS are still only supported by the legacy stack. I'm ignoring some known BSP regressions that will get fixed as a normal part of moving forward. If RTEMS 5 + EPICS uses the legacy stack, that's OK. But I'd like to move the legacy stack to its own repository. Downgrading the legacy stack that way while BSPs used by EPICS users haven't been updated to libbsd is not a good thing. I expect motorola_powerpc and beatnik/mvme5500 to be on libbsd sometime in the near future but that leaves other EPICS BSPs. We need to include EPICS considerations in our roadmap. This means the legacy stack can't be moved out without considering them. And we need to figure out how to bring them up to date. This needs to be part of release planning. The other big work is the qualification effort. It would be nice for it to be complete but I don't see that as a blocker for RTEMS 6. It could be the driving factor for RTEMS 7 if the timeline doesn't work out. Basically, I'd like a quicker RTEMS 6 even if 7 comes out quickly to address the legacy stack. Each of these still has major user facing considerations. Let's just be quicker. Thoughts? --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: A question about rtems license
Thanks both of you for these advice. It is very clear for me now. small...@aliyun.com From: Gedare Bloom Date: 2020-07-18 23:49 To: Christian Mauderer CC: small...@aliyun.com; devel Subject: Re: A question about rtems license On Sat, Jul 18, 2020 at 9:20 AM Christian Mauderer wrote: > > Hello, > > note that I'm not a lawyer. I can only provide my personal opinion > regarding that topic. Depending of the legal system of your country a > lawyer might has a different point of view. I'm also only a small part > of the project and can't speak for all persons involved. > Indeed, we have no lawyers here to provide legal advice. > > As far as I understand your situation you basically forked RTEMS. The > fork would consist of "rtems src" and "rtems src2". These parts would be > covered by the RTEMS license. So if you provide a binary to someone, you > would have to make the "rtems src" and "rtems src2" available to this > person too if they ask. > Yes, if you modified "rtems src" and then distribute it, you need to provide the source for those modifications. > But your application is still a separate part and would be covered by > the linking exception. That means: you can keep it private. > Also correct. > > Please note that there is an ongoing effort to change the RTEMS license > to a BSD style license. A lot of sources are already BSD licensed. You > can see that if you have a look at the file headers. > That said, we encourage users to provide us with the changes they made to rtems. There are advantages if your changes are accepted, then you have more confidence about their correctness (additional review) and they may also be maintained by the community as long as they are useful. > As another note: RTEMS is always open to patches. So you might want to > think about polishing the "rtems src2" parts a bit and sending them to > the mailing list for integration into the official sources. > +1 > Best regards > > Christian > > On 18/07/2020 11:45, small...@aliyun.com wrote: > > Hi, > > There is a project using rtems as a real time os in an arm cortex R5 > > bsp. Primary RTEMS License says > > that RTEMS is free software; you can redistribute it and/or modify it under > > terms of the > > GPL. > > As a special exception, including RTEMS header files in a file, > > instantiating RTEMS generics or templates, or linking other files with > > RTEMS objects to produce an executable application, does not by itself > > cause the resulting executable application to be covered by the GPL. > > I draw a picture to describe this special exception: > > There are "rtems src", "rtems header" and our "application". The "rtems > > src" will be compiled to a lib called "rtems lib". If our "application" > > includes "rtems header" and linkes with "rtems lib", then our > > "application" does not follow GPL. > > > > OK, here is my question: we modify some code in "rtems src" and build it > > to "rtems lib2". If our "application" includes "rtems header" and > > linkes with "rtems lib2", whether or not our "application" should follow > > GPL? > > (of course, rtems src2 should follow GPL) > > > > > > small...@aliyun.com > > > > ___ > > 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 rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?
Hello， I have a TI bsp which uses a ARM cortex A72 process. It has 4 cores and MMU enabled. So does rtems support SMP and MMU in such a platform? After searching the mail and source code, I only find a cortex A53 platform. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?
32-bit mode is OK. Does it fully support SMP and MMU in this bsp? small...@aliyun.com From: Joel Sherrill Date: 2020-07-24 00:14 To: Sebastian Huber CC: small...@aliyun.com; devel Subject: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp? On Thu, Jul 23, 2020 at 7:25 AM Sebastian Huber wrote: Hello, On 23/07/2020 07:52, small...@aliyun.com wrote: > Hello， > I have a TI bsp which uses a ARM cortex A72 process. It has 4 cores > and MMU enabled. > So does rtems support SMP and MMU in such a platform? > After searching the mail and source code, I only find a cortex A53 > platform. AArch64 is currently not supported by RTEMS. Getting it to work in 32-bit mode should be feasible using the existing RTEMS support, but there is no out of the box support for it. The xilinx-zynqmp BSP runs on aarch64 but using 32-bit mode. --joel ___ 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
Re: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?
xilinx-zynqmp BSP has a ARM cortex A53 processor. Is it a ARMv8-A architeture? small...@aliyun.com From: Sebastian Huber Date: 2020-07-24 12:49 To: small...@aliyun.com; joel CC: devel Subject: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp? On 24/07/2020 03:09, small...@aliyun.com wrote: > 32-bit mode is OK. > Does it fully support SMP and MMU in this bsp? RTEMS supports SMP on ARMv7-A and in particular the xilinx-zynqmp BSP. The MMU is statically set up. RTEMS doesn't support processes with virtual memory. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
is there a list to diff the rtems 4.x and 5.x
hello, We decide to use rtems in our arm cortex r5 bsp. Considering the high reliability requirement, do we choose current stable 4.11.3 or future 5.1.0 ? And could somebody give me a list to display the difference between 4.11.3 and 5.1.0 ? I just find a little change lists in the document. But after I compare the two edition's source code, I find the difference is much more than the document listed. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Does rtems support pci device in arm architecture?
hi, all QEMU has a feature which lets vm shared memory with host. In such case, the guest can access host memory through a virtual pci device memory space. And I want use rtems in such a guest. I test qemu arm realview-pbx-a9 and xilinx-zynq-a9 bsp, but both of them can not support pci device in qemu. Does anybody try use rtems to access a pci device in arm platform, especially a qemu environment, as I want use the ivshmem function of qemu. Thank you very much! small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: Does rtems support pci device in arm architecture?
Thank you very much! If anything found, please send me a message. small...@aliyun.com From: Sebastian Huber Date: 2020-09-04 16:10 To: small...@aliyun.com; devel Subject: Re: Does rtems support pci device in arm architecture? Hello, there is some support for PCI in libbsd. I would have a look at the FreeBSD code. Maybe there are drivers for these platforms. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
I am developing applications in rtems 5.1. As we know, my application and rtems kernel are both in the same address space. So if my application access an invalid address or encounter other fatal errors, I want the kernel not just being hunging, but create a core dump file. This file contains the whole contents of memory and I could use a debuger to analyse the file to handle the bug. The question arise because I do not want always debug rtems in the bsp. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
You are right. Anything in the target could not been used to generate a core dump. In Linux kernel, there is a mini kernel outside the running kernel. When the running kernel crash, it will trigger the mini kernel to run. The mini kernel will analyse the memory of the crashed kernel and generate a core dump file. Then, I will use the crash cmd to analyse the core dump and find the reason of this crash. Is it possible to reserve some memory for a mini rtems kernel. This memory can not be used by the normal kernel. Once the normal kernel crashed, the mini kernel can generate a core dump of the normal kernel. small...@aliyun.com From: Gedare Bloom Date: 2020-09-15 23:26 To: small...@aliyun.com CC: devel Subject: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors? No, there is no facility to generate a core dump. Due to shared address space, once there is a fatal error you can't really trust anything running in the target. You wouldn't necessarily want to try writing to a mounted filesystem. You could probably set up a debugger to do something like this by triggering it in the fatal exception handler. You'd need to make use of whatever the debugger can do already though. You really can't rely on the executing target. Gedare On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com wrote: > > I am developing applications in rtems 5.1. As we know, my application and > rtems kernel are both in the same address space. > So if my application access an invalid address or encounter other fatal > errors, I want the kernel not just being hunging, but create a core dump file. > This file contains the whole contents of memory and I could use a debuger to > analyse the file to handle the bug. > The question arise because I do not want always debug rtems in the bsp. > > > small...@aliyun.com > ___ > 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
Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
Thanks very much for you reply. I get many useful information from your
suggestion.
Our BSP has a 8MB memory for rtems and a 32MB flash device. So it may not spend
too much time for dumping the core.
The question is that our application running with rtems is very complex. There
are several threads and many async processes.
When the fatal error happened, it is possible that the backtrace of current
thread is not enough.
We need analyse other data structures to debug, such as all items in a queue or
some global variable.
What's more, when our product sold to consumer and some bugs trigger a crash.
We could not connect to user's environment to debug.
So, it will be a better option if a core dump is generated.
However, if the core dump policy is not possible, the method you provided is
feasible.
I will study it and check how it will be integrated to our system.
small...@aliyun.com
From: Chris Johns
Date: 2020-09-16 08:33
To: small...@aliyun.com; devel
Subject: Re: does rtems 5.1 support create a core dump file when accessing a
invalid address or other fatal errors?
On 15/9/20 8:58 pm, small...@aliyun.com wrote:
> I am developing applications in rtems 5.1. As we know, my application and
> rtems
> kernel are both in the same address space.
> So if my application access an invalid address or encounter other fatal
> errors,
> I want the kernel not just being hunging, but create a core dump file.
> This file contains the whole contents of memory and I could use a debuger to
> analyse the file to handle the bug.
> The question arise because I do not want always debug rtems in the bsp.
This is an interesting question. For production units I think capturing and
reporting an error is important but a full core is not worth the effort.
Core images can be saved with a single address space OS. I remember Cisco's
single address space OS for routers from 20 years ago could capture a complete
core that could be loaded by gdb. Those devices had a Compact flash card
installed to capture the core and I suppose their users did not mind the wait
while the core was saved.
As others have explained capturing the full address space and saving it so gdb
could be taught to load it is difficult. You need to put aside some memory to
construct the core image as you save it and you need to have small stand alone
drivers and what ever else to get the image off the target and saved. RTEMS
cannot be used. Where this approach gets hard is when you start to consider
hardware failure type issues.
My preferred solution is to add a small storage area away from the RTEMS memory
map called the Run Time Error (RTE) store. This is a piece of RAM that can
survive a reset or reboot and is not part of the RTEMS memory map. Internal SoC
memory can often be enough. The memory cannot be cleared or corrupted during
reset. The struct is something like:
typedef struct
{
uint32_t type;/* The type of error in this trace buffer. */
uint32_t count; /* The number of times we have had an error. */
uint64_t uptime; /* The period of time we have been up. */
union
{
error_trace_fatal fatal; /* A fatal error. */
error_trace_assert assert; /* An assert error. */
error_trace_error error; /* An error code. */
} error;
uint32_t crc; /* Checksum */
} error_trace;
You provide a struct for a fatal error, an assert or an error. It is a matter of
hooking the error handlers and saving the data. The fatal error is something
like:
typedef struct
{
rtems_fatal_source source;
uint32_tinternal;
rtems_fatal_codecode;
CPU_Exception_frame frame;
uint32_tstack[ET_STACK_SIZE];
} error_trace_fatal;
Catch the fatal error handler and fill in the fields including the crc then
reset the board. Limit the code you call before reset.
When RTEMS starts get your application to check the RTE and if the checksum is
valid check the error count. If the error count is not zero you have captured an
error. You now have a working RTEMS that can be used to process and save the
error. I have production systems that save errors to a JFFS2 disk and a web
interface can be used to download it. I also have systems that send the data to
a syslog type server when the devices are networked. In those systems it is
really important to capture _every_ reset.
Finding the error in the code is a matter of getting the PC address and the ELF
executable image with the DWARF debug information and using `objdump -d
--source`. Disassemble the exe with source and search for the PC address. The
report points to the location and the dumped registers will help you see what
the issue is. Most of the time the issue can be found or investigated further
and resolved but sometimes it cannot be found directly. In those cases you need
to stress the system in a lab to expose the crash and then investigate. The key
information is the crash happened and where.
Chris
___
