Raspberrypi3: AUX Uart driver
Christian Mauderer
christian.mauderer at embedded-brains.de
Mon Jan 13 08:20:43 UTC 2020
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.gn at gmail.com
> <mailto:gsnb.gn at gmail.com>> wrote:
>
> On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer
> <list at c-mauderer.de <mailto: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>
> > <mailto: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.
> >
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
--
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at 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.
More information about the devel
mailing list