[meta-xilinx] Fwd: toolchain

[andrey]

Hello Mike,

Thanks for trying this software, and I'm sure we'll make it work. It has plenty of debug features as we had to go through all the low-level boot process verifying all works as expected. I'm glad you liked HTML output, did you look through the other generated but human-understandable file - ezynq.c (/arch/arm/cpu/armv7/zynq/ezynq.c) ?

We had split the functionality of ps7 into the register pairs initialized by the RBL and the C code that does the rest - the code that needs the PLLs to be set (and waited for) - the nice RBL register load feature does not support waiting.

Our code does not support switching between different silicon revisions at run time - the revision should be selected at build time, and we have very small base of tested hardware (just 3).

Code uses two debug features - selected LED that can be turned on/off at different stages of the process and uart - configuration file has options to selectively enable them. Most of these debug actions, but the very first initialization by RBL that can just turn on or off LED before passing control to u-boot (that calls arch_cpu_init() in ezynq.c). So you can just look in ezynq.c code and see what outputs and were it gets stuck.

Python script runs twice - first time in the very beginning, generating ezynq.c. Then that file is compiled with the rest of uboot and the second run of ezynqcfg.py already has uboot.bin and knows the size to generate header for the RBL.

The arch_cpu_init() in ezynq.c initializes PLL, UART and DDR, copies itself (and the rest of u-boot) from the OCM (3 lower 0-based pages) to DDR, starting from 0x4000000 (same as ps7), then at some point adds 0x4000000 to the program counter continuing to execute the same instructions. After that it switches off the OCM (being careful not to call functions from that range) and copies itself back to the the same zero-based address range, but this time in DDR. Stack is in the high memory - 4-th OCM bank it is not re-mapped here. And after the second copying is done program can just return to the caller and continue execution in the low addresses. Then uboot gets to copying itself, but notices it is already in place so skips that stage.

So Mike, if you can try more and find where it gets stuck in ezynq.c (you can use LED control in CONFIG_EZYNQ_LED_CHECKPOINT_XX in ezynq_<board>.h), we'll try to look there too and see what is wrong.

Meanwhile we have all the non-FPGA hardware tested in our new Zynq-based camera, and I'm preparing tools for the PL design, hope to be able to present this Eclipse-based environment in a few weeks. The idea of this software originally made for us a long time ago is based on a separate XML-based tool specification language (TSL) so adding new tools and their control pages does not require getting into the plugin code and so can be done by a hardware engineer, not Eclipse plugin developer. That software existed in unfinished stage for more than 6 years, I now updated it to the current VEditor, and starting to use, debugging in the process.

Andrey

---- On Thu, 23 Jan 2014 23:33:22 -0800 Mike Looijmans <mike.looijmans at topic.nl> wrote ---- 


On 01/05/2014 06:12 PM, andrey wrote: 
> Edward, 
> 
> you may try to generate boot.bin without use of Xilinx tools, only free 
> software. We use it for our Zynq-based product (http://blog.elphel.com) and 
> also it tested on Microzed and ZC706 boards. There is a configuration for the 
> Zedboard, but we do not have the board and did not test it. 
> http://sourceforge.net/p/elphel/meta-ezynq 
> 
 
I found some time to give your system a test drive. That HTML output with all 
the configuration information from the program is really nice! 
 
I've tried to compile it "as is" on the Zedboard. When I boot the generated 
BOOT.BIN file on an SD card, I only get these three lines on the UART using 
the reset button (on power-up, the ACM serial port takes rather long to boot, 
so normal power up doesn't produce any serial output at all): 
 
Aug 19 2011 - 07:31:52 
5 
OutputStatus = 0x8300 
 
After that, nothing happens, so it seems it doesn't get far, though it manages 
to execute "something". 
 
I'll go through the configuration and see if I can find what might cause this. 
 
My roadmap for the longer run is to attempt to build something akin to the SPL 
loader for the OMAPs, which basically loads a small u-boot into OCM and uses 
that to load the remainder into DDR. That should allow one to create a bigger 
u-boot (e.g. with USB, network, UBI support and similar features). 
 
Mike. 
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20140124/ed3353f0/attachment.html>