Re: File system deadlock troubleshooting
I’m fairly certain I’m running into this reported issue: https://devel.rtems.org/ticket/2792 Is there any status change on this? Is there a temporary workaround recovery procedure? I’m tempted to give the conditional wait a timeout. Sent from my iPhone > On Oct 9, 2019, at 23:05, Mathew Benson wrote: > > I enabled RTEMS_RAMDISK_TRACE. That appears to be dead code in my build. > Change didn't do anything. I checked the symbol table and none of those > functions are in my build. The actual ram disk driver is in a different > location and didn't have a trace equivalent. Is there another way to get a > trace from ramdisk? > >> On Wed, Oct 9, 2019 at 6:01 PM Chris Johns wrote: >> On 10/10/19 6:23 am, Mathew Benson wrote: >> > I added the tracerfs command to the shell. Not sure why that's not already >> > there. >> >> The command is not in the shell directory and I did not add it to the config >> for >> the shell. Maybe is should be. I am not sure. >> >> > I enabled all with "tracerfs set all". It took a while, but I did run >> > into the problem. The end of the log is below. Can you see what the >> > kernel is >> > trying to do and what its waiting on from this? It's going to be a while, >> > reading through kernel code, to understand exactly what this means. >> >> Thank you for this. I am travelling from tomorrow for a while. I will try and >> have a look while in transit if I can. >> >> Chris > > > -- > Mathew Benson > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: FACE
Can I call you later this morning? What is your number? Sent from my iPhone > On Oct 23, 2019, at 09:18, Joel Sherrill wrote: > > > >> On Wed, Oct 23, 2019 at 8:26 AM Mathew Benson >> wrote: >> Is there a version of RTEMS that is FACE compliant? Possibly certified? If >> so, how do we get it and which official version from the mainline did it >> come from? > > It's almost like I asked you to give me that question. :) > > In September, Deos/RTEMS was verified to meet FACE conformance and given a > conformance certificate from the FACE Consortium. The combination meets the > FACE Safety Base profile for FACE Technical Standard Edition 3.0. Safety Base > requires that the environment provide both ARINC 653 and a subset of POSIX > services. Deos provides the ARINC 653 environment and a paravirtualized RTEMS > provides the POSIX APIs. The conformance certificate was done for the > PowerPC. This was a joint effort between OAR and DDC-I with DDC-I being the > customer facing side of the partnership for this product. > > The version was off the git master and a few months old. We are in the > process of updating to the git master and conforming an updated version for > PowerPC, ARM, and x86. It already supports all three architectures, we just > didn't do the conformance process on all three in that first pass. > > Deos has DO-178 Level A certification. RTEMS does not yet have certification > but hopefully that will change based on user requests and funding. > > I must say that I am quite proud of us having achieved this. The process of > doing this has improved the RTEMS POSIX support. All of the cross-platform > improvements are upstream. > > I don't want this to be more of a marketing spiel than needed on the Users > list so you can email privately or call me. I am happy to answer technical > questions about the integration. The environments integrated nicely IMO. > > There are a couple of papers that were presented at FACE TIMs while we were > working and I can pass them along as well as the marketing contact > information. > > --joel > >> >> Sent from my iPad >> ___ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: shell output
I take it that’s a no on the documentation. Can somebody just tell me what these mean or point me where in the code it is? It’s not an easy follow. Sent from my iPhone > On Oct 31, 2019, at 13:43, Mathew Benson wrote: > > is there any documentation that explains the actual output of the shell > commands? For example, the documentation for the task command says how to > run it, and gives the following sample output: > > SHLL [/] # task > ID NAME SHED PRI STATE MODESEVENTS WAITINFO > -- > 0a010001 UI1 UPD 254 EV P:T:nA NONE > 0a010002 SHLL UPD 100 READY P:T:nA NONE > > But doesn't actually explain what the data in the columns mean. What do the > following "STATE" values mean: EV, SIG:IS, READY, MSG, SEM, and TIME? What > do the MODES mean? Same question for the "sema" command output. > > -- > Mathew Benson > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
That’s kind of my point. The low priority shell task is working perfectly. The higher priority task is pended by time. I do have some sleep functions in the driver code but they are short sleeps. They shouldn’t just pens indefinitely until a run any random command in the shell. Unless I’m not understanding the priority model correctly and have inadvertently inverted my prioritities. Sent from my iPhone > On Nov 1, 2019, at 14:40, Joel Sherrill wrote: > > > >> On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom wrote: >> >>> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson >>> wrote: >>> So no matter what priority the shell task is initialized as, it preempts >>> all other tasks? >>> >> No. > > But an odd artifact of looking at the status of threads in the shell is that > the shell thread has to be **EXECUTING** to do that. Since this is a single > core system, it means all other threads are either blocked or ready and have > a lower priority. > >> >> With low priority (250) under the default scheduling (fixed priority >> round-robin), the shell would only run when higher priority tasks are >> blocked. This is typical, and the shell will be preempted when higher >> priority tasks are made ready. The "TIME" state indicates your driver task >> self-suspended on a timer, e.g., nanosleep or wake_after type call. It >> should preempt the shell after the timeout. If it isn't then something is >> going strangely. > > Yep. >> >> As Joel hinted, if you're using POSIX threads, then 250 is higher priority >> than 235. > > But I don't know how this is reported by the command he is using. I recall > one command to list Classic API tasks and one for POSIX threads. I don't > recall one which lists all but I could be wrong. > > --joel > >> >> Gedare >> On Fri, Nov 1, 2019 at 11:36 AM Joel Sherrill wrote: > On Fri, Nov 1, 2019, 11:24 AM Mathew Benson > wrote: > My shell task is set to priority 250. I have another task that I've set > to a priority of 235. When I have the shell in the build, that priority > 235 task appears to pend indefinitely with the shell reporting state = > "TIME" and I don't know where it would be pending. The task is accessing > NOR drivers. But just by running the shell command, releases that > priority 235 task. In fact, any command releases it. Whether its a > valid command or not. But if I remove the shell from the build, > everything is fine. The task doesn't pend. It executes as it should. > Did I miss something in the documentation regarding integration of the > shell? Is there something we are or are not supposed to do when the > shell is integrated? I'm off today and this is from my phone. TIME should indicate that the task is sleeping. Assuming these are not POSIX thread priority The priority 235 task has to be blocked or the shell task won't run at all. So anytime your shell task runs, the others should be blocked. --joel > > -- > Mathew Benson > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > > ___ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users >>> >>> >>> -- >>> Mathew Benson >>> CEO | Chief Engineer >>> Windhover Labs, LLC >>> 832-640-4018 >>> >>> >>> www.windhoverlabs.com >>> >>> ___ >>> users mailing list >>> users@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Zynq Ultrascale+
Trying the other list. Is RTEMS actually running on a Zynq Ultrascale? The instructions I found for the Ultra96 make me think 1) either it doesn’t actually work, or 2) there are undocumented assumptions including running the A53’s in 32bit mode. What I’m most interested in is running RTEMS on the Cortex R5 both in split and lock step mode. Sent from my iPhone > On Dec 8, 2019, at 13:15, Mathew Benson wrote: > > My new board arrived so I'm shelving the OcPoC (Zynq 7020) to focus on the > new Zynq Ultrascale+. > > https://shop.trenz-electronic.de/en/TE0820-03-2AI21FA-MPSoC-Module-with-Xilinx-Zynq-UltraScale-ZU2CG-1I-2-GByte-DDR4-SDRAM-4-x-5-cm > > Has anybody ported RTEMS to the Zynq Ultrascale+? I saw that "xilinx_zynqmp" > is the arm family with "xilinx_zynqmp_ultra96" BSP. Does this actually work? > Maybe this is a dumb question, but why is the xilinx_zynqmp_ultra96 BSP > built using the arm-rtems5 toolchain? It builds a 32 bit binary. The Zynq > Ultrascale is 64 bit. The linux kernel built by the Xilinx Petalinux > toolchain results in an aarch64 kernel. > > > -- > Mathew Benson > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: CPU Usage
I basically just copied and renamed the existing function that prints to the console, but changed it to return a struct. I couldn’t personally give it back. I thought my customer at the time would roll it back in. Looks like that never happened. Sorry. > On Jan 13, 2023, at 17:05, Joel Sherrill wrote: > > > That's the right answer Karel. > > I will add that we have been open to the addition of an API to obtain this > information if someone could propose one. > > This is an area where not knowing what users would like to have has been a > hurdle. > >> On Fri, Jan 13, 2023 at 3:42 PM Karel Gardas wrote: >> >> I would guess it is, but judge yourself by going to the RTEMS source >> code[*] and grepping for "rtems_cpu_usage". >> >> Cheers, >> Karel >> >> [*] used few months old trunk here. >> >> On 1/13/23 21:48, Molock, Dwaine S. (GSFC-5820) wrote: >> > Hello, >> > >> > Is there a RTEMS API available to obtain the current CPU usage or >> > anything similar to the “/proc/stat” file in Linux that can be read to >> > obtain this information? >> > >> > Thanks, >> > >> > Dwaine >> > >> > >> > ___ >> > users mailing list >> > users@rtems.org >> > http://lists.rtems.org/mailman/listinfo/users >> >> ___ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > ___ > users mailing list > users@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Snapdragon
Has anybody ported RTEMS to the Qualcomm Snapdragon? Sent from my iPhone ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
JFFS2
Does JFFS2 provide bad block management and wear leveling? If so, is there anything we need to do to enable it? Sent from my iPhone ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
