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 afd@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@ti.com > Reviewed-by: Tom Rini trini@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!
Ok, but where should I add such a call?
Guillaume