[U-Boot] Beagleboard xM boot broken due to FIT enable
Guillaume Gardet
guillaume.gardet at free.fr
Wed Oct 4 11:59:57 UTC 2017
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 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!
>
Ok, but where should I add such a call?
Guillaume
More information about the U-Boot
mailing list