raspberry BSP: Maybe there is a bug in the linker file?
Niteesh
gsnb.gn at gmail.com
Sat Dec 21 09:02:48 UTC 2019
I am very much interested in taking part in GSOC 2020. I want to get this
running on raspberrypi3
so that I could start learning and exploring more of RTEMS. I am planning
to add framebuffer support, using this year's GSOC work
on beagle bone as a reference.
On Sat, Dec 21, 2019 at 2:20 PM Christian Mauderer <list at c-mauderer.de>
wrote:
> On 21/12/2019 08:28, Niteesh wrote:
> > Did you take a look at the exception?
>
> Not yet.
>
> > I still couldn't get it running on
> > the rpi3 using rpi2 bsp.
>
> Again: It's quite likely that the serial interface is a problem. I don't
> think that you'll see any output on rpi3 without changes.
>
> > I built the bsp again by checking out a commit before
> > c5fd79cd4704a4270ba0114a1009ab8556f997c9
> > and created a kernel.img using objcopy.
>
> That should work. But Most likely you'll get your output on the serial
> interface that is pointing to the bluetooth module.
>
I configured such that PL011 it is pointing to the serial port. We can do
that by adding disable-bt in the config.txt file.
> > I tried running it on gdb with set scheduler-locking on. I seem to jump
> > to bsp_vector_table_begin and hang there (0x000000c).
>
> I thought you don't have a debugger connected? How do you run it with gdb?
Ran the executable with qemu and connected to it.
qemu-system-arm -M raspi2 -m 1G -kernel hello.exe -serial mon:stdio
-nographic -S -s
>
> >
> >
> > On Sat, Dec 21, 2019 at 1:42 AM Christian Mauderer <list at c-mauderer.de
> > <mailto: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
> > <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>
> > > <mailto: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/9bb820bd/attachment.html>
More information about the devel
mailing list