Did you take a look at the exception? I still couldn't get it running on the rpi3 using rpi2 bsp. I built the bsp again by checking out a commit before c5fd79cd4704a4270ba0114a1009ab8556f997c9 and created a kernel.img using objcopy. I tried running it on gdb with set scheduler-locking on. I seem to jump to bsp_vector_table_begin and hang there (0x000000c).
On Sat, Dec 21, 2019 at 1:42 AM Christian Mauderer <l...@c-mauderer.de> wrote: > On 20/12/2019 19:19, Niteesh wrote: > > How do you test a patch? Do you checkout that particular commit and > > build and the BSP again?. > > Basically yes: You check out the version that you want fixed and apply > the patch. In that case I have gone back and forward a few times to find > the commit that introduced the second bug. > > > @Christian Mauderer <mailto:l...@c-mauderer.de> how did you build it > > for the rpi1? Did you follow the steps as in previous threads? > > Basically the same steps like for every BSP: > 1. Build a recent toolchain using RSB. > 2. Build the BSP. > 3. Test it on the board. > > For the rpi1 the BSP is "raspberrypi" instead of "raspberrypi2". And I > didn't install the BSP because I only wanted the tests and no extra > application. > > For testing it I used the guide that you found: Objcopy into a binary > file and replace the kernel.img with it. > > > and how did you come to the conclusion that these changes cause the > > exceptions, > > I had a look at the history of the raspberry BSP (`gitk > bsps/arm/raspberrypi` or `git log bsps/arm/raspberrypi`) and looked for > suspicious patches. For the raspberry there are not much patches in the > last year so that was quite easy. Then I just tested before and after > some of the patches to find the ones that introduced the bugs. > > Again: In this case it was necessary to backport Sebastians patch so > that I have been able to test before / after the one that introduces the > exception. > > I haven't had a detailled look at the exception yet but I assume it's > some problem that the wrong variant is used or that my RPi1 is an early > model with less RAM or something like that. > > > as a beginner these ideas > > will help in the future. > > On Fri, Dec 20, 2019 at 2:46 PM Christian Mauderer <l...@c-mauderer.de > > <mailto:l...@c-mauderer.de>> wrote: > > > > On 20/12/2019 09:22, Christian Mauderer wrote: > > > On 20/12/2019 07:33, Sebastian Huber wrote: > > >> On 19/12/2019 15:28, Niteesh wrote: > > >>> As far as I know, 0x8000 is a fixed address where the bootloader > > jumps > > >>> to after loading the application assuming the CPU is in 32bit > mode. > > >>> For 64bit mode, it jumps to 0x80000. > > >> > > >> Would you mind testing this patch: > > >> > > >> https://lists.rtems.org/pipermail/devel/2019-December/056551.html > > >> > > > > > > On the Pi 1 now the binary has three time the size (with a lot of > 0x00 > > > in it) and at least RTEMS starts. But it runs into an exception > quite > > > fast. I'll investigate that a bit. > > > > > > @Niteesh: For the Pi 3 I would expect that it still doesn't print > > > anything on the console due to the different UART pins. > > > > > > The output on the Pi 1 is: > > > > > > executing� > > > *** FATAL *** > > > fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION) > > > > > > R0 = 0xfc037f80 R8 = 0x00000000 > > > R1 = 0xfc345980 R9 = 0x00000010 > > > R2 = 0x00000001 R10 = 0xfc037f8a > > > R3 = 0x03fc8080 R11 = 0x0030da00 > > > R4 = 0xfc037f80 R12 = 0xfc345988 > > > R5 = 0x00000008 SP = 0x00300ba8 > > > R6 = 0x0030d9fe LR = 0x00205a78 > > > R7 = 0x00305218 PC = 0x00205ac8 > > > CPSR = 0x600001d3 VEC = 0x00000004 > > > RTEMS version: 5.0.0.254f38583fe68c3e17dfe274a2deeb00a5a538d6 > > > RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (6c65fc237b9e > modified), > > > Newlib d14714c69) > > > > The exception seems to be caused by some of the changes in bspstart.c > > and bspgetworkarea.c in patch > a4d7e4cee77d16b0e34ef543f0804e7eb2954137. > > So the fix for the linker command file is fine. > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
