Commit c12dc912 authored by Andrey Filippov's avatar Andrey Filippov

Reformatted README to fit available width

parent 1b95dd52
Ezynq project is started to create a bootloader for systems based on the Xilinx Zynq SoC without the inconvenience of the non-free tools and/or files. Ezynq project is started to create a bootloader for systems based on the Xilinx Zynq SoC without
The goal is not just to "free" the code, but to provide users with the higher degree of flexibility in fine-tuning of the configuration parameters. the inconvenience of the non-free tools and/or files.
The goal is not just to "free" the code, but to provide users with the higher degree of flexibi-
Initial release includes configuration for the MicroZed board we used for this software development, we plan to add support for more boards, including lity in fine-tuning of the configuration parameters.
Elphel NC393 camera - the reason we started this project.
Initial release includes configuration for the MicroZed board we used for this software develop-
Ezynq partially duplicates functionality of Xilinx proprietary tools - bootgen and fsbl (first stage boot loader). It does not support secure boot ment, we plan to add support for more boards, including Elphel NC393 camera - the reason we
functionality (that we have no interest in) and loading the FPGA (PL) part with the bitstream - we plan to do that under control of the operating system started this project.
as we did in our earlier products, if needed this feature can be implemented using u-boot.
Ezynq partially duplicates functionality of Xilinx proprietary tools - bootgen and fsbl (first
This software consists of Python program that processes data from u-boot configuration files (configuration parameters start with CONFIG_EZYNQ_ prefix) stage boot loader). It does not support secure boot functionality (that we have no interest in)
that are collected in include/autoconf.mk (it is generated by "make include/autoconf.mk") and generates several output files: and loading the FPGA (PL) part with the bitstream - we plan to do that under control of the
operating system as we did in our earlier products, if needed this feature can be implemented
1 - the header file (default name boot_head.bin) formatted for the Zynq ROM Boot Loader (RBL) according to section 6.3.2 of Xilinx UG585 - using u-boot.
"Zynq-7000 AP SoC Technical Reference Manual". This file uses RBL register initialization feature to set registers (MIO, DDR) that can be written before
system clocks and DDR memory are initialized - that requires polling status information and waiting for particular states are reached. This software consists of Python program that processes data from u-boot configuration files
(configuration parameters start with CONFIG_EZYNQ_ prefix) that are collected in
2 - ezynq.c file to be compiled and linked with other u-boot files. All ezynq-specific code is called by a modified version of the arch_cpu_init() include/autoconf.mk (it is generated by "make include/autoconf.mk") and generates several output
function - the only difference from the u-boot version for Xilinx Zynq designed to be used with the proprietary FSBL program. This code finishes files:
register initialization (contrary to RBL it can wait for certain states are reached) and performs relocation of the code from the on-chip memory (OCM) to
the main system memory, u-boot takes over from there. Optionally the debug code is generated that controls the LED state at different stages of the 1 - the header file (default name boot_head.bin) formatted for the Zynq ROM Boot Loader (RBL)
boot process and outputs register states to the serial port. according to section 6.3.2 of Xilinx UG585 -"Zynq-7000 AP SoC Technical Reference Manual". This
file uses RBL register initialization feature to set registers (MIO, DDR) that can be written
3 - html output file (default name u-boot.html) that lists the configuration parameters used (specified and calculated from others), used PLLs and clocks, before system clocks and DDR memory are initialized - that requires polling status information
configured interfaces and their usage of the MIO pins. It then lists all the registers written by RBL and written/tested during execution of the and waiting for particular states are reached.
arch_cpu_init(). Most of the registers are listed in the same sequence as they are set in hardware, the very last ones show registers that may be
set/tested multiple times (as related to UART debug data output). The software keeps track of the register data writes and uses the default values 2 - ezynq.c file to be compiled and linked with other u-boot files. All ezynq-specific code is
provided in UG585, so when only some bit fields of the whole register need to be modified, software relies on the calculated previous value and does not called by a modified version of the arch_cpu_init() function - the only difference from the
perform read operations on the actual registers before writing the modified data back. u-boot version for Xilinx Zynq designed to be used with the proprietary FSBL program. This code
finishes register initialization (contrary to RBL it can wait for certain states are reached)
The u-boot version designed to be used with FSBL relied on it to initialize registers, clocks and DRAM memory, load u-boot image to DRAM at address and performs relocation of the code from the on-chip memory (OCM) to the main system memory,
0x4000000 and pass control there. FSBL itself was loaded by RBL into on-chip memory (OCM) at address 0, having 192K of the total 256K mapped to u-boot takes over from there. Optionally the debug code is generated that controls the LED state
0x0..0x2ffff and the remaining 64K - to the upper 0xffff0000..0xffffffff, the same mapping is passed to u-boot that uses the high OCM memory for stack at different stages of the boot process and outputs register states to the serial port.
initially and later remaps all of the OCM to 0xfffc0000.0xffffffff. Starting from 0x4000000 u-boot relocates itself to address zero and runs there.
3 - html output file (default name u-boot.html) that lists the configuration parameters used
When using Ezynq the size of the u-boot image is limited to 192K - it is all what Zynq RBL can load by itself. It is quite a lot (192K is just for code, (specified and calculated from others), used PLLs and clocks, configured interfaces and their
data uses DRAM and is not limited by the OCM) so u-boot can be loaded in a simple one-stage process without the need of the SPL when first a mini- usage of the MIO pins. It then lists all the registers written by RBL and written/tested during
version of u-boot is loaded, and that version later loads the full u-boot to DRAM. execution of the arch_cpu_init(). Most of the registers are listed in the same sequence as they
are set in hardware, the very last ones show registers that may be set/tested multiple times (as
Generated arch_cpu_init() starts running in OCM, initializes DRAM, copies itself (first 192K OCM) to DRAM to 0x4000000.0x402ffff (using just C, related to UART debug data output). The software keeps track of the register data writes and
not assembly code) and than adds 0x4000000 to the program counter. In this state it is possible to map DRAM to the 0x0.0x2ffff instead of the OCM and uses the default values provided in UG585, so when only some bit fields of the whole register
copy 0x4000000.0x402ffff back to 0x0.0x2ffff and so return from the function arch_cpu_init() gets the execution to the same low address where it need to be modified, software relies on the calculated previous value and does not perform read
started, but now it is in the DRAM, not in the OCM. U-boot relocation functionality nicely skips actual relocation (as source and destination addresses operations on the actual registers before writing the modified data back.
are the same) and the data memory is initialized when 192K OCM limit is not in effect anymore.
The u-boot version designed to be used with FSBL relied on it to initialize registers, clocks
and DRAM memory, load u-boot image to DRAM at address 0x4000000 and pass control there. FSBL
itself was loaded by RBL into on-chip memory (OCM) at address 0, having 192K of the total 256K
mapped to 0x0..0x2ffff and the remaining 64K - to the upper 0xffff0000..0xffffffff, the same
mapping is passed to u-boot that uses the high OCM memory for stack initially and later remaps
all of the OCM to 0xfffc0000.0xffffffff. Starting from 0x4000000 u-boot relocates itself to
address zero and runs there.
When using Ezynq the size of the u-boot image is limited to 192K - it is all what Zynq RBL can
load by itself. It is quite a lot (192K is just for code, data uses DRAM and is not limited by
the OCM) so u-boot can be loaded in a simple one-stage process without the need of the SPL when
first a mini-version of u-boot is loaded, and that version later loads the full u-boot to DRAM.
Generated arch_cpu_init() starts running in OCM, initializes DRAM, copies itself (first 192K
OCM) to DRAM to 0x4000000.0x402ffff (using just C, not assembly code) and than adds 0x4000000 to
the program counter. In this state it is possible to map DRAM to the 0x0.0x2ffff instead of the
OCM and copy 0x4000000.0x402ffff back to 0x0.0x2ffff and so return from the function
arch_cpu_init() gets the execution to the same low address where it started, but now it is in
the DRAM, not in the OCM. U-boot relocation functionality nicely skips actual relocation (as
the source and destination addresses are the same) and the data memory is initialized when 192K
OCM limit is not in effect anymore.
Installation Installation
When Ezynq repository is cloned, there is install_uboot.sh script in the top directory. Running this script clones u-boot-xlnx and then adds links to the When Ezynq repository is cloned, there is install_uboot.sh script in the top directory. Running
files in Ezynq sub-directory u-boot-tree from the corresponding directories of the u-boot-xlnx, that allows to update Ezynq project files by "git pull". this script clones u-boot-xlnx and then adds links to the files in Ezynq sub-directory
u-boot-tree from the corresponding directories of the u-boot-xlnx, that allows to update Ezynq
project files by "git pull".
These links created by install_uboot.sh add new configuration files and replace 3 files in the u-boot-xlnx: These links created by install_uboot.sh add new configuration files and replace 3 files in the
u-boot-xlnx:
* boards.cfg - adding zynq-microzed there * boards.cfg - adding zynq-microzed there
* arch/arm/cpu/armv7/zynq/cpu.c - disabling arch_cpu_init() there if configuration was made for Ezynq * arch/arm/cpu/armv7/zynq/cpu.c - disabling arch_cpu_init() there if configuration was made for
* arch/arm/cpu/armv7/zynq/Makefile - to add autogenerated (not in repository) arch/arm/cpu/armv7/zynq/ezynq.c Ezynq
* arch/arm/cpu/armv7/zynq/Makefile - to add autogenerated (not in the repository)
arch/arm/cpu/armv7/zynq/ezynq.c
New files include: New files include:
* include/configs/zynq_microzed.h configuration parameters for u-boot features, described in u-boot README file * include/configs/zynq_microzed.h configuration parameters for u-boot features, described in
* include/configs/ezynq/ezynq_MT41K256M16RE125.h - Ezynq configuration parameters containing Micron DDR3 memory datasheet for the memory used by MicroZed u-boot README file
board * include/configs/ezynq/ezynq_MT41K256M16RE125.h - Ezynq configuration parameters containing
* include/configs/ezynq/ezynq_XC7Z010_1CLG400.h - Ezynq configuration parameters containing Xilinx Zynq datasheet data for the SoC used by MicroZed board Micron DDR3 memory datasheet for the memory used by MicroZed board
* include/configs/ezynq/ezynq_XC7Z010_1CLG400.h - Ezynq configuration parameters containing Xilinx Zynq datasheet data for the SoC used by MicroZed board * include/configs/ezynq/ezynq_XC7Z010_1CLG400.h - Ezynq configuration parameters containing
* include/configs/ezynq/zed_ezynq.h - rest of the Ezynq configuration parameters (it has the include lines for the 2 datasheet files listed above) Xilinx Zynq datasheet data for the SoC used by MicroZed board
* makeuboot - script that configures u-boot for the microzed board, creates include/autoconf.mk, runs ezynqcfg.py to create Ezynq code (RBL header and * include/configs/ezynq/ezynq_XC7Z010_1CLG400.h - Ezynq configuration parameters containing
ezynq.c), builds and links u-boot generating u-boot.bin, reruns ezynqcfg.py to include the length of the u-boot.bin into boot_head.bin and then Xilinx Zynq datasheet data for the SoC used by MicroZed board
combines boot_head.bin and u-bootbin into boot.bin with a simple 'cat' command. * include/configs/ezynq/zed_ezynq.h - rest of the Ezynq configuration parameters (it has the
include lines for the 2 datasheet files listed above)
* makeuboot - script that configures u-boot for the microzed board, creates include/autoconf.mk,
runs ezynqcfg.py to create Ezynq code (RBL header and ezynq.c), builds and links u-boot
generating u-boot.bin, reruns ezynqcfg.py to include the length of the u-boot.bin into
boot_head.bin and then combines boot_head.bin and u-bootbin into boot.bin with a simple
'cat' command.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment