Re: [rtems-release commit] Do not use tar Jxf for uncompressed archives

2022-02-18 Thread Sebastian Huber 

On 17/02/2022 20:15, Chris Johns wrote:

On 17/2/22 4:45 pm, Sebastian Huber wrote:

Hello Chris,

On 17/02/2022 04:11, Chris Johns wrote:

I would like to approve all commits to this repo.

Why have you made this change?

I tried to run the scripts on my Linux machine and this fixed one of the issues
that occurred.

Have you tested the change on FreeBSD?


Not yet, I had some issues to set up our FreeBSD VM. The virtualenv and 
npm is not installed by default.



--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Problem compiling leon3 and gr712rc with Tests and SMP enabled.

2022-02-18 Thread Jerzy Jaskuc 
Hi,

I've been trying to manually build BSP using waf on RTEMS 6. I'm working
off HEAD of the RTEMS master branch.
However, on gr712rc, whenever I try to have both SMP and tests enabled I
get compile errors, which I can't really understand. When I try building
with only either option, it works in both cases.

Contents of my .ini file:
`[sparc/gr712rc]
RTEMS_SMP = True
BUILD_TESTS = True`

Commands I run:
`./waf configure --prefix=$HOME/RTEMS/rtems/6`
`./waf -v`

Bottom excerpt of error Log:
`/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
./librtemscpu.a(threadqops.c.59.o): in function
`_Thread_Scheduler_get_node_by_index':
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/threadimpl.h:1553:
undefined reference to `_Scheduler_Node_size'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
./librtemscpu.a(threadqops.c.59.o):/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/threadimpl.h:1553:
more undefined references to `_Scheduler_Node_size' follow
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
./librtemscpu.a(threadrestart.c.59.o): in function `_Per_CPU_Get_index':
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/percpu.h:681:
undefined reference to `_Per_CPU_Information'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/percpu.h:681:
undefined reference to `_Per_CPU_Information'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
./librtemscpu.a(userextaddset.c.59.o): in function `_Per_CPU_Acquire_all':
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/percpu.h:744:
undefined reference to `_Per_CPU_Information'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/percpu.h:744:
undefined reference to `_Per_CPU_Information'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/percpu.h:746:
undefined reference to `_Per_CPU_Information'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
./librtemscpu.a(userextaddset.c.59.o):/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc/../../../cpukit/include/rtems/score/percpu.h:746:
more undefined references to `_Per_CPU_Information' follow
collect2: error: ld returned 1 exit status

Waf: Leaving directory `/home/yoman/RTEMS/src/rtems/build/sparc/gr712rc'
Build failed
 -> task in '' failed with exit status 1:
{task 139809939310064: link dl04-tar.o,init.o,dl-load.o -> dl04.pre}
''
 -> task in '' failed with exit status 1:
{task 139809939309840: link dl02-tar.o,init.o,dl-load.o -> dl02.pre}
''
 -> task in '' failed with exit status 1:
{task 139809939310512: link dl06-pre-tar.o,pre-init.o,dl-load.o -> dl06.pre}
''
 -> task in '' failed with exit status 1:
{task 139809939309616: link dl01-tar.o,init.o,dl-load.o -> dl01.pre}
''`

Similarly when I'm trying the same with Leon3. However, on Leon3 I can't
even build it with only tests enabled.

Contents of my .ini file:
`[sparc/leon3]
BUILD_TESTS = True`

Commands I run:
`./waf configure --prefix=$HOME/RTEMS/rtems/6`
`./waf -v`

Log excerpt:
`/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/leon3/testsuites/libtests/dl10/init.o:(.rodata._Scheduler_Table+0x30):
undefined reference to `_Scheduler_default_Sticky_do_nothing'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/leon3/testsuites/libtests/dl10/init.o:(.rodata._Scheduler_Table+0x34):
undefined reference to `_Scheduler_default_Sticky_do_nothing'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/leon3/testsuites/libtests/dl10/init.o:(.rodata._Scheduler_Table+0x38):
undefined reference to `_Scheduler_default_Pin_or_unpin_do_nothing'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/leon3/testsuites/libtests/dl10/init.o:(.rodata._Scheduler_Table+0x3c):
undefined reference to `_Scheduler_default_Pin_or_unpin_do_nothing'
/home/yoman/RTEMS/rtems/6/lib/gcc/sparc-rtems6/10.3.1/../../../../sparc-rtems6/bin/ld:
/home/yoman/RTEMS/src/rtems/build/sparc/leon3/testsuites/libtests/dl10/init.o:(.rodata._Scheduler_Table+0x5c):
undefined reference to `_Scheduler_default_Set_affinity'
collect2: error: ld returned 1 exit status

