[PATCH] user: Add xilinx-zynq BSP details

[Joel Sherrill]

Looks good to me other than Gedare's comments. Glad to see it.

I don't think it goes in the Zynq section but when using networking
with qemu, you tend to need to forward ports. Is there a logical
location for general BSP independent information on using Qemu
with RTEMS?



On Thu, Sep 10, 2020 at 10:30 AM Gedare Bloom <gedare at rtems.org> wrote:

> Thanks for the doco. Just a few comments.
>
> On Mon, Sep 7, 2020 at 9:30 PM <chrisj at rtems.org> wrote:
> >
> > From: Chris Johns <chrisj at rtems.org>
> >
> > ---
> >  user/bsps/arm/xilinx-zynq.rst | 114 +++++++++++++++++++++++++++++++++-
> >  1 file changed, 112 insertions(+), 2 deletions(-)
> >
> > diff --git a/user/bsps/arm/xilinx-zynq.rst
> b/user/bsps/arm/xilinx-zynq.rst
> > index 909b23e..365c336 100644
> > --- a/user/bsps/arm/xilinx-zynq.rst
> > +++ b/user/bsps/arm/xilinx-zynq.rst
> > @@ -1,8 +1,118 @@
> >  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >
> > -.. Copyright (C) 2019 TBD
> > +.. Copyright (C) 2020 Chris Johns (chrisj at rtems.org)
> >
> >  xilinx-zynq
> >  ===========
> >
> > -TODO.
> > +This BSP supports the Xilinx Zynq range of devices. This family of
> > +devices contain the same ARM hard IP and the different parts have
> > +different sizes of programable logic.
> programmable?
> (Might be a UK/AU English thing, if so let me know :).)
>
> > +
> > +The BSP defaults may need to be adjusted using ``configure`` BSP
> > +options to match the size of memory your board may have.
> > +
> > +Bootloader
> > +----------
> > +
> > +The bootloader initialises the Zynq device. The Xilinx tool provide an
> "tools provide" or "tool provides"
>
> > +interface to configure the hardware. This is includes the buses,
> delete 'is'
>
> > +clocks, memory and UART board rate. The output of this is called
> > +``ps7_init`` and it a C file. The Xilinx SDK builds a first stage boot
> "it is a"
>
> > +loader (FSBL) using this file.
> > +
> > +The U-Boot boot loader has it's own FSBL called ``MLO`` to initialise
> no apostrophe: its
>
> > +the hardware.
> > +
> > +Clocks
> > +------
> > +
> > +An application can provide a function called:
> > +
> > +.. code-block:: none
> > +
> > +    uint32_t a9mpcore_clock_periphclk(void);
> > +
> > +to return the peripheral clock. Normally this is half the CPU
> > +clock. This function is declared ``weak`` so you can override the
> > +default behaviour by providing it in your application.
> > +
> > +Debugging with xilinx_zynq_a9_qemu
> > +----------------------------------
> > +
> > +To debug an application add the QEMU options ``-s``. If you need to
> > +debug an initialisation issue also add ``-S``. For example to debug a
> > +networking application you could use:
> > +
> > +.. code-block:: none
> > +
> > +    qemu-system-arm -M xilinx-zynq-a9 -m 256M -no-reboot -serial \
> > +        null -serial mon:stdio -nographic \
> > +       -net nic,model=cadence_gem -net vde,id=vde0,sock=/tmp/vde1 \
> > +       -kernel myapp.exe \
> > +       -s -S
> > +
> > +Start GDB with the same executable QEMU is running and connect to the
> > +QEMU GDB server:
> > +
> > +.. code-block:: none
> > +
> > +    (gdb) target remote :1234
> > +
> > +If your application is crashing set a breakpoint on the fatal error
> > +handler:
> > +
> > +.. code-block:: none
> > +
> > +    (gdb) b bsp_fatal_extension
> > +
> > +Enter continue to run the application. Running QEMU loads the
> > +executable and initialises the CPU. If the ``-S`` option is provided
> > +the CPU is held in reset. Without the option the CPU runs starting
> > +RTEMS. Either way you are connecting to set up target and all you need
> "set up the"
>
> > +to do is continue:
> > +
> > +.. code-block:: none
> > +
> > +    (gdb) c
> > +
> > +If you have a crash and the breakpoint on ``bsp_fatal_extension`` is
> > +hit, load the following a GDB script:
> delete 'a'
>
> > +
> > +.. code-block:: none
> > +
> > +    define arm-crash
> > +     set $code = $arg0
> > +     set $r0 = ((const rtems_exception_frame *) $code)->register_r0
> > +     set $r1 = ((const rtems_exception_frame *) $code)->register_r1
> > +     set $r2 = ((const rtems_exception_frame *) $code)->register_r2
> > +     set $r3 = ((const rtems_exception_frame *) $code)->register_r3
> > +     set $r4 = ((const rtems_exception_frame *) $code)->register_r4
> > +     set $r5 = ((const rtems_exception_frame *) $code)->register_r5
> > +     set $r6 = ((const rtems_exception_frame *) $code)->register_r6
> > +     set $r7 = ((const rtems_exception_frame *) $code)->register_r7
> > +     set $r8 = ((const rtems_exception_frame *) $code)->register_r8
> > +     set $r9 = ((const rtems_exception_frame *) $code)->register_r9
> > +     set $r10 = ((const rtems_exception_frame *) $code)->register_r10
> > +     set $r11 = ((const rtems_exception_frame *) $code)->register_r11
> > +     set $r12 = ((const rtems_exception_frame *) $code)->register_r12
> > +     set $sp = ((const rtems_exception_frame *) $code)->register_sp
> > +     set $lr = ((const rtems_exception_frame *) $code)->register_lr
> > +     set $pc = ((const rtems_exception_frame *) $code)->register_pc
> > +     set $cpsr = ((const rtems_exception_frame *) $code)->register_cpsr
> > +   end
> > +
> > +Enter the command:
> > +
> > +.. code-block:: none
> > +
> > +    (gdb) arm-crash code
> > +
> > +
> > +Enter ``bt`` to see the stack back trace.
> > +
> > +The script moves the context back to the crash location. You should be
> > +able to view variables and inspect the stack.
> > +
> > +The fatal error handler runs inside an exception context that is not
> > +the one than generated the exception.
> s/than/that
>
> > --
> > 2.24.1
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200910/100e1db7/attachment-0001.html>