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