raspberry BSP: Maybe there is a bug in the linker file?
Christian Mauderer
list at c-mauderer.de
Sun Dec 22 08:50:32 UTC 2019
Hello Niteesh,
thanks for the detailed information. I agree that this is a completely
different hardware module and will need a different driver.
The data sheet (by the way: one of the worst I've ever seen) tells that
the Mini UART has "16550 like registers" that are "as far as possible
[...] like a 16550". So maybe the driver from
bsps/shared/dev/serial/ns16550.c can be used or extended.
By the way: It's a really odd idea to integrate two completely different
UARTs into one chip. I know chips with variations but completely
different is unusual. Especially because most serial peripherals are
small and need very few chip area compared to memory. But maybe they had
a reason ...
Best regards
Christian
On 22/12/2019 08:12, Niteesh wrote:
> 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
> <mailto: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>
> > <mailto: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>>
> > > <mailto: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>>
> > <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 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>>
> > <mailto: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