Re: What are level in the thread?

I tried searching it on Google and RTEMS Documentation, but couldn't find anything that explains this. On Sat, Dec 5, 2020 at 11:34 AM Richi Dubey wrote: > Hi, > > Can someone please help me understand what is meant by level? What is > meant by the dispatch level and the pin level and other

Re: Which threads execute _Thread_Handler ?

Also, The stack trace for the thread looks like this: Tasks (entry function) -> rtems_task_wake_after ->_Thread_Dispatch_direct -> _Thread_Do_dispatch (where the _Context_switch function call lies), how can then the heir thread start executing from the _Thread_Handler? I do not see it in the

What are level in the thread?

Hi, Can someone please help me understand what is meant by level? What is meant by the dispatch level and the pin level and other such definitions? I just want a high-level idea of what we achieve by having levels and why we need them. Why do we have: _Assert(

Re: Which threads execute _Thread_Handler ?

> > I have currently no time to help you debugging this issue. Okay, even a hint would be helpful. returns to _Thread_Do_dispatch() or jumps to _Thread_Handler(). When does it return to _Thread_Do_dispatch() and when does it jump to _Thread_Handler() ? Is there a condition? How does it choose

Re: Building llvm/clang for RTEMS

On Sat, Dec 5, 2020 at 1:09 AM Vijay Kumar Banerjee wrote: > > > On Fri, Dec 4, 2020 at 6:58 AM Joel Sherrill wrote: > >> >> >> On Thu, Dec 3, 2020 at 4:19 PM Vijay Kumar Banerjee >> wrote: >> >>> Hello, >>> >>> I am thinking about building an LLVM toolchain for RISC-V and AArch64 >>> from

Re: [PATCH rtems] bsps/imxrt: Split up dts.

Hello Gedare, On 04/12/2020 17:04, Gedare Bloom wrote: seems fine to me. Thanks. is this stuff documented somewhere (at least for this BSP)? At the moment it's the only BSP where we have a dts that is written purely for RTEMS and linked in that way. Other BSPs either use a Linux FDT

Re: [PATCH rtems] bsps/imxrt: Split up dts.

seems fine to me. is this stuff documented somewhere (at least for this BSP)? On Fri, Dec 4, 2020 at 2:07 AM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > This allows simpler creation of own dts files for custom boards. > > Update #4180 > --- >

[PATCH rtems] bsps/imxrt: Split up dts.

This allows simpler creation of own dts files for custom boards. Update #4180 --- bsps/arm/imxrt/dts/imxrt1050-evkb.dts | 287 +- bsps/arm/imxrt/include/imxrt/imxrt1050.dtsi | 309 spec/build/bsps/arm/imxrt/bspimxrt.yml | 1 + 3 files changed,

Re: [PATCH v3 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

Hello, In this set of patches, I have added a test header which allows us to reinitialize the OFW API with test FDT. Other than that, I have also added a few explicit casts to suppress warnings. Thanks, Niteesh On Fri, Dec 4, 2020 at 1:41 PM G S Niteesh Babu wrote: > RTEMS OFW is a FDT only

[PATCH v3 2/2] libtests/ofw01: Added a test for RTEMS OFW

This commit adds a basic test that tests all the implemented RTEMS OFW functions. --- spec/build/testsuites/libtests/grp.yml | 2 + spec/build/testsuites/libtests/ofw01.yml | 21 +++ testsuites/libtests/ofw01/init.c | 197 +++ testsuites/libtests/ofw01/ofw01.doc

[PATCH v3 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

RTEMS OFW is a FDT only implementation of the OpenFirmWare interface. This API is created to be compatible with FreeBSD OpenFirmWare interface. The main intention is to make porting of FreeBSD drivers to RTEMS easier. Most functions implemented have an direct one-one mapping with the original OFW

Re: Which threads execute _Thread_Handler ?

On 04/12/2020 08:56, Richi Dubey wrote: When I am trying to debug tm24 running on the Strong APA scheduler code, I can see that the thread which comes after the call to _CPU_Context_switch, resumes execution from the same code (next line in the _Thread_Do_dispatch function after