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.rip...@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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
