raspberry BSP: Maybe there is a bug in the linker file?
Christian Mauderer
list at c-mauderer.de
Sat Dec 21 20:26:08 UTC 2019
I haven't had a look at the different types of UARTS yet. What is the
difference? What do you use as reference?
If it is just a variant of an existing driver, the existing one should
be extended to support both variants.
On 21/12/2019 20:45, Niteesh wrote:
> 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
> <mailto: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>
> > <mailto: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>
> <mailto: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>
> <mailto: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.
> >
>
More information about the devel
mailing list