| Message ID | 1434459610-6429-2-git-send-email-guillaume.gardet@free.fr |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
On Tue, Jun 16, 2015 at 03:00:09PM +0200, Guillaume GARDET wrote: > Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B). > Compilation tested on TI armv7 boards and OMAP boards from other vendors. > > Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> > Cc: Tom Rini <trini@konsulko.com> > Reviewed-by: Tom Rini <trini@konsulko.com>
On Tue, Jun 16, 2015 at 03:00:09PM +0200, Guillaume GARDET wrote: > Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B). > Compilation tested on TI armv7 boards and OMAP boards from other vendors. > > Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> > Cc: Tom Rini <trini@konsulko.com> > Reviewed-by: Tom Rini <trini@konsulko.com> Applied to u-boot/master, thanks!
Hi, In testing v2015.07 with OMAP35xx (Overo) boards (ES3.1), I see boot failure which I bisected down to this patch. Reverting just this patch from v2015.07 allows the same boards to boot into SPL without issue. My OMAP37xx-based Overos seem unaffected. My guess is enabling CONFIG_SYS_THUMB_BUILD for SPL is causing some problems for OMAP35xx processors. I wanted to check if this sounded familiar to anyone or if another platform ( anyone have an original Beagle with which to test?) also showed the same problem. I tried two different compilers, gcc 4.9.2 and 4.7.4, with no apparent difference but the problem could certainly be any of board, cpu rev., cpu, or compiler-specific. Thanks, --Ash On Fri, Jun 19, 2015 at 1:25 PM, Tom Rini <trini@konsulko.com> wrote: > On Tue, Jun 16, 2015 at 03:00:09PM +0200, Guillaume GARDET wrote: > >> Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B). >> Compilation tested on TI armv7 boards and OMAP boards from other vendors. >> >> Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> >> Cc: Tom Rini <trini@konsulko.com> >> Reviewed-by: Tom Rini <trini@konsulko.com> > > Applied to u-boot/master, thanks! > > -- > Tom > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
On Thu, Jul 23, 2015 at 06:25:54PM -0700, Ash Charles wrote: > Hi, > > In testing v2015.07 with OMAP35xx (Overo) boards (ES3.1), I see boot > failure which I bisected down to this patch. Reverting just this > patch from v2015.07 allows the same boards to boot into SPL without > issue. My OMAP37xx-based Overos seem unaffected. My guess is > enabling CONFIG_SYS_THUMB_BUILD for SPL is causing some problems for > OMAP35xx processors. I wanted to check if this sounded familiar to > anyone or if another platform ( anyone have an original Beagle with > which to test?) also showed the same problem. > > I tried two different compilers, gcc 4.9.2 and 4.7.4, with no apparent > difference but the problem could certainly be any of board, cpu rev., > cpu, or compiler-specific. Can you give us more details on the exact nature of the failure? Thanks!
On Fri, Jul 24, 2015 at 7:04 AM, Tom Rini <trini@konsulko.com> wrote:
> Can you give us more details on the exact nature of the failure? Thanks!
Oh sorry--that wasn't clear! The boards appear to get stuck in SPL
before anything can be printed to the console. Basically, I power on,
see gunk from the boot rom on the console port, and then...nothing.
Happy to test further if there is a way to narrow down what precisely
is failing.
--Ash
Hi, Le 24/07/2015 17:22, Ash Charles a écrit : > On Fri, Jul 24, 2015 at 7:04 AM, Tom Rini <trini@konsulko.com> wrote: >> Can you give us more details on the exact nature of the failure? Thanks! > Oh sorry--that wasn't clear! The boards appear to get stuck in SPL > before anything can be printed to the console. Basically, I power on, > see gunk from the boot rom on the console port, and then...nothing. gunk? I think ROM should display nothing if MLO/SPL is found and if nothing is found, you get a '60' for UART boot. > Happy to test further if there is a way to narrow down what precisely > is failing. I have no original beagle, only a xM version with DM3730 which seems to be unaffacted. But, in Overo config, There are those lines : #undef CONFIG_SPL_MAX_SIZE #define CONFIG_SPL_MAX_SIZE (64*1024) #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x40200000 Which bump SPL size from 54*1024 to 64*1024 and moves SPL text base from 0x40200800 to 0x40200000. Any reason for that? What happens if you use original values? What is the size of your MLO? Guillaume > > --Ash >
On Mon, Jul 27, 2015 at 9:39 AM, Guillaume Gardet <guillaume.gardet@free.fr> wrote: > Which bump SPL size from 54*1024 to 64*1024 and moves SPL text base from > 0x40200800 to 0x40200000. > Any reason for that? What happens if you use original values? > > What is the size of your MLO? Hi Guillaume, I changed the lines to get a little more space [1] for BCH support but I see the same behaviour even if I revert these lines. Regardless, my MLO is 50kB with thumb enabled (wow...that's notably smaller). I tried the files you linked (thanks!) but, regrettably, these fail in the same way my Overo OMAP35xx boards and where the AM/DM37xx Overos boot fine (as beagles). [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg163947.html --Ash
Le 28/07/2015 02:23, Ash Charles a écrit : > On Mon, Jul 27, 2015 at 9:39 AM, Guillaume Gardet > <guillaume.gardet@free.fr> wrote: >> Which bump SPL size from 54*1024 to 64*1024 and moves SPL text base from >> 0x40200800 to 0x40200000. >> Any reason for that? What happens if you use original values? >> >> What is the size of your MLO? > Hi Guillaume, > > I changed the lines to get a little more space [1] for BCH support but > I see the same behaviour even if I revert these lines. Regardless, my > MLO is 50kB with thumb enabled (wow...that's notably smaller). > I tried the files you linked (thanks!) but, regrettably, these fail in > the same way my Overo OMAP35xx boards and where the AM/DM37xx Overos > boot fine (as beagles). Maybe there is an ARM errata for OMAP35xx related to thumb? I found a barebox patch related to thumb and OMAP3: http://lists.infradead.org/pipermail/barebox/2012-January/005799.html Maybe it would be useful for u-boot too? Tom, any opinion? Guillaume > > [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg163947.html > > --Ash >
Le 24/07/2015 17:22, Ash Charles a écrit : > On Fri, Jul 24, 2015 at 7:04 AM, Tom Rini <trini@konsulko.com> wrote: >> Can you give us more details on the exact nature of the failure? Thanks! > Oh sorry--that wasn't clear! The boards appear to get stuck in SPL > before anything can be printed to the console. Basically, I power on, > see gunk from the boot rom on the console port, and then...nothing. > Happy to test further if there is a way to narrow down what precisely > is failing. In files ./arch/arm/cpu/armv7/omap3/{board.c, sys_info.c} there are some ASM instructions lines, including MCR and MRC instructions which are ARM only (no thumb). This may be the problem? Guillaume > > --Ash >
On Tue, Jul 28, 2015 at 3:46 AM, Guillaume Gardet <guillaume.gardet@free.fr> wrote: > n files ./arch/arm/cpu/armv7/omap3/{board.c, sys_info.c} there are some ASM > instructions lines, including MCR and MRC instructions which are ARM only > (no thumb). > This may be the problem? I tested this by faking out this assemble code with no change in behaviour. In particular: * commented out the body of the secureworld_exit (not relevant) * hardcoded the cpuid for get_cpu_id * pretended to be in SRAM for get_base I agree it seems a bit odd to have assembly inlined without explicitly switching between ARM and thumb mode but my knowledge of interworking is pretty limited. FWIW, an objdump --special-syms just shows ARM mode as far as I can see. I suspect testing u-boot v2015.07 on another OMAP35xx platform besides Overo will be most useful to confirm the scope of the problem. Anyone have a board and willing to test? I'm happy to send binaries :). --Ash
On Tue, Jul 28, 2015 at 10:19 AM, Ash Charles <ashcharles@gmail.com> wrote: > I suspect testing u-boot v2015.07 on another OMAP35xx platform besides > Overo will be most useful to confirm the scope of the problem. Anyone > have a board and willing to test? I'm happy to send binaries :). Hi, FWIW, I just tried this with the latest code on the master branch and I see the same issue where my OMAP35xx boards fail to start in on SPL and the AM/DM37xx boards work just fine. --Ash
Hi, Kevin Hilman kindly tested on an original Beagle board (i.e. "OMAP3530-GP ES3.0") and sees the same failure. I'd say THUMB mode in SPL isn't working for OMAP35xx-based systems. Any suggestions on how to debug/resolve this issue short of simply reverting? --Ash On Thu, Jul 30, 2015 at 12:58 PM, Ash Charles <ashcharles@gmail.com> wrote: > On Tue, Jul 28, 2015 at 10:19 AM, Ash Charles <ashcharles@gmail.com> wrote: >> I suspect testing u-boot v2015.07 on another OMAP35xx platform besides >> Overo will be most useful to confirm the scope of the problem. Anyone >> have a board and willing to test? I'm happy to send binaries :). > Hi, > > FWIW, I just tried this with the latest code on the master branch and > I see the same issue where my OMAP35xx boards fail to start in > on SPL and the AM/DM37xx boards work just fine. > > --Ash
On Fri, Aug 28, 2015 at 11:50:46AM -0700, Ash Charles wrote: > Hi, > > Kevin Hilman kindly tested on an original Beagle board (i.e. > "OMAP3530-GP ES3.0") and sees the same failure. > > I'd say THUMB mode in SPL isn't working for OMAP35xx-based systems. > Any suggestions on how to debug/resolve this issue short of simply > reverting? I _suspect_ some THUMB related errata on really early cores like this and that we will just need to revert this change, at least for boards where we may run into it. If we can't find and fix the errata in question. > > --Ash > > On Thu, Jul 30, 2015 at 12:58 PM, Ash Charles <ashcharles@gmail.com> wrote: > > On Tue, Jul 28, 2015 at 10:19 AM, Ash Charles <ashcharles@gmail.com> wrote: > >> I suspect testing u-boot v2015.07 on another OMAP35xx platform besides > >> Overo will be most useful to confirm the scope of the problem. Anyone > >> have a board and willing to test? I'm happy to send binaries :). > > Hi, > > > > FWIW, I just tried this with the latest code on the master branch and > > I see the same issue where my OMAP35xx boards fail to start in > > on SPL and the AM/DM37xx boards work just fine. > > > > --Ash > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h index 2bd1164..8762930 100644 --- a/include/configs/ti_armv7_common.h +++ b/include/configs/ti_armv7_common.h @@ -256,6 +256,11 @@ #define CONFIG_SPL_LIBDISK_SUPPORT #define CONFIG_SPL_MMC_SUPPORT #define CONFIG_SPL_FAT_SUPPORT +#define CONFIG_SPL_EXT_SUPPORT +#endif + +#ifdef CONFIG_SPL_BUILD +#define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */ #endif /* General parts of the framework, required. */
Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B). Compilation tested on TI armv7 boards and OMAP boards from other vendors. Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr> Cc: Tom Rini <trini@konsulko.com> --- include/configs/ti_armv7_common.h | 5 +++++ 1 file changed, 5 insertions(+)