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

[Niteesh]

On raspberry pis equipped with the wireless/Bluetooth module, the PL011 is
connected to the Bluetooth module,
and the mini UART is used as the primary UART. On all other models, the
PL011 is used as the primary UART.

The mini UART has smaller FIFOs. Combined with the lack of flow control,
this makes it more prone to losing characters at higher baudrates. It is
also generally less capable than the PL011, mainly due to its baud rate
link to the VPU clock speed.

The particular deficiencies of the mini UART compared to the PL011 are :

No break detection
No framing errors detection
No parity bit
No receive timeout interrupt
No DCD, DSR, DTR or RI signals

https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
the official doc from broadcom, this is what I used while developing
drivers for bare metal project.



On Sun, Dec 22, 2019 at 1:56 AM Christian Mauderer <list at c-mauderer.de>
wrote:

> 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.
> >     >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191222/f50fdf6f/attachment-0001.html>