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

Niteesh gsnb.gn at gmail.com
Sat Dec 21 09:36:32 UTC 2019


Looks like there is already framebuffer support for RPi, but still I would
like to play with it and add some GUI example as in
https://blog.thelunatic.dev/gsoc-final-report/

On Sat, Dec 21, 2019 at 2:32 PM Niteesh <gsnb.gn at gmail.com> wrote:

> 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/b7bb5e85/attachment-0001.html>


More information about the devel mailing list