[PATCH] ZYNQ BSP

[Claus, Ric]

Hello Sebastian,

  Thanks for the notification.  I will take a more detailed look as soon as have some time.

  Meanwhile, a few questions:  
- 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.
- 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!
- Maybe I need to dig deeper, but I don't see any code to boot the other core(s).
- 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.
- 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?

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