On Sat, Jan 1, 2022, 4:02 PM Петр Борисенко <pe...@awsmtek.com> wrote:
> Ok I see. > The master branch is a bit ahead of my local one. > And I really don't know what to think about these conflicts: > If this is applying a patch for an older version of RTEMS to the master, the build system has changed ``` > # Conflicts: > # bsps/arm/stm32f4/headers.am > Part of the old build system > > # bsps/arm/stm32f4/include/bsp/irq.h > Will have to be resolved. # bsps/arm/stm32f4/start/bsp_specs > Gone now. # c/src/lib/libbsp/arm/stm32f4/Makefile.am > Old build system. > ``` > Has `arm/stm32f4` been eliminated from the main source tree? > It is still there. Under bsps/arm. The changes to those.filea may have to be translated to the current master. Andrei will be more familiar. I answering from my phone. > Best regards. > Peter Borisenko > Awesome Technologies, Ltd. > http://awsmtek.com > hardw...@awsmtek.com > +79062165482 > > > On Sun, Jan 2, 2022 at 12:13 AM <gro...@chichak.ca> wrote: > >> I reported this, Set fixed it, and the report was closed. >> >> Either someone said “multilib, multilib, multilib” and it came back, >> Peter needs to do a pull, or something has reverted. >> >> https://devel.rtems.org/ticket/4504 >> >> A >> >> On 2022-January-01, at 13:56, Петр Борисенко <pe...@awsmtek.com> wrote: >> >> I didn't print anything explisitly. >> Here is call stack: >> ``` >> Thread #1 (Suspended : Signal : SIGINT:Interrupt) >> output_char() at console-config.c:104 0x8007132 >> rtems_putc() at rtems_putc.c:31 0x800f038 >> _IO_Vprintf() at iovprintf.c:133 0x800b8b4 >> vprintk() at vprintk.c:31 0x8009aa0 >> printk() at printk.c:40 0x800794e >> bsp_fatal_extension() at bspfatal-default.c:26 0x8006ea2 >> _User_extensions_Iterate() at userextiterate.c:181 0x800e686 >> _User_extensions_Fatal() at userextimpl.h:446 0x800b856 >> _Terminate() at interr.c:38 0x800b856 >> rtems_fatal() at fatal.h:158 0x80103a6 >> _ARM_Exception_default() at arm-exception-default.c:24 0x80103a6 >> <signal handler called>() at 0xfffffff9 >> 0x0 >> ``` >> >> Best regards. >> Peter Borisenko >> Awesome Technologies, Ltd. >> http://awsmtek.com >> hardw...@awsmtek.com >> +79062165482 >> >> >> On Sat, Jan 1, 2022 at 7:09 PM Joel Sherrill <j...@rtems.org> wrote: >> >>> Assuming it is compiled correctly, printing this early should be via >>> printk(). >>> >>> Can you attach gdb and just walk through the BSP initialisation? >>> >>> --joel >>> >>> On Sat, Jan 1, 2022, 2:08 AM <gro...@chichak.ca> wrote: >>> >>> > (sorry, I accidentally sent this to the dev list instead of users. too >>> > much cheer) >>> > >>> > It’s bombing in printf. It’s so early that the stack hasn’t been set up >>> > yet, and it’s found an error and it’s trying to poot a message out on >>> the >>> > console, which is also not set up yet. >>> > >>> > Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in >>> > RTEMS4.11, and a version in RTEMS5) >>> > >>> > I had problems with that BSP blowing up just like this because >>> portions of >>> > it weren’t compiled with the proper instruction set, and when the >>> startup >>> > code called memset (I think), it would call memset in newlib/libc that >>> was >>> > compiled for the wrong architecture, do the wrong thing, end up in >>> printf >>> > and die a horrible death. >>> > >>> > Let’s see if I can find the thread on Discord… >>> > >>> > around August 19/2021 >>> > >>> > run: >>> > >>> > rtems-exeinfo -O blah.exe >>> > >>> > and make sure that all of the functions have the same architecture >>> > specified. Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which >>> are >>> > incompatible. >>> > >>> > >>> > >>> > Andrei Chichak >>> > (from The Great White North) >>> > >>> > >>> > > On 2021-December-31, at 18:48, Петр Борисенко <pe...@awsmtek.com> >>> wrote: >>> > > >>> > > Hello and Happy new year! >>> > > I am getting an error during startup: >>> > > RTEMS_FATAL_SOURCE_EXCEPTION >>> > > Catching it in _ARM_Exception_default. >>> > > The bsp is `arm/stm32f4`. >>> > > Here is contains of CPU_Exception_frame: >>> > > register_r0 uint32_t 0x80139bc >>> > > register_r1 uint32_t 0 >>> > > register_r2 uint32_t 0 >>> > > register_r3 uint32_t 76 >>> > > register_r4 uint32_t 0 >>> > > register_r5 uint32_t 0 >>> > > register_r6 uint32_t 0 >>> > > register_r7 uint32_t 0 >>> > > register_r8 uint32_t 0 >>> > > register_r9 uint32_t 0 >>> > > register_r10 uint32_t 0 >>> > > register_r11 uint32_t 0 >>> > > register_r12 uint32_t 0 >>> > > register_sp uint32_t 536909088 >>> > > register_lr void * 0x80001c3 <bsp_start_hook_0_done+4> >>> > > register_pc void * 0x8013f08 <_svfprintf_r+8152> >>> > > register_xpsr uint32_t 16777216 >>> > > vector uint32_t 3 >>> > > vfp_context const ARM_VFP_context * 0x0 >>> > > reserved_for_stack_alignment uint32_t 3522771716 >>> > > &Console_Port_Minor rtems_device_minor_number * 0x20006988 >>> > > <Console_Port_Minor> >>> > > *&Console_Port_Minor rtems_device_minor_number 1363452156 >>> > > >>> > > What could it be? Any common reasons? Or what additional info should >>> I >>> > > provide? >>> > > >>> > > Also it would be really appreciated if someone will help me >>> export/build >>> > > bsp as a debuggable source tree. >>> > > >>> > > Best regards. >>> > > Peter Borisenko >>> > > Awesome Technologies, Ltd. >>> > > http://awsmtek.com >>> > > hardw...@awsmtek.com >>> > > +79062165482 >>> > > _______________________________________________ >>> > > users mailing list >>> > > users@rtems.org >>> > > http://lists.rtems.org/mailman/listinfo/users >>> > >>> > _______________________________________________ >>> > devel mailing list >>> > de...@rtems.org >>> > http://lists.rtems.org/mailman/listinfo/devel >>> > _______________________________________________ >>> > 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
