On Tuesday, November 17, 2015 at 04:20:16 PM, Simon Brown wrote: Hi,
> I thought I checked out "v2015.10", rather than a rc. I assumed that was > the proper version. > > The startup message says: > U-Boot 2015.10-dirty (Nov 17 2015 - 14:31:48 +0000) Try git describe HEAD ;-) > I don't have USB either - only input means before ethernet is serial port. > Not very clever, but at least we have ONE means of getting comms going. What about ethernet ? Hell, you have an FPGA, you can route the eMMC pins on some edge connector and plug that thing into a card reader :b > Regards, > Simon > > On 17 November 2015 at 15:15, Marek Vasut <[email protected]> wrote: > > On Tuesday, November 17, 2015 at 04:03:03 PM, Simon Brown wrote: > > > Ok, that seems to have helped - I think one problem I had was using > > > u-boot.img, not u-boot-dtb.img - what is the difference? > > > > The later has the device tree attached to the end of the binary, > > the former does not. > > > > > It now prints the U-boot startup prompt, followed by some information > > > > about > > > > > setup, up to DRAM: 1 GiB > > > then it says "Error binding driver 'gpio-dwapb'" three times, followed > > > by > > > > > > some other error messages: > > > >Some drivers failed to bind > > > >Error binding driver 'generic_simple_bus' > > > >Some drivers failed to bind > > > > > > finishing with "initcall sequence 3ffb1ce4 failed at call > > > 010031bf(err=-1)". > > > > Is this stock 2015.10 or u-boot/master ? > > > > > As regards not configuring SD card until after we boot - we made the > > > decision to use an EMMC chip rather than an SD card, but no means of > > > programming it without Linux! > > > > Oh, we do the same on MCVEVK. At one point, I just cooked stripped down > > version of U-Boot with USB mass storage support and placed that into > > RAM cells in the FPGA. Then I made the SoCFPGA boot from FPGA. > > > > The MCVEVK behaves as a USB stick and the eMMC is the backing store. > > > > > Anyway, will try and workout what the above errors signify. > > > Kind regards, > > > > > > Simon > > > > > > On 17 November 2015 at 14:18, Marek Vasut <[email protected]> wrote: > > > > On Tuesday, November 17, 2015 at 02:08:21 PM, Simon Brown wrote: > > > > > Hi, > > > > > > > > Hi, > > > > > > > > > I've been in discussion with Marek on this issue, and he suggested > > > > > I post to the u-boot mailing list. > > > > > > > > > > I've git cloned uboot 2015.10 and checked it out in my own branch. > > > > > I wasn't about to submit anything back, but this way I hopefully > > > > wouldn't > > > > > > > break anything if I did! > > > > > > > > > > I've created a new board, "Axim". I've setup the DTS, Kconfig, > > > > > defconfig files etc similar to the Atlas board addition, and things > > > > > are compiling ok. However, when I run U-boot it gets to a > > > > > relatively early point and then says "### ERROR ### Please reset > > > > > the board ###". I can't see it say this ,as it no longer talks to > > > > > the UART, but I can see that it points to the memory address > > > > > containing this string in > > > > the > > > > > > > debugger, so assume > > > > > > > > that's > > > > > > > > > what it prints out, before entering an endless loop. > > > > > > > > > > My setup is slightly odd, in that I need to get U-boot running > > > > before I > > > > > > can > > > > > > > > > configure an SD card. > > > > > > > > Why ? > > > > > > > > > This means I'm programming my FPGA via JTAG, then > > > > > loading the preloader with the ARM DS-5 debugger via JTAG and > > > > > running it. > > > > > > > > OK, so what I suggest you do (to make things easy) is: > > > > > > > > 1) edit arch/arm/mach-socfpga/spl.c > > > > 2) locate board_init_f() > > > > 3) Add the following code all the way to the end of board_init_f() > > > > (which > > > > > > is, > > > > > > > > incidentally, at the end of the file): > > > > asm volatile("x: b x"); > > > > > > > > This will make sure that the SPL starts spinning in an endless loop > > > > at this point. Once you load this modified SPL with your debugger, > > > > it will init the hardware, but it won't do anything funny anymore. > > > > > > > > So once your hardware is running, load U-Boot (u-boot-dtb.bin) to > > > > 0x01000040 > > > > and execute it from that address. This should get you the prompt. > > > > > > > > > I get output on the UART (via FPGA pins), to my PC, to suggest that > > > > all > > > > > > is > > > > > > > > > running well. I can then upload my u-boot.img file to the > > > > > preloader > > > > > > > > using > > > > > > > > > Ymodem (preloader configured to accept this), and I can run U-boot. > > > > > > > > > > Before I was using the preconfigured 2013.01.01 U-boot as provided > > > > > on Rocketboards.org, but since we are using the KSZ9031 chip for > > > > > our PHY > > > > > > > > felt > > > > > > > > > I needed a newer version to support this. But 2013.01.01 runs ok, > > > > and > > > > > > > I can get to the U-boot prompt on the UART, whereas 2015 hangs. > > > > > > > > > > Any clues gratefully received. > > > > > > > > Try the above method, hope that helps. > > > > > > > > Best regards, > > > > Marek Vasut _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
