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

Niteesh gsnb.gn at gmail.com
Sat Dec 21 19:45:14 UTC 2019


On inspecting the code, the driver is for PL011. We have to write a driver
for the mini uart.
which we will have start from scratch. So, how do you want the structure to
be?

The code of PL011 can be improved. We could use gpio functions to configure
pins.
And also many of the UART values are set in place instead of using the
appropriate function, for example
the usart_set_baud is empty and the baud rate is set directly in the init
function.
What do you think about these changes? Should we change them also?
On Sun, Dec 22, 2019 at 12:25 AM Christian Mauderer <list at c-mauderer.de>
wrote:

> On 21/12/2019 19:26, Niteesh wrote:
> > There is already a PL011 driver in the arm shared section. should we
> > just import it?
>
> If you say "import" and you mean "use" and not "copy": yes, that would
> be great.
>
> >
> > On Sat, Dec 21, 2019 at 10:46 PM Niteesh <gsnb.gn at gmail.com
> > <mailto:gsnb.gn at gmail.com>> wrote:
> >
> >     Shall I start writing a driver for raspberrypi3 PL011?
> >
> >
> >     On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer
> >     <list at c-mauderer.de <mailto:list at c-mauderer.de>> wrote:
> >
> >         On 19/12/2019 15:05, Christian Mauderer wrote:
> >         > On 19/12/2019 14:27, Sebastian Huber wrote:
> >         >> On 19/12/2019 14:24, Christian Mauderer wrote:
> >         >>> Hello,
> >         >>>
> >         >>> triggered by the discussion regarding RTEMS on raspberrypi 3
> >         I did some
> >         >>> tests. I haven't been able to start a RTEMS on my Pi 1 if I
> >         tried a
> >         >>> version after commit
> >         c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
> >         >>> 29.07.2019. Right before it everything works as expected.
> >         >>>
> >         >>> The commit changes the memory locations. From what I
> >         understood, the
> >         >>> bootloader on a raspberry always jumps to address 0x8000
> >         after loading
> >         >>> the application. So I'm not convinced that the change is
> >         correct.
> >         >>
> >         >> Is the 0x8000 a fixed address or you configure this in a boot
> >         image header?
> >         >>
> >         >
> >         >>From what I've seen the bootloader just uses a fixed address.
> >         All guides
> >         > that I've found just use objcopy to generate a binary from the
> >         elf files
> >         > without adding a header. For example a guide for RTEMS:
> >         >
> >         >
> >         >
> >
> http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
> >         >
> >         > A FreeRTOS port mentions this behavior explicitly in a comment
> >         in the
> >         > linker file:
> >         >
> >         >
> >         >
> >
> https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17
> >         >
> >         > The "graphics processor" is no typo here. It seems the
> >         initialization is
> >         > really done by the graphics processor on the pi.
> >         > _______________________________________________
> >         > devel mailing list
> >         > devel at rtems.org <mailto:devel at rtems.org>
> >         > http://lists.rtems.org/mailman/listinfo/devel
> >         >
> >
> >         I just found an option: It is possible to set a "kernel_address"
> >         in the
> >         config.txt:
> >
> >
> >
> https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
> >
> >         So the start address can be changed and maybe the adaption to
> >         the linker
> >         file isn't necessary.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191222/1b1fada7/attachment.html>


More information about the devel mailing list