raspberry BSP: Maybe there is a bug in the linker file?

Sun Dec 22 08:51:54 UTC 2019

PS: Please create a new mailing list thread for discussing details
regarding the UART driver. The subject of this one just isn't correct
any more.

On 22/12/2019 09:50, Christian Mauderer wrote:
> Hello Niteesh,
> 
> thanks for the detailed information. I agree that this is a completely
> different hardware module and will need a different driver.
> 
> The data sheet (by the way: one of the worst I've ever seen) tells that
> the Mini UART has "16550 like registers" that are "as far as possible
> [...] like a 16550". So maybe the driver from
> bsps/shared/dev/serial/ns16550.c can be used or extended.
> 
> By the way: It's a really odd idea to integrate two completely different
> UARTs into one chip. I know chips with variations but completely
> different is unusual. Especially because most serial peripherals are
> small and need very few chip area compared to memory. But maybe they had
> a reason ...
> 
> Best regards
> 
> Christian
> 
> 
> On 22/12/2019 08:12, Niteesh wrote:
>> On raspberry pis equipped with the wireless/Bluetooth module, the PL011
>> is connected to the Bluetooth module,
>> and the mini UART is used as the primary UART. On all other models, the
>> PL011 is used as the primary UART.
>>
>> The mini UART has smaller FIFOs. Combined with the lack of flow control,
>> this makes it more prone to losing characters at higher baudrates. It is
>> also generally less capable than the PL011, mainly due to its baud rate
>> link to the VPU clock speed.
>>
>> The particular deficiencies of the mini UART compared to the PL011 are :
>>
>> No break detection
>> No framing errors detection
>> No parity bit
>> No receive timeout interrupt
>> No DCD, DSR, DTR or RI signals
>>
>> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>> the official doc from broadcom, this is what I used while developing
>> drivers for bare metal project.
>>
>>
>>
>> On Sun, Dec 22, 2019 at 1:56 AM Christian Mauderer <list at c-mauderer.de
>> <mailto:list at c-mauderer.de>> wrote:
>>
>>     I haven't had a look at the different types of UARTS yet. What is the
>>     difference? What do you use as reference?
>>
>>     If it is just a variant of an existing driver, the existing one should
>>     be extended to support both variants.
>>
>>     On 21/12/2019 20:45, Niteesh wrote:
>>     > On inspecting the code, the driver is for PL011. We have to write a
>>     > driver for the mini uart.
>>     > which we will have start from scratch. So, how do you want the
>>     structure
>>     > to be?
>>     >
>>     > The code of PL011 can be improved. We could use gpio functions to
>>     > configure pins.
>>     > And also many of the UART values are set in place instead of using the
>>     > appropriate function, for example
>>     > the usart_set_baud is empty and the baud rate is set directly in the
>>     > init function.
>>     > What do you think about these changes? Should we change them also?
>>     > On Sun, Dec 22, 2019 at 12:25 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 21/12/2019 19:26, Niteesh wrote:
>>     >     > There is already a PL011 driver in the arm shared section.
>>     should we
>>     >     > just import it?
>>     >
>>     >     If you say "import" and you mean "use" and not "copy": yes,
>>     that would
>>     >     be great.
>>     >
>>     >     >
>>     >     > On Sat, Dec 21, 2019 at 10:46 PM Niteesh <gsnb.gn at gmail.com
>>     <mailto:gsnb.gn at gmail.com>
>>     >     <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>>
>>     >     > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>>     <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>>>> wrote:
>>     >     >
>>     >     >     Shall I start writing a driver for raspberrypi3 PL011?
>>     >     >
>>     >     >
>>     >     >     On Sat, Dec 21, 2019 at 8:40 PM 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>>
>>     >     <mailto: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 19/12/2019 15:05, Christian Mauderer wrote:
>>     >     >         > On 19/12/2019 14:27, Sebastian Huber wrote:
>>     >     >         >> On 19/12/2019 14:24, Christian Mauderer wrote:
>>     >     >         >>> Hello,
>>     >     >         >>>
>>     >     >         >>> triggered by the discussion regarding RTEMS on
>>     >     raspberrypi 3
>>     >     >         I did some
>>     >     >         >>> tests. I haven't been able to start a RTEMS on
>>     my Pi 1
>>     >     if I
>>     >     >         tried a
>>     >     >         >>> version after commit
>>     >     >         c5fd79cd4704a4270ba0114a1009ab8556f997c9 from
>>     >     >         >>> 29.07.2019. Right before it everything works as
>>     expected.
>>     >     >         >>>
>>     >     >         >>> The commit changes the memory locations. From what I
>>     >     >         understood, the
>>     >     >         >>> bootloader on a raspberry always jumps to
>>     address 0x8000
>>     >     >         after loading
>>     >     >         >>> the application. So I'm not convinced that the
>>     change is
>>     >     >         correct.
>>     >     >         >>
>>     >     >         >> Is the 0x8000 a fixed address or you configure
>>     this in
>>     >     a boot
>>     >     >         image header?
>>     >     >         >>
>>     >     >         >
>>     >     >         >>From what I've seen the bootloader just uses a fixed
>>     >     address.
>>     >     >         All guides
>>     >     >         > that I've found just use objcopy to generate a binary
>>     >     from the
>>     >     >         elf files
>>     >     >         > without adding a header. For example a guide for
>>     RTEMS:
>>     >     >         >
>>     >     >         >
>>     >     >         >
>>     >     >       
>>     >   
>>       http://alanstechnotes.blogspot.com/2013/03/running-your-first-rtems-program-on.html
>>     >     >         >
>>     >     >         > A FreeRTOS port mentions this behavior explicitly in a
>>     >     comment
>>     >     >         in the
>>     >     >         > linker file:
>>     >     >         >
>>     >     >         >
>>     >     >         >
>>     >     >       
>>     >   
>>       https://github.com/jameswalmsley/RaspberryPi-FreeRTOS/blob/master/raspberrypi.ld#L17
>>     >     >         >
>>     >     >         > The "graphics processor" is no typo here. It seems the
>>     >     >         initialization is
>>     >     >         > really done by the graphics processor on the pi.
>>     >     >         > _______________________________________________
>>     >     >         > devel mailing list
>>     >     >         > devel at rtems.org <mailto:devel at rtems.org>
>>     <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>>     >     <mailto:devel at rtems.org <mailto:devel at rtems.org>
>>     <mailto:devel at rtems.org <mailto:devel at rtems.org>>>
>>     >     >         > http://lists.rtems.org/mailman/listinfo/devel
>>     >     >         >
>>     >     >
>>     >     >         I just found an option: It is possible to set a
>>     >     "kernel_address"
>>     >     >         in the
>>     >     >         config.txt:
>>     >     >
>>     >     >
>>     >     >       
>>     >   
>>       https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md
>>     >     >
>>     >     >         So the start address can be changed and maybe the
>>     adaption to
>>     >     >         the linker
>>     >     >         file isn't necessary.
>>     >     >
>>     >
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 