[PATCH] ZYNQ BSP

Fri May 3 20:13:08 UTC 2013

On 5/3/2013 1:33 PM, Claus, Ric wrote:
> Hello Sebastian,
>
>    Thanks for the notification.  I will take a more detailed look as soon as have some time.
>
>    Meanwhile, a few questions:
Sebastian will certainly follow up but here is a stab at a few of these.
> - Why is the generated file preinstall.am in the patch?  Am I supposed to include those, too?  I thought generated files don't go in the same repository as the source code.
preinstall.am only changes when the installed set of .h files changes
which is rare enough so has been put in the repo.
> - I'm still confused on the differences between what is meant by a 'processor' and a 'core' with regards to RTEMS.  Xi Yang's stuff seems to indicate that other changes to RTEMS need to be made to support MP.  Maybe they're in and I haven't noticed yet, but otherwise, I'm trying to get to it.  Really!
Depends on the sentence and person. In the most general sense, a core is the
piece that executes instructions without peripherals. In an SMP system, you
have multiple cores.

Often though, it helps to remember that the "part" is a System on Chip with
a processor or core at the center with a set of peripherals. RTEMS is 
generally
ported to the processor/core and the BSP is responsible for the peripherals.

We use processor family and target architecture to mean the same thing.

GCC is usually focused on an instruction level/revision or ISA. In some 
cases,
this is embodied as a particular processor part number (e.g. mc68020 versus
mc68040) or ISA implementation (e.g. PowerPC 603e vs 750).

But you are likely seeing us all use the terms almost interchangeably. :)
> - Maybe I need to dig deeper, but I don't see any code to boot the other core(s).
There is currently no ARM SMP support in the tree.
> - The two Zynq boards I've worked with have two levels of cache.  I take it that your CA9 has only one level of cache?  The current RTEMS cache support for ARM needs additional functionality to handle both levels of cache independently and thus avoid unnecessary operations.
> - Sometimes it is very difficult for me to understand the intent without some help.  For example, what are the assumptions on the CPU state prior to _start()?  For the Zynq, there is a lot that must happen before getting to _start(), but your BSP doesn't seem to accommodate those.  Most of these are chip set-up, so I wouldn't think that an emulator (which I've never had a chance to play with) would be sensitive to these.  Since I'm currently working on a boot loader, I've recently been wondering whether they belong in the boot loader's domain and the BSP just assumes it did it right.  That ties the user of the BSP to the boot loader and places a requirement on the boot loader, over which one might not have control, e.g. U-Boot.
In general, if the boot loader (or simulator) takes care of it, the BSP 
won't do it again.
If someone has ever booted the board/SoC without a boot loader, then it 
will have that
type of code. Which may be disabled if there is a boot loader present.

However, I do know of cases where bootloader type initialization is 
duplicated in the
BSP and custom boot firmware. That is the system preference.

No hard requirement from RTEMS.
> - What do you mean by "a basic BSP"?  Do you want to have a MP CA9 BSP from which both your BSP and the Zynq BSP are derived (in the C++ sense)?  In that case, would an in-memory console driver like I did for the Virtex4 and 5 be adequate?
OAR uses basic BSP to refer to having initialization and shutdown plus
a console, clock, and timer driver.  This is enough to run all the tests.

It looks like he provided a real console driver for a UART. Another variant
could have a different UART.

The rest is Sebastian's to answer. In general, we do not want to duplicate
code so if it is reasonable to share, then yes, please find a way.

SMP capabilities would be layered on top of this I think.
>
> There's a lot on my plate for the foreseeable future, so I think I won't be able to play with Qemu anytime soon.  I continue to think about a solution to be able to verify the integrity of the Zynq BSP without the Xilinx code.  Since Chris J. was interested in this BSP as well, perhaps he has some thoughts on all this?
>
>    Ric
> ________________________________________
> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] On Behalf Of Sebastian Huber [sebastian.huber at embedded-brains.de]
> Sent: Friday, May 03, 2013 8:44 AM
> To: rtems-devel at rtems.org
> Subject: Re: [PATCH] ZYNQ BSP
>
> Hello Claus,
>
> I added a new BSP with Cortex-A9 MPCore support:
>
> http://git.rtems.org/rtems/commit/?id=a91dc98b5ad5ee9bc8d592c62753a467daf4e711
>
> It should be possible to use the MMU, cache, GIC and PT (Cortex-A9 MPCore
> Private Timer) support also for the Zync BSP.
>
> With that we only have to add a console driver to get a basic BSP.
>
> There is Qemu support for the Zync.  It is desirable that this BSP runs on the
> simulator to test it.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985