<div dir="ltr">On raspberry pis equipped with the wireless/Bluetooth module, the PL011 is connected to the Bluetooth module,<div>and the mini UART is used as the primary UART. On all other models, the PL011 is used as the primary UART.</div><div><br></div><div>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.<br><br>The particular deficiencies of the mini UART compared to the PL011 are :<br><br>No break detection<br>No framing errors detection<br>No parity bit<br>No receive timeout interrupt<br>No DCD, DSR, DTR or RI signals</div><div><br></div><div><a href="https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf">https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf</a></div><div>the official doc from broadcom, this is what I used while developing drivers for bare metal project.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 22, 2019 at 1:56 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I haven't had a look at the different types of UARTS yet. What is the<br>
difference? What do you use as reference?<br>
<br>
If it is just a variant of an existing driver, the existing one should<br>
be extended to support both variants.<br>
<br>
On 21/12/2019 20:45, Niteesh wrote:<br>
> On inspecting the code, the driver is for PL011. We have to write a<br>
> driver for the mini uart.<br>
> which we will have start from scratch. So, how do you want the structure<br>
> to be?<br>
> <br>
> The code of PL011 can be improved. We could use gpio functions to<br>
> configure pins.<br>
> And also many of the UART values are set in place instead of using the<br>
> appropriate function, for example<br>
> the usart_set_baud is empty and the baud rate is set directly in the<br>
> init function.<br>
> What do you think about these changes? Should we change them also?<br>
> On Sun, Dec 22, 2019 at 12:25 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
>     On 21/12/2019 19:26, Niteesh wrote:<br>
>     > There is already a PL011 driver in the arm shared section. should we<br>
>     > just import it?<br>
> <br>
>     If you say "import" and you mean "use" and not "copy": yes, that would<br>
>     be great.<br>
> <br>
>     ><br>
>     > On Sat, Dec 21, 2019 at 10:46 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>><br>
>     > <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>> wrote:<br>
>     ><br>
>     >     Shall I start writing a driver for raspberrypi3 PL011?<br>
>     ><br>
>     ><br>
>     >     On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer<br>
>     >     <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
>     ><br>
>     >         On 19/12/2019 15:05, Christian Mauderer wrote:<br>
>     >         > On 19/12/2019 14:27, Sebastian Huber wrote:<br>
>     >         >> On 19/12/2019 14:24, Christian Mauderer wrote:<br>
>     >         >>> Hello,<br>
>     >         >>><br>
>     >         >>> triggered by the discussion regarding RTEMS on<br>
>     raspberrypi 3<br>
>     >         I did some<br>
>     >         >>> tests. I haven't been able to start a RTEMS on my Pi 1<br>
>     if I<br>
>     >         tried a<br>
>     >         >>> version after commit<br>
>     >         c5fd79cd4704a4270ba0114a1009ab8556f997c9 from<br>
>     >         >>> 29.07.2019. Right before it everything works as expected.<br>
>     >         >>><br>
>     >         >>> The commit changes the memory locations. From what I<br>
>     >         understood, the<br>
>     >         >>> bootloader on a raspberry always jumps to address 0x8000<br>
>     >         after loading<br>
>     >         >>> the application. So I'm not convinced that the change is<br>
>     >         correct.<br>
>     >         >><br>
>     >         >> Is the 0x8000 a fixed address or you configure this in<br>
>     a boot<br>
>     >         image header?<br>
>     >         >><br>
>     >         ><br>
>     >         >>From what I've seen the bootloader just uses a fixed<br>
>     address.<br>
>     >         All guides<br>
>     >         > that I've found just use objcopy to generate a binary<br>
>     from the<br>
>     >         elf files<br>
>     >         > without adding a header. For example a guide for RTEMS:<br>
>     >         ><br>
>     >         ><br>
>     >         ><br>
>     >       <br>
>      <a href="http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html" rel="noreferrer" target="_blank">http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html</a><br>
>     >         ><br>
>     >         > A FreeRTOS port mentions this behavior explicitly in a<br>
>     comment<br>
>     >         in the<br>
>     >         > linker file:<br>
>     >         ><br>
>     >         ><br>
>     >         ><br>
>     >       <br>
>      <a href="https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17" rel="noreferrer" target="_blank">https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17</a><br>
>     >         ><br>
>     >         > The "graphics processor" is no typo here. It seems the<br>
>     >         initialization is<br>
>     >         > really done by the graphics processor on the pi.<br>
>     >         > _______________________________________________<br>
>     >         > devel mailing list<br>
>     >         > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>     >         > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>     >         ><br>
>     ><br>
>     >         I just found an option: It is possible to set a<br>
>     "kernel_address"<br>
>     >         in the<br>
>     >         config.txt:<br>
>     ><br>
>     ><br>
>     >       <br>
>      <a href="https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md" rel="noreferrer" target="_blank">https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md</a><br>
>     ><br>
>     >         So the start address can be changed and maybe the adaption to<br>
>     >         the linker<br>
>     >         file isn't necessary.<br>
>     ><br>
> <br>
</blockquote></div>