Le 04/10/2017 à 13:46, Tom Rini a écrit :
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 <[email protected]>
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 <[email protected]>
      Reviewed-by: Tom Rini <[email protected]>

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!


Ok, but where should I add such a call?

Guillaume

_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot

Reply via email to