
On Tue, Aug 23, 2016 at 09:41:21PM +0200, Boris Brezillon wrote:
On Tue, 23 Aug 2016 20:05:59 +0200 Marcus Glocker marcus@nazgul.ch wrote:
On Mon, Aug 22, 2016 at 09:55:01AM +0200, Boris Brezillon wrote:
+Glaucio who is facing the same problem but on a cubieboard2.
On Sun, 21 Aug 2016 16:14:39 +0200 Boris Brezillon boris.brezillon@free-electrons.com wrote:
Hi,
On Sun, 21 Aug 2016 12:03:19 +0200 Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 21-08-16 11:01, Marcus Glocker wrote:
On Sat, Aug 20, 2016 at 03:05:38PM -0400, Tom Rini wrote:
> On Sat, Aug 20, 2016 at 07:26:19AM +0200, Marcus Glocker wrote: >> Hello, >> >> While U-Boot SPL 2015.10 works fine on my allwinner,sun5i-r8 board I >> face following issue with U-Boot SPL 2016.09-rc1 on it: >> >> bash-4.3# cu -l /dev/cuaU0 -s 115200 >> Connected to /dev/cuaU0 (speed 115200) >> >> U-Boot SPL 2016.09-rc1 (Jul 31 2016 - 16:37:00) >> DRAM: 512 MiB >> CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 >> Trying to boot from NAND >> ### ERROR ### Please RESET the board ### >> >> Any ideas what change did cause this or where to start looking after?
Markus, can you share your .config? I tested the different bits while submitting the NAND driver and the SPL NAND driver improvements and it was working fine. I'll try to test 2016.09-rc1 tomorrow.
Just tried to boot a mainline uboot on my CHIP and it boots fine [1]. Here is my .config [2], can you compare yours with this one?
Can you also detail how you flash the images?
Thanks for sharing your configuration! Based on that I was able to narrow down the configuration parameter which makes SPL 2016.09-rc1 now work on my allwinner,sun5i-r8 board as well:
+CONFIG_USE_PRIVATE_LIBGCC=n
When I don't set it explicitly I get 'CONFIG_USE_PRIVATE_LIBGCC=y' in my .config. Could it be that it was set to 'n' by default in previous releases?
Yep. This is enabled by default on ARM platforms since 2016.07 (see commit 91b86e21564d ("lib: Enable private libgcc by default")). Now, this does not explain why the SPL code does not work correctly with the internal libgcc implem.
Can you reproduce the issue when compiling on your side using the internal libgcc? Since here I'm using gcc-linaro to cross-compile it.