[U-Boot] am3517: segmentation fault in Linux after upgrading from arago src to mainline u-boot

Yegor Yefremov yegorslists at googlemail.com
Fri Nov 29 12:09:17 CET 2013


On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini <trini at ti.com> wrote:
> On Thu, Nov 28, 2013 at 05:39:09PM +0100, Yegor Yefremov wrote:
>
>> I'm having problems with the new u-boot (November 2013) and am3517
>> SoC. When I start Debian 7.0 armhf I get lots of Segmentation faults,
>> I can't even perform apt-get udpate. With the older u-boot (arago
>> sources from 2010) everything seems to work properly.
>>
>> I've checked ATAG_MEM and both u-boot versions deliver same RAM start
>> address and size. I've compared EMIF4 settings
>> (arch/arm/cpu/armv7/omap3/emif4.c) and PINMUX and everything is the
>> same.
>>
>> Where else can I look for differences?
>
> Can you bisect the arago tree from what it's based on, to what the top
> of tree is there?  Some errata or another being patched up I guess..

I've compared the x-loader's init routine with the one from SPL. An
found this workaround in the mainline U-Boot
(arch/arm/cpu/armv7/omap3/board.c):

static void omap3_setup_aux_cr(void)
{
        /* Workaround for Cortex-A8 errata: #454179 #430973
         *      Set "IBE" bit
         *      Set "Disable Branch Size Mispredicts" bit
         * Workaround for erratum #621766
         *      Enable L1NEON bit
         * ACR |= (IBE | DBSM | L1NEON) => ACR |= 0xE0
         */
        omap3_update_aux_cr_secure(0xE0, 0);
}

After commenting this routine and I don't see any segmentation faults
during apt usage.

I haven't all of the tests I was intended to, but it looks good so far.

Yegor


More information about the U-Boot mailing list