raspberry BSP: Maybe there is a bug in the linker file?
Christian Mauderer
list at c-mauderer.de
Sat Dec 21 09:48:12 UTC 2019
On 21/12/2019 10:36, Niteesh wrote:
> 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/
Yes, there is some framebuffer support. For the rpi I think it's a
driver ported to RTEMS. You can think about adding the FreeBSD one as an
alternative if that is accepted by the community. If you want to do that
please suggest it on the mailing list in a separate thread as a GSoC
project idea. Please think about what advanteges it could have for RTEMS
to use the libbsd framebuffer instead of the one already in the driver.
I would have to take a more detailed look at the expected effort. But
maybe it will need some small extra targets to have the right size for a
GSoC project.
>
> On Sat, Dec 21, 2019 at 2:32 PM Niteesh <gsnb.gn at gmail.com
> <mailto: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 <mailto: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 assume that you are referring to this option:
https://github.com/raspberrypi/firmware/blob/0c01dbefba45a08c47f8538d5a071a0fba6b7e83/boot/overlays/README#L553
That is only a "dtoverlay" line and therefore has an influence on the
device tree. Basically it adds the following overlay: (de-compiled from
the disable-bt.dtbo in the repo with the config.txt description above):
https://gist.github.com/c-mauderer/86fd005f265c329c321e2dccc1032a6b
It disables UART1 and changes some pin configs. So most likely on Linux
you'll end up with the same device name. But it will still be a
different UART module on register level.
>
> > 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
>
Sounds OK. But note that no one tested qemu for raspberry pi together
with RTEMS. So I'm not sure whether you would need for example the
bootloaders or some different initialization.
>From what you describe (jump to bsp_vector_table_begin and hang there)
it is possible that the simulated CPU isn't active. On real hardware the
bootloaders run on the GPU and start the CPU as the last step. Maybe
that is necessary for the emulator too.
>
> >
> >
> > On Sat, Dec 21, 2019 at 1:42 AM 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 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>
> > <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>>
> > > <mailto: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.
> > >
> >
>
More information about the devel
mailing list