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:
Regarding WAF and SMP: I can't follow unfortunately, I only ran "./waf configure --rtems=..." and saw the missing SMP output there. 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
