Actions
Forum Thread Details
  • State Not Answered
  • Replies 8 replies
  • Subscribers 367 subscribers
  • Views 511 views
  • Users 0 members are here
Related

u-boot hangs immediately on new 04/2014 Rev D boards

vadimv

Hello,

I have a Zynq PS/PL design that happily runs on my two Rev D Zedboards, boots using tftpboot, runs great. I'm a longtime Zedboard/Xilinx user, never had serious problems before.

I recently bought 8 new Rev D boards to share with the rest of my development team. I have tried all 8 - every single one fails to boot in the exact same setup as my original 2 that work. I power off working board, unplug, plug in new board exactly the same way, and fail. Booting from JTAG, u-boot gets to approx this step and hangs:

I2C:   ready
Memory: ECC disabled
DRAM: 

Sometimes it hangs when printing out the Memory: line, sometimes in the following line. I can turn off and unplug new Rev D, plug in old Red D, power on, and boot like a champ, so nothing is really changing... The truly bizzare thing is that this behavior only happens on JTAG/TFTP boot. SD card boot works fine. There's nothing in my network for controlling MAC addresses, all the boards look the same to the network. Nonetheless, u-boot fails to load way before  the TFTP step.

New boards have an 0814 datecode and S/N of D57XXXX. Additionally, the new boards have different markings on the DDR3 chips - 4CK77 D9PTK. Old Rev Ds that work were 1334 datecode and had DDR3 of 2WD22 D9LGQ, with an S/N of D53XXXX. That's the only difference, these boards are the same rev after all...

Anyone know what could be happening?  

  • 0

    So no one else has hit this? No problems with new Rev D Zedboards?

  • 0

    We have not encountered this problem ourselves or had any other reports but we are not discounting your issue. You mention that SD Card boot works fine but it fails to boot via JTAG. Are you booting the same system with both SD Card and JTAG or could differences in the booting system account for the problem? If they are not the same could you try and see if that might be an issue.

     

    -Gary

  • 0 in reply to Former Member

    Identical boot system, identical u-boot... It's configured for SD operation with "run sdboot" entered in the appropriate place in the .h configuration file. When booting JTAG, on rare occasions I get to the point where I can get to a u-boot prompt to call tftpboot at the console, but most of the time it gets stuck earlier...


    That's really the bizzare aspect of this - sometimes, on rare occasions, it almost works. This tends to happen when the board is cool, which again pointed me to some sort of board issue. Doesn't happen at all with our working Rev D pair of boards, those things are rock solid.

  • 0

    Interesting. The only thing I can think of that would be different is the ps7_init.tcl from the FSBL in your SD Card boot and the one you use in the JTAG initialization. Unless there is a real difference in the JTAG interface that we are not aware of. You might want to see if you can see any differences in your initialization files.

     

    I am working to get a Zedboard with the same date code as your new ones to try to duplicate your issue but it will take a couple of days to get here. If you could contact me via private email and provide me with your SD Card boot files and your JTAG project settings / files that would help me to try to isolate the problem once I have the new Zedboard.

     

    -Gary

  • 0 in reply to Former Member

    Thank you for taking a look at this - very excited to see what you come up with... Unfortunately, I can't send my files as my company restricts what I can share so I can't get it out.

    However, I'm definitely certain that the ps7_init.tcl is the same for both cases. There is only one hardware design, and I triple verified that the FSBL and ultimately its BSP all used that ps7_init.

    Just to make sure I didn't mess something up, I used the ps7_init.tcl that is designed for the ZED, not the one I created from my own hardware. Shouldn't matter if I can't even get u-boot going, right? Same issues, occasionally u-boot boots, most of the time failure happens almost immediatly.

  • 0 in reply to vadimv

    I am a little confused by your referring to a design for 'your hardware' and one for ZED. I will assume that what you meant is a custom hardware design targeted to the ZedBoard (and not custom hardware).

     

    If that is true then, when you exported your design from Vivado to the SDK, several files were generated and moved into the '_wrapper_hw_platform_0 folder of your SDK project, including ps7_init.tcl, ps7_init.h and ps7_init.c. These init files have the values needed to initialize the Zynq PS (processing system) to match the selections you made in your Vivado project. If you use the SDK debugger to load your design via JTAG it uses the ps7_init.tcl file to initialize the Zynq PS before starting your code. If you generate a FSBL you will have included the ps7_init.h and ps7_init.c so that the resulting FSBL code will initialize the Zynq PS in the same manner. So in order to get the same results you would want to use the ps7_init files exported from the Vivado hardware design you generated targeting the Zedboard for both the JTAG and FSBL boots, not a ps7_init.tcl from another source.

     

    While it is targeting the MicroZed board tutorial 4 found here gives a good explaination of how this works: http://www.zedboard.org/support/design/1519/10

     

    If you cannot share your ZedBoard design at least give me some idea of the parameters and IP you used in your design so that I can make an attempt to duplicate your situation.

     

    -Gary

  • 0

    Yes, the flow and use case for the ps7_init files is well understood... "My Hardware" is referring to ps7_init files generated when the platform is exported from Vivado. "ZED Hardware" is when one goes into SDK and creates a platform+BSP targeting the canned (pre-defined) ZED board design.


    I have failures in both cases, so the easiest way to duplicate my setup is to create the basic ZED board BSP in SDK from the pre-defined HW Platform, and use that as the configuration for export to PetaLinux. I have no particular kernel configs that are unique, so there really shouldn't be much to modify, but turn on SD as a boot source, which shouldn;t matter in the JTAG case. Doing this I rarely even get u-boot running. Need to get in there with the debugger and see what's going on.

  • 0

    Thought I'd throw my hat in the ring...

    First thing I'd like to know is what version of Vivado are you using?

    Here are a couple possibilities I can think of:

    1) Maybe Petalinux isn't booting properly on these boards. What command line are you executing to boot from JTAG (e.g. "petalinux-boot -prebuilt 3")? When you execute this command, does the Done light go high before you see any UART activity from u-boot? Last, what version of petalinux are you using (latest is 14.2)?.

    2) The hardware platforms you are using might not be using proper DRAM timing parameters. Try creating a new Vivado project in 2014.2 and target the ZedBoard. Then create a new block design and insert a Zynq PS block. Run the design automation to configure it properly for the Zedboard. You can note now that the DDR settings are correct, and the DRAM training settings are all active. Now export the design to SDK and use it for your petalinux project.

    Sam Bobrowicz
    Digilent Inc.