<div dir="ltr">Thank you, it works now :)<div>I have tested in on a real rpi3 and on rpi2 using QEMU, it works on both of them.</div><div>Shall I send it as two patches, because the first one adds the facility to pass</div><div>user define functions to calculate baud divisor and the 2nd is the driver patch?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 15, 2020 at 1:25 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.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">On 15/01/2020 06:27, Niteesh wrote:<br>
> I commented out all FDT queries and everything works using ns16550 driver.<br>
> How do I load FDT blob using uboot, I tried using the default<br>
> bootloader, but<br>
> it doesn't work. I tried the following command but they don't work<br>
> fatload mmc 0 0x200000 kernel7.img<br>
> fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb<br>
> fdt addr 0x1000<br>
> fdt boardsetup<br>
> go 0x200080<br>
<br>
Instead of "go 0x200080" try it with bootm with the syntax for linux:<br>
<br>
<a href="https://www.denx.de/wiki/view/DULG/UBootCmdGroupExec#Section_5.9.4.2" rel="noreferrer" target="_blank">https://www.denx.de/wiki/view/DULG/UBootCmdGroupExec#Section_5.9.4.2</a>.<br>
<br>
With the commands you used it should be a<br>
<br>
bootm 0x200000 - 0x1000<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> On Tue, Jan 14, 2020 at 9:40 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>>> wrote:<br>
> <br>
> I am finished with code, I tested it in QEMU emulator raspi2but it<br>
> doesn't work<br>
> when testing on real rpi3. I don't know if the problem is with<br>
> loading the FDT<br>
> or with my code?<br>
> How do I send the code, so that you can take a look at it?<br>
> <br>
> On Tue, Jan 14, 2020 at 8:04 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>>> wrote:<br>
> <br>
> On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer<br>
> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
> <br>
> On 13/01/2020 19:04, Niteesh wrote:<br>
> > The ns16550_context already has a field named<br>
> baud_divisor, so if the<br>
> > user passes<br>
> > value for it, then we can skip the GetBaudDivisor function<br>
> and use that<br>
> > value instead.<br>
> ><br>
> > Is this approach okay?<br>
> <br>
> Is the driver still able to handle different baud rates with<br>
> this? Does<br>
> the ioctl call for setting the baudrate work?<br>
> <br>
> I didn't think about this, it won't work if we are using this<br>
> method. ns16550_set_attributes<br>
> calls ns16550_GetBaudDivisor, then I think we will have to stick<br>
> with the old method.<br>
> <br>
> <br>
> <br>
> Best regards<br>
> <br>
> Christian<br>
> <br>
> ><br>
> > On Mon, Jan 13, 2020 at 3: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>
> > On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer<br>
> > <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
> > <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>>> wrote:<br>
> ><br>
> > On 12/01/2020 21:26, Niteesh wrote:<br>
> > > On Sun, Jan 12, 2020 at 11:42 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>>><br>
> > > <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><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>> wrote:<br>
> > ><br>
> > > Hello Niteesh,<br>
> > ><br>
> > > On 12/01/2020 16:06, Niteesh wrote:<br>
> > > > The only issue, I faced while using this<br>
> driver is the<br>
> > baud divisor is<br>
> > > > calculated <br>
> > > > by CLOCK_FREQ/(BAUD_RATE * 16)<br>
> (*ns16550-context.c:68)*<br>
> > > > but it should BAUD_DIV = (CLOCK_FREQ/(8 *<br>
> BAUD_RATE)) -<br>
> > 1, for Rpi3.<br>
> > > > For testing, I assigned the baud divisor<br>
> to 270 (115200<br>
> > bits/s) in<br>
> > > > ns16550-context.c,<br>
> > > > and everything works fine.<br>
> > ><br>
> > > Sounds great. In NS16550_GetBaudDivisor<br>
> there is already a<br>
> > case where<br>
> > > the baudDivisor is calculated differently<br>
> (depending on<br>
> > > ctx->has_precision_clock_synthesizer and<br>
> > > ctx->has_fractional_divider_register). If<br>
> none of the two<br>
> > cases are ok<br>
> > > for the controller you could just add<br>
> another one.<br>
> > ><br>
> > > Can we pass in a function, which gets called,<br>
> won't this be more<br>
> > > flexible? because<br>
> > > in the future if we have some other board that<br>
> has a different<br>
> > > calculation for the baud rate<br>
> > > the function will take care of it.<br>
> ><br>
> > It's possible. Please make sure to be compatible<br>
> with the<br>
> > current API.<br>
> > For example if the pointer is NULL you should call<br>
> the legacy<br>
> > function<br>
> > instead.<br>
> ><br>
> > <br>
> > I will be adding an extra field, a function pointer to<br>
> ns16550_context,<br>
> > the prototype of the function would be *uint32_t<br>
> > calculate_baud_divisor( ns16550_context * )*<br>
> > This is will calculate the baud divisor using its own<br>
> formula and<br>
> > the initial baud.<br>
> > If this function is not NULL then it would be called<br>
> inside<br>
> > *NS16550_GetBaudDivisor* function,<br>
> > *<br>
> > *<br>
> ><br>
> > ><br>
> > > ><br>
> > > > For console selection, my plan is to<br>
> search for the aux<br>
> > node using<br>
> > > > compatible<br>
> > > > property and if its status is enabled,<br>
> then initialize<br>
> > the AUX<br>
> > > uart and<br>
> > > > set the BSP_output_char<br>
> > > > to aux_output_char, else<br>
> pl011_output_char. All this<br>
> > will be done<br>
> > > inside<br>
> > > > the uart_probe function,<br>
> > > > except for the initialization of AUX which<br>
> will be done in<br>
> > > init_ctx_aux.<br>
> > > > And finally, call the output char<br>
> > > > function using *BSP_output_char. Do you<br>
> have any neat<br>
> > way to do this?<br>
> > ><br>
> > > I don't have an example for a similar case<br>
> at hand. So:<br>
> > No, no neat way<br>
> > > that I can tell you.<br>
> > ><br>
> > > Before you start to write code: Please take<br>
> a look at the<br>
> > different<br>
> > > beagle variants what is possible. Is there a<br>
> variant where<br>
> > AUX uart<br>
> > > would be there but shouldn't be used as a<br>
> console (one of<br>
> > the Zeros<br>
> > > maybe or the compute module?). How does<br>
> Raspbian or<br>
> > FreeBSD decide which<br>
> > > port should be used? Maybe they decide based<br>
> on the<br>
> > commandline.txt? In<br>
> > > such a case it would be better to just<br>
> initialize all<br>
> > active (in the<br>
> > > fdt) serial ports and decide based on the<br>
> commandline too.<br>
> > ><br>
> > > <br>
> > > The Documentation says the following: <br>
> > > *By default, on Raspberry Pis equipped with the<br>
> > wireless/Bluetooth*<br>
> > > *module (Raspberry Pi 3 and Raspberry Pi Zero<br>
> W), **the PL011<br>
> > UART is*<br>
> > > *connected to the Bluetooth module, while the<br>
> mini UART is<br>
> > used as the<br>
> > > primary UART and*<br>
> > > *will have a Linux console on it. On all other<br>
> models, the<br>
> > PL011 is used<br>
> > > as the primary UART.<br>
> > ><br>
> > > *<br>
> > > *In Linux device terms, by default, /dev/ttyS0<br>
> refers to the<br>
> > mini UART,<br>
> > > and /dev/ttyAMA0 refers*<br>
> > > *to the PL011. The primary UART is the one<br>
> assigned to the Linux<br>
> > > console, which depends on*<br>
> > > *the Raspberry Pi model as described above.<br>
> There are also<br>
> > symlinks:<br>
> > > /dev/serial0, which always*<br>
> > > *refers to the primary UART (if enabled), and<br>
> /dev/serial1, which<br>
> > > similarly always refers to the secondary UART<br>
> (if enabled).*<br>
> > > *<br>
> > > *<br>
> > > I checked in all the DTB files, by decompiling<br>
> them (files are<br>
> > ><br>
> from <a href="https://github.com/raspberrypi/firmware/tree/master/boot" rel="noreferrer" target="_blank">https://github.com/raspberrypi/firmware/tree/master/boot</a>).<br>
> > > In all board with support for wireless and<br>
> bluetooth, the AuX<br>
> > is enabled<br>
> > > and serial0 points to it. So we could use serial0<br>
> > > to find the correct UART port. I think this is<br>
> solid enough.<br>
> > So, should<br>
> > > I use this approach?<br>
> ><br>
> > Sounds OK. If possible please initialize the other<br>
> UART too if it is<br>
> > enabled in the FDT. Although we don't support<br>
> bluetooth yet<br>
> > maybe there<br>
> > will be support in the future or someone wants to<br>
> do it in the<br>
> > application.<br>
> ><br>
> > I will go with this method then. <br>
> ><br>
> > ><br>
> > > Or if using the command line, then we need to<br>
> move the link to<br>
> > > CONSOLE_DEVICE to console_initialize, and parse the<br>
> > > command line twice. If this is no problem, then<br>
> we could use this<br>
> > > approach also.<br>
> ><br>
> > Would be possible too.<br>
> ><br>
> > ><br>
> > > ><br>
> > > > And why don't we have a function similar<br>
> > to *of_device_is_available*,<br>
> > > > since there will be more and more<br>
> > > > FDT based boards, this will be really helpful.<br>
> > ><br>
> > > I agree that it would be helpful. Seems that<br>
> you just<br>
> > found a function<br>
> > > that should be in a FDT framework.<br>
> > ><br>
> > > RTEMS currently only has the basic libfdt<br>
> functions and<br>
> > some RTEMS<br>
> > > specific ones. The of_... functions belong<br>
> to the FreeBSD<br>
> > "Open Firmware<br>
> > > Bus" which is an abstraction layer on top of<br>
> FDT. It would<br>
> > be great to<br>
> > > identify useful ones and port them or<br>
> provide an RTEMS<br>
> > implementation.<br>
> > > Like already discussed this could be part of<br>
> a GSoC project.<br>
> > ><br>
> > > Best regards<br>
> > ><br>
> > > Christian<br>
> > ><br>
> > > ><br>
> > > > On Sun, Jan 5, 2020 at 12:57 AM Christian<br>
> Mauderer<br>
> > > <<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><br>
> <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><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><br>
> <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><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><br>
> <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><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><br>
> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>>> wrote:<br>
> > > ><br>
> > > > On 04/01/2020 09:32, Niteesh wrote:<br>
> > > > > We could now run RTEMS on Rpi3. I<br>
> tried examples<br>
> > from the<br>
> > > samples<br>
> > > > > section and they run<br>
> > > > > fine. But still, a lot of<br>
> functionality has to<br>
> > tested since it<br>
> > > > uses the<br>
> > > > > RPI2 BSP. To test these examples<br>
> > > > > I used a simple driver for the AUX.<br>
> > > > > The documentation from BCM link<br>
> > > > ><br>
> > > > <br>
> > > <br>
> > <br>
> <<a href="https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf" rel="noreferrer" target="_blank">https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf</a>> (pg<br>
> > > > > no 10) states that<br>
> > > > > <br>
> > > > ><br>
> > > > > *The implemented UART is not a 16650<br>
> > compatible UART However<br>
> > > > as far<br>
> > > > > as possible the first 8 control<br>
> and status<br>
> > registers are<br>
> > > laid out<br>
> > > > > like a 16550 UART.*<br>
> > > ><br>
> > > > It also tells<br>
> > > ><br>
> > > > "Al 16550 register bits which are<br>
> not supported<br>
> > can be<br>
> > > written but<br>
> > > > will be ignored and read back as 0.<br>
> All control bits for<br>
> > > simple UART<br>
> > > > receive/transmit operations are<br>
> available."<br>
> > > ><br>
> > > > So I would expect that not everything<br>
> works like<br>
> > expected (for<br>
> > > example<br>
> > > > setting DCD, DSR, DTR, RI - they are<br>
> not there for<br>
> > the mini<br>
> > > UART) but<br>
> > > > the basic stuff should work.<br>
> > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > My question is can we use the<br>
> existing ns16550<br>
> > driver or<br>
> > > should I<br>
> > > > create<br>
> > > > > a new one? I also checked the<br>
> address of the<br>
> > registers the<br>
> > > offsets<br>
> > > > don't<br>
> > > > > seem right to me, but someone should<br>
> check and<br>
> > correct me if<br>
> > > I am<br>
> > > > wrong. <br>
> > > ><br>
> > > > If you compare the registers in the<br>
> existing driver<br>
> > > > (NS16550_RECEIVE_BUFFER, ... in<br>
> ns16550_p.h) and the<br>
> > one in<br>
> > > the BCM<br>
> > > > datasheet the registers look very<br>
> similar (at least<br>
> > from the<br>
> > > position /<br>
> > > > function). I haven't done a bit by bit<br>
> comparison<br>
> > yet. Please<br>
> > > note that<br>
> > > > you have to do a conversion between<br>
> the defines and<br>
> > register<br>
> > > addresses.<br>
> > > > The define gives you a register index<br>
> for a 32bit<br>
> > register. So<br>
> > > you have<br>
> > > > to multiply by 4 to get an address.<br>
> The driver is<br>
> > designed<br>
> > > that you<br>
> > > > provide a setRegister and getRegister<br>
> function that<br>
> > can do this<br>
> > > > conversion.<br>
> > > ><br>
> > > > Where did you find differences?<br>
> > > ><br>
> > > > I would suggest to just try the driver.<br>
> > > ><br>
> > ><br>
> > ><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>
> > --<br>
> > --------------------------------------------<br>
> > embedded brains GmbH<br>
> > Herr Christian Mauderer<br>
> > Dornierstr. 4<br>
> > D-82178 Puchheim<br>
> > Germany<br>
> > email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
> > <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>><br>
> > Phone: +49-89-18 94 741 - 18<br>
> > Fax: +49-89-18 94 741 - 08<br>
> > PGP: Public key available on request.<br>
> ><br>
> > Diese Nachricht ist keine geschäftliche Mitteilung<br>
> im Sinne des<br>
> > EHUG.<br>
> ><br>
> <br>
> -- <br>
> --------------------------------------------<br>
> embedded brains GmbH<br>
> Herr Christian Mauderer<br>
> Dornierstr. 4<br>
> D-82178 Puchheim<br>
> Germany<br>
> email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
> Phone: +49-89-18 94 741 - 18<br>
> Fax: +49-89-18 94 741 - 08<br>
> PGP: Public key available on request.<br>
> <br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne<br>
> des EHUG.<br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>