Hi Christian, thanks a lot, changing the timer node path to /soc/timer in the bspstart.c did the trick! Finally I have a (basic) working build setup. Yes, I am running the RTEMS 5.1 release. And that's odd, because I definitely always built it like you described (--with-rtems-smp), but the ./waf configure output always showed me, that SMP was not enabled. But now I rebuilt my complete toolchain and it works. Now I can finally go on and actually work on a SMP application.
Kind regards, Stefan On Feb 19 2021, at 9:53 pm, Christian Mauderer <[email protected]> wrote: > Hello Stefan, > > On 19/02/2021 21:29, Stefan Akatyschew wrote: > > Yeah, there was no timer entry in the FDT, hence I created it (only > > filled with clock-frequency) manually. I forgot to attach the fdt list > > output before my changes in my last mail: > > No timer entry doesn't sound right. Normally the timer entry should > exist like here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx7s.dtsi#n152 > It seems that phytec decided to move it to soc/timer at least in some FDTs: > https://stash.phytec.com/projects/PUB/repos/linux-phytec-fsl/browse/arch/arm/boot/dts/imx7s.dtsi?at=BSP-Yocto-FSL-iMX7-PD18.2.0#366 > If that is the case for you, you might have to create a patch for > bsps/arm/imx/start/bspstart.c. Basically you would have to change the > search for the timer node from: > > ```` > node = fdt_path_offset(fdt, "/timer"); > ```` > > to > ```` > node = fdt_path_offset(fdt, "/timer"); > if (node < 0) { > node = fdt_path_offset(fdt, "/soc/timer"); > } > ```` > > or alternatively search for a "compatible" node. > > > > Regarding WAF and SMP: I can't follow unfortunately, I only ran "./waf > > configure --rtems=..." and saw the missing SMP output there. > > Sorry, I might have asked that already: Which version of RTEMS do you use? > If it is the 5 release, you should have a something like like > ./configure --target=arm-rtems5 \ > --prefix=${PREFIX} \ > --enable-posix \ > --enable-rtemsbsp=imx \ > --disable-networking \ > --with-rtems-smp > make > > or similar to build your BSP. For the current master with the waf based > build system, you will have calls like > > ./waf bsp_defaults --rtems-bsps=arm/imx > config.ini > # edit config.ini to fit your needs - for example ENABLE_RTEMS_SMP > ./waf configure --prefix=${PREFIX} > ./waf > > Best regards > Christian > > > > Kind regards, > > Stefan > > On Feb 18 2021, at 9:52 pm, Christian Mauderer <[email protected]> wrote: > > > > On 18/02/2021 21:03, Stefan Akatyschew wrote: > > > Hello Christian, > > > I'm very grateful for the script, it seems to work with the load > > adress > > > 0x80800000 and I don't get the previously described error. Thank you! > > > Unfortunately though I got the Fatal error 3072, as described here: > > > https://www.mail-archive.com/[email protected]/msg02837.html > > > <https://www.mail-archive.com/[email protected]/msg02837.html> > > > But could "resolve" that, by setting up /timer/clock-frequency in > > the ftd: > > > run loadfdt > > > run loadimage > > > fdt addr 0x83000000 > > > fdt resize > > > fdt mknode / timer > > > fdt set /time clock-frequency <0x007a1200> > > > bootz ${loadaddr} - ${fdt_addr} > > > > That's odd. Normally U-Boot should already add that. Only barebox didn't > > seem to add it on the i.MX6UL/ULL. But barebox also didn't initialize > > the timer. So if the clock-frequency is missing, you might need a bit > > more than just adding the field. It is possible that U-Boot then also > > doesn't call the timer_init: > > > > https://gitlab.denx.de/u-boot/u-boot/-/blob/2dddc1bb296308/arch/arm/mach-imx/syscounter.c#L63 > > > > Maybe only certain U-Boots did call that and add the clock-frequency? I > > can't say fur sure which version has been used on the i.mx7 boards that > > have been used for the original BSP development. > > > > Maybe you want to try the patch that I added for initializing the system > > counter on i.MX6ULL: > > > > https://git.rtems.org/rtems/commit/bsps/arm/imx/start/bspstart.c?id=7b99d7619ec3ff1143db003a541505367f8004d5 > > > > It should work on an i.MX7 too if the counter hasn't been initialized. > > > > > I just chose the value for the clock-frequency out of the fdt > > > /clock-osc/clock-frequency. Not sure if that is the correct value, I > > > also tried some others, but I always get the error code 263 > > > (BSP_ARM_FATAL_GENERIC_TIMER_CLOCK_IRQ_INSTALL) . (I fiddled it > > > together, so please correct if I did any mistakes) > > > That also seems to fit the description of JunBeom, but I couldn't > > follow > > > with Step 2. Do I have to just get the current u-boot sources, > > make the > > > change and normally build it? I used the imx7 u-boot image > > provided by > > > PHYTEC and am not sure if there are necessary custom changes for the > > > imx7 Board or the fdt information is needed to be provided. I looked > > > quiet a while on the internet, but couldn't find much guidance on > > that > > > process. Can someone please give me pointers on how to proceed > > from here? > > > > I think the problem in that thread has been that U-Boot for some reason > > started in a different mode. But note that JunBeom didn't get an > > interrupt. He didn't have a problem installing the interrupt handler. > > > > Installing the interrupt handler can fail for different reasons. The > > most likely one in this case is that the entry for the interrupt is also > > missing in the FDT. > > > > How does the timer entry of your FDT look like? Is there even an timer > > entry? > > > > > > > > Regarding the SMP flag, I found it here on the quick-start guide: > > > > > https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html > > > > > <https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/user/start/bsp-build.html> > > > > Ah, sorry. I missed that you are using the 5 release and not the latest > > master. In that case I assume the waf call has been for libbsd, right? > > > > Best regards > > > > Christian > > > > > > > > Thanks again for the great help so far! > > > Kind regards, > > > Stefan > > > On Feb 8 2021, at 8:41 am, Christian MAUDERER > > > <[email protected]> wrote: > > > > > > Hello Stefan, > > > > > > Am 07.02.21 um 20:35 schrieb Christian Mauderer: > > > > Hello Stefan, > > > > > > > > On 07/02/2021 19:31, Stefan Akatyschew wrote: > > > >> Hey Christian, > > > >> no problem, thanks a lot for your reply! > > > >> Here it starts, right after loading the elf file: > > > >> Just to be sure there is no mistake in my setup, I attached the > > > >> complete listing shown (start.S), as well as my .cmm script to > > load > > > >> the binary. > > > > > > > > That looks like there is a bug in the setup of your debugger. > > > > > > > > The i.MX7 BSP normally runs out of SDRAM. It expects to be > > > started by a > > > > U-Boot on the i.MX7. If I understand your trace script > > correctly, it > > > > resets the board, then it loads the application. This will try > > to put > > > > the application into a SDRAM that is not yet initialized. It's a > > > bit odd > > > > that Trace32 doesn't throw an error when you try to access the > > > code there. > > > > > > > > For boards with a boot loader (like U-Boot) I most of the time > > > use the > > > > following approach: > > > > > > > > - Make sure that there is an application that can be loaded by > > > the boot > > > > loader (Linux Kernel, RTEMS application, ...) > > > > - If the BSP needs an FDT (i.MX does need one): Make sure that > > one is > > > > loaded too. > > > > > > > > In the debug script: > > > > > > > > - Reset and halt the board > > > > - Set a breakpoint at the location where the Kernel would start > > > (in that > > > > case 0x80200000; for Linux maybe 0x80000000 - check the U-Boot > > output > > > > for that) > > > > - Start the board and let it run till the breakpoint. This will > > > execute > > > > the boot loader and let it do all the basic setup. > > > > - Load the application for debugging. > > > > - Let the CPU run. > > > > > > > > I can take a look whether I have some debug script for an i.MX7 > > on my > > > > work PC tomorrow. > > > > > > A simplified version of the script that I would try: > > > > > > ~~~~~~~~ > > > &APPLICATION_FILE="path/to/app.exe" > > > > > > global &initialized > > > > > > if "&initialized"=="" > > > ( > > > &initialized="1" > > > > > > RESet > > > SYStem.RESet > > > SYStem.CPU IMX7DUAL-CA7 > > > SYStem.Option ResBreak OFF > > > SYStem.Option WaitReset 30.0ms > > > SYStem.JtagClock CTCK 10MHz > > > CORE.ASSIGN 1. > > > ) > > > > > > break.IMPLEMENTATION PROGRAM ONCHIP > > > sys.mode down > > > sys.mode up > > > go.direct > > > wait 1s > > > Break.direct > > > go 0x80004000 ; You most likely have to adapt that based on what > > > ; your U-Boot currently loads. > > > wait !run() > > > > > > data.load "&APPLICATION_FILE" > > > break.set _Terminate > > > > > > enddo > > > ~~~~~~~~ > > > > > > Best regards > > > > > > Christian > > > > > > > > > > >> > > > >> Another question, I wonder why when I run waf configure, it > > tells me > > > >> "Checking for RTEMS_SMP : no", when I > > built my > > > >> BSP with the option "--with-rtems-smp"? > > > > > > > > --with-rtems-smp was for the old make based build system. For > > the waf > > > > based one I think you have to set RTEMS_SMP = True in the > > config.ini. > > > > > > > > Where did you find the --with-rtems-smp switch? It's quite > > > possible that > > > > there is a there a bug in the documentation? > > > > > > > >> On this occasion also, in case you missed it, the ssl > > > certificate for > > > >> ftp.rtems.org expired a few days ago. > > > > > > > > I forwarded the information to our internal list. There has > > been just > > > > recently a certificate update for devel.rtems.org. Most likely the > > > > ftp.rtems.org has been missed. > > > > > > > > Best regards > > > > > > > > Christian > > > > > > > >> > > > >> Kind regards, > > > >> Stefan > > > >> > > > >> On Feb 6 2021, at 12:38 pm, Christian Mauderer > > > <[email protected]> wrote: > > > >> > > > >> Hello Stefan, > > > >> > > > >> sorry for not answering earlier. I somehow missed the mail. > > > >> > > > >> On 02/02/2021 18:02, Stefan Akatyschew wrote: > > > >> > Hey together! > > > >> > > > > >> > I'm new to RTEMS and just hit some errors, I just can't > > > figure > > > >> out. > > > >> > Since I will probably lure around a bit longer, I wanted > > > to give > > > >> short > > > >> > introduction, so you can estimate what to expect from me: > > > I'm a > > > >> > nearly-finished(tm) EE undergrad from Germany, not > > having any > > > >> hands-on > > > >> > experience on RTOS, my embedded knowledge is confined > > to some > > > >> hobby > > > >> > STM32/PIC projects and the usual microcontroller stuff they > > > >> teach at > > > >> > uni. Not a great starting point for something as > > advanced as > > > >> RTEMS, I'm > > > >> > aware, but I'm eager to learn it. Besides embedded stuff > > > I'm also > > > >> into > > > >> > the RF electronics :) > > > >> > > > >> It's not a too bad starting point either. It's quite > > similar to > > > >> the one > > > >> I had when I had my first contact with RTEMS. > > > >> > > > >> > Goal of my engagement with RTEMS: Setting up a small > > SMP Demo > > > >> > Application on the Phytec Zeta i.MX7d Board > > > >> > > > > >> > > > https://www.phytec.eu/product-eu/single-board-computer/phyboard-zeta/ > > > >> > for a university project, though after getting to know > > > RTEMS, I > > > >> hope to > > > >> > be able to stick around after that, the applications in > > > >> (aero)space, are > > > >> > exactly what I'm passionate about! Also I hope after I > > > get to run > > > >> > everything, I can compile and publish my > > > >> documentation/experience to > > > >> > help others with the i.MX 7, since the road has been > > > rather rocky > > > >> for me > > > >> > now. > > > >> > > > > >> > > > >> I hope I didn't add too much stones to the road. I worked > > > quite a > > > >> bit on > > > >> the imx BSP when I added i.MX 6 and some of the changes > > > haven't been > > > >> extensively tested on i.MX 7. > > > >> > > > >> > > > > >> > So to my actual problem: I have the before mentioned > > i.MX 7d > > > >> Board and a > > > >> > Lauterbach Power Debug Interface with trace32, to directly > > > >> flash my > > > >> > binaries onto the SRAM. I'm using their i.MX7d SABRE > > > >> configuration file, > > > >> > which successfully worked with their sample binary and > > > slightly > > > >> modified > > > >> > it (mainly deactivating ETF on-chip tracing). > > > >> > > > > >> > I've built the RTEMS 5 toolchain according to your > > > quick-start > > > >> guide ( > > > >> > > > > https://docs.rtems.org/branches/master/user/start/index.html), > > > >> with some > > > >> > slight modifications arm/imx7 on my Ubuntu 18.04 VM > > > (kernel built > > > >> from > > > >> > sources, somehow didn't work otherwise). I also built the > > > >> simplest demo > > > >> > application from 2.7, which went without problems (well, > > > after > > > >> many > > > >> > hours of troubleshooting stupid mistakes). Now after > > > flashing the > > > >> binary > > > >> > directly to the SRAM with my Lauterbach Debugger (without > > > RTEMS OS > > > >> > Awareness yet), I end up in the exception routine > > > >> > "_ARMV4_Exception_data_abort_default", with the following > > > >> > call-tree-hierarchy: > > > >> > > > > >> > > > >> Can you hit "Up" once and take a look at the code location > > > and send a > > > >> screen shot. Best thing would be the mode that shows assembler > > > >> istructions too. And maybe the window with the CPU registers. > > > >> > > > >> Best regards > > > >> > > > >> Christian > > > >> > > > >> > I also tried removing the printf (just letting it count an > > > >> integer up > > > >> > and overflow), since I was confused why RTEMS would call a > > > >> uart_write > > > >> > function otherwise, but that didn't change anything and > > > actually > > > >> doesn't > > > >> > even get to the Init rtems_task. > > > >> > > > > >> > I already looked on the internet, the documentation and the > > > >> mailing-list > > > >> > archive for help (not nearly finished reading through the > > > complete > > > >> > Classic API Guide and User Manual, that'll take some time). > > > >> > Unfortunately I'm also new to the Lauterbach Debugger, > > which > > > >> seems to be > > > >> > a beast of its own, so I unfortunately can't provide any > > > useful > > > >> on-chip > > > >> > trace data yet. I hope anyone can point me to the, > > > probably rather > > > >> > obvious, mistake I'm making, any help is appreciated! > > > >> > > > > >> > > > > >> > Last but not least, thanks for your awesome work on RTEMS! > > > >> > > > > >> > Kind regards, > > > >> > Stefan > > > >> > > > > >> > > > > >> > Attached some maybe useful outputs: > > > >> > > > > >> > stefan@rtems-vm:~$ arm-rtems5-gcc --version > > > >> > arm-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5.1, > > Newlib > > > >> 7947581) > > > >> > > > > >> > ./waf configure --rtems=$HOME/rtems/5 --rtems-bsp=arm/imx7 > > > >> > Setting top to : > > > >> > /home/stefan/VCS/rtems-bp/first-test > > > >> > Setting out to : > > > >> > /home/stefan/VCS/rtems-bp/first-test/build > > > >> > RTEMS Version : 5 > > > >> > Architectures : arm-rtems5 > > > >> > Board Support Package (BSP) : arm-rtems5-imx7 > > > >> > Show commands : no > > > >> > Long commands : no > > > >> > Checking for program 'arm-rtems5-gcc' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-gcc > > > >> > Checking for program 'arm-rtems5-g++' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-g++ > > > >> > Checking for program 'arm-rtems5-gcc' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-gcc > > > >> > Checking for program 'arm-rtems5-ld' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-ld > > > >> > Checking for program 'arm-rtems5-ar' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-ar > > > >> > Checking for program 'arm-rtems5-nm' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-nm > > > >> > Checking for program 'arm-rtems5-objdump' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-objdump > > > >> > Checking for program 'arm-rtems5-objcopy' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-objcopy > > > >> > Checking for program 'arm-rtems5-readelf' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-readelf > > > >> > Checking for program 'arm-rtems5-strip' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-strip > > > >> > Checking for program 'arm-rtems5-ranlib' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-ranlib > > > >> > Checking for program 'rtems-ld' : > > > >> > /home/stefan/rtems/5/bin/rtems-ld > > > >> > Checking for program 'rtems-tld' : > > > >> > /home/stefan/rtems/5/bin/rtems-tld > > > >> > Checking for program 'rtems-syms' : > > > >> > /home/stefan/rtems/5/bin/rtems-syms > > > >> > Checking for program 'rtems-bin2c' : > > > >> > /home/stefan/rtems/5/bin/rtems-bin2c > > > >> > Checking for program 'tar' : /bin/tar > > > >> > Checking for program 'gcc, cc' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-gcc > > > >> > Checking for program 'ar' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-ar > > > >> > Checking for program 'g++, c++' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-g++ > > > >> > Checking for program 'ar' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-ar > > > >> > Checking for program 'gas, gcc' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-gcc > > > >> > Checking for program 'ar' : > > > >> > /home/stefan/rtems/5/bin/arm-rtems5-ar > > > >> > Checking for c flags '-MMD' : yes > > > >> > Checking for cxx flags '-MMD' : yes > > > >> > Compiler version (arm-rtems5-gcc) : 7.5.0 > > > 20191114 (RTEMS > > > >> 5, RSB > > > >> > 5.1, Newlib 7947581) > > > >> > Checking for a valid RTEMS BSP installation : yes > > > >> > Checking for RTEMS_DEBUG : no > > > >> > Checking for RTEMS_MULTIPROCESSING : no > > > >> > Checking for RTEMS_NEWLIB : yes > > > >> > Checking for RTEMS_POSIX_API : yes > > > >> > Checking for RTEMS_SMP : no > > > >> > Checking for RTEMS_NETWORKING : yes > > > >> > 'configure' finished successfully (1.056s) > > > >> > > > > >> > > > > >> > _______________________________________________ > > > >> > users mailing list > > > >> > [email protected] > > > >> > http://lists.rtems.org/mailman/listinfo/users > > > >> > > > > >> > > > > > > -- > > > -------------------------------------------- > > > embedded brains GmbH > > > Herr Christian MAUDERER > > > Dornierstr. 4 > > > 82178 Puchheim > > > Germany > > > email: [email protected] > > > phone: +49-89-18 94 741 - 18 > > > 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/ > > > > > >
_______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
