Re: bsp/riscv: Store/AMO address misaligned trap occured

[Padmarao.Begari]

Hi Sebastian,

> On Fri, 2022-11-04 at 14:03 +0100, Sebastian Huber wrote:
> On 04/11/2022 10:49, Sebastian Huber wrote:
> > On 04/11/2022 10:44, padmarao.beg...@microchip.com wrote:
> > > Hi Sebastian,
> > > 
> > > > On Fri, 2022-11-04 at 08:07 +0100, Sebastian Huber wrote:
> > > > 
> > > > On 03/11/2022 06:40,padmarao.beg...@microchip.com  wrote:
> > > > > > On Wed, 2022-11-02 at 09:58 -0600, Gedare Bloom wrote:
> > > > > > 
> > > > > > t0 contains the address of .Lsecondary_processor_go
> > > > > > 
> > > > > > start.S has:
> > > > > > ```asm
> > > > > > #if __riscv_xlen == 32
> > > > > > .align  2
> > > > > > #elif __riscv_xlen == 64
> > > > > > .align  3
> > > > > > #endif
> > > > > > 
> > > > > > .Lsecondary_processor_go:
> > > > > > ```
> > > > > > Can you confirm the value of __riscv_xlen is properly
> > > > > > defined to
> > > > > > 64
> > > > > > for the PolarFire?
> > > > > > 
> > > > > No, the value of __riscv_xlen is showing 32(config.log)
> > > > > instead of
> > > > > 64
> > > > > for PolarFire SoC and other 64-bit RISCV BSPs.
> > > > This is a compiler built-in define.  It doesn't matter what is
> > > > in the
> > > > config.log. What matters is that the compiler is invoked with
> > > > the
> > > > right
> > > > options. In my build this looks all right.
> > > > 
> > > > What is the value of t0 in
> > > > 
> > > > amoswap.w zero, zero, 0(t0)
> > > > 
> > > > ?
> > > > 
> > > The "t0" value is 0x1000ae
> > 
> > Ok, is this the address of .Lsecondary_processor_go?
> > 
> > It is a value > 4GiB. I am not sure how such a value is loaded
> > through
> > la or lla.
> 
> It seems that the .align directive is broken in the assembler. I
> checked
> in b4ffaa7cdcce4fedb857f6b8342301f8dde65c78 as a workaround. Could
> you
> please test this commit?
> 

I have tested it and working fine.

Regards
Padmarao
> --
> 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: Apple's Ventura OS issue with RSB.

[Karel Gardas]

On 11/6/22 22:42, Chris Johns wrote:

indeed, the report here is probably minimal thing I should do.


Sebastian has pushed updates to the tools to the RSB. Did you happen to pick up
those?


Not at all! I'm still on:

https://git.rtems.org/rtems-source-builder/commit/?id=b02f7788e8bec38bbab9c57f65802e473d492a9c

Exactly the code working on Monterey.

Karel

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

Re: Apple's Ventura OS issue with RSB.

[Chris Johns]

On 7/11/2022 5:38 am, Karel Gardas wrote:
> 
> Side note before answering : the email was motivated by the fact that I 
> provided
> few patches to RSB to make that working well on Monterey running on M1. This 
> was
> just few weeks ago so I know, this was running well. Last week I've updated to
> Ventura and things felt apart. Hence the report here.
> 
> On 11/6/22 16:09, Joel Sherrill wrote:
>> Is the cross gcc compiled with the native compiler provided by Apple? 
> 
> Yes, it is.
> 
>> The alternative would likely be you installing something special.
> 
> No, I keep OS as clean as possible and as stock as possible to be as close as
> possible to customer configuration.
> 
>> I wonder if using gcc to compile it would work. But there's not a real 
>> solution.
> 
> Indeed, I'll see if I can do anything about that as that would also be usable
> for...
> 
>>
>> Seems like an issue which needs reporting to gcc.
>>
> 
> indeed, the report here is probably minimal thing I should do.

Sebastian has pushed updates to the tools to the RSB. Did you happen to pick up
those?

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

Re: Apple's Ventura OS issue with RSB.

[Karel Gardas]

Side note before answering : the email was motivated by the fact that I 
provided few patches to RSB to make that working well on Monterey 
running on M1. This was just few weeks ago so I know, this was running 
well. Last week I've updated to Ventura and things felt apart. Hence the 
report here.


On 11/6/22 16:09, Joel Sherrill wrote:
Is the cross gcc compiled with the native compiler provided by Apple? 


Yes, it is.


The alternative would likely be you installing something special.


No, I keep OS as clean as possible and as stock as possible to be as 
close as possible to customer configuration.


I wonder if using gcc to compile it would work. But there's not a real 
solution.