Waf: Leaving directory `/home/yoman/RTEMS/src/rtems/build/sparc/leon3'
Build failed
 -> task in ''

Re: Problem compiling leon3 and gr712rc with Tests and SMP enabled.

2022-02-18 Thread Sebastian Huber 

On 18/02/2022 12:02, Jerzy Jaskuc wrote:

Am I doing something wrong or missing some new steps with it? Any help
would be appreciated!


This is probably a bug in the dependency tracking of the build system. 
Try to delete the build directory before the waf configure.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Problem compiling leon3 and gr712rc with Tests and SMP enabled.

2022-02-18 Thread Jerzy Jaskuc 
Thanks Sebastian!

It seems like it was dependency tracking. All is working now after deleting
the build directory.

Thanks and all the best,
Jerzy

On Fri, 18 Feb 2022 at 11:20, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/02/2022 12:02, Jerzy Jaskuc wrote:
> > Am I doing something wrong or missing some new steps with it? Any help
> > would be appreciated!
>
> This is probably a bug in the dependency tracking of the build system.
> Try to delete the build directory before the waf configure.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

NTP client recommendation for RTEMS?

2022-02-18 Thread Sebastian Huber 

Hello,

I would like to add an NTP client support for RTEMS. The ntp_adjtime() 
implementation is already available as a patch. For testing purposes I 
ported the NTP daemon from FreeBSD to libbsd. This basically works fine. 
I am not sure about the maintenance status of this code 
(https://www.ntp.org/). There is also


https://www.ntpsec.org/

This project has a public Git repository and seems to be more active. 
However, there is no standard package for openSUSE Leap 15.3. Maybe this 
is because most Linux users use now timesyncd from systemd. Any 
recommendations?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NTP client recommendation for RTEMS?

2022-02-18 Thread Joel Sherrill 
On Fri, Feb 18, 2022, 7:22 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I would like to add an NTP client support for RTEMS. The ntp_adjtime()
> implementation is already available as a patch. For testing purposes I
> ported the NTP daemon from FreeBSD to libbsd. This basically works fine.
> I am not sure about the maintenance status of this code
> (https://www.ntp.org/). There is also
>
> https://www.ntpsec.org/
>
> This project has a public Git repository and seems to be more active.
> However, there is no standard package for openSUSE Leap 15.3. Maybe this
> is because most Linux users use now timesyncd from systemd. Any
> recommendations?
>

I'd stick with ntp.org without much thought. With that being what FreeBSD
uses, it is icing on the cake.

Did you eliminate use of signals like Chris had to do with ptpd?

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: NTP client recommendation for RTEMS?

2022-02-18 Thread Sebastian Huber 

On 18/02/2022 14:43, Joel Sherrill wrote:
On Fri, Feb 18, 2022, 7:22 AM Sebastian Huber 
> wrote:


Hello,

I would like to add an NTP client support for RTEMS. The ntp_adjtime()
implementation is already available as a patch. For testing purposes I
ported the NTP daemon from FreeBSD to libbsd. This basically works
fine.
I am not sure about the maintenance status of this code
(https://www.ntp.org/ ). There is also

https://www.ntpsec.org/ 

This project has a public Git repository and seems to be more active.
However, there is no standard package for openSUSE Leap 15.3. Maybe
this
is because most Linux users use now timesyncd from systemd. Any
recommendations?


I'd stick with ntp.org  without much thought. With that 
being what FreeBSD uses, it is icing on the cake.


The code looks not that good. There seems to be a lot of cleanup done in 
ntpsec.org.




Did you eliminate use of signals like Chris had to do with ptpd?


Not yet, they use both select(), but this should be changed to use 
kqueue(). I hacked away the use of signal.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 3/5] cpukit/microblaze: Add interrupt hooks

2022-02-18 Thread Kinsey Moore 



On 2/17/2022 20:31, Chris Johns wrote:

On 18/2/22 8:58 am, Kinsey Moore wrote:

On 2/17/2022 15:31, Chris Johns wrote:

On 18/2/22 7:12 am, Kinsey Moore wrote:

On 2/17/2022 13:53, Chris Johns wrote:

Who is setting breaks points in interrupts?

Where I encountered issues was setting breaks in library functions that I was
stepping through in non-interrupt context, particularly in memset(). ISR
handlers can also call into this library code and libdebugger bails when
application debugging intersects with ISR handler execution.

Interesting use case. Does this effect all archs? I think it does.

It does to an extent. Stepping through with inverse breakpoints on ARM and
single-step mode on AArch64 wouldn't encounter this issue, but software
breakpoints placed in those shared functions would cause the same problems I'm
seeing on MicroBlaze. ARM may not see this issue at all if it makes hardware
breakpoints available, but I don't remember whether it does.

Hmm .. the GDB solution is to place the instruction back and step then return
the break point. I am not sure if this is possible and less intrusive to the 
system?

Does this solution means the interrupts have extra overheads?
In the nominal case (libdebugger not running), the overhead is less than 
30 instructions per interrupt execution which could theoretically be 
optimized a bit by integrating the handler dispatch into the ISR_Handler 
assembly instead of having it be a stand-alone C function. In the case 
where libdebugger is running, the overhead is the nominal overhead plus 
O(n) on the number of software breakpoints installed. If I had to hazard 
a guess on the incremental number of instructions per software break, 
I'd put it at 50 or so on top of the overhead of the call chain to get 
there.


Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: NTP client recommendation for RTEMS?

2022-02-18 Thread Joel Sherrill 
On Fri, Feb 18, 2022 at 7:46 AM Sebastian Huber
 wrote:
>
> On 18/02/2022 14:43, Joel Sherrill wrote:
> > On Fri, Feb 18, 2022, 7:22 AM Sebastian Huber
> >  > > wrote:
> >
> > Hello,
> >
> > I would like to add an NTP client support for RTEMS. The ntp_adjtime()
> > implementation is already available as a patch. For testing purposes I
> > ported the NTP daemon from FreeBSD to libbsd. This basically works
> > fine.
> > I am not sure about the maintenance status of this code
> > (https://www.ntp.org/ ). There is also
> >
> > https://www.ntpsec.org/ 
> >
> > This project has a public Git repository and seems to be more active.
> > However, there is no standard package for openSUSE Leap 15.3. Maybe
> > this
> > is because most Linux users use now timesyncd from systemd. Any
> > recommendations?
> >
> >
> > I'd stick with ntp.org  without much thought. With that
> > being what FreeBSD uses, it is icing on the cake.
>
> The code looks not that good. There seems to be a lot of cleanup done in
> ntpsec.org.

Yes that is true. And I will communicate my concerns offline. One of
the main ones is that the ntpsec project was heading in a very Linux
centric way on what APIs would be used. They did kill a lot of old platforms
and do some clean up which is good.

There were discussions about re-writing it in Go. If that happens, we
would have issues.

In general, I leaned to the freebsd.org code because we already have
a process in place for dealing with it. And if it is good enough for FreeBSD,
it should be a good first choice for us.

If this turns out to be wrong, there is ntpsec and OpenNTP which seem
to be derived from ntp.org. Any porting done on the freebsd.org code should
apply to the others easily enough.

No idea what to do about a full NTP client for lwip. Any thoughts?

>
> >
> > Did you eliminate use of signals like Chris had to do with ptpd?
>
> Not yet, they use both select(), but this should be changed to use
> kqueue(). I hacked away the use of signal.

Great! Is this work going to land in the public in the near future?

--joel

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] config: CONFIGURE_DISABLE_NEWLIB_REENTRANCY

2022-02-18 Thread Sebastian Huber 
Do not initialize Thread_Control::libc_reent if
CONFIGURE_DISABLE_NEWLIB_REENTRANCY is defined.  This helps to catch errors
with a NULL pointer exception rather than a corruption of the thread control
block.
---
 cpukit/include/rtems/confdefs/threads.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/cpukit/include/rtems/confdefs/threads.h 
b/cpukit/include/rtems/confdefs/threads.h
index 279c6264db..503a4b20ec 100644
--- a/cpukit/include/rtems/confdefs/threads.h
+++ b/cpukit/include/rtems/confdefs/threads.h
@@ -161,8 +161,6 @@ struct Thread_Configured_control {
   #endif
   #ifdef _CONFIGURE_ENABLE_NEWLIB_REENTRANCY
 struct _reent Newlib;
-  #else
-struct { /* Empty */ } Newlib;
   #endif
 };
 
@@ -176,13 +174,16 @@ const Thread_Control_add_on _Thread_Control_add_ons[] = {
   Control.API_Extensions[ THREAD_API_RTEMS ]
 ),
 offsetof( Thread_Configured_control, API_RTEMS )
-  }, {
-offsetof(
-  Thread_Configured_control,
-  Control.libc_reent
-),
-offsetof( Thread_Configured_control, Newlib )
   }
+  #ifdef _CONFIGURE_ENABLE_NEWLIB_REENTRANCY
+, {
+  offsetof(
+Thread_Configured_control,
+Control.libc_reent
+  ),
+  offsetof( Thread_Configured_control, Newlib )
+}
+  #endif
   #if CONFIGURE_MAXIMUM_THREAD_NAME_SIZE > 1
 , {
   offsetof(
-- 
2.26.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

config, _IO_Initialize_all_drivers

2022-02-18 Thread Heinz Junkes 
I'm still trying to get the booting and registering and initialising of the i2c 
devices on the MVME3100 to work properly.

In confdefs/iodrivers.h the driver address table is built up and then 
_IO_Initialize_all_drivers() is called without registering the individual 
devices first.

If I now enter in already before in bspstart.c

RTEMS_SYSINIT_ITEM(
  mvme3100_i2c_initialize,
  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
  RTEMS_SYSINIT_ORDER_MIDDLE
);

a device (register it and e.g. got the major number 0) this is ignored by the 
IO_Initialize_all_drivers().

Shouldn't initialisation be preceded by registration ( 
rtems_io_register_driver() )?

Heinz

rtems_driver_address_table
_IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
  #ifdef CONFIGURE_BSP_PREREQUISITE_DRIVERS
CONFIGURE_BSP_PREREQUISITE_DRIVERS,
  #endif
  #ifdef CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS
CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
CONSOLE_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER
RTC_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER
WATCHDOG_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
DEVNULL_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
DEVZERO_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER
IDE_CONTROLLER_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
ATA_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
FRAME_BUFFER_DRIVER_TABLE_ENTRY,
  #endif
  #ifdef CONFIGURE_APPLICATION_EXTRA_DRIVERS
CONFIGURE_APPLICATION_EXTRA_DRIVERS,
  #endif
  #if defined(CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER) \
|| ( !defined(CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER) \
  && !defined(CONFIGURE_APPLICATION_EXTRA_DRIVERS) )
NULL_DRIVER_TABLE_ENTRY
  #endif
};

const size_t _IO_Number_of_drivers =
  RTEMS_ARRAY_SIZE( _IO_Driver_address_table );

RTEMS_SYSINIT_ITEM(
  _IO_Initialize_all_drivers,
  RTEMS_SYSINIT_DEVICE_DRIVERS,
  RTEMS_SYSINIT_ORDER_MIDDLE
);



--
Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
Faradayweg 4-6| VC: 102220181...@bjn.vc
D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
--

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: config, _IO_Initialize_all_drivers

2022-02-18 Thread Joel Sherrill 
On Fri, Feb 18, 2022 at 10:18 AM Heinz Junkes  wrote:
>
> I'm still trying to get the booting and registering and initialising of the 
> i2c devices on the MVME3100 to work properly.
>
> In confdefs/iodrivers.h the driver address table is built up and then
> _IO_Initialize_all_drivers() is called without registering the individual 
> devices first.
>
> If I now enter in already before in bspstart.c
>
> RTEMS_SYSINIT_ITEM(
>   mvme3100_i2c_initialize,
>   RTEMS_SYSINIT_BSP_PRE_DRIVERS,
>   RTEMS_SYSINIT_ORDER_MIDDLE
> );
>
> a device (register it and e.g. got the major number 0) this is ignored by the 
> IO_Initialize_all_drivers().

Any method registered that way is "void METHOD(void)" so you are lucky
you saw 0 for major.

> Shouldn't initialisation be preceded by registration ( 
> rtems_io_register_driver() )?

"Normally" the driver initialization entry registers names.

I don't know if it is a good example but libtests/i2c01 is doing
something different.

Perhaps someone who has more knowledge of the i2c framework needs
to speak up.

FWIW Christian is often on Discord. It's good for quick answers.

--joel-



> Heinz
>
> rtems_driver_address_table
> _IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
>   #ifdef CONFIGURE_BSP_PREREQUISITE_DRIVERS
> CONFIGURE_BSP_PREREQUISITE_DRIVERS,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS
> CONFIGURE_APPLICATION_PREREQUISITE_DRIVERS,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> CONSOLE_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER
> RTC_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_WATCHDOG_DRIVER
> WATCHDOG_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
> DEVNULL_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
> DEVZERO_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER
> IDE_CONTROLLER_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER
> ATA_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER
> FRAME_BUFFER_DRIVER_TABLE_ENTRY,
>   #endif
>   #ifdef CONFIGURE_APPLICATION_EXTRA_DRIVERS
> CONFIGURE_APPLICATION_EXTRA_DRIVERS,
>   #endif
>   #if defined(CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER) \
> || ( !defined(CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_NEEDS_RTC_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER) \
>   && !defined(CONFIGURE_APPLICATION_EXTRA_DRIVERS) )
> NULL_DRIVER_TABLE_ENTRY
>   #endif
> };
>
> const size_t _IO_Number_of_drivers =
>   RTEMS_ARRAY_SIZE( _IO_Driver_address_table );
>
> RTEMS_SYSINIT_ITEM(
>   _IO_Initialize_all_drivers,
>   RTEMS_SYSINIT_DEVICE_DRIVERS,
>   RTEMS_SYSINIT_ORDER_MIDDLE
> );
>
>
>
> --
> Fritz-Haber-Institut| Phone: (+49 30) 8413-4270
> Heinz Junkes | Fax (G3+G4):   (+49 30) 8413-5900
> Faradayweg 4-6| VC: 102220181...@bjn.vc
> D - 14195 Berlin| E-Mail:jun...@fhi-berlin.mpg.de
> --
>
> ___
> 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

[PATCH v2 0/6] Add MicroBlaze libdebugger support

2022-02-18 Thread Kinsey Moore 
Differences from v1:
* Patch 1/6: Commit message reworded
* Patch 4/6: Added for independent exception control
* Patch 6/6: Reworked to use illegal opcode instead of
 architecture-defined software break instruction


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 1/6] cpukit/libdebugger: Avoid missed swbreak removal

2022-02-18 Thread Kinsey Moore 
It is possible to remove software breaks without actually restoring the
original instruction to memory. When this happens, the original
instruction is lost. This ensures that the original instruction is
restored when a software break is removed.
---
 cpukit/libdebugger/rtems-debugger-target.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/cpukit/libdebugger/rtems-debugger-target.c 
b/cpukit/libdebugger/rtems-debugger-target.c
index 04b274909b..c298a62357 100644
--- a/cpukit/libdebugger/rtems-debugger-target.c
+++ b/cpukit/libdebugger/rtems-debugger-target.c
@@ -191,6 +191,22 @@ rtems_debugger_target_swbreak_control(bool insert, 
uintptr_t addr, DB_UINT kind)
 if (loc == swbreaks[i].address) {
   size_t remaining;
   if (!insert) {
+if (target->breakpoint_size > 4)
+  memcpy(loc, swbreaks[i].contents, target->breakpoint_size);
+else {
+  switch (target->breakpoint_size) {
+  case 4:
+loc[3] = swbreaks[i].contents[3];
+  case 3:
+loc[2] = swbreaks[i].contents[2];
+  case 2:
+loc[1] = swbreaks[i].contents[1];
+  case 1:
+loc[0] = swbreaks[i].contents[0];
+break;
+  }
+}
+rtems_debugger_target_cache_sync(&swbreaks[i]);
 --target->swbreaks.level;
 remaining = (target->swbreaks.level - i) * swbreak_size;
 memmove(&swbreaks[i], &swbreaks[i + 1], remaining);
-- 
2.30.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 2/6] cpukit/libdebugger: Add pure swbreak capability

2022-02-18 Thread Kinsey Moore 
Add a capability that allows for implementations that operate purely
using software breaks. Due to this implementation method, software
breaks must not be restored until just before returning control to the
thread itself and will be handled by the implementation through thread
switch and interrupt hooks.
---
 cpukit/libdebugger/rtems-debugger-target.h  | 14 +++---
 cpukit/libdebugger/rtems-debugger-threads.c |  4 +++-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/cpukit/libdebugger/rtems-debugger-target.h 
b/cpukit/libdebugger/rtems-debugger-target.h
index 1e132fb28c..7836f93bd6 100644
--- a/cpukit/libdebugger/rtems-debugger-target.h
+++ b/cpukit/libdebugger/rtems-debugger-target.h
@@ -49,9 +49,17 @@ extern "C" {
 /**
  * Target capabilities mask.
  */
-#define RTEMS_DEBUGGER_TARGET_CAP_SWBREAK   (1 << 0)
-#define RTEMS_DEBUGGER_TARGET_CAP_HWBREAK   (1 << 1)
-#define RTEMS_DEBUGGER_TARGET_CAP_HWWATCH   (1 << 2)
+#define RTEMS_DEBUGGER_TARGET_CAP_SWBREAK  (1 << 0)
+#define RTEMS_DEBUGGER_TARGET_CAP_HWBREAK  (1 << 1)
+#define RTEMS_DEBUGGER_TARGET_CAP_HWWATCH  (1 << 2)
+/*
+ * This target capability indicates that the target implementation uses a pure
+ * software break implementation which must not allow breakpoints to be
+ * inserted before the actual switch to the thread, be it in interrupt context
+ * or otherwise. Such implementations must necessarily implement a thread
+ * switch hook and interrupt hooks to handle these situations.
+ */
+#define RTEMS_DEBUGGER_TARGET_CAP_PURE_SWBREAK (1 << 3)
 
 /**
  * Types of hardware breakpoints.
diff --git a/cpukit/libdebugger/rtems-debugger-threads.c 
b/cpukit/libdebugger/rtems-debugger-threads.c
index c628c0250e..841199bfe3 100644
--- a/cpukit/libdebugger/rtems-debugger-threads.c
+++ b/cpukit/libdebugger/rtems-debugger-threads.c
@@ -355,9 +355,11 @@ rtems_debugger_thread_system_resume(bool detaching)
   current = rtems_debugger_thread_current(threads);
   if (current != NULL) {
 size_t i;
+rtems_debugger_target* target = rtems_debugger->target;
 if (rtems_debugger_verbose())
   rtems_debugger_printf("rtems-db: sys:: resuming\n");
-if (!detaching) {
+if (!detaching
+  && (target->capabilities & RTEMS_DEBUGGER_TARGET_CAP_PURE_SWBREAK) == 0) 
{
   r = rtems_debugger_target_swbreak_insert();
   if (r == 0)
 r = rtems_debugger_target_hwbreak_insert();
-- 
2.30.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 3/6] cpukit/microblaze: Add interrupt hooks

2022-02-18 Thread Kinsey Moore 
Add hooks for manipulating system state before and after interrupts are
run. These hooks serve primarily to allow the MicroBlaze libdebugger
backend to prevent software breaks from occurring in interrupt context.
---
 cpukit/score/cpu/microblaze/cpu.c | 42 +++
 cpukit/score/cpu/microblaze/cpu_asm.S | 12 ++
 .../cpu/microblaze/include/rtems/score/cpu.h  | 17 
 3 files changed, 71 insertions(+)

diff --git a/cpukit/score/cpu/microblaze/cpu.c 
b/cpukit/score/cpu/microblaze/cpu.c
index fe55ef5546..960ac1bfea 100644
--- a/cpukit/score/cpu/microblaze/cpu.c
+++ b/cpukit/score/cpu/microblaze/cpu.c
@@ -229,3 +229,45 @@ void _MicroBlaze_Debug_handle( CPU_Exception_frame *ef )
 
   rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) ef );
 }
+
+MicroBlaze_Interrupt_hook installed_preint_hook = NULL;
+
+void _MicroBlaze_Pre_Interrupt_install_hook(
+  MicroBlaze_Interrupt_hook  new_hook,
+  MicroBlaze_Interrupt_hook *old_hook
+)
+{
+  if ( old_hook != NULL ) {
+*old_hook = installed_preint_hook;
+  }
+
+  installed_preint_hook = new_hook;
+}
+
+void _MicroBlaze_Pre_Interrupt_hook()
+{
+  if ( installed_preint_hook != NULL ) {
+installed_preint_hook();
+  }
+}
+
+MicroBlaze_Interrupt_hook installed_postint_hook = NULL;
+
+void _MicroBlaze_Post_Interrupt_install_hook(
+  MicroBlaze_Interrupt_hook  new_hook,
+  MicroBlaze_Interrupt_hook *old_hook
+)
+{
+  if ( old_hook != NULL ) {
+*old_hook = installed_postint_hook;
+  }
+
+  installed_postint_hook = new_hook;
+}
+
+void _MicroBlaze_Post_Interrupt_hook()
+{
+  if ( installed_postint_hook != NULL ) {
+installed_postint_hook();
+  }
+}
diff --git a/cpukit/score/cpu/microblaze/cpu_asm.S 
b/cpukit/score/cpu/microblaze/cpu_asm.S
index 0a2c5d8fff..6bd81eedd9 100644
--- a/cpukit/score/cpu/microblaze/cpu_asm.S
+++ b/cpukit/score/cpu/microblaze/cpu_asm.S
@@ -82,6 +82,15 @@ switch_to_interrupt_stack:
swi r4, r1, 0
 
 on_interrupt_stack:
+   /*
+* Temporarily stash param 1 into r2 which is a special register not
+* used by RTEMS
+*/
+   addik r2, r5, 0
+   bralid r15, _MicroBlaze_Pre_Interrupt_hook
+   nop
+   addik r5, r2, 0
+
/* Add 1 to ISR_NEST_LEVEL */
lwi r3, r0, _Per_CPU_Information + 8
addik r3, r3, 1
@@ -120,6 +129,9 @@ after_stack_switch:
/* Fall through to quick exit */
 
 quick_exit:
+   bralid r15, _MicroBlaze_Post_Interrupt_hook
+   nop
+
/* Simple return from nested interrupt */
/* Restore registers */
lwi  r3, r1, MICROBLAZE_INTERRUPT_FRAME_MSR
diff --git a/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h 
b/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
index 5ca0609e91..9c6b213e20 100644
--- a/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
@@ -362,6 +362,23 @@ void _CPU_Context_switch(
   Context_Control  *heir
 );
 
+/* Interrupt hooks used by libdebugger */
+typedef void ( *MicroBlaze_Interrupt_hook )( void );
+
+void _MicroBlaze_Pre_Interrupt_install_hook(
+  MicroBlaze_Interrupt_hook  new_hook,
+  MicroBlaze_Interrupt_hook *old_hook
+);
+
+void _MicroBlaze_Pre_Interrupt_hook( void );
+
+void _MicroBlaze_Post_Interrupt_install_hook(
+  MicroBlaze_Interrupt_hook  new_hook,
+  MicroBlaze_Interrupt_hook *old_hook
+);
+
+void _MicroBlaze_Post_Interrupt_hook( void );
+
 /* Selects the appropriate resume function based on CEF state */
 RTEMS_NO_RETURN void _CPU_Exception_resume( CPU_Exception_frame *frame );
 
-- 
2.30.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 4/6] microblaze: Decouple exceptions from interrupts

2022-02-18 Thread Kinsey Moore 
Exception handling should be enabled at all times during execution to
ensure that exceptions are not ignored which would cause further
problems. This separates use of the exception enable bit from use of the
interrupt enable bit in the machine status register so that they can be
manipulated independently.
---
 bsps/microblaze/microblaze_fpga/start/crtinit.S   |  3 +++
 cpukit/score/cpu/microblaze/cpu.c |  6 +++---
 cpukit/score/cpu/microblaze/include/rtems/score/cpu.h | 10 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/bsps/microblaze/microblaze_fpga/start/crtinit.S 
b/bsps/microblaze/microblaze_fpga/start/crtinit.S
index a9779404b2..d56bee3b19 100644
--- a/bsps/microblaze/microblaze_fpga/start/crtinit.S
+++ b/bsps/microblaze/microblaze_fpga/start/crtinit.S
@@ -81,6 +81,9 @@ _crtinit:
 #ifndef __rtems__
brlid   r15, main  /* Execute 
the program */
 #else
+   mfs r3, rmsr
+   ori r3, r3, 0x100  /* Set 
Exception Enable MSR flag */
+   mts rmsr, r3
brlid   r15, boot_card
 #endif /* __rtems__ */
addir5, r0, 0
diff --git a/cpukit/score/cpu/microblaze/cpu.c 
b/cpukit/score/cpu/microblaze/cpu.c
index 960ac1bfea..259053f88a 100644
--- a/cpukit/score/cpu/microblaze/cpu.c
+++ b/cpukit/score/cpu/microblaze/cpu.c
@@ -142,9 +142,9 @@ void _CPU_ISR_Set_level( uint32_t level )
   _CPU_MSR_GET( microblaze_switch_reg );
 
   if ( level == 0 ) {
-microblaze_switch_reg |= (MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE);
+microblaze_switch_reg |= MICROBLAZE_MSR_IE;
   } else {
-microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE);
+microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE);
   }
 
   _CPU_MSR_SET( microblaze_switch_reg );
@@ -158,7 +158,7 @@ uint32_t _CPU_ISR_Get_level( void )
 
   /* This is unique. The MSR register contains an interrupt enable flag where
* most other architectures have an interrupt disable flag. */
-  return ( level & (MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE) ) == 0;
+  return ( level & MICROBLAZE_MSR_IE ) == 0;
 }
 
 void _CPU_ISR_install_vector(
diff --git a/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h 
b/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
index 9c6b213e20..253810ad59 100644
--- a/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/microblaze/include/rtems/score/cpu.h
@@ -212,7 +212,7 @@ typedef struct {
   { \
 unsigned int _new_msr;  \
 _CPU_MSR_GET(_isr_cookie); \
-_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE); \
+_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE); \
 _CPU_MSR_SET(_new_msr); \
   }
 
@@ -221,9 +221,9 @@ typedef struct {
 uint32_t _microblaze_interrupt_enable; \
 uint32_t _microblaze_switch_reg; \
 \
-_microblaze_interrupt_enable = (_isr_cookie) & (MICROBLAZE_MSR_IE | 
MICROBLAZE_MSR_EE); \
+_microblaze_interrupt_enable = (_isr_cookie) & (MICROBLAZE_MSR_IE); \
 _CPU_MSR_GET(_microblaze_switch_reg); \
-_microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE); \
+_microblaze_switch_reg &= ~(MICROBLAZE_MSR_IE); \
 _microblaze_switch_reg |= _microblaze_interrupt_enable; \
 _CPU_MSR_SET(_microblaze_switch_reg); \
   }
@@ -232,7 +232,7 @@ typedef struct {
   { \
 unsigned int _new_msr;  \
 _CPU_MSR_SET(_isr_cookie); \
-_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE); \
+_new_msr = (_isr_cookie) & ~(MICROBLAZE_MSR_IE); \
 _CPU_MSR_SET(_new_msr); \
   }
 
@@ -242,7 +242,7 @@ uint32_t _CPU_ISR_Get_level( void );
 
 RTEMS_INLINE_ROUTINE bool _CPU_ISR_Is_enabled( uint32_t level )
 {
-  return ( level & (MICROBLAZE_MSR_IE | MICROBLAZE_MSR_EE) ) != 0;
+  return ( level & MICROBLAZE_MSR_IE ) != 0;
 }
 
 void _CPU_Context_Initialize(
-- 
2.30.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 5/6] cpukit/microblaze: Create interrupt flag

2022-02-18 Thread Kinsey Moore 
The MicroBlaze Machine Status Register (MSR) does not have a flag that
designates the current execution status of the interrupt handler other
than the Interrupt Enable (IE) bit which may be unset for other reasons.
This makes use of R13 to signal the current interrupt nesting
encompassing the entirety of interrupt execution versus the more limited
scope of ISR_NEST_LEVEL. R13 would typically be used as a TLS data
pointer, but is currently unused by RTEMS. This interrupt flag is
necessary for a pure software break libdebugger backend implementation
since interrupt execution status must be known during thread dispatch.
---
 cpukit/score/cpu/microblaze/cpu_asm.S | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/cpukit/score/cpu/microblaze/cpu_asm.S 
b/cpukit/score/cpu/microblaze/cpu_asm.S
index 6bd81eedd9..5bb1a944b0 100644
--- a/cpukit/score/cpu/microblaze/cpu_asm.S
+++ b/cpukit/score/cpu/microblaze/cpu_asm.S
@@ -41,6 +41,17 @@
.align 2
 
 _ISR_Handler:
+   /*
+* Increment interrupt context flag. This TLS register is coopted for
+* this purpose since it is not used by RTEMS. R2 would suffice as well,
+* but would need to be added to Context_Control. This is used by
+* libdebugger since ISR_NEST_LEVEL is not sufficient to indicate
+* execution in interrupt context after the stack is switched back for
+* thread dispatch. There is no MSR bit to indicate Interrupt in
+* Progress.
+*/
+   addik r13, r13, 1
+
/* Save stack frame */
swi  r3, r1, MICROBLAZE_INTERRUPT_FRAME_R3
swi  r4, r1, MICROBLAZE_INTERRUPT_FRAME_R4
@@ -153,5 +164,8 @@ quick_exit:
/* Remove stack frame */
addik r1, r1, CPU_INTERRUPT_FRAME_SIZE
 
+   /* Decrement interrupt context flag */
+   addik r13, r13, -1
+
rtid r14, 0
nop
-- 
2.30.2

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2 6/6] cpukit/libdebugger: Add MicroBlaze support

2022-02-18 Thread Kinsey Moore 
Add MicroBlaze support for libdebugger. This uses only software break
type instructions to provide self-hosted GDB debugging support for
applications since internal control of debug hardware is not possible.

Also of note, this implementation for MicroBlaze would typically use the
brki instruction for software break, but instead uses an illegal opcode
to manage software breaks as exceptions. This is due to poor interaction
with the debug hardware where the debug hardware will intercept software
breaks instead of allowing the software break vector to execute.
---
 .../libdebugger/rtems-debugger-microblaze.c   | 1462 +
 .../cpu/microblaze/include/rtems/score/cpu.h  |   24 +
 spec/build/cpukit/libdebugger.yml |2 +
 spec/build/cpukit/objdbgmicroblaze.yml|   15 +
 spec/build/cpukit/optlibdebugger.yml  |1 +
 5 files changed, 1504 insertions(+)
 create mode 100644 cpukit/libdebugger/rtems-debugger-microblaze.c
 create mode 100644 spec/build/cpukit/objdbgmicroblaze.yml

diff --git a/cpukit/libdebugger/rtems-debugger-microblaze.c 
b/cpukit/libdebugger/rtems-debugger-microblaze.c
new file mode 100644
index 00..13b43b287b
--- /dev/null
+++ b/cpukit/libdebugger/rtems-debugger-microblaze.c
@@ -0,0 +1,1462 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSLibdebugger
+ *
+ * @brief MicroBlaze libdebugger implementation
+ */
+
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#define TARGET_DEBUG 0
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+/* Defined by linkcmds.base */
+extern char bsp_section_text_begin[];
+extern char bsp_section_text_end[];
+extern char bsp_section_fast_text_begin[];
+extern char bsp_section_fast_text_end[];
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "rtems-debugger-target.h"
+#include "rtems-debugger-threads.h"
+
+#if TARGET_DEBUG
+#include 
+#endif
+
+/*
+ * Number of registers.
+ */
+#define RTEMS_DEBUGGER_NUMREGS 57
+
+/*
+ * Number of bytes per type of register.
+ */
+#define RTEMS_DEBUGGER_REG_BYTES4
+
+/* Debugger registers layout. See microblaze-core.xml in GDB source. */
+#define REG_R00
+#define REG_R11
+#define REG_R22
+#define REG_R33
+#define REG_R44
+#define REG_R55
+#define REG_R66
+#define REG_R77
+#define REG_R88
+#define REG_R99
+#define REG_R10   10
+#define REG_R11   11
+#define REG_R12   12
+#define REG_R13   13
+#define REG_R14   14
+#define REG_R15   15
+#define REG_R16   16
+#define REG_R17   17
+#define REG_R18   18
+#define REG_R19   19
+#define REG_R20   20
+#define REG_R21   21
+#define REG_R22   22
+#define REG_R23   23
+#define REG_R24   24
+#define REG_R25   25
+#define REG_R26   26
+#define REG_R27   27
+#define REG_R28   28
+#define REG_R29   29
+#define REG_R30   30
+#define REG_R31   31
+#define REG_PC32
+#define REG_MS33
+#define REG_EA34
+#define REG_ES35
+#define REG_FS36
+#define REG_BT37
+#define REG_PV0   38
+#define REG_PV1   39
+#define REG_PV2   40
+#define REG_PV3   41
+#define REG_PV4   42
+#define REG_PV5   43
+#define REG_PV6   44
+#define REG_PV7   45
+#define REG_PV8   46
+#define REG_PV9   47
+#define REG_PV10  48
+#define REG_PV11  49
+#define REG_ED50
+#define REG_PID   51
+#define REG_ZP52
+#define REG_TBLX  53
+#define REG_TBLSX 54
+#define REG_TBLLO 55
+#define REG_TBLHI 56
+
+/**
+ * Register offset table with the total as the last entry.
+ *
+ * Check this table in gdb with the command:
+ *
+ *   maint print registers
+ */
+static const size_t microblaze_reg_offsets[

Re: config, _IO_Initialize_all_drivers

2022-02-18 Thread Heinz Junkes 



> On 18. Feb 2022, at 17:47, Joel Sherrill  wrote:
> 
> 
> "Normally" the driver initialization entry registers names.

Unfortunately, I cannot confirm that. I don't see any registrations 
(rtems_io_register_driver()) of the drivers.

Only rtems_io_initialize() major 0 - > (in my case) 39 is called.

Heinz

  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 3/5] cpukit/microblaze: Add interrupt hooks

2022-02-18 Thread Gedare Bloom 
On Fri, Feb 18, 2022 at 6:50 AM Kinsey Moore  wrote:
>
>
> On 2/17/2022 20:31, Chris Johns wrote:
> > On 18/2/22 8:58 am, Kinsey Moore wrote:
> >> On 2/17/2022 15:31, Chris Johns wrote:
> >>> On 18/2/22 7:12 am, Kinsey Moore wrote:
>  On 2/17/2022 13:53, Chris Johns wrote:
> > Who is setting breaks points in interrupts?
>  Where I encountered issues was setting breaks in library functions that 
>  I was
>  stepping through in non-interrupt context, particularly in memset(). ISR
>  handlers can also call into this library code and libdebugger bails when
>  application debugging intersects with ISR handler execution.
> >>> Interesting use case. Does this effect all archs? I think it does.
> >> It does to an extent. Stepping through with inverse breakpoints on ARM and
> >> single-step mode on AArch64 wouldn't encounter this issue, but software
> >> breakpoints placed in those shared functions would cause the same problems 
> >> I'm
> >> seeing on MicroBlaze. ARM may not see this issue at all if it makes 
> >> hardware
> >> breakpoints available, but I don't remember whether it does.
> > Hmm .. the GDB solution is to place the instruction back and step then 
> > return
> > the break point. I am not sure if this is possible and less intrusive to 
> > the system?
> >
> > Does this solution means the interrupts have extra overheads?
> In the nominal case (libdebugger not running), the overhead is less than
> 30 instructions per interrupt execution which could theoretically be
> optimized a bit by integrating the handler dispatch into the ISR_Handler
> assembly instead of having it be a stand-alone C function. In the case
> where libdebugger is running, the overhead is the nominal overhead plus
> O(n) on the number of software breakpoints installed. If I had to hazard
> a guess on the incremental number of instructions per software break,
> I'd put it at 50 or so on top of the overhead of the call chain to get
> there.
>
> Kinsey

I think this will be undesirable in production. Can we find a way to
make it conditional compilation?

>
> ___
> 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: [PATCH v1 3/5] cpukit/microblaze: Add interrupt hooks

2022-02-18 Thread Kinsey Moore 

On 2/18/2022 14:37, Gedare Bloom wrote:

On Fri, Feb 18, 2022 at 6:50 AM Kinsey Moore  wrote:

On 2/17/2022 20:31, Chris Johns wrote:

On 18/2/22 8:58 am, Kinsey Moore wrote:

On 2/17/2022 15:31, Chris Johns wrote:

On 18/2/22 7:12 am, Kinsey Moore wrote:

On 2/17/2022 13:53, Chris Johns wrote:

Who is setting breaks points in interrupts?

Where I encountered issues was setting breaks in library functions that I was
stepping through in non-interrupt context, particularly in memset(). ISR
handlers can also call into this library code and libdebugger bails when
application debugging intersects with ISR handler execution.

Interesting use case. Does this effect all archs? I think it does.

It does to an extent. Stepping through with inverse breakpoints on ARM and
single-step mode on AArch64 wouldn't encounter this issue, but software
breakpoints placed in those shared functions would cause the same problems I'm
seeing on MicroBlaze. ARM may not see this issue at all if it makes hardware
breakpoints available, but I don't remember whether it does.

Hmm .. the GDB solution is to place the instruction back and step then return
the break point. I am not sure if this is possible and less intrusive to the 
system?

Does this solution means the interrupts have extra overheads?

In the nominal case (libdebugger not running), the overhead is less than
30 instructions per interrupt execution which could theoretically be
optimized a bit by integrating the handler dispatch into the ISR_Handler
assembly instead of having it be a stand-alone C function. In the case
where libdebugger is running, the overhead is the nominal overhead plus
O(n) on the number of software breakpoints installed. If I had to hazard
a guess on the incremental number of instructions per software break,
I'd put it at 50 or so on top of the overhead of the call chain to get
there.

Kinsey

I think this will be undesirable in production. Can we find a way to
make it conditional compilation?
As mentioned in the RTEMS discord, I'm going to pursue elimination of 
the interrupt hooks in favor of a slight change to the behavior of 
libdebugger on software break in interrupt context that should solve 
similar issues across all libdebugger backends that use software breaks 
in any capacity.


Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] added malloc usable size and test

2022-02-18 Thread Gedare Bloom 
On Thu, Feb 17, 2022 at 8:14 PM zack leung  wrote:
>
> ---
>  cpukit/include/rtems/libcsupport.h|  5 ++-
>  cpukit/libcsupport/src/mallocusablesize.c | 47 +++
>  spec/build/cpukit/librtemscpu.yml |  1 +
>  testsuites/libtests/malloctest/init.c | 13 +++
>  4 files changed, 65 insertions(+), 1 deletion(-)
>  create mode 100644 cpukit/libcsupport/src/mallocusablesize.c
>
> diff --git a/cpukit/include/rtems/libcsupport.h 
> b/cpukit/include/rtems/libcsupport.h
> index f4be4cfc9a..5609c5bb94 100644
> --- a/cpukit/include/rtems/libcsupport.h
> +++ b/cpukit/include/rtems/libcsupport.h
> @@ -73,7 +73,10 @@ extern size_t malloc_free_space(void);
>   * Find amount of free heap remaining.
>   */
>  extern int malloc_info(Heap_Information_block *the_info);
> -
Keep the blank line

> +/**
> + * @brief Find the usable size of the block of memory .
Still a space before the period

> + */
> +extern size_t malloc_usable_size(void *ptr);
add a space

>  /*
>   *  Prototypes required to install newlib reentrancy user extension
>   */
> diff --git a/cpukit/libcsupport/src/mallocusablesize.c 
> b/cpukit/libcsupport/src/mallocusablesize.c
> new file mode 100644
> index 00..8a8d6467ad
> --- /dev/null
> +++ b/cpukit/libcsupport/src/mallocusablesize.c
> @@ -0,0 +1,47 @@
> +/*
> + * SPDX-License-Identifier: BSD-2-Clause
> + *
> + * Copyright (C) ,  
fill in the template

> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +size_t malloc_usable_size(void *ptr) {
> +  Heap_Control *heap_ptr ;
> +  size_t size;
> +  if (ptr == NULL) {
> +return 0;
> +  }
> +
> +  heap_ptr = malloc_get_heap_pointer();
> +  _Heap_Size_of_alloc_area(heap_ptr, ptr, &size);
check return value

> +
> +  return size;
> +}
> diff --git a/spec/build/cpukit/librtemscpu.yml 
> b/spec/build/cpukit/librtemscpu.yml
> index 7d6dbae0db..5902008c94 100644
> --- a/spec/build/cpukit/librtemscpu.yml
> +++ b/spec/build/cpukit/librtemscpu.yml
> @@ -670,6 +670,7 @@ source:
>  - cpukit/libcsupport/src/lseek.c
>  - cpukit/libcsupport/src/lstat.c
>  - cpukit/libcsupport/src/malloc.c
> +- cpukit/libcsupport/src/mallocusablesize.c
>  - cpukit/libcsupport/src/malloc_deferred.c
>  - cpukit/libcsupport/src/malloc_dirtier.c
>  - cpukit/libcsupport/src/malloc_walk.c
> diff --git a/testsuites/libtests/malloctest/init.c 
> b/testsuites/libtests/malloctest/init.c
> index a33764177d..ee6a670372 100644
> --- a/testsuites/libtests/malloctest/init.c
> +++ b/testsuites/libtests/malloctest/init.c
> @@ -1362,6 +1362,18 @@ static void test_alloc_zero_size(void)
>rtems_test_assert( p == NULL );
>rtems_test_assert( errno == -1 );
>  }
> +static void test_usablesize(void)
> +{
> +  int * a = malloc(sizeof( int )*100);
> +  int alloc_size=sizeof( int ) *100 ;
> +  rtems_test_assert(  malloc_usable_size(a) <= alloc_size + 
> CPU_HEAP_ALIGNMENT);
> +  free(a);
> +
> +  char * b = malloc(sizeof(char)*100);
> +  int alloc_size2=sizeof(char) *100 ;
> +  rtems_test_assert( malloc_usable_size ( b ) <= alloc_size2 + 
> CPU_HEAP_ALIGNMENT);
> +  free(b);
> +}
>
>  rtems_task Init(
>rtems_task_argument argument
> @@ -1405,6 +1417,7 @@ rtems_task Init(
>test_protected_heap_info();
>test_rtems_heap_allocate_aligned_with_boundary();
>test_rtems_malloc();
> +  test_usablesize();
>test_rtems_calloc();
>test_greedy_allocate();
>test_alloc_zero_size();
> --
> 2.35.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___