Valid ranges of tuning parameters for different setting of CR132, PHYs ... /Jiri

The QuadSPI bootloader found in the MQX installation folder needs an SD card that contains the images to load in iRAM or DDR. This means that the bootloader does not flash the application in QSPI memory, and using this bootloader in the field implies the need of an SD card every time the application needs to restart. NOTE: This document uses as reference MQX 4.1.1 The attached project is a modified bootloader_vybrid_qspixip project that works in the next way: The bootloader and applications are stored in QuadSPI memory. An application or bootloader upgrade can be performed, placing the new images in an SD card. The SD card is needed only to re-flash the QuadSPI memory. If and SD card is detected by the bootloader at startup and correct configurations and images are found, the bootloader will flash the images in QuadSPI. If it is not detected, the bootloader will execute the current image found in QuadSPI memory. The next figures show an example of the implementation. The BootROM code loads the MQX Bootloader from QuadSPI in iRAM.  When the MQX Bootloader starts, it checks if there is a mounted SD. If the SD contains valid application binary files and a valid configuration file it flash the images into the SD. BSP Changes To get this behavior a simple change in the QuadSPI driver from the BSP is required. In the file qspi_quadspi.c file of the BSP change line 898 to this: quadspi_reg_ptr->BUF3CR =     (quadspi_reg_ptr->BUF3CR & ~QuadSPI_BUF3CR_ADATSZ_MASK)  | QuadSPI_BUF3CR_ADATSZ(128);  /* AHB prefetch size: 128*8byte */ The attached file contains the  modified files that have to be used in the MQX bootloader_vybrid_qspixip project.

The attached project shows a configuration for the DAC and its functionality is explained in the below points: The PDB triggers the next DAC conversion. The DAC features an internal buffer (DAC_DATx) that contains that data to be converted. The DAC data to be converted is determined by  an internal pointer. This internal pointer increases or moves to the next element in the buffer on every PDB trigger The DAC uses the Data Buffer as normal mode. This means that the buffer works as a circular buffer. When the internal pointer reaches some point in the internal buffer, the DMA is triggered and it transfers the new data from an iRAM buffer to the DAC internal buffer. In this specific example the DMA treats the source as a circular buffer, because the source buffer size is 512 bytes but the destination (DAC_DATx) buffer is 8 bytes. The below figure represents the configuration of the example: The frequency of each output sample is determined by the source frequency of the PDB and the DACINT value. Sample_Output_Frequency =  Source_Frequency/ [(PDB_MULT * PDB_PRESCALER) * (DACINT + 1)] In the attached example the Bus Clock = 66MHz., PDB_MULT = 1 ,  PDB_PRESCALER = 128, DACINT = 63 For the 256 elements to convert the frequency of the output signal is 31.47Hz. (Sine Wave)

Unofficial User Manual for Rev.G Vybrid Tower board. (Skip page 1 if not loading properly - only title there.)

The VYBRID_SAMPLE_CODE from the website includes an DRAM init Script for the DS-5 Debugger. However it seems it doesn't correctly initialize the Vybrid Tower Samsung Memory. I modified some register settings and got this script works now for my Vybrid Tower Kit. Care must be taken when you again initialize clocks etc in your C Project because most of PLLs etc are already setup  in the script. Regards, Hans-Peter

Here is a quick summary at booting u-boot on the  TWR-VF65GS10 Vybrid tower board. This is an adaptation of u-boot on the i.MX6 sabre sd platform in a few commands for Vybrid, now that mainline u-boot has proper support. This assumes you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get u-boot sources We will use git to fetch the U-Boot sources:   $ git clone git://git.denx.de/u-boot.git This should create a u-boot directory with all the latest sources. Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v2*', and git checkout <the-desired-tag>. Vybrid support in "mainline" u-boot is fairly recent so you will need a tag no older than v2013.07. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd u-boot   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make vf610twr_config   $ make This should create a number of files, including u-boot.imx. Put on SD U-boot should reside at offset 1024B of your SD card. To put it there, do:   $ dd if=u-boot.imx of=/dev/<your-sd-card> bs=1k seek=1   $ sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your Vybrid tower board, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data, power up the platform and you should see something like: U-Boot 2013.04-00300-g3d9138e (Jul 09 2013 - 11:57:02) CPU:   Freescale Vybrid VF610 at 396 MHz Reset cause: WDOG Board: vf610twr DRAM:  128 MiB WARNING: Caches not enabled MMC:   FSL_SDHC: 0 In:    serial Out:   serial Err:   serial Net:   Phy not found PHY reset timed out FEC Warning: failed to set MAC address Hit any key to stop autoboot:  0 => Enjoy! See also... u-boot most common mission is to boot the Linux kernel. See this post for details on how to do it (on i.MX6). If you plan to compile u-boot often, you might want to use a C compiler cache; see this post. Running a Script in U-boot u-boot on the i.MX6 sabre sd platform in a few commands