raspberry BSP: Maybe there is a bug in the linker file?

[Niteesh]

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 <list at 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:list at 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 <list at c-mauderer.de
> > <mailto:list at 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191221/e79aa80b/attachment-0001.html>