Actions
Forum Thread Details
  • Replies 3 replies
  • Subscribers 176 subscribers
  • Views 287 views
  • Users 0 members are here
Related

MiniZed fundamental documentation?

embeddeddesigner

I have been trying to educate myself for a couple of weeks on MiniZed  architecture and design possibilities, but have been frustrated by gaping holes  in the documentation that came with it (or that I have since found on-line). I  am aware that the user can re-configure the hardware in many different ways but  will restrict my question to that hardware architecture provided by the factory.

 

  1. What peripherals are burned into the programmable logic (PL) and how do I access them (whether hardware registers or BSP function calls)?
  2. What is the boot process? I have read that apart from a boot ROM which is hidden from the programmer, the PS contains only RAM, so everything must be transferred there from outside before it can be executed. I have read  elsewhere that the boot ROM loads and executes the FSBL, but still don't know how control gets from there to top of my main() function.
  3. Why does it need so many non-volatile memory storage devices? I am aware of a:

 

  • QSPI NOR flash (128 Mb)
  • eMMC (8 GB)
  • SD card (which you have to buy and install yourself)
  • USB thumb drive (ditto)

 

I know access speed vs size is part of the equation, as is the ability to remove media and transfer stuff to other systems, but is there a strategy that explains the role of each part?

 

4.     What resources are provided on each device? Why are they on that chip (and not concentrated in one place)?

 

Is this stuff written down anywhere?  If so, how do I find it?

 

Thanks for any help you can lend.

  • Good questions and unfortunately the answers are scattered across many forums and Zynq documents.  MiniZed is a development board, specifically for single-core Zynq, and as such it is an entry-level device.  Fortunately this means that there is a lot of training material that Avnet created specifically for MiniZed,  Still, some concepts such as the FSBL and boot strategies are not delved into very deeply because there is a lot of Xilinx material available on the subject and because MiniZed is relatively simple in this regard.  Compared to other Zynq devices that can boot from many sources, the MiniZed boot mode switch only allows you to select between booting from JTAG or from the QSPI flash.  The boot modes, options and operation and described in many Xilinx documents, but the Zynq7000 TRM is a good one https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf .

    Even though this is not a MiniZed option, you may well ask why you cannot boot the 7007S device directly from eMMC, while booting from SD card is an option and those two seem to be quite similar.  As I understand it, the internal bootRom code does not support eMMC, while SD card boot drivers may be more generic and are therefore supported.  Still, booting directly from an eMMC or SD card is primarily done in development and not in a production system.  These devices are less reliable and since users may write to these or corrupt them, it is not unusual that one has to recover an eMMC partition after a bad power/access sequence.  The small (and faster) QSPI device is reliable and that is why you should have your fallback code stored there.

    So the MiniZed boot sequence is rather generic and typically the FSBL loads from QSPI flash.  This code typically configures the PL with the bitstream that it also finds in QSPI.  Then it tries to load an image.ub from eMMC.  If it is not found or is corrupt, the user is notified, otherwise that image.ub is loaded and executed.  In the factory image, you can revert to the image.ub in QSPI by interrupting the boot process and entering "run boot_qspi".  That image is smaller so it can fit in QSPI, so it does not load the wireless drivers for Wi-Fi and Bluetooth, for instance.  A useful improvement on the boot process would be to try and load the PL bitstream from eMMC, and to only load the one in QSPI in that one is not found.  In this way your latest updates to the executable and PL will be in eMMC, while you will never touch the fallback images in QSPI.

    In terms of your questions:

    1) Apart from the external memories, the PS peripherals are hardened in the Zynq device and though you can create your own in the PL, in the MiniZed production image the PL is mostly a pass-through to the hardware peripherals, such as LEDs, the button, the accelerometer/temperature sensor and the Wi-Fi/Bluetooth peripheral.

    2) I described some of the boot process above, but to get to your main() function you should follow some tutorials.  You can build a standalone image that will boot directly to your executable, but it will be limited in its ability to communicate using Wi-Fi and other drivers that are supported under Linux.  Under Linux you can auto-boot and run your executable directly.  Or you can invoke it from the command line via a serial terminal.

    3) In terms of the storage devices, QSPI is the small reliable non-volatile storage, while eMMC or and SD card allows for larger files and user storage.  MiniZed does not have a built-in SD card, but I have used one as a PMOD.  You can modify your Linux boot process to support such a device if you prefer it over eMMC, though eMMC is similar and very convenient, especially when you copy files over Wi-Fi. Having a USB interface to Zynq, as to most embedded processors, is useful.  One option is to use it for a "thumb drive" memory device.  If you mess up your QSPI or need to get data into your device without Wi-Fi, using a USB memory device can be very useful on a development board.

    4) The resources of each device are documented in their datasheets of course, but maybe I do not understand your question of why they are in that chip.  These architectures have evolved to be as they are and they keep evolving.

     

    The MiniZed page at MiniZed  has a "Reference Designs" tab where there are many convenient tutorials and examples, while the "Technical Documents" tab contains useful MiniZed-specific documents.

     

    Regards,

    Stefan

  • in reply to stefanrousseau

    Stephan,

    I thank you as well.  I will try to re-phrase my questions but that will take some time.