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 <l...@c-mauderer.de > <mailto:l...@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 > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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...@gmail.com > <mailto:gsnb...@gmail.com> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>> > > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com> > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>>>> wrote: > > > > > > Shall I start writing a driver for raspberrypi3 PL011? > > > > > > > > > On Sat, Dec 21, 2019 at 8:40 PM Christian Mauderer > > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@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@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@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. > > > > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
