Raspberrypi3: AUX Uart driver

Sun Jan 12 20:56:11 UTC 2020

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?
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?
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?

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.

On Mon, Jan 13, 2020 at 1:56 AM Niteesh <gsnb.gn at gmail.com> wrote:

> On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer <list at 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 <list at c-mauderer.de
>> > <mailto:list at 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.
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200113/b0a5ebf1/attachment-0001.html>