On 03/20/2016 04:55 PM, Dinh Nguyen wrote:
On 03/16/2016 08:35 PM, Marek Vasut wrote:
Does this work for anybody else? Is it in anyone's experience that these (cheaper) Terasic eval boards are generally out of spec?
Is there a way to relax the calibration parameters? the USB parameters?
Would it help if I posted debug output?
Sorry for the late reply, I am horribly overloaded now. I asked someone in #u-boot who has the DE0-NANO-SOC board to test latest u-boot/master on it and it apparently worked for him. I should get some more feedback in the morning [ see http://pastebin.com/CM1QJGnh ] .
Still, this is getting real creepy. You are the second person who is complaining about misbehavior of terasic boards with mainline u-boot and whatever I do, I cannot replicate this.
I am at least CCing the Altera guys. Sorry I have no better suggestion for you :(
I don't have any problems with mainline U-Boot and SPL on my DE0-NANO-BOARD:
U-Boot SPL 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot from MMC
U-Boot 2016.03-00307-ge4fb863 (Mar 20 2016 - 10:37:13 -0500)
CPU: Altera SoCFPGA Platform FPGA: Altera Cyclone V, SE/A4 or SX/C4, version 0x0 BOOT: SD/MMC Internal Transceiver (3.0V) Watchdog enabled I2C: ready DRAM: 1 GiB MMC: dwmmc0@ff704000: 0 In: serial Out: serial Err: serial Model: Terasic DE0-Nano(Atlas) Net: eth0: ethernet@ff702000 Hit any key to stop autoboot: 0 =>
Sorry, I know that doesn't help. So let's walk through my workflow. I am not using any Altera tools when I build.
$make socfpga_de0_nano_soc_defconfig $make u-boot-with-spl.sfp $dd if=u-boot-with-spl.sfp of=/dev/sdb3
My gcc is: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3
Has the board ever worked for you at all? Can you try this image:
https://rocketboards.org/foswiki/view/Documentation/AtlasSoCSdCardImage
Dinh
I just ported U-Boot to another customer board. I noticed QSPI has problems and USB can be flaky. That's the standard cache issue we have, disabling dcache fixed that.
I am starting to wonder whether we're hitting some corner case here. Maybe we should eventually try and trace all the register reads and writes generated by the DDR calibration code both in old and new SPL and make a diff to see if something really did change.
Dinh, can you share the marking on the SoC and the DRAMs on your board?
Thanks!