Indeed, I'll see if I can do anything about that as that would also be 
usable for...




Seems like an issue which needs reporting to gcc.



indeed, the report here is probably minimal thing I should do.

Thanks,
Karel

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

Re: Apple's Ventura OS issue with RSB.

[Joel Sherrill]

Is the cross gcc compiled with the native compiler provided by Apple? The
alternative would likely be you installing something special.

I wonder if using gcc to compile it would work. But there's not a real
solution.

Seems like an issue which needs reporting to gcc.

On Sun, Nov 6, 2022, 5:25 AM Karel Gardas  wrote:

>
>   Folks,
>
> upgraded to Ventura from Monterey and this breaks RSB for unknown
> reason. The issue looks like segfault/internal compiler error in GCC
> while compiling newlib.
>
> 6/rtems-sparc:
>
>CC   libc/stdlib/libc_a-strtoll_r.o
>CC   libm/complex/libm_a-cpowf.o
> ../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c: In
> function 'cexpf':
> ../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c:47:9:
> internal compiler error: Segmentation fault: 11
> 47 | w = r * cosf(y) + r * sinf(y) * I;
>| ^
> libbacktrace could not find executable to open
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> See  for instructions.
> make[6]: *** [libm/complex/libm_a-cexpf.o] Error 1
> make[6]: *** Waiting for unfinished jobs
>CC   libc/stdlib/libc_a-strtoull_r.o
>CC   libc/stdlib/libc_a-wcstoll.o
>CC   libc/stdlib/libc_a-wcstoll_r.o
>CC   libc/stdlib/libc_a-wcstoull.o
>CC   libc/stdlib/libc_a-wcstoull_r.o
>CC   libc/stdlib/libc_a-atoll.o
> make[5]: *** [all] Error 2
> make[4]: *** [multi-do] Error 1
> make[3]: *** [all-multi] Error 2
> make[3]: *** Waiting for unfinished jobs
>
>
>
> 6/rtems-arm:
>
>CC   libm/common/libm_a-s_isinf.o
>CC   libm/common/libm_a-s_isinfd.o
> ../../../../../../gnu-mirror-gcc-a5a6598/newlib/libm/common/s_expm1.c:
> In function 'expm1':
>CC   libm/common/libm_a-s_isnan.o
> ../../../../../../gnu-mirror-gcc-a5a6598/newlib/libm/common/s_expm1.c:225:9:
>
> internal compiler error: in real_from_string, at real.cc:2131
>225 | hfx = 0.5*x;
>| ^~~
>CC   libm/common/libm_a-s_isnand.o
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> See  for instructions.
> make[6]: *** [libm/common/libm_a-s_expm1.o] Error 1
> make[6]: *** Waiting for unfinished jobs
>CC   libm/common/libm_a-s_log1p.o
> make[5]: *** [all] Error 2
> make[4]: *** [multi-do] Error 1
> make[3]: *** [all-multi] Error 2
> make[2]: *** [all] Error 2
> make[1]: *** [all-target-newlib] Error 2
> make: *** [all] Error 2
> shell cmd failed: /bin/sh -ex
> /Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gcc-a5a6598
>
>
> So just HEADS UP to those using Mac OS X on Apple silicon!
>
> Karel
>
> ___
> 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: Microblaze 2nd timer interrupt

[Alan Cudmore]

