[U-Boot] am3517: segmentation fault in Linux after upgrading from arago src to mainline u-boot
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?
Yegor
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..
Tom Rini trini@ti.com writes:
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.
Misconfigured memory would have been my first guess.
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..
Which A8 revision does this chip use? Is it the same r1p3 as the 3530?
On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini trini@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
Hi Tom,
Am 29.11.2013 12:09, schrieb Yegor Yefremov:
On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini trini@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); }
This is what my thread "ARM: omap3: Add option to disable errata workarounds." was about. Unfortunately I went on parents leave just after I found it and didnt follow through on the suggestion given by Albert ARIBAUD back then (http://lists.denx.de/pipermail/u-boot/2013-July/158382.html) If needed, I wouldnt mind resending a patch in the sense of Alberts remark 2.
cheers, Andi
Yegor Yefremov yegorslists@googlemail.com writes:
On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini trini@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.
On an r1pX Cortex-A8 (as found in the 35xx chips) you absolutely want those bits set, especially if you're running Thumb2 code. Otherwise you will get random crashes.
On Thu, Dec 5, 2013 at 6:28 PM, Måns Rullgård mans@mansr.com wrote:
Yegor Yefremov yegorslists@googlemail.com writes:
On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini trini@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.
On an r1pX Cortex-A8 (as found in the 35xx chips) you absolutely want those bits set, especially if you're running Thumb2 code. Otherwise you will get random crashes.
Where can I find info, if am3517 is r1pX? I've looked through "AM35x ARM Microprocessor: Technical Reference Manual", but found nothing similar.
Yegor
On Fri, Dec 6, 2013 at 8:28 AM, Yegor Yefremov yegorslists@googlemail.com wrote:
On Thu, Dec 5, 2013 at 6:28 PM, Måns Rullgård mans@mansr.com wrote:
Yegor Yefremov yegorslists@googlemail.com writes:
On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini trini@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.
On an r1pX Cortex-A8 (as found in the 35xx chips) you absolutely want those bits set, especially if you're running Thumb2 code. Otherwise you will get random crashes.
Where can I find info, if am3517 is r1pX? I've looked through "AM35x ARM Microprocessor: Technical Reference Manual", but found nothing similar.
This info was in the Errata.pdf:
AM3517AZCN i.e. silicon revision 1.1 (r1p7 ROM 15:58)
Yegor
Yegor Yefremov yegorslists@googlemail.com writes:
On Fri, Dec 6, 2013 at 8:28 AM, Yegor Yefremov yegorslists@googlemail.com wrote:
On Thu, Dec 5, 2013 at 6:28 PM, Måns Rullgård mans@mansr.com wrote:
Yegor Yefremov yegorslists@googlemail.com writes:
On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini trini@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.
On an r1pX Cortex-A8 (as found in the 35xx chips) you absolutely want those bits set, especially if you're running Thumb2 code. Otherwise you will get random crashes.
Where can I find info, if am3517 is r1pX? I've looked through "AM35x ARM Microprocessor: Technical Reference Manual", but found nothing similar.
This info was in the Errata.pdf:
AM3517AZCN i.e. silicon revision 1.1 (r1p7 ROM 15:58)
All of those errata are present in r1p7. The 454179 and 430973 also need workarounds enabled in the kernel. Enabling the workarounds on a CPU without the problems will not break anything, but it will cause a minor performance drop.
participants (4)
-
Andreas Naumann -
Måns Rullgård -
Tom Rini -
Yegor Yefremov