On Mon, Nov 14, 2016 at 07:58:03PM +0100, Maxime Ripard wrote:
Hi,
On Mon, Nov 14, 2016 at 10:25:27AM -0500, Tom Rini wrote:
On Mon, Nov 14, 2016 at 04:20:49PM +0100, Maxime Ripard wrote:
On Fri, Nov 11, 2016 at 11:20:47AM -0500, Tom Rini wrote:
On Tue, Nov 08, 2016 at 05:21:14PM +0100, Maxime Ripard wrote:
This program generates raw SPL images that can be flashed on the NAND with the ECC and randomizer properly set up.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
[snip]
+++ b/tools/sunxi-spl-image-builder.c @@ -0,0 +1,1113 @@ +/*
- Generic binary BCH encoding/decoding library
OK, but this is also lib/bch.c and re-using lib/ code for tools is a normal best practice. I'd suggest re-factoring this code in sunxi-tools sot that it too borrows lib/bch.c from the kernel (and can re-sync bugfixes if needed). Thanks!
I finally figured that out.
It turns out that the driver was doing a modulo by 0. I guess gcc's and our libgcc don't have the same behaviour in this case, but in U-boot's case, the function was simply returning (which is kind of odd).
I'll send a fix for the driver.
So it's something in how lib/bch.c and lib1funcs.S interact? Please CC me on these when fixing whatever side of this it is in the kernel, thanks!
Hmm, no, sorry, I meant to reply on the cover letter. The issue isn't in lib/bch.c, it was really in our NAND driver. No changes required in the kernel, just an extra patch in this serie :)
Ah-ah! OK, thanks for clarifying.