[U-Boot] Beagleboard xM boot broken due to FIT enable

[Tom Rini]

On Wed, Oct 04, 2017 at 09:39:52AM +0200, Guillaume Gardet wrote:
> 
> 
> Le 02/10/2017 à 18:14, Guillaume Gardet a écrit :
> >
> >
> >Le 02/10/2017 à 17:58, Tom Rini a écrit :
> >>On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:
> >>>
> >>>Le 02/10/2017 à 15:53, Tom Rini a écrit :
> >>>>On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:
> >>>>>Hi,
> >>>>>
> >>>>>commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
> >>>>>Author: Andrew F. Davis <afd at ti.com>
> >>>>>Date:   Fri Apr 21 10:01:28 2017 -0500
> >>>>>
> >>>>>     Kconfig: Enable FIT support by default for TI platforms
> >>>>>
> >>>>>     Almost all TI defconfigs enable this already, add this as a default
> >>>>>     and remove the explicit assignment.
> >>>>>
> >>>>>     Signed-off-by: Andrew F. Davis <afd at ti.com>
> >>>>>     Reviewed-by: Tom Rini <trini at konsulko.com>
> >>>>>
> >>>>>broke boot on Beagleboard xM. I mean the board hangs after:
> >>>>>     OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
> >>>>>     OMAP3 Beagle board + LPDDR/NAND
> >>>>>     I2C:   ready
> >>>>>     DRAM:  512 MiB
> >>>>>
> >>>>>
> >>>>>To get back the board booting, I need to manually disable FIT (CONFIG_FIT) _and_ disable SHA256 hash support (CONFIG_SHA256).
> >>>>>
> >>>>>If I enable FIT without sha256 : it breaks boot.
> >>>>>If I enable sha256 without FIT : it breaks boot.
> >>>>>
> >>>>>Any idea what could cause this?
> >>>>>
> >>>>>As a workaround we could disable it in the omap3_beagle_defconfig but I guess it would be better to fix it instead of workaround it, since other boards may also be affected.
> >>>>Which Beagleboard xM rev do you have?  And how are you booting (FAT or
> >>>>raw) ?  Mine, FAT booting, is working currently and is part of my
> >>>>automated test farm, thanks!
> >>>This is a Beagleboard xM rev. B.
> >>>We use raw booting (instead of default FAT booting).
> >>OK.  Can you test FAT booting?  Both should work, but I have an idea at
> >>least on RAW, but I'd like to rule out anything else other than size
> >>changes.   Thanks!
> >
> >Indeed, if u-boot.img is on FAT partition, it boots properly!
> 
> So, what is the problem?
> Are we limited in size for u-boot.img when raw booting is used?

Actually, I'm not sure now.  I thought it was one thing, but no, it
can't be just a size thing.  And it's proper U-Boot that fails, not SPL.
Can you add a call to image_check_dcrc() to make sure that the
u-boot.img that's being loaded is not corrupted in some dway?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171004/7ec9a96b/attachment.sig>