Hi Sam,You need to add the timer.h file to the list of files to be installed:https://git.rtems.org/rtems/tree/spec/build/bsps/microblaze/microblaze_fpga/obj.yml#n14Alan From: Sam PriceSent: Sunday, November 6, 2022 12:52 AMTo: DevelopmentSubject: Re: Microblaze 2nd timer interrupt I pushed my changes to rtems sourcehttps://github.com/RTEMS/rtems/compare/master...thesamprice:rtems:timer_debug and setup a hello world an example project to test withhttps://github.com/thesamprice/rtems_mb_timer/blob/main/hello.c However im getting the following error.rtems_mb_timer/hello.c:8:10: fatal error: bsp/timer.h: No such file or directory    8 | #include   |  ^ Is the correct approach to just put all bsp specific calls in bsp.h?  On Sat, Nov 5, 2022 at 10:04 PM Sam Price  wrote:> > The current microblaze design only has a single timer.> > I want to use the 2nd timer on the microblaze to run some low level tasks.> > Wondering if someone could see if i'm on the right track.> > > Regarding the timer from the Xilinx api api> > """The interrupt service routine reads the timer control/status> registers to determine the source of the interrupt."""> > Also there is a interrupt controller on microblaze that has a single> jump register.> > > So the underlying logic is interrupt occurs, 32bit interrupt register> is checked for what bits are set determining what interrupts have> occured.> > > if bit 0 is set then it is a clock interrupt.> > > Then 2 clock register need checked for what timer caused the interrupt.> > > Current RTEMS implementation only uses 1 of the timers.> > > > > > I added static ISR callbacks for the system and user callback at the> top of the mb clock.c file.> > static rtems_interrupt_handler mblaze_clock_isr = 0x0;> > static rtems_interrupt_handler mblaze_user_isr = 0x0;> > > > I added a callback that checks both registers and calls the> appropriate callback.> > > > static void microblaze_clock_handler( void * data){> >   volatile Microblaze_Timer *timer = _Microblaze_Timer;> >   if ( ( timer->tcsr0 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )> >   {> > if(mblaze_clock_isr != 0x0){> >   mblaze_clock_isr(data);> > }> >   }> >   if ( ( timer->tcsr1 & MICROBLAZE_TIMER_TCSR0_T0INT ) == 0 )> >   {> > if(mblaze_user_isr != 0x0){> >   mblaze_user_isr(data);> >   /* Clear the interrupt */> >   timer->tcsr1 |= MICROBLAZE_TIMER_TCSR0_T0INT;> > }> >   }> > }> > > > > > I updated the ISR register to store the system clock, and replace the> isr callback with mine.> > > > static void microblaze_clock_handler_install( rtems_interrupt_handler isr )> > {> >   rtems_status_code sc = RTEMS_SUCCESSFUL;> >   mblaze_clock_isr = isr; <- Store the system ISR> >   sc = rtems_interrupt_handler_install(> > 0,> > "Clock",> > RTEMS_INTERRUPT_UNIQUE,> > microblaze_clock_handler, <- Changed from ISR to my new handler.> > NULL> >   );> > > >   if ( sc != RTEMS_SUCCESSFUL ) {> > bsp_fatal( MICROBLAZE_FATAL_CLOCK_IRQ_INSTALL );> >   }> > }> > > > To the microblaze bsp.h> > > im adding my callback functions to register the users clock function.> > void microblaze_user_clock_handler_install(rtems_interrupt_handler isr);> > > And the appropriate non static function to the mb clock.c file> > void microblaze_user_clock_handler_install(rtems_interrupt_handler isr){> mblaze_user_isr = isr;> }> > Anyhow about to compile and see if it works.   -- Sincerely, Sam Price___devel mailing listdevel@rtems.orghttp://lists.rtems.org/mailman/listinfo/devel 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Apple's Ventura OS issue with RSB.

[Karel Gardas]

 Folks,

upgraded to Ventura from Monterey and this breaks RSB for unknown 
reason. The issue looks like segfault/internal compiler error in GCC 
while compiling newlib.


6/rtems-sparc:

  CC   libc/stdlib/libc_a-strtoll_r.o
  CC   libm/complex/libm_a-cpowf.o
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c: In 
function 'cexpf':
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c:47:9: 
internal compiler error: Segmentation fault: 11

   47 | w = r * cosf(y) + r * sinf(y) * I;
  | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

See  for instructions.
make[6]: *** [libm/complex/libm_a-cexpf.o] Error 1
make[6]: *** Waiting for unfinished jobs
  CC   libc/stdlib/libc_a-strtoull_r.o
  CC   libc/stdlib/libc_a-wcstoll.o
  CC   libc/stdlib/libc_a-wcstoll_r.o
  CC   libc/stdlib/libc_a-wcstoull.o
  CC   libc/stdlib/libc_a-wcstoull_r.o
  CC   libc/stdlib/libc_a-atoll.o
make[5]: *** [all] Error 2
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[3]: *** Waiting for unfinished jobs



6/rtems-arm:

  CC   libm/common/libm_a-s_isinf.o
  CC   libm/common/libm_a-s_isinfd.o
../../../../../../gnu-mirror-gcc-a5a6598/newlib/libm/common/s_expm1.c: 
In function 'expm1':

  CC   libm/common/libm_a-s_isnan.o
../../../../../../gnu-mirror-gcc-a5a6598/newlib/libm/common/s_expm1.c:225:9: 
internal compiler error: in real_from_string, at real.cc:2131

  225 | hfx = 0.5*x;
  | ^~~
  CC   libm/common/libm_a-s_isnand.o
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

See  for instructions.
make[6]: *** [libm/common/libm_a-s_expm1.o] Error 1
make[6]: *** Waiting for unfinished jobs
  CC   libm/common/libm_a-s_log1p.o
make[5]: *** [all] Error 2
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all] Error 2
make[1]: *** [all-target-newlib] Error 2
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex 
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gcc-a5a6598



So just HEADS UP to those using Mac OS X on Apple silicon!

Karel

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