On 12/01/2020 21:56, Niteesh wrote: > The following questions are not related to uart, but they kept bugging > me for a while, and want to clear them > > 1) If the linker places the text section at 0x200000 what happens all > the memory below that? Are they left empty > or are they used for things like stack and ISR table?
This memory will be empty. I didn't have an exact look but I think that the MMU will generate a memory access error when you try to read / write it. This gives a bit of a NULL-pointer protection. If the area is bigger the protection will work for a bigger offset. > 2) According to the docs, the cpu start executing instruction from > kernel_address(0x200000) then why is the > start address at 0x200080? I looked the dump 0x200000 - > 0x200040(bsp_section_start_begin) > contains low level initialization like cache and mmu setup, which is > then followed by the vector table. In OS environment > the loader would load the elf file and read the start address and jump > to it, but here we only have a binary file, then > why do we care about the start address? I would have expect that the vector table is at at 0x200000. For most controllers I met the first vector is the reset vector which then jumps to the start address. > 3) Does the loader(start.elf) start placing the image from address 0, > for rpi the RAM starts at address 0x0 so, > does the loader copy word by word from the binary file to the RAM? As far as I understood it, the loader should copy the kernel.img directly to the kernel_address given in the config file. There should be no modification. So it doesn't touch 0 if you set kernel_address to something else. > > English is not my native language, and it is really hard for me to > express my question's so please if you don't understand the question > do let me know. No problem. I'm not a native speaker too. My mother tongue is German. There are a lot of people on this list (and other OSS mailing lists) that don't speak English as their mother tongue. So it's quite a normal case. Best regards Christian > > On Mon, Jan 13, 2020 at 1:56 AM Niteesh <gsnb...@gmail.com > <mailto:gsnb...@gmail.com>> wrote: > > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer > <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. > > > > > 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? > > 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. > > > > > 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>>> 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 > 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 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
