<div dir="ltr">The following questions are not related to uart, but they kept bugging me for a while, and want to clear them<div><br></div><div>1) If the linker places the text section at 0x200000 what happens all the memory below that? Are they left empty</div><div>or are they used for things like stack and ISR table?</div><div>2) According to the docs, the cpu start executing instruction from kernel_address(0x200000) then why is the</div><div>start address at 0x200080? I looked the dump 0x200000 - 0x200040(bsp_section_start_begin)</div><div>contains low level initialization like cache and mmu setup, which is then followed by the vector table. In OS environment</div><div>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</div><div>why do we care about the start address? </div><div>3) Does the loader(start.elf) start placing the image from address 0, for rpi the RAM starts at address 0x0 so,</div><div>does the loader copy word by word from the binary file to the RAM?</div><div><br></div><div>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</div><div>do let me know. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 1:56 AM Niteesh <<a href="mailto:gsnb.gn@gmail.com">gsnb.gn@gmail.com</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"><div dir="ltr"><div dir="ltr">On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Niteesh,<br>
<br>
On 12/01/2020 16:06, Niteesh wrote:<br>
> The only issue, I faced while using this driver is the baud divisor is<br>
> calculated <br>
> by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*<br>
> but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for Rpi3.<br>
> For testing, I assigned the baud divisor to 270 (115200 bits/s) in<br>
> ns16550-context.c,<br>
> and everything works fine.<br>
<br>
Sounds great. In NS16550_GetBaudDivisor there is already a case where<br>
the baudDivisor is calculated differently (depending on<br>
ctx->has_precision_clock_synthesizer and<br>
ctx->has_fractional_divider_register). If none of the two cases are ok<br>
for the controller you could just add another one.<br></blockquote><div>Can we pass in a function, which gets called, won't this be more flexible? because</div><div>in the future if we have some other board that has a different calculation for the baud rate</div><div>the function will take care of it.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> For console selection, my plan is to search for the aux node using<br>
> compatible<br>
> property and if its status is enabled, then initialize the AUX uart and<br>
> set the BSP_output_char<br>
> to aux_output_char, else pl011_output_char. All this will be done inside<br>
> the uart_probe function,<br>
> except for the initialization of AUX which will be done in init_ctx_aux.<br>
> And finally, call the output char<br>
> function using *BSP_output_char. Do you have any neat way to do this?<br>
<br>
I don't have an example for a similar case at hand. So: No, no neat way<br>
that I can tell you.<br>
<br>
Before you start to write code: Please take a look at the different<br>
beagle variants what is possible. Is there a variant where AUX uart<br>
would be there but shouldn't be used as a console (one of the Zeros<br>
maybe or the compute module?). How does Raspbian or FreeBSD decide which<br>
port should be used? Maybe they decide based on the commandline.txt? In<br>
such a case it would be better to just initialize all active (in the<br>
fdt) serial ports and decide based on the commandline too.<br></blockquote><div> </div><div>The Documentation says the following: </div><b>By default, on Raspberry Pis equipped with the wireless/Bluetooth</b></div><div class="gmail_quote"><b>module (Raspberry Pi 3 and Raspberry Pi Zero W), </b><b>the PL011 UART is</b></div><div class="gmail_quote"><b>connected to the Bluetooth module, while the mini UART is used as the primary UART and</b></div><div class="gmail_quote"><b>will have a Linux console on it. On all other models, the PL011 is used as the primary UART.<br><br></b><div><b>In Linux device terms, by default, /dev/ttyS0 refers to the mini UART, and /dev/ttyAMA0 refers</b></div><div><b>to the PL011. The primary UART is the one assigned to the Linux console, which depends on</b></div><div><b>the Raspberry Pi model as described above. There are also symlinks: /dev/serial0, which always</b></div><div><b>refers to the primary UART (if enabled), and /dev/serial1, which similarly always refers to the secondary UART (if enabled).</b></div><div><b><br></b></div><div>I checked in all the DTB files, by decompiling them (files are from <a href="https://github.com/raspberrypi/firmware/tree/master/boot" target="_blank">https://github.com/raspberrypi/firmware/tree/master/boot</a>).<br></div><div>In all board with support for wireless and bluetooth, the AuX is enabled and serial0 points to it. So we could use serial0</div><div>to find the correct UART port. I think this is solid enough. So, should I use this approach?</div><div><br></div><div>Or if using the command line, then we need to move the link to CONSOLE_DEVICE to console_initialize, and parse the</div><div>command line twice. If this is no problem, then we could use this approach also.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> And why don't we have a function similar 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 you just found a function<br>
that should be in a FDT framework.<br>
<br>
RTEMS currently only has the basic libfdt functions and some RTEMS<br>
specific ones. The of_... functions belong to the FreeBSD "Open Firmware<br>
Bus" which is an abstraction layer on top of FDT. It would be great to<br>
identify useful ones and port them or provide an RTEMS implementation.<br>
Like already discussed this could be part of a GSoC project.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> On Sun, Jan 5, 2020 at 12:57 AM Christian Mauderer <<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 tried examples from the samples<br>
> > section and they run<br>
> > fine. But still, a lot of functionality has to 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>
> <<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 compatible UART However<br>
> as far<br>
> > as possible the first 8 control and status registers are laid out<br>
> > like a 16550 UART.*<br>
> <br>
> It also tells<br>
> <br>
> "Al 16550 register bits which are not supported can be written but<br>
> will be ignored and read back as 0. All control bits for simple UART<br>
> receive/transmit operations are available."<br>
> <br>
> So I would expect that not everything works like expected (for example<br>
> setting DCD, DSR, DTR, RI - they are not there for the mini UART) but<br>
> the basic stuff should work.<br>
> <br>
> ><br>
> ><br>
> > My question is can we use the existing ns16550 driver or should I<br>
> create<br>
> > a new one? I also checked the address of the registers the offsets<br>
> don't<br>
> > seem right to me, but someone should check and correct me if I am<br>
> wrong. <br>
> <br>
> If you compare the registers in the existing driver<br>
> (NS16550_RECEIVE_BUFFER, ... in ns16550_p.h) and the one in the BCM<br>
> datasheet the registers look very similar (at least from the position /<br>
> function). I haven't done a bit by bit comparison yet. Please note that<br>
> you have to do a conversion between the defines and register addresses.<br>
> The define gives you a register index for a 32bit register. So you have<br>
> to multiply by 4 to get an address. The driver is designed that you<br>
> provide a setRegister and getRegister function that can do this<br>
> conversion.<br>
> <br>
> Where did you find differences?<br>
> <br>
> I would suggest to just try the driver.<br>
> <br>
</blockquote></div></div>
</blockquote></div>