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 <a...@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 <a...@ti.com> > >>>>> Reviewed-by: Tom Rini <tr...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
