On Sun, Dec 22, 2019, 12:29 PM Niteesh <gsnb...@gmail.com> wrote: > On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer <l...@c-mauderer.de> > wrote: > >> Hello Niteesh, >> >> thanks for doing that work. >> >> On 22/12/2019 12:10, Niteesh wrote: >> > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's equipped with >> > wireless/Bluetooth module, the PL011 is connected to the Bluetooth >> > module, and the mini UART is used as the primary UART. >> >> In my opinion it would be great if you could use the FDT to distinguish >> between the boards. That should allow to add raspberry 3 (and maybe 4) >> support without adding another BSP. More BSPs mean a bigger maintenance >> effort for the RTEMS community. > > Learning more about FDT is on my list for a long time. I would love to > work on that > but I have almost no exp with FDT's. > But another thing could also be done, in raspberrypi/start/bspstart.c we > get the revision and > model of the board using the mailbox. Every board has a unique id, which > we could use to initialize > the BSP. But using FDT seems to be a more elegant option, it is a lot of > work I think, but we could take > help from libbsd and linux I suppose. What do you think? >
I think there are almost always two steps to a project like this: get it to work and make it nice. :) If you fix the startup code to read the board revision and memory size, you can get a working BSP that dynamically adapts to the models and memory variations with minimal modifications. If you want to then convert the BSP to FDT, it will be a LOT easier to debug with a working BSP. Plus you may be able to identify every variation point based on just the model info. Then FDT is just a matter of switching the source of some/all of the info. That would be my work plan anyway. > >> > >> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf >> > But from the above doc (PAGE 10), the mini uart has 16550 like registers >> > and RTEMS already has the driver for it >> > bsps/shared/dev/serial/ns16550.c. But I am not sure how compatible they >> > are? Should a new driver be implemented from scratch or use ns16550 if >> > possible? >> >> In general it's better to re-use existing code. That has multiple >> advantages: >> >> - It reduces the maintenance effort. Fewer code means fewer work. >> - If you have multiple driver for the same or similar hardware it can >> happen that a bug is fixed in one but not the other. >> - It's simpler to find a hardware to test changes. >> - The driver becomes more universal with every new supported hardware. >> That increases the chance that it fits the next new hardware. >> >> I'm sure there are some more if you ask someone else. > > I do understand the issues, I just spent some time reading the driver code. > I think we could most probably use it. I will take a closer look and will > update. > >> >> > > >> > Also, the core clock on which the PL011 is based on is changed in rpi3. >> > Rpi1 and 2 use 250Mhz as the default clock but it was changed to 400Mhz >> > in Rpi3 and newer >> >> Again: Would be great if that could be adapted based on FDT or by >> reading the right registers. >> >> > >> > Few differences between PL011 and Mini uart >> > The mini UART has smaller FIFOs. Combined with the lack of flow control, >> > this makes it more prone to losing characters at higher baud rates. It >> > is also generally less capable than the PL011, mainly due to its baud >> > rate link to the VPU clock speed. >> >> That shouldn't really be a problem for the system console. >> >> > >> > 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 >> > >> > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
