On Tue, Oct 20, 2015 at 03:32:27PM -0400, Tom Rini wrote:
On Mon, Oct 19, 2015 at 10:17:46AM +0200, Maxime Ripard wrote:
On Sat, Oct 17, 2015 at 04:42:09PM +0200, Hans de Goede wrote:
Hi,
On 17-10-15 15:59, Hans de Goede wrote:
Hi,
On 15-10-15 14:34, Maxime Ripard wrote:
Hi everyone,
Here is the second attempt at getting fastboot flashing functions working on top of a NAND, for arbitraly large images.
While the NAND support itself was quite easy to do, the support for the Android sparse images was quite difficult to add, and ended up being a quite huge refactoring of the sparse parse already in tree, that was tied to the MMC layer.
This serie has been tested on a CHIP and an A13-Olinuxino, two Allwinner devices, the CHIP for the NAND, and the Cubietruck to test the MMC.
Let me know what you think, Maxime
Thanks, I've applied the 3 sunxi patches (12 - 14) to u-boot-sunxi/next, with the commit msg fixup suggested by Ian.
Looks like I've spoken too soon, the patch for enabling otg on the cubietruck causes build errors:
arm-linux-gnu-ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o) uses VFP register arguments, u-boot does not arm-linux-gnu-ld.bfd: failed to merge target specific data of file /usr/lib/gcc/arm-linux-gnueabi/5.2.1/libgcc.a(_udivmoddi4.o) Makefile:1173: recipe for target 'u-boot' failed make: *** [u-boot] Error 1
Usually this means that some code is using 64 bit int division without using the proper macros for this.
For some reason I'm not seeing the same on the A13-OlinuxIno, that patch for that seems to be missing the id pin, which could have something to do with this.
I think this is caused by some 64 bit math in the fastboot code somewhere ...
For now I've dropped these 2 patches from u-boot-sunxi/next
Which 2 patches then? Cubietruck and this one?
Do you have a toolchain tarball for this so that I can test easily?
The arm-none-eabi toolchain that's apt-get'able should show this. You could even fudge this by (I _think_) forcing U-Boot to build with -march=armv5te rather than armv7. I _might_ even be able to spot it in the patch review :)
... I take it back, I couldn't locally reproduce this with the arm-none-eabi toolchain I have around and 12-14 applied in a local branch. Hans, last time I saw this error (last night even) there was a bit more in the log about which file/function was doing the mis-match. Do you have the full error log handy? Thanks!