Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Santosh Shilimkar [110224 21:31]: > > > > Was this with linux-omap master branch or mainline? > > > > The V6 vs V7 issues should be sorted out with Russell's patches that > > we also have now in linux-omap master branch. > > > This was with mainline. > Then I applied RMK's series and things were OK. OK good to hear & thanks for checking that. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Tony Lindgren > Sent: Thursday, February 24, 2011 11:09 PM > To: Santosh Shilimkar > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > Munegowda; Felipe Balbi > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > 4430SDP boot failure) > > * Santosh Shilimkar [110212 00:45]: > > Tony, > > > -Original Message- > > > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > > > Sent: Thursday, February 03, 2011 2:13 PM > > > To: Tony Lindgren > > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > > > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > > > Munegowda; Felipe Balbi > > > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > > > 4430SDP boot failure) > > > > > > > -Original Message- > > > > From: Tony Lindgren [mailto:t...@atomide.com] > > > > Sent: Thursday, February 03, 2011 1:19 AM > > > > To: Santosh Shilimkar > > > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > > > > ker...@lists.infradead.org; linux-omap@vger.kernel.org; > Keshava > > > > Munegowda; Felipe Balbi > > > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP > (Re: > > > > 4430SDP boot failure) > > > > > > > > * Santosh Shilimkar [110201 22:04]: > > > > > > > > > > > > It's a ES1.0 blaze, with the patch below it reboots early > > > > > > during the boot. I also have to disable omap_l2_cache_init > > > > > > on this board to get it to boot. > > > > > > > > > > > Do you still get this problem with 'omap_l2_cache_init' ? > > > > > As reported earlier, we don't see this issue on ES1.0 > > > > > SDP. > > > > > > > > Yeah I do, it rarely makes it to the userspace. Works reliably > > > > if I disable omap_l2_cache_init. > > > > > > > Ok. I shall try few experiments and try to reproduce it > > > > Not sure if it's the same issue but I managed to reproduce the > > issue on ES2.0 itself. And after some experiments, it boiled > > down to the V6 and V7 issue. By disabling OMAP2 from the build, > > everything was fine again. > > Was this with linux-omap master branch or mainline? > > The V6 vs V7 issues should be sorted out with Russell's patches that > we also have now in linux-omap master branch. > This was with mainline. Then I applied RMK's series and things were OK. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Santosh Shilimkar [110212 00:45]: > Tony, > > -Original Message- > > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > > Sent: Thursday, February 03, 2011 2:13 PM > > To: Tony Lindgren > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > > Munegowda; Felipe Balbi > > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > > 4430SDP boot failure) > > > > > -Original Message- > > > From: Tony Lindgren [mailto:t...@atomide.com] > > > Sent: Thursday, February 03, 2011 1:19 AM > > > To: Santosh Shilimkar > > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > > > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > > > Munegowda; Felipe Balbi > > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > > > 4430SDP boot failure) > > > > > > * Santosh Shilimkar [110201 22:04]: > > > > > > > > > > It's a ES1.0 blaze, with the patch below it reboots early > > > > > during the boot. I also have to disable omap_l2_cache_init > > > > > on this board to get it to boot. > > > > > > > > > Do you still get this problem with 'omap_l2_cache_init' ? > > > > As reported earlier, we don't see this issue on ES1.0 > > > > SDP. > > > > > > Yeah I do, it rarely makes it to the userspace. Works reliably > > > if I disable omap_l2_cache_init. > > > > > Ok. I shall try few experiments and try to reproduce it > > Not sure if it's the same issue but I managed to reproduce the > issue on ES2.0 itself. And after some experiments, it boiled > down to the V6 and V7 issue. By disabling OMAP2 from the build, > everything was fine again. Was this with linux-omap master branch or mainline? The V6 vs V7 issues should be sorted out with Russell's patches that we also have now in linux-omap master branch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Tony, > -Original Message- > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > Sent: Thursday, February 03, 2011 2:13 PM > To: Tony Lindgren > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > Munegowda; Felipe Balbi > Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > 4430SDP boot failure) > > > -Original Message- > > From: Tony Lindgren [mailto:t...@atomide.com] > > Sent: Thursday, February 03, 2011 1:19 AM > > To: Santosh Shilimkar > > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > > Munegowda; Felipe Balbi > > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > > 4430SDP boot failure) > > > > * Santosh Shilimkar [110201 22:04]: > > > > > > > > It's a ES1.0 blaze, with the patch below it reboots early > > > > during the boot. I also have to disable omap_l2_cache_init > > > > on this board to get it to boot. > > > > > > > Do you still get this problem with 'omap_l2_cache_init' ? > > > As reported earlier, we don't see this issue on ES1.0 > > > SDP. > > > > Yeah I do, it rarely makes it to the userspace. Works reliably > > if I disable omap_l2_cache_init. > > > Ok. I shall try few experiments and try to reproduce it Not sure if it's the same issue but I managed to reproduce the issue on ES2.0 itself. And after some experiments, it boiled down to the V6 and V7 issue. By disabling OMAP2 from the build, everything was fine again. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Thursday, February 03, 2011 1:19 AM > To: Santosh Shilimkar > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm- > ker...@lists.infradead.org; linux-omap@vger.kernel.org; Keshava > Munegowda; Felipe Balbi > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > 4430SDP boot failure) > > * Santosh Shilimkar [110201 22:04]: > > > > > > It's a ES1.0 blaze, with the patch below it reboots early > > > during the boot. I also have to disable omap_l2_cache_init > > > on this board to get it to boot. > > > > > Do you still get this problem with 'omap_l2_cache_init' ? > > As reported earlier, we don't see this issue on ES1.0 > > SDP. > > Yeah I do, it rarely makes it to the userspace. Works reliably > if I disable omap_l2_cache_init. > Ok. I shall try few experiments and try to reproduce it -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Anand Gadiyar [110202 10:51]: > Tony Lindgren wrote: > > * Anand Gadiyar [110201 04:54]: > > > > > > I believe this fix is fixing your reboot issue, but it's breaking > > > EHCI support on the SDP. > > > > > > The MODE4 above should really be MODE3 - all GPIOs are on MODE3. > > > By changing > > > > > > The patch snippet below fixes EHCI on the SDP, but I believe that > > > making this change will reintroduce the "board reboots" issue > > > you originally reported. Could you check and tell me if this > > > is the case? > > > > Hmm sorry looks like I made a typo there. That should be fixed. > > > > > Just curious - is your board a Blaze, or an SDP? > > > > It's a ES1.0 blaze, with the patch below it reboots early > > during the boot. I also have to disable omap_l2_cache_init > > on this board to get it to boot. > > > > ... > > > Maybe there should be a check for ES1.0 for the USB also? > > Looks like a bug on the Blaze boards. There's a large capacitor > on the rails that starts charging when we try to power the USB PHY. > The inrush current is quite high and this causes the reboot. > > The capacitor is on the big motherboard called the application > board, so it's independent of the silicon rev. I'm not sure > which revs are affected - I'll try and find out more about the > issue to see if I can come up with a better fix. OK thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Santosh Shilimkar [110201 22:04]: > > > > It's a ES1.0 blaze, with the patch below it reboots early > > during the boot. I also have to disable omap_l2_cache_init > > on this board to get it to boot. > > > Do you still get this problem with 'omap_l2_cache_init' ? > As reported earlier, we don't see this issue on ES1.0 > SDP. Yeah I do, it rarely makes it to the userspace. Works reliably if I disable omap_l2_cache_init. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Tony Lindgren wrote: > * Anand Gadiyar [110201 04:54]: > > > > I believe this fix is fixing your reboot issue, but it's breaking > > EHCI support on the SDP. > > > > The MODE4 above should really be MODE3 - all GPIOs are on MODE3. > > By changing > > > > The patch snippet below fixes EHCI on the SDP, but I believe that > > making this change will reintroduce the "board reboots" issue > > you originally reported. Could you check and tell me if this > > is the case? > > Hmm sorry looks like I made a typo there. That should be fixed. > > > Just curious - is your board a Blaze, or an SDP? > > It's a ES1.0 blaze, with the patch below it reboots early > during the boot. I also have to disable omap_l2_cache_init > on this board to get it to boot. > ... > Maybe there should be a check for ES1.0 for the USB also? Looks like a bug on the Blaze boards. There's a large capacitor on the rails that starts charging when we try to power the USB PHY. The inrush current is quite high and this causes the reboot. The capacitor is on the big motherboard called the application board, so it's independent of the silicon rev. I'm not sure which revs are affected - I'll try and find out more about the issue to see if I can come up with a better fix. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, February 02, 2011 6:40 AM > To: Anand Gadiyar > Cc: Russell King - ARM Linux; linux-arm-ker...@lists.infradead.org; > linux-omap@vger.kernel.org; Keshava Munegowda; Santosh Shilimkar; > Felipe Balbi > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: > 4430SDP boot failure) > > * Anand Gadiyar [110201 04:54]: > > > > I believe this fix is fixing your reboot issue, but it's breaking > > EHCI support on the SDP. > > > > The MODE4 above should really be MODE3 - all GPIOs are on MODE3. > > By changing > > > > The patch snippet below fixes EHCI on the SDP, but I believe that > > making this change will reintroduce the "board reboots" issue > > you originally reported. Could you check and tell me if this > > is the case? > > Hmm sorry looks like I made a typo there. That should be fixed. > > > Just curious - is your board a Blaze, or an SDP? > > It's a ES1.0 blaze, with the patch below it reboots early > during the boot. I also have to disable omap_l2_cache_init > on this board to get it to boot. > Do you still get this problem with 'omap_l2_cache_init' ? As reported earlier, we don't see this issue on ES1.0 SDP. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Anand Gadiyar [110201 04:54]:
>
> I believe this fix is fixing your reboot issue, but it's breaking
> EHCI support on the SDP.
>
> The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
> By changing
>
> The patch snippet below fixes EHCI on the SDP, but I believe that
> making this change will reintroduce the "board reboots" issue
> you originally reported. Could you check and tell me if this
> is the case?
Hmm sorry looks like I made a typo there. That should be fixed.
> Just curious - is your board a Blaze, or an SDP?
It's a ES1.0 blaze, with the patch below it reboots early
during the boot. I also have to disable omap_l2_cache_init
on this board to get it to boot.
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
> b/arch/arm/mach-omap2/board-4430sdp.c
> index 07d1b20..ab9fb4d 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,7 +554,7 @@ static void __init omap_sfh7741prox_init(void)
>
> #ifdef CONFIG_OMAP_MUX
> static struct omap_board_mux board_mux[] __initdata = {
> - OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
> + OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
> #else
Maybe there should be a check for ES1.0 for the USB also?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Tony Lindgren wrote:
> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren
> Date: Tue Jan 11 15:03:03 2011 -0800
>
> omap4: Fix ULPI PHY init for ES1.0 SDP
>
> Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
> enable the ehci port on 4430SDP) added code to enable EHCI
> support on 4430sdp board.
>
> Looks like the ULPI pin does not seem to be muxed properly on ES1.0
> SDP and this causes the system to reboot when the ULPI PHY is
> enabled.
>
> Fix this by muxing the pin, this is the same setting for
> both ES1.0 and ES2.0. Also add checking for gpio_request.
>
> Cc: Keshava Munegowda Signed-off-by: Tony Lindgren
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
>
> #ifdef CONFIG_OMAP_MUX
> static struct omap_board_mux board_mux[] __initdata = {
> + OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
> #else
Tony,
I believe this fix is fixing your reboot issue, but it's breaking
EHCI support on the SDP.
The MODE4 above should really be MODE3 - all GPIOs are on MODE3.
By changing
The patch snippet below fixes EHCI on the SDP, but I believe that
making this change will reintroduce the "board reboots" issue
you originally reported. Could you check and tell me if this
is the case?
Just curious - is your board a Blaze, or an SDP?
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 07d1b20..ab9fb4d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -554,7 +554,7 @@ static void __init omap_sfh7741prox_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
- OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Sat, Jan 15, 2011 at 05:04:55PM +, Russell King - ARM Linux wrote: > On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux [110114 16:24]: > > > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote: > > > > * Russell King - ARM Linux [110114 15:58]: > > > > > > > > > > # ARMv6k > > > > > config CPU_32v6K > > > > > bool "Support ARM V6K processor extensions" if !SMP > > > > > depends on CPU_V6 || CPU_V7 > > > > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) > > > > > > > > > > OMAP2 prevents the selection of armv6k support. This is probably a > > > > > very > > > > > bad idea if you want to run the resulting kernel on SMP hardware as it > > > > > removes a barrier in the spinlock code and disables the SMP-safe > > > > > bitops. > > > > > > > > I have some ideas to fix this. Unfortunately it will be inefficient > > > > as spinlock.h can be included from modules too :( I was thinking we can > > > > implement dsb_sev in the proc-*.S functions for the unoptimized > > > > multi-arm > > > > builds. > > > > > > For spinlocks, the important thing is the barrier. The wfe/sev are an > > > optimization. The barrier contained with the ifdef is a valid V6 > > > instruction. > > > > OK, great it's just drain WB. Then we can do the ussual iffdeffery > > on it for multi-arm builds as it does not depend on the 6K extensions. > > I can do a patch for this on Monday, gotta run now. > > > > > > > The original patch which started turning this off was from the MX3 > > > > > stuff, > > > > > but without explaination. > > > > > > > > > > However, OMAP extended this to disabling the select statement for > > > > > CPU_32v6K > > > > > even if CPU_V7 is set: > > > > > > > > > > config CPU_V7 > > > > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || > > > > > MACH_REALVIEW_EB |- select CPU_32v6K > > > > > + select CPU_32v6K if !ARCH_OMAP2 > > > > > > > > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, > > > > > and this > > > > > patch should not have been merged. > > > > > > > > The only way we can fix that is do smp_on_up style rewriting of the > > > > assembly > > > > during init between CPUv6 and v6K. Want me to do a patch for that? > > > > > > The bitops code is quite different between the two versions, and I doubt > > > the smp_on_up rewriting will look at all pretty. I think it needs an > > > alternative idea - like not using the 'byte' operations at all. > > > > > > Whether we have any code which passes non-word aligned pointers to bitops > > > isn't particularly known - in theory they should all be unsigned long *'s, > > > so should be word-aligned. Who knows what filesystems do though... and > > > such a change could be disasterous to peoples data if the block/inode > > > bitmaps get corrupted. > > > > Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? > > I guess we could do some address checking in the bitops functions too for > > multi-arm builds.. > > > > > IOW, such a change needs testing on a box where a range of filesystems are > > > used, and the filesystems can be thrown away if corrupted. > > > > Or we could patch in the address checking first and only disable it > > later if now warnings. > > Right, this is what I'm going to do - and it's going to *intentionally* > break omap2plus_defconfig. Please see the commit comments for the > reason why. We need to address the V6 issue properly without risking > users data. > > To Sascha: this replaces the previous patch which I asked for your ack. Ack for this one aswell: Acked-by: Sascha Hauer > > 8<--- > Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection > > CPU_32v6K controls whether we use the ARMv6K extension instructions in > the kernel, and in some places whether we use SMP-safe code sequences > (eg, bitops.) > > Having this configuration option disabled on a SMP supporting kernel > results in a problem: the SMP-unsafe code sequences will be used, and > as such the resulting kernel is not SMP safe. > > As the atomic bitops are used by filesystems (eg, ext2 - to manipulate > the inode and block bitmaps) not having the SMP safe code sequences is > fatal for filesystem data integrity. So running an SMP kernel without > CPU_32v6K set is dangerous. > > MX3 prevents the selection of this option to ensure that it is not > enabled for their CPU, which is ARMv6 only. MX3 folk need to ensure > that their kernel is properly configured. > > OMAP prevents the selection of this option in an attempt to produce a > kernel which runs on architectures from ARMv6 to ARMv7 MPCore. > > Balancing between oopsing on boot and filesystem corruption, it is far > more preferable to oops on boot until the code sequences are sorted out > properly. > > Signed-off-by: Russell King > --- > arch/arm/mm/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 dele
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Fri, Jan 14, 2011 at 04:37:34PM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [110114 16:24]: > > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote: > > > * Russell King - ARM Linux [110114 15:58]: > > > > > > > > # ARMv6k > > > > config CPU_32v6K > > > > bool "Support ARM V6K processor extensions" if !SMP > > > > depends on CPU_V6 || CPU_V7 > > > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) > > > > > > > > OMAP2 prevents the selection of armv6k support. This is probably a very > > > > bad idea if you want to run the resulting kernel on SMP hardware as it > > > > removes a barrier in the spinlock code and disables the SMP-safe bitops. > > > > > > I have some ideas to fix this. Unfortunately it will be inefficient > > > as spinlock.h can be included from modules too :( I was thinking we can > > > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm > > > builds. > > > > For spinlocks, the important thing is the barrier. The wfe/sev are an > > optimization. The barrier contained with the ifdef is a valid V6 > > instruction. > > OK, great it's just drain WB. Then we can do the ussual iffdeffery > on it for multi-arm builds as it does not depend on the 6K extensions. > I can do a patch for this on Monday, gotta run now. > > > > > The original patch which started turning this off was from the MX3 > > > > stuff, > > > > but without explaination. > > > > > > > > However, OMAP extended this to disabling the select statement for > > > > CPU_32v6K > > > > even if CPU_V7 is set: > > > > > > > > config CPU_V7 > > > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || > > > > MACH_REALVIEW_EB |- select CPU_32v6K > > > > + select CPU_32v6K if !ARCH_OMAP2 > > > > > > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and > > > > this > > > > patch should not have been merged. > > > > > > The only way we can fix that is do smp_on_up style rewriting of the > > > assembly > > > during init between CPUv6 and v6K. Want me to do a patch for that? > > > > The bitops code is quite different between the two versions, and I doubt > > the smp_on_up rewriting will look at all pretty. I think it needs an > > alternative idea - like not using the 'byte' operations at all. > > > > Whether we have any code which passes non-word aligned pointers to bitops > > isn't particularly known - in theory they should all be unsigned long *'s, > > so should be word-aligned. Who knows what filesystems do though... and > > such a change could be disasterous to peoples data if the block/inode > > bitmaps get corrupted. > > Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? > I guess we could do some address checking in the bitops functions too for > multi-arm builds.. > > > IOW, such a change needs testing on a box where a range of filesystems are > > used, and the filesystems can be thrown away if corrupted. > > Or we could patch in the address checking first and only disable it > later if now warnings. Right, this is what I'm going to do - and it's going to *intentionally* break omap2plus_defconfig. Please see the commit comments for the reason why. We need to address the V6 issue properly without risking users data. To Sascha: this replaces the previous patch which I asked for your ack. 8<--- Subject: [PATCH] ARM: Do not disable CPU_32v6K based on platform selection CPU_32v6K controls whether we use the ARMv6K extension instructions in the kernel, and in some places whether we use SMP-safe code sequences (eg, bitops.) Having this configuration option disabled on a SMP supporting kernel results in a problem: the SMP-unsafe code sequences will be used, and as such the resulting kernel is not SMP safe. As the atomic bitops are used by filesystems (eg, ext2 - to manipulate the inode and block bitmaps) not having the SMP safe code sequences is fatal for filesystem data integrity. So running an SMP kernel without CPU_32v6K set is dangerous. MX3 prevents the selection of this option to ensure that it is not enabled for their CPU, which is ARMv6 only. MX3 folk need to ensure that their kernel is properly configured. OMAP prevents the selection of this option in an attempt to produce a kernel which runs on architectures from ARMv6 to ARMv7 MPCore. Balancing between oopsing on boot and filesystem corruption, it is far more preferable to oops on boot until the code sequences are sorted out properly. Signed-off-by: Russell King --- arch/arm/mm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig index 49db8b3..d61af9c 100644 --- a/arch/arm/mm/Kconfig +++ b/arch/arm/mm/Kconfig @@ -405,7 +405,7 @@ config CPU_V6 config CPU_32v6K bool "Support ARM V6K processor extensions" if !SMP depends on CPU_V6 || CPU_V7 - default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) + default y if S
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Russell King - ARM Linux [110114 16:24]: > On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux [110114 15:58]: > > > > > > # ARMv6k > > > config CPU_32v6K > > > bool "Support ARM V6K processor extensions" if !SMP > > > depends on CPU_V6 || CPU_V7 > > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) > > > > > > OMAP2 prevents the selection of armv6k support. This is probably a very > > > bad idea if you want to run the resulting kernel on SMP hardware as it > > > removes a barrier in the spinlock code and disables the SMP-safe bitops. > > > > I have some ideas to fix this. Unfortunately it will be inefficient > > as spinlock.h can be included from modules too :( I was thinking we can > > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm > > builds. > > For spinlocks, the important thing is the barrier. The wfe/sev are an > optimization. The barrier contained with the ifdef is a valid V6 > instruction. OK, great it's just drain WB. Then we can do the ussual iffdeffery on it for multi-arm builds as it does not depend on the 6K extensions. I can do a patch for this on Monday, gotta run now. > > > The original patch which started turning this off was from the MX3 stuff, > > > but without explaination. > > > > > > However, OMAP extended this to disabling the select statement for > > > CPU_32v6K > > > even if CPU_V7 is set: > > > > > > config CPU_V7 > > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || > > > MACH_REALVIEW_EB |- select CPU_32v6K > > > + select CPU_32v6K if !ARCH_OMAP2 > > > > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and > > > this > > > patch should not have been merged. > > > > The only way we can fix that is do smp_on_up style rewriting of the assembly > > during init between CPUv6 and v6K. Want me to do a patch for that? > > The bitops code is quite different between the two versions, and I doubt > the smp_on_up rewriting will look at all pretty. I think it needs an > alternative idea - like not using the 'byte' operations at all. > > Whether we have any code which passes non-word aligned pointers to bitops > isn't particularly known - in theory they should all be unsigned long *'s, > so should be word-aligned. Who knows what filesystems do though... and > such a change could be disasterous to peoples data if the block/inode > bitmaps get corrupted. Hmm, how about emulation of those instructions for non-v6K ARMv6 processors? I guess we could do some address checking in the bitops functions too for multi-arm builds.. > IOW, such a change needs testing on a box where a range of filesystems are > used, and the filesystems can be thrown away if corrupted. Or we could patch in the address checking first and only disable it later if now warnings. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [110114 15:58]: > > > > # ARMv6k > > config CPU_32v6K > > bool "Support ARM V6K processor extensions" if !SMP > > depends on CPU_V6 || CPU_V7 > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) > > > > OMAP2 prevents the selection of armv6k support. This is probably a very > > bad idea if you want to run the resulting kernel on SMP hardware as it > > removes a barrier in the spinlock code and disables the SMP-safe bitops. > > I have some ideas to fix this. Unfortunately it will be inefficient > as spinlock.h can be included from modules too :( I was thinking we can > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm > builds. For spinlocks, the important thing is the barrier. The wfe/sev are an optimization. The barrier contained with the ifdef is a valid V6 instruction. > > The original patch which started turning this off was from the MX3 stuff, > > but without explaination. > > > > However, OMAP extended this to disabling the select statement for CPU_32v6K > > even if CPU_V7 is set: > > > > config CPU_V7 > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || > > MACH_REALVIEW_EB |- select CPU_32v6K > > + select CPU_32v6K if !ARCH_OMAP2 > > > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this > > patch should not have been merged. > > The only way we can fix that is do smp_on_up style rewriting of the assembly > during init between CPUv6 and v6K. Want me to do a patch for that? The bitops code is quite different between the two versions, and I doubt the smp_on_up rewriting will look at all pretty. I think it needs an alternative idea - like not using the 'byte' operations at all. Whether we have any code which passes non-word aligned pointers to bitops isn't particularly known - in theory they should all be unsigned long *'s, so should be word-aligned. Who knows what filesystems do though... and such a change could be disasterous to peoples data if the block/inode bitmaps get corrupted. IOW, such a change needs testing on a box where a range of filesystems are used, and the filesystems can be thrown away if corrupted. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Russell King - ARM Linux [110114 15:58]: > > # ARMv6k > config CPU_32v6K > bool "Support ARM V6K processor extensions" if !SMP > depends on CPU_V6 || CPU_V7 > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) > > OMAP2 prevents the selection of armv6k support. This is probably a very > bad idea if you want to run the resulting kernel on SMP hardware as it > removes a barrier in the spinlock code and disables the SMP-safe bitops. I have some ideas to fix this. Unfortunately it will be inefficient as spinlock.h can be included from modules too :( I was thinking we can implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm builds. > The original patch which started turning this off was from the MX3 stuff, > but without explaination. > > However, OMAP extended this to disabling the select statement for CPU_32v6K > even if CPU_V7 is set: > > config CPU_V7 > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || > MACH_REALVIEW_EB |- select CPU_32v6K > + select CPU_32v6K if !ARCH_OMAP2 > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this > patch should not have been merged. The only way we can fix that is do smp_on_up style rewriting of the assembly during init between CPUv6 and v6K. Want me to do a patch for that? For the defconfigs, I have a branch where I occasionally compile all the old removed defconfigs too. And I believe Kevin test compiles various PM options. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Fri, Jan 14, 2011 at 04:10:29PM -0700, Paul Walmsley wrote: > I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6 > plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your > compile-testing regimen, if one is not already present? > > That would help catch compile problems like the recent CONFIG_SWP_EMULATE > one[1]. Such as these? ../build/msm/.config:CONFIG_CPU_V6=y ../build/omap2/.config:CONFIG_CPU_V6=y ../build/omap3/.config:CONFIG_CPU_V7=y ../build/omap3/.config:# CONFIG_SWP_EMULATE is not set ../build/omap4/.config:CONFIG_CPU_V7=y ../build/omap4/.config:# CONFIG_SWP_EMULATE is not set ../build/realview/.config:CONFIG_CPU_V6=y ../build/realview/.config:CONFIG_CPU_V7=y ../build/realview/.config:CONFIG_SWP_EMULATE=y ../build/vexpress/.config:CONFIG_CPU_V7=y ../build/vexpress/.config:CONFIG_SWP_EMULATE=y So, I already have configs for V7 only+SWP_EMULATE=y, V7 only+SWP_EMULATE=n, V6 only, V6+V7+SWP_EMULATE=y but not V6+V7+SWP_EMULATE=n It doesn't appear for me because my toolchain new enough to be broken. What has been merged into the toolchain (gcc emitting a .armv7 at the beginning of its assembler output) was a pretty stupid idea as it's going to break _everything_ out there which has been carefully crafted to compile for ARMv6 but selectively use ARMv7 instructions. I am very much of the opinion that this new "feature" needs to be removed from the toolchain, and it should do as previous versions of the toolchain does - where the gcc frontend passes the correct architecture flags to the assembler. This "feature" will have broken a lot more than just the SWP emulate code in the kernel - anything which tries to build a kernel crossing several CPU architectures will hit this failure. This is what I get from building the realview configuration listed above: $ emake O=../build/realview/ arch/arm/kernel/ Using /home/rmk/git/linux-2.6-rmk as source for kernel GEN /home/rmk/git/build/realview/Makefile CHK include/linux/version.h CHK include/generated/utsrelease.h make[2]: `include/generated/mach-types.h' is up to date. CALL/home/rmk/git/linux-2.6-rmk/scripts/checksyscalls.sh CC arch/arm/kernel/elf.o AS arch/arm/kernel/entry-armv.o AS arch/arm/kernel/entry-common.o CC arch/arm/kernel/irq.o CC arch/arm/kernel/process.o CC arch/arm/kernel/ptrace.o CC arch/arm/kernel/return_address.o CC arch/arm/kernel/setup.o CC arch/arm/kernel/signal.o CC arch/arm/kernel/sys_arm.o CC arch/arm/kernel/stacktrace.o CC arch/arm/kernel/time.o CC arch/arm/kernel/traps.o CC arch/arm/kernel/compat.o CC arch/arm/kernel/leds.o CC arch/arm/kernel/armksyms.o CC arch/arm/kernel/module.o CC arch/arm/kernel/sched_clock.o CC arch/arm/kernel/smp.o CC arch/arm/kernel/smp_tlb.o CC arch/arm/kernel/smp_scu.o CC arch/arm/kernel/smp_twd.o CC arch/arm/kernel/sys_oabi-compat.o CC arch/arm/kernel/swp_emulate.o CC arch/arm/kernel/hw_breakpoint.o CC arch/arm/kernel/pmu.o CC arch/arm/kernel/perf_event.o CC arch/arm/kernel/io.o AS arch/arm/kernel/debug.o LD arch/arm/kernel/built-in.o AS arch/arm/kernel/head.o CC arch/arm/kernel/init_task.o LDS arch/arm/kernel/vmlinux.lds So, as you can see, it builds perfectly fine for me. GCC 4.3.5, binutils 2.19.1. The command used to build swp_emulate.o was: arm-linux-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d -nostdinc -isystem /usr/local/aeabi/lib/gcc/arm-linux/4.3.5/include -I/home/rmk/git/linux-2.6-rmk/arch/arm/include -Iinclude -I/home/rmk/git/linux-2.6-rmk/include -include include/generated/autoconf.h -I/home/rmk/git/linux-2.6-rmk/arch/arm/kernel -Iarch/arm/kernel -D__KERNEL__ -mlittle-endian -I/home/rmk/git/linux-2.6-rmk/arch/arm/mach-realview/include -I/home/rmk/git/linux-2.6-rmk/arch/arm/plat-versatile/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -marm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s -msoft-float -Uarm -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -Wa,-march=armv7-a -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)" -D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)" -c -o arch/arm/kernel/swp_emulate.o /home/rmk/git/linux-2.6-rmk/arch/arm/kernel/swp_emulate.c So, the reason I don't see it is because I don't build the omap2plus_defconfig build, as: # ARMv6k config CPU_32v6K bool "Support ARM V6K processor extensions" if !SMP depends on CPU_V6 || CPU_V7 default y if SMP && !(ARCH_MX3 || ARCH_OMAP2) OMAP2 pre
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Fri, 14 Jan 2011, Russell King - ARM Linux wrote: > If it helps, here's what I do - not only do I run a few of the standard > defconfigs in the tree, but I also run a number of platform specific > builds, both covering platforms I do and do not have. I'll pick a random > selection of existing build trees to rebuild and see what the results are. > This shows the spread of trees which I've built over the last year - and > note that many of these I don't even have: > > drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4 > drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile > drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx > drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress > drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator > drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview > drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet > drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc > drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3 > drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu > drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2 > drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap > drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300 > drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa > drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm > drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood > drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695 > drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410 > drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx > drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2 > drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285 > drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite > drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx > drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi > drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110 > drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x > drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx > drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100 > drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x > drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1 > drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb > > omap4 = 4430SDP only (I have). > omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't) > omap2 = H2 (whose config can be traced to 2005 from when I once had one.) > omap = some random omap1 config > realview = realview eb/smp only > assabet = assabet+neponset daugter board > > All those are build trees, built from my git tree with: > make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree > > You can see from the above that I built a kernel for at least orion-kirkwood, > msm, u300, omap, nommu trees before sending my pull to Linus on the 6th, > none of which I have (ever) had hardware for. I also built omap3, omap4, > and a bunch of the ARM evaluation platforms as well as older platforms > like RiscPC, but those are hidden by later re-builds for work I've been > doing since (which is all based upon commit 9e9bc97.) > > I'm not saying that's perfect - it isn't. It's better than just testing > the defconfigs - and with regular checking of kautobuild/linux-next, it > seems to catch quite a bit of really silly stuff. I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6 plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your compile-testing regimen, if one is not already present? That would help catch compile problems like the recent CONFIG_SWP_EMULATE one[1]. - Paul 1. _linux-next: omap2plus_defconfig not building_. linux-arm-kernel mailing list thread, started 19 October 2010 by Anand Gadiyar. http://comments.gmane.org/gmane.linux.ports.arm.kernel/93694 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> > On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > > * Russell King - ARM Linux [110113 01:15]:
> > > > > Given the very sorry state of OMAP in mainline at present, I'm
> > > > > surprised
> > > > > that this kind of stuff is still going on...
> > > >
> > > > At least I boot test the patches I send..
> > >
> > > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > > spit out lots of compile errors in the OMAP code... As they won't
> > > even compile they couldn't have been boot tested.
> >
> > Current mainline != the patches that Tony sent to Linus[1].
> >
> > The patches that Tony sent to Linus, which Linus merged, build fine
> > with omap2plus_defconfig[2].
>
> Right, but is that sufficient testing?
>
> Can I read into your statement that the only testing which was done was
> a build of the omap2plus defconfig?
No. The patches that Tony merged from me were built with omap1_defconfig
and boot-tested on OMAP5912 OSK; they were built with an N8x0-specific
configuration and boot-tested on N800; and they were built with
omap2plus_defconfig and boot-tested on 2430SDP, OMAP3530 Beagle, DM37xx
Beagle XM, and OMAP4430 ES2 Panda. A brief summary of that testing was
part of the pull request that was sent to Tony[1].
The problem in this case was that I did not compile-test them with an
OMAP4-only configuration - hence the clockdomain and PRM breakage.
> Weren't builds specific to OMAP2, OMAP3, and OMAP4 tried?
>
> As there is stuff like:
>
> struct clockdomain {
> const char *name;
> union {
> const char *name;
> struct powerdomain *ptr;
> } pwrdm;
> #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> const u16 clktrctrl_mask;
> #endif
>
> would you consider it's a good idea to at least run a build test with
> an OMAP4-only configuration?
Yes. Given the clockdomain and PRM breakage from this merge window, I
plan to compile-test future branches that I send to Tony with quite a few
non-multi-OMAP configs. I consider it my responsibility to catch breakage
from my branches before it makes it to Tony.
> If it helps, here's what I do - not only do I run a few of the standard
> defconfigs in the tree, but I also run a number of platform specific
> builds, both covering platforms I do and do not have. I'll pick a random
> selection of existing build trees to rebuild and see what the results are.
> This shows the spread of trees which I've built over the last year - and
> note that many of these I don't even have:
>
> drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx
> drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc
> drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3
> drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm
> drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood
> drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695
> drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410
> drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx
> drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2
> drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285
> drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite
> drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx
> drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi
> drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110
> drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x
> drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx
> drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100
> drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x
> drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1
> drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb
>
> omap4 = 4430SDP only (I have).
> omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
> omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
> omap = some random omap1 config
> realview = realview eb/smp only
> assabet = assabet+neponset daugter board
>
> All those are build trees, built from my git tree with:
> make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree
>
> You can see from the above that I built a kernel for at least orion-kirkwood,
> msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
> none of which I have (ever) had hardware
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Fri, Jan 14, 2011 at 12:18:50PM -0700, Paul Walmsley wrote:
> On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
> > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote:
> > > * Russell King - ARM Linux [110113 01:15]:
> > > > Given the very sorry state of OMAP in mainline at present, I'm surprised
> > > > that this kind of stuff is still going on...
> > >
> > > At least I boot test the patches I send..
> >
> > Which is why OMAP3 and OMAP4 can't be built in mainline because they
> > spit out lots of compile errors in the OMAP code... As they won't
> > even compile they couldn't have been boot tested.
>
> Current mainline != the patches that Tony sent to Linus[1].
>
> The patches that Tony sent to Linus, which Linus merged, build fine
> with omap2plus_defconfig[2].
Right, but is that sufficient testing?
Can I read into your statement that the only testing which was done was
a build of the omap2plus defconfig? Weren't builds specific to OMAP2,
OMAP3, and OMAP4 tried?
As there is stuff like:
struct clockdomain {
const char *name;
union {
const char *name;
struct powerdomain *ptr;
} pwrdm;
#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
const u16 clktrctrl_mask;
#endif
would you consider it's a good idea to at least run a build test with
an OMAP4-only configuration?
If it helps, here's what I do - not only do I run a few of the standard
defconfigs in the tree, but I also run a number of platform specific
builds, both covering platforms I do and do not have. I'll pick a random
selection of existing build trees to rebuild and see what the results are.
This shows the spread of trees which I've built over the last year - and
note that many of these I don't even have:
drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4
drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile
drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx
drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress
drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator
drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview
drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet
drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc
drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3
drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu
drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2
drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap
drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300
drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa
drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm
drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood
drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695
drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410
drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx
drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2
drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285
drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite
drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx
drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi
drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110
drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x
drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx
drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100
drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x
drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1
drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb
omap4 = 4430SDP only (I have).
omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
omap = some random omap1 config
realview = realview eb/smp only
assabet = assabet+neponset daugter board
All those are build trees, built from my git tree with:
make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree
You can see from the above that I built a kernel for at least orion-kirkwood,
msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
none of which I have (ever) had hardware for. I also built omap3, omap4,
and a bunch of the ARM evaluation platforms as well as older platforms
like RiscPC, but those are hidden by later re-builds for work I've been
doing since (which is all based upon commit 9e9bc97.)
I'm not saying that's perfect - it isn't. It's better than just testing
the defconfigs - and with regular checking of kautobuild/linux-next, it
seems to catch quite a bit of really silly stuff.
Please test a (small) selection of configurations to improve build
coverage. Try to develop a set of configurations which trip up common
issues which won't be found with the omap2plus defconfig. Don't assume
that just because the omap2plus defconfig builds that it's ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Thu, 13 Jan 2011, Russell King - ARM Linux wrote: > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux [110113 01:15]: > > > Given the very sorry state of OMAP in mainline at present, I'm surprised > > > that this kind of stuff is still going on... > > > > At least I boot test the patches I send.. > > Which is why OMAP3 and OMAP4 can't be built in mainline because they > spit out lots of compile errors in the OMAP code... As they won't > even compile they couldn't have been boot tested. Current mainline != the patches that Tony sent to Linus[1]. The patches that Tony sent to Linus, which Linus merged, build fine with omap2plus_defconfig[2]. - Paul 1. Lindgren, Tony. _[GIT PULL] omap changes for v2.6.38_. Posted to the linux-kernel mailing list on 6 January 2011. http://www.gossamer-threads.com/lists/linux/kernel/1324357 (among others) 2. Compilation log of the patches that Tony submitted for the 2.6.38 merge window (included below) --- $ git log mainline/master --pretty=oneline | fgrep omap-for-linus |head -1 01539ba2a706ab7d35fc0667dff919ade7f87d63 Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 $ git show 01539ba2a706ab7d35fc0667dff919ade7f87d63 |head -5 commit 01539ba2a706ab7d35fc0667dff919ade7f87d63 Merge: 9e9bc97 dc69d1a Author: Linus Torvalds Date: Thu Jan 6 19:13:58 2011 -0800 $ git checkout dc69d1a HEAD is now at dc69d1a... omap2: Make OMAP2PLUS select OMAP_DM_TIMER $ make mrproper $ make omap2plus_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # $ make -j2 scripts/kconfig/conf --silentoldconfig Kconfig CHK include/linux/version.h UPD include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h HOSTCC scripts/genksyms/genksyms.o Generating include/generated/mach-types.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/arm/kernel/asm-offsets.s SHIPPED scripts/genksyms/lex.c SHIPPED scripts/genksyms/parse.h SHIPPED scripts/genksyms/keywords.c SHIPPED scripts/genksyms/parse.c HOSTCC scripts/genksyms/lex.o GEN include/generated/asm-offsets.h CALLscripts/checksyscalls.sh HOSTCC scripts/genksyms/parse.o CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/genksyms/genksyms HOSTCC scripts/kallsyms HOSTCC scripts/pnmtologo HOSTCC scripts/mod/modpost.o HOSTCC scripts/conmakehash HOSTCC scripts/bin2c HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost CC init/main.o HOSTCC usr/gen_init_cpio GEN usr/initramfs_data.cpio AS usr/initramfs_data.o LD usr/built-in.o CC arch/arm/nwfpe/fpa11.o CC arch/arm/nwfpe/fpa11_cpdo.o CC arch/arm/nwfpe/fpa11_cpdt.o CC arch/arm/nwfpe/fpa11_cprt.o CC arch/arm/nwfpe/fpmodule.o CHK include/generated/compile.h UPD include/generated/compile.h CC init/do_mounts.o CC arch/arm/nwfpe/fpopcode.o CC arch/arm/nwfpe/softfloat.o CC init/do_mounts_rd.o CC arch/arm/nwfpe/single_cpdo.o CC init/do_mounts_initrd.o CC arch/arm/nwfpe/double_cpdo.o AS arch/arm/nwfpe/entry.o LD arch/arm/nwfpe/nwfpe.o LD arch/arm/nwfpe/built-in.o CC init/initramfs.o CC init/calibrate.o CC init/version.o LD init/mounts.o CC arch/arm/vfp/vfpmodule.o LD init/built-in.o CC arch/arm/kernel/elf.o AS arch/arm/vfp/entry.o AS arch/arm/vfp/vfphw.o CC arch/arm/vfp/vfpsingle.o AS arch/arm/kernel/entry-armv.o AS arch/arm/kernel/entry-common.o CC arch/arm/kernel/irq.o CC arch/arm/vfp/vfpdouble.o CC arch/arm/kernel/process.o LD arch/arm/vfp/vfp.o LD arch/arm/vfp/built-in.o CC arch/arm/mm/dma-mapping.o CC arch/arm/kernel/ptrace.o CC arch/arm/mm/extable.o CC arch/arm/mm/fault.o CC arch/arm/kernel/return_address.o arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables" arch/arm/kernel/return_address.c:61:2: warning: #warning "TODO: return_address should use unwind tables" CC arch/arm/kernel/setup.o CC arch/arm/mm/init.o CC arch/arm/mm/iomap.o CC arch/arm/kernel/signal.o CC arch/arm/mm/fault-armv.o CC arch/arm/kernel/sys_arm.o CC arch/arm/mm/flush.o CC arch/arm/kernel/stacktrace.o CC arch/arm/mm/ioremap.o CC arch/arm/kernel/time.o CC ar
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Russell King - ARM Linux [110113 08:49]: > On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux [110113 01:15]: > > > Given the very sorry state of OMAP in mainline at present, I'm surprised > > > that this kind of stuff is still going on... > > > > At least I boot test the patches I send.. > > Which is why OMAP3 and OMAP4 can't be built in mainline because they > spit out lots of compile errors in the OMAP code... As they won't > even compile they couldn't have been boot tested. Huh? I have fixes queued up for the issues that showed up with merges with various other trees. I certainly make sure everything I merge is compile and boot tested. Sure there are still tons of issues still remaining, but people are working on those. That's why we have the -rc releases. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Thu, Jan 13, 2011 at 07:51:53AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [110113 01:15]: > > Given the very sorry state of OMAP in mainline at present, I'm surprised > > that this kind of stuff is still going on... > > At least I boot test the patches I send.. Which is why OMAP3 and OMAP4 can't be built in mainline because they spit out lots of compile errors in the OMAP code... As they won't even compile they couldn't have been boot tested. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Russell King - ARM Linux [110113 01:15]:
> On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> > Tony Lindgren wrote:
> > > /* Power on the ULPI PHY */
> > > - if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> > > - /* FIXME: Assumes pad is already muxed for GPIO mode */
> > > - gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> > VMDM_3V3");
> > > + status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> > VMDM_3V3");
> > > + if (status)
> > > + pr_err("%s: Could not get USBB1 PHY GPIO\n");
> >
> > Tony,
> >
> > This throws up a build warning as there's no parameter corresponding to
> > the %s. Showed up in linux-next as of today.
Oops, sorry, will fix.
> It's pretty obvious that the above is wrong, and the compiler would
> have caught it with a warning when building it. Was the above patch
> not build-tested before it was committed?
Sure, boot tested it but missed the warning though.
> Given the very sorry state of OMAP in mainline at present, I'm surprised
> that this kind of stuff is still going on...
At least I boot test the patches I send..
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
On Thu, Jan 13, 2011 at 02:22:06PM +0530, Anand Gadiyar wrote:
> Tony Lindgren wrote:
> > /* Power on the ULPI PHY */
> > - if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> > - /* FIXME: Assumes pad is already muxed for GPIO mode */
> > - gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> VMDM_3V3");
> > + status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
> VMDM_3V3");
> > + if (status)
> > + pr_err("%s: Could not get USBB1 PHY GPIO\n");
>
> Tony,
>
> This throws up a build warning as there's no parameter corresponding to
> the %s. Showed up in linux-next as of today.
It's pretty obvious that the above is wrong, and the compiler would
have caught it with a warning when building it. Was the above patch
not build-tested before it was committed?
Given the very sorry state of OMAP in mainline at present, I'm surprised
that this kind of stuff is still going on...
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
Tony Lindgren wrote:
> Here's one more es1.0 fix after the recent USB changes.
>
> Regards,
>
> Tony
>
>
> Author: Tony Lindgren
> Date: Tue Jan 11 15:03:03 2011 -0800
>
> omap4: Fix ULPI PHY init for ES1.0 SDP
>
> Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
> enable the ehci port on 4430SDP) added code to enable EHCI
> support on 4430sdp board.
>
> Looks like the ULPI pin does not seem to be muxed properly on ES1.0
> SDP and this causes the system to reboot when the ULPI PHY is
> enabled.
>
> Fix this by muxing the pin, this is the same setting for
> both ES1.0 and ES2.0. Also add checking for gpio_request.
>
> Cc: Keshava Munegowda Signed-off-by: Tony Lindgren
>
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
>
> #ifdef CONFIG_OMAP_MUX
> static struct omap_board_mux board_mux[] __initdata = {
> + OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
> { .reg_offset = OMAP_MUX_TERMINATOR },
> };
> #else
> @@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
> omap4_twl6030_hsmmc_init(mmc);
>
> /* Power on the ULPI PHY */
> - if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
> - /* FIXME: Assumes pad is already muxed for GPIO mode */
> - gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
VMDM_3V3");
> + status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY
VMDM_3V3");
> + if (status)
> + pr_err("%s: Could not get USBB1 PHY GPIO\n");
Tony,
This throws up a build warning as there's no parameter corresponding to
the %s. Showed up in linux-next as of today.
- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
* Tony Lindgren [110110 10:51]:
> * Russell King - ARM Linux [110107 08:12]:
> > On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> > > Anyways, I can debug the DEBUG_LL booting issue further if the patch
> > > I posted does not help.
> >
> > This is what I ended up with earlier today to make the debug code work
> > both in the decompressor and in the kernel - once I had it working I
> > haven't bothered putting any more effort into it.
>
> Hmm I have DEBUG_LL working fine (execept not for the uncompress code).
>
> Looks like the only issue I have with my 4430 es1.0 blaze board is
> that it won't boot reliably unless I disable l2x0_init.
>
> Have you guys seen this issue?
>
> Of course there are all kinds of omap4 warnings there, but after
> disabling l2x0_init I was able to run apt-get dist-upgrade on my
> board. This is with what I have queued up in omap-fixes.
Here's one more es1.0 fix after the recent USB changes.
Regards,
Tony
Author: Tony Lindgren
Date: Tue Jan 11 15:03:03 2011 -0800
omap4: Fix ULPI PHY init for ES1.0 SDP
Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
enable the ehci port on 4430SDP) added code to enable EHCI
support on 4430sdp board.
Looks like the ULPI pin does not seem to be muxed properly on ES1.0
SDP and this causes the system to reboot when the ULPI PHY is
enabled.
Fix this by muxing the pin, this is the same setting for
both ES1.0 and ES2.0. Also add checking for gpio_request.
Cc: Keshava Munegowda
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
omap4_twl6030_hsmmc_init(mmc);
/* Power on the ULPI PHY */
- if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
- /* FIXME: Assumes pad is already muxed for GPIO mode */
- gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+ status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+ if (status)
+ pr_err("%s: Could not get USBB1 PHY GPIO\n");
+ else
gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
- }
+
usb_ehci_init(&ehci_pdata);
usb_musb_init(&musb_board_data);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Russell King - ARM Linux [110107 08:12]: > On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote: > > Anyways, I can debug the DEBUG_LL booting issue further if the patch > > I posted does not help. > > This is what I ended up with earlier today to make the debug code work > both in the decompressor and in the kernel - once I had it working I > haven't bothered putting any more effort into it. Hmm I have DEBUG_LL working fine (execept not for the uncompress code). Looks like the only issue I have with my 4430 es1.0 blaze board is that it won't boot reliably unless I disable l2x0_init. Have you guys seen this issue? Of course there are all kinds of omap4 warnings there, but after disabling l2x0_init I was able to run apt-get dist-upgrade on my board. This is with what I have queued up in omap-fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 09:25:11AM -0800, Tony Lindgren wrote: > * Grant Likely [110107 09:18]: > > On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote: > > > Grant, > > > > > > Care to queue or ack the following fix? > > > > If you bounce the patch to me, then I'll pick it up into the spi tree > > and send it on to Linus right away. (It didn't get sent to either me > > or the spi list, so I don't have the original). > > Thanks, bounced it to you. As noted in the original patch, someone who understands this driver should fix the other exit paths so buffers aren't left mapped when they shouldn't be. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 03:49:20PM +, Russell King - ARM Linux wrote: > And, with one ARM errata disabled, the kernel finally boots. So the > "X-Loader hangs" message means that we did something that non-secure > mode prevented us from doing. Here's the dmesg with as many things as I could find enabled. Linux version 2.6.37+ (r...@rmk-pc) (gcc version 4.3.5 (GCC) ) #67 SMP PREEMPT Fri Jan 7 19:38:30 GMT 2011 CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache Machine: OMAP4430 4430SDP board vmalloc area is too big, limiting to 864MB Memory policy: ECC disabled, Data cache writealloc OMAP4430 ES1.0 SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 FIXME: omap44xx_sram_init not implemented On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c035f540, node_mem_map c0381000 Normal zone: 64 pages used for memmap Normal zone: 0 pages reserved Normal zone: 8128 pages, LIFO batch:0 HighMem zone: 960 pages used for memmap HighMem zone: 121920 pages, LIFO batch:31 PERCPU: Embedded 7 pages/cpu @c0786000 s4192 r8192 d16288 u32768 pcpu-alloc: s4192 r8192 d16288 u32768 alloc=8*4096 pcpu-alloc: [0] 0 [0] 1 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/mmcblk0p2 ip=dhcp rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2 PID hash table entries: 128 (order: -3, 512 bytes) Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 512MB = 512MB total Memory: 516492k/516492k available, 7796k reserved, 491520K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc280 - 0xf800 ( 856 MB) lowmem : 0xc000 - 0xc200 ( 32 MB) pkmap : 0xbfe0 - 0xc000 ( 2 MB) modules : 0xbf00 - 0xbfe0 ( 14 MB) .init : 0xc0008000 - 0xc002f000 ( 156 kB) .text : 0xc002f000 - 0xc0334000 (3092 kB) .data : 0xc0334000 - 0xc035ff00 ( 176 kB) SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Preemptable hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:402 powerdomain: waited too long for powerdomain dss_pwrdm to complete transition [ cut here ] WARNING: at arch/arm/mach-omap2/clockdomain.c:868 omap2_clkdm_deny_idle+0x58/0xcc() clockdomain: OMAP4 wakeup/sleep dependency support is not yet implemented Modules linked in: Backtrace: [] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c) r7:c0335f30 r6:c004a7f0 r5:c02f6189 r4:0364 [] (dump_stack+0x0/0x1c) from [] (warn_slowpath_common+0x58/0x70) [] (warn_slowpath_common+0x0/0x70) from [] (warn_slowpath_fmt+0x38/0x40) r8:c0347860 r7:c03464c4 r6:0060 r5:c0346f4c r4:c036032c [] (warn_slowpath_fmt+0x0/0x40) from [] (omap2_clkdm_deny_idle+0x58/0xcc) r3: r2:c02f61c7 [] (omap2_clkdm_deny_idle+0x0/0xcc) from [] (clkdm_init+0x144/0x17c) r5:c0347860 r4:c0346f4c [] (clkdm_init+0x0/0x17c) from [] (omap2_init_common_hw+0x20/0xa0) [] (omap2_init_common_hw+0x0/0xa0) from [] (omap_4430sdp_init_irq+0x34/0x54) [] (omap_4430sdp_init_irq+0x0/0x54) from [] (init_IRQ+0x1c/0x24) r4:c035ff00 [] (init_IRQ+0x0/0x24) from [] (start_kernel+0x18c/0x2fc) [] (start_kernel+0x0/0x2fc) from [<80008038>] (0x80008038) r7:c0345cb4 r6:c0029120 r5:c0342bf0 r4:10c53c7d ---[ end trace 1b75b31a2719ed1c ]--- omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck. GPMC revision 6.0 OMAP GPIO hardware version 0.1 OMAP clockevent source: GPTIMER1 at 32768 Hz Console: colour dummy device 80x30 Calibrating delay loop... 2013.49 BogoMIPS (lpj=7864320) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok L310 cache controller enabled l2x0: 16 ways, CACHE_ID 0x41c2, AUX_CTRL 0x0e05, Cache size: 524288 B CPU1: Booted secondary processor CPU1: Unknown IPI message 0x1 Brought up 2 CPUs SMP: Total of 2 processors activated (4026.98 BogoMIPS). regulator: core version 0.5 regulator: dummy: NET: Registered protocol family 16 OMAP DMA hardware revision 0.0 sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms bio: create slab at 0 i2c_omap i2c_omap.1: bus 1 rev4.0 at 400 kHz Skipping twl internal clock init and using bootloader value (unknown osc rate) twl6030: PIH (irq 39) chaining IRQs 368..387 regulator: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby regulator: VPP: 1800 <--> 2500 mV at 1900 mV normal standby regulator: VUSIM: 1200 <--> 2900 mV at 1800 mV normal standby regulator: VANA: 2100 mV normal standby regulator: VCXIO: 1800 mV normal standby regulator: VDAC: 1800 mV normal standby regulator: VUSB:
RE: 4430SDP boot failure - solved + SPI bug fix
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:50 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Saturday, January 08, 2011 12:23 AM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> > >
> > > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar
> wrote:
> > > > > And, with one ARM errata disabled, the kernel finally boots.
> So
> > > the
> > > > > "X-Loader hangs" message means that we did something that
> non-
> > > secure
> > > > > mode prevented us from doing.
> > > > >
> > > > Actually it's not. The error message is quite misleading.
> > > Basically in
> > > > x-loader exception handlers are setup and all these handlers
> > > report
> > > > same message ("X-Loader hangs"). This should be fixed so that
> it
> > > can
> > > > report more meaningful info like data abort, prefetch abort
> etc.
> > > >
> > > > Till the vector relocation in the kernel exceptions are not
> set up
> > > > so code jumps to already installed exceptions in the x-loader
> and
> > > > hence the messege.
> > >
> > > I disagree with your "actually it's not". It was errata 742230,
> > > which
> > > requires access to the CP15, c15, c0, 1 register (a diagnostic
> > > register)
> > > which I bet provokes an undefined instruction trap from non-
> secure
> > > mode.
> > >
> > 742230 errata workaround is not implemented in the x-loader so I
> > can surely say it's not the secure violation.
>
> Precisely. So when we directly read, modify and write this
> diagnostic
> register in the non-secure world during kernel boot, we end up
> faulting.
> Comment those instructions out, we don't get a fault, and the kernel
> boots normally.
I understand now. Was confused last time.
So your custom build did have this errata
CONFIG_ARM_ERRATA_742230 where there is an access
to diagnostic register which is not accessible on OMAP4
from non-secure side.
Thanks for clarification.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Sat, Jan 08, 2011 at 12:35:38AM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Saturday, January 08, 2011 12:23 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure - solved + SPI bug fix
> >
> > On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > > And, with one ARM errata disabled, the kernel finally boots. So
> > the
> > > > "X-Loader hangs" message means that we did something that non-
> > secure
> > > > mode prevented us from doing.
> > > >
> > > Actually it's not. The error message is quite misleading.
> > Basically in
> > > x-loader exception handlers are setup and all these handlers
> > report
> > > same message ("X-Loader hangs"). This should be fixed so that it
> > can
> > > report more meaningful info like data abort, prefetch abort etc.
> > >
> > > Till the vector relocation in the kernel exceptions are not set up
> > > so code jumps to already installed exceptions in the x-loader and
> > > hence the messege.
> >
> > I disagree with your "actually it's not". It was errata 742230,
> > which
> > requires access to the CP15, c15, c0, 1 register (a diagnostic
> > register)
> > which I bet provokes an undefined instruction trap from non-secure
> > mode.
> >
> 742230 errata workaround is not implemented in the x-loader so I
> can surely say it's not the secure violation.
Precisely. So when we directly read, modify and write this diagnostic
register in the non-secure world during kernel boot, we end up faulting.
Comment those instructions out, we don't get a fault, and the kernel
boots normally.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure - solved + SPI bug fix
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, January 08, 2011 12:23 AM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > > And, with one ARM errata disabled, the kernel finally boots. So
> the
> > > "X-Loader hangs" message means that we did something that non-
> secure
> > > mode prevented us from doing.
> > >
> > Actually it's not. The error message is quite misleading.
> Basically in
> > x-loader exception handlers are setup and all these handlers
> report
> > same message ("X-Loader hangs"). This should be fixed so that it
> can
> > report more meaningful info like data abort, prefetch abort etc.
> >
> > Till the vector relocation in the kernel exceptions are not set up
> > so code jumps to already installed exceptions in the x-loader and
> > hence the messege.
>
> I disagree with your "actually it's not". It was errata 742230,
> which
> requires access to the CP15, c15, c0, 1 register (a diagnostic
> register)
> which I bet provokes an undefined instruction trap from non-secure
> mode.
>
742230 errata workaround is not implemented in the x-loader so I
can surely say it's not the secure violation.
He is the x-loader source tree.
http://dev.omapzoom.org/?p=bootloader/x-loader.git;a=shortlog;h=refs/heads
/omap4_dev
Even simple things like if DDR is not configured correctly or not
Stable, code/data access takes abort which lands up in the "X-loader
hang messege"
> Hence, the reason it vectored to the X-loader was because we tried
> to
> do something in the non-secure mode which we're prevented from
> doing.
My suspect was clock configurations on the older boot loaders were
Incomplete that might have lead to issue since now more drivers are
getting enabled in newer kernels.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 11:59:07PM +0530, Santosh Shilimkar wrote: > > ks8851 spi1.0: message enable is 0 > > ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194 > > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144 > > IP-Config: Complete: > > device=eth0, addr=192.168.0.144, mask=255.255.255.0, > > gw=192.168.0.1, > > host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none), > > bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= > > > > but the board doesn't respond to that IP address. Meanwhile the > > DHCP > > server shows: > > > > DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0 > > > > in its log, and the ethernet address appears to be random for each > > boot. > > Obviously, as I can't log into the board via any means, it's nigh on > > impossible to work out what's actually going on. > > DHCP seems to work for me without any issues. The board now has an ethernet address of 1E:89:8E:DA:80:7C - it seems to be intentionally random which isn't particularly nice. At least it's intentionally random and not some undefined region of memory being poked in there... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 11:55:10PM +0530, Santosh Shilimkar wrote:
> > And, with one ARM errata disabled, the kernel finally boots. So the
> > "X-Loader hangs" message means that we did something that non-secure
> > mode prevented us from doing.
> >
> Actually it's not. The error message is quite misleading. Basically in
> x-loader exception handlers are setup and all these handlers report
> same message ("X-Loader hangs"). This should be fixed so that it can
> report more meaningful info like data abort, prefetch abort etc.
>
> Till the vector relocation in the kernel exceptions are not set up
> so code jumps to already installed exceptions in the x-loader and
> hence the messege.
I disagree with your "actually it's not". It was errata 742230, which
requires access to the CP15, c15, c0, 1 register (a diagnostic register)
which I bet provokes an undefined instruction trap from non-secure mode.
Hence, the reason it vectored to the X-loader was because we tried to
do something in the non-secure mode which we're prevented from doing.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, January 07, 2011 9:54 PM > To: Santosh Shilimkar > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: Re: 4430SDP boot failure > > On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote: > > > -Original Message- > > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > > Sent: Friday, January 07, 2011 7:55 PM > > > To: Santosh Shilimkar > > > Cc: linux-omap@vger.kernel.org; Tony Lindgren > > > Subject: Re: 4430SDP boot failure > > > > > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar > wrote: > > > > Have sent you latest bootloaders and full bootlog on my ES1.0 > > > > OMAP4430SDP. 2.6.37 just boots fine for me. > > > > > > > > Low level debug as you reported seems to be broken though. > > > > > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely > on > > > the board - which should ease the debugging problem as it no > longer > > > requires anything but the reset button pressed to test a new > kernel. > > > > Glad to hear that. > > Right, next couple of problems. > > udev isn't creating the ttyO* nodes for whatever reason on my fs - > does > anyone know what device major/minor numbers these end up with? It > seems > they're dynamically assigned. > Right now don't have access to my board so can't check this. > There's also something fishy going on with networking (if I > configure > PNP IP, I get an IP: > > ks8851 spi1.0: message enable is 0 > ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194 > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144 > IP-Config: Complete: > device=eth0, addr=192.168.0.144, mask=255.255.255.0, > gw=192.168.0.1, > host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none), > bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= > > but the board doesn't respond to that IP address. Meanwhile the > DHCP > server shows: > > DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0 > > in its log, and the ethernet address appears to be random for each > boot. > Obviously, as I can't log into the board via any means, it's nigh on > impossible to work out what's actually going on. DHCP seems to work for me without any issues. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure - solved + SPI bug fix
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Friday, January 07, 2011 9:19 PM
> To: Santosh Shilimkar
> Cc: linux-omap@vger.kernel.org; Tony Lindgren
> Subject: Re: 4430SDP boot failure - solved + SPI bug fix
>
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar
> wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely
> on
> > > the board - which should ease the debugging problem as it no
> longer
> > > requires anything but the reset button pressed to test a new
> kernel.
> >
> > Glad to hear that.
>
> And, with one ARM errata disabled, the kernel finally boots. So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.
>
Actually it's not. The error message is quite misleading. Basically in
x-loader exception handlers are setup and all these handlers report
same message ("X-Loader hangs"). This should be fixed so that it can
report more meaningful info like data abort, prefetch abort etc.
Till the vector relocation in the kernel exceptions are not set up
so code jumps to already installed exceptions in the x-loader and
hence the messege.
> It would be a good idea if X-loader could tell dump out the
> exception,
> register dump, and for data/prefetch aborts, the relevent FSR and
> FAR
> registers - that would make debugging this kind of failure a lot
> easier.
>
Yes. At least it should report data/prefect aborts.
> =
> Subject: Fix DMA API usage in OMAP MCSPI driver
>
> Running the latest kernel on the 4430SDP board with DMA API
> debugging
> enabled results in this:
>
> WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> NULL NULL: DMA-API: device driver tries to free DMA memory it has
> not allocated
> [device address=0x8129901a] [size=260 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from []
> (dump_stack+0x18/0x1c)
> r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from []
> (warn_slowpath_fmt+0x38/0x40)
> r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> [] (warn_slowpath_fmt+0x0/0x40) from []
> (check_unmap+0x19c/0x6f0)
> r3:c03110de r2:c0304e6b
> [] (check_unmap+0x0/0x6f0) from []
> (debug_dma_unmap_page+0x74/0x80)
> [] (debug_dma_unmap_page+0x0/0x80) from []
> (omap2_mcspi_work+0x514/0xbf0)
> [] (omap2_mcspi_work+0x0/0xbf0) from []
> (process_one_work+0x294/0x400)
> [] (process_one_work+0x0/0x400) from []
> (worker_thread+0x220/0x3f8)
> [] (worker_thread+0x0/0x3f8) from []
> (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from []
> (do_exit+0x0/0x5fc)
> r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> ---[ end trace 1b75b31a2719ed20 ]---
>
> I've no idea why this driver uses NULL for dma_unmap_single instead
> of
> the &spi->dev that is laying around just waiting to be used in that
> function - but it's an easy fix.
>
> Also replace this comment with a FIXME comment:
> /* Do DMA mapping "early" for better error reporting
> and
> * dcache use. Note that if dma_unmap_single() ever
> starts
> * to do real work on ARM, we'd need to clean up
> mappings
> * for previous transfers on *ALL* exits of this
> loop...
> */
> as the comment is not true - we do work in dma_unmap() functions,
> particularly on ARMv6 and above. I've corrected the existing unmap
> functions but if any others are required they must be added ASAP.
>
> Signed-off-by: Russell King
Thanks for fixing it
> ---
> I'm surprised this driver got merged as it has such a comment, and
> is
> abusing the DMA API... well, at least with the DMA API debugging we
> can now catch this stuff.
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/
Re: 4430SDP boot failure - solved + SPI bug fix
* Grant Likely [110107 09:18]: > On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote: > > Grant, > > > > Care to queue or ack the following fix? > > If you bounce the patch to me, then I'll pick it up into the spi tree > and send it on to Linus right away. (It didn't get sent to either me > or the spi list, so I don't have the original). Thanks, bounced it to you. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 09:10:20AM -0800, Tony Lindgren wrote: > Grant, > > Care to queue or ack the following fix? If you bounce the patch to me, then I'll pick it up into the spi tree and send it on to Linus right away. (It didn't get sent to either me or the spi list, so I don't have the original). Or if you want to pick it up: Acked-by: Grant Likely Nothing in my tree touches omap_mcspi.c for this merge window, so there won't be a merge conflict (I'm assuming you want this fix to go into 2.6.28). g. > > * Russell King - ARM Linux [110107 07:48]: > > On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote: > > > > -Original Message- > > > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > > > Sent: Friday, January 07, 2011 7:55 PM > > > > To: Santosh Shilimkar > > > > Cc: linux-omap@vger.kernel.org; Tony Lindgren > > > > Subject: Re: 4430SDP boot failure > > > > > > > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: > > > > > Have sent you latest bootloaders and full bootlog on my ES1.0 > > > > > OMAP4430SDP. 2.6.37 just boots fine for me. > > > > > > > > > > Low level debug as you reported seems to be broken though. > > > > > > > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on > > > > the board - which should ease the debugging problem as it no longer > > > > requires anything but the reset button pressed to test a new kernel. > > > > > > Glad to hear that. > > > > And, with one ARM errata disabled, the kernel finally boots. So the > > "X-Loader hangs" message means that we did something that non-secure > > mode prevented us from doing. > > > > It would be a good idea if X-loader could tell dump out the exception, > > register dump, and for data/prefetch aborts, the relevent FSR and FAR > > registers - that would make debugging this kind of failure a lot > > easier. > > > > = > > Subject: Fix DMA API usage in OMAP MCSPI driver > > > > Running the latest kernel on the 4430SDP board with DMA API debugging > > enabled results in this: > > > > WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0() > > NULL NULL: DMA-API: device driver tries to free DMA memory it has not > > allocated > > [device address=0x8129901a] [size=260 bytes] > > Modules linked in: > > Backtrace: > > [] (dump_backtrace+0x0/0x10c) from [] > > (dump_stack+0x18/0x1c) > > r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323 > > [] (dump_stack+0x0/0x1c) from [] > > (warn_slowpath_common+0x58/0x70) > > [] (warn_slowpath_common+0x0/0x70) from [] > > (warn_slowpath_fmt+0x38/0x40) > > r8:c1839e40 r7: r6:0104 r5: r4:8129901a > > [] (warn_slowpath_fmt+0x0/0x40) from [] > > (check_unmap+0x19c/0x6f0) > > r3:c03110de r2:c0304e6b > > [] (check_unmap+0x0/0x6f0) from [] > > (debug_dma_unmap_page+0x74/0x80) > > [] (debug_dma_unmap_page+0x0/0x80) from [] > > (omap2_mcspi_work+0x514/0xbf0) > > [] (omap2_mcspi_work+0x0/0xbf0) from [] > > (process_one_work+0x294/0x400) > > [] (process_one_work+0x0/0x400) from [] > > (worker_thread+0x220/0x3f8) > > [] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90) > > [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc) > > r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0 > > ---[ end trace 1b75b31a2719ed20 ]--- > > > > I've no idea why this driver uses NULL for dma_unmap_single instead of > > the &spi->dev that is laying around just waiting to be used in that > > function - but it's an easy fix. > > > > Also replace this comment with a FIXME comment: > > /* Do DMA mapping "early" for better error reporting and > > * dcache use. Note that if dma_unmap_single() ever starts > > * to do real work on ARM, we'd need to clean up mappings > > * for previous transfers on *ALL* exits of this loop... > > */ > > as the comment is not true - we do work in dma_unmap() functions, > > particularly on ARMv6 and above. I've corrected the existing unmap > > functions but if any others are required they must be added ASAP. > > > > Signed-off-by: Russell King > > Acked-by: Tony Lindgren > > > > --- > > I'm surprised this driver got merged as it has such a comment, and is > > abusing the DMA API..
Re: 4430SDP boot failure - solved + SPI bug fix
Grant,
Care to queue or ack the following fix?
* Russell King - ARM Linux [110107 07:48]:
> On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > > -Original Message-
> > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > > Sent: Friday, January 07, 2011 7:55 PM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > > Subject: Re: 4430SDP boot failure
> > >
> > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > > >
> > > > Low level debug as you reported seems to be broken though.
> > >
> > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > > the board - which should ease the debugging problem as it no longer
> > > requires anything but the reset button pressed to test a new kernel.
> >
> > Glad to hear that.
>
> And, with one ARM errata disabled, the kernel finally boots. So the
> "X-Loader hangs" message means that we did something that non-secure
> mode prevented us from doing.
>
> It would be a good idea if X-loader could tell dump out the exception,
> register dump, and for data/prefetch aborts, the relevent FSR and FAR
> registers - that would make debugging this kind of failure a lot
> easier.
>
> =
> Subject: Fix DMA API usage in OMAP MCSPI driver
>
> Running the latest kernel on the 4430SDP board with DMA API debugging
> enabled results in this:
>
> WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
> NULL NULL: DMA-API: device driver tries to free DMA memory it has not
> allocated
> [device address=0x8129901a] [size=260 bytes]
> Modules linked in:
> Backtrace:
> [] (dump_backtrace+0x0/0x10c) from []
> (dump_stack+0x18/0x1c)
> r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
> [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x58/0x70)
> [] (warn_slowpath_common+0x0/0x70) from []
> (warn_slowpath_fmt+0x38/0x40)
> r8:c1839e40 r7: r6:0104 r5: r4:8129901a
> [] (warn_slowpath_fmt+0x0/0x40) from []
> (check_unmap+0x19c/0x6f0)
> r3:c03110de r2:c0304e6b
> [] (check_unmap+0x0/0x6f0) from []
> (debug_dma_unmap_page+0x74/0x80)
> [] (debug_dma_unmap_page+0x0/0x80) from []
> (omap2_mcspi_work+0x514/0xbf0)
> [] (omap2_mcspi_work+0x0/0xbf0) from []
> (process_one_work+0x294/0x400)
> [] (process_one_work+0x0/0x400) from []
> (worker_thread+0x220/0x3f8)
> [] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
> r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
> ---[ end trace 1b75b31a2719ed20 ]---
>
> I've no idea why this driver uses NULL for dma_unmap_single instead of
> the &spi->dev that is laying around just waiting to be used in that
> function - but it's an easy fix.
>
> Also replace this comment with a FIXME comment:
> /* Do DMA mapping "early" for better error reporting and
> * dcache use. Note that if dma_unmap_single() ever starts
> * to do real work on ARM, we'd need to clean up mappings
> * for previous transfers on *ALL* exits of this loop...
> */
> as the comment is not true - we do work in dma_unmap() functions,
> particularly on ARMv6 and above. I've corrected the existing unmap
> functions but if any others are required they must be added ASAP.
>
> Signed-off-by: Russell King
Acked-by: Tony Lindgren
> ---
> I'm surprised this driver got merged as it has such a comment, and is
> abusing the DMA API... well, at least with the DMA API debugging we
> can now catch this stuff.
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 951a160..abb1ffb 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> spi_transfer *xfer)
>
> if (tx != NULL) {
> wait_for_completion(&mcspi_dma->dma_tx_completion);
> - dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
> + dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
>
> /* for TX_ONLY mode, be sure all words have shifted out */
> if (rx == NULL) {
> @@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
> spi_transfer *xfer)
>
> if (rx != NULL) {
>
Re: 4430SDP boot failure
Hello! On Fri, Jan 7, 2011 at 10:24 AM, Russell King - ARM Linux wrote: > On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote: >> > -Original Message- >> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] >> > Sent: Friday, January 07, 2011 7:55 PM >> > To: Santosh Shilimkar >> > Cc: linux-omap@vger.kernel.org; Tony Lindgren >> > Subject: Re: 4430SDP boot failure >> > >> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: >> > > Have sent you latest bootloaders and full bootlog on my ES1.0 >> > > OMAP4430SDP. 2.6.37 just boots fine for me. >> > > >> > > Low level debug as you reported seems to be broken though. >> > >> > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on >> > the board - which should ease the debugging problem as it no longer >> > requires anything but the reset button pressed to test a new kernel. >> >> Glad to hear that. > > Right, next couple of problems. > > udev isn't creating the ttyO* nodes for whatever reason on my fs - does > anyone know what device major/minor numbers these end up with? Â It seems > they're dynamically assigned. This is what I have: mazi-gentoo ~ # ls -l /dev/ttyO? crw-rw 1 root uucp 247, 0 Dec 31 1999 /dev/ttyO0 crw-rw 1 root uucp 247, 1 Dec 31 1999 /dev/ttyO1 crw--- 1 ddiaz tty 247, 2 Jan 7 11:02 /dev/ttyO2 crw-rw 1 root uucp 247, 3 Dec 31 1999 /dev/ttyO3 Greetings! Daniel DÃaz yo...@danieldiaz.org > There's also something fishy going on with networking (if I configure > PNP IP, I get an IP: > > ks8851 spi1.0: message enable is 0 > ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194 > IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144 > IP-Config: Complete: > Â Â device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1, > Â Â host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none), > Â Â bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= > > but the board doesn't respond to that IP address. Â Meanwhile the DHCP > server shows: > > Â Â Â Â DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0 > > in its log, and the ethernet address appears to be random for each boot. > Obviously, as I can't log into the board via any means, it's nigh on > impossible to work out what's actually going on. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote: > > -Original Message- > > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > > Sent: Friday, January 07, 2011 7:55 PM > > To: Santosh Shilimkar > > Cc: linux-omap@vger.kernel.org; Tony Lindgren > > Subject: Re: 4430SDP boot failure > > > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: > > > Have sent you latest bootloaders and full bootlog on my ES1.0 > > > OMAP4430SDP. 2.6.37 just boots fine for me. > > > > > > Low level debug as you reported seems to be broken though. > > > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on > > the board - which should ease the debugging problem as it no longer > > requires anything but the reset button pressed to test a new kernel. > > Glad to hear that. Right, next couple of problems. udev isn't creating the ttyO* nodes for whatever reason on my fs - does anyone know what device major/minor numbers these end up with? It seems they're dynamically assigned. There's also something fishy going on with networking (if I configure PNP IP, I get an IP: ks8851 spi1.0: message enable is 0 ks8851 spi1.0: eth0: revision 0, MAC 1a:6a:b1:02:1d:90, IRQ 194 IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.0.144 IP-Config: Complete: device=eth0, addr=192.168.0.144, mask=255.255.255.0, gw=192.168.0.1, host=192.168.0.144, domain=arm.linux.org.uk, nis-domain=(none), bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= but the board doesn't respond to that IP address. Meanwhile the DHCP server shows: DHCPDISCOVER from 1a:6a:b1:02:1d:90 via eth0 in its log, and the ethernet address appears to be random for each boot. Obviously, as I can't log into the board via any means, it's nigh on impossible to work out what's actually going on. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote: > Anyways, I can debug the DEBUG_LL booting issue further if the patch > I posted does not help. This is what I ended up with earlier today to make the debug code work both in the decompressor and in the kernel - once I had it working I haven't bothered putting any more effort into it. diff --git a/arch/arm/mach-omap2/include/mach/debug-macro.S b/arch/arm/mach-omap2/include/mach/debug-macro.S index 6a4d413..47df8a6 100644 --- a/arch/arm/mach-omap2/include/mach/debug-macro.S +++ b/arch/arm/mach-omap2/include/mach/debug-macro.S @@ -13,6 +13,7 @@ #include +#if 0 #include #include @@ -139,6 +140,24 @@ omap_uart_lsr: .word 0 teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE) bne 1001b .endm +#else + .macro addruart, rp, rv + mov \rp, #0x0002 + orr \rv, \rp, #0xfa00 + orr \rp, \rp, #0x4800 + .endm + + .macro senduart, ch, rb + strb\ch, [\rb] + .endm + + .macro busyuart, rb, tmp +1001: ldrb\tmp, [\rb, #UART_LSR << 2] + and \tmp, \tmp, #UART_LSR_TEMT | UART_LSR_THRE + teq \tmp, #UART_LSR_TEMT | UART_LSR_THRE + bne 1001b + .endm +#endif .macro waituart,rd,rx .endm -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure - solved + SPI bug fix
On Fri, Jan 07, 2011 at 07:56:34PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, January 07, 2011 7:55 PM
> > To: Santosh Shilimkar
> > Cc: linux-omap@vger.kernel.org; Tony Lindgren
> > Subject: Re: 4430SDP boot failure
> >
> > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote:
> > > Have sent you latest bootloaders and full bootlog on my ES1.0
> > > OMAP4430SDP. 2.6.37 just boots fine for me.
> > >
> > > Low level debug as you reported seems to be broken though.
> >
> > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on
> > the board - which should ease the debugging problem as it no longer
> > requires anything but the reset button pressed to test a new kernel.
>
> Glad to hear that.
And, with one ARM errata disabled, the kernel finally boots. So the
"X-Loader hangs" message means that we did something that non-secure
mode prevented us from doing.
It would be a good idea if X-loader could tell dump out the exception,
register dump, and for data/prefetch aborts, the relevent FSR and FAR
registers - that would make debugging this kind of failure a lot
easier.
=
Subject: Fix DMA API usage in OMAP MCSPI driver
Running the latest kernel on the 4430SDP board with DMA API debugging
enabled results in this:
WARNING: at lib/dma-debug.c:803 check_unmap+0x19c/0x6f0()
NULL NULL: DMA-API: device driver tries to free DMA memory it has not allocated
[device address=0x8129901a] [size=260 bytes]
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x10c) from [] (dump_stack+0x18/0x1c)
r7:c1839dc0 r6:c0198578 r5:c0304b17 r4:0323
[] (dump_stack+0x0/0x1c) from []
(warn_slowpath_common+0x58/0x70)
[] (warn_slowpath_common+0x0/0x70) from []
(warn_slowpath_fmt+0x38/0x40)
r8:c1839e40 r7: r6:0104 r5: r4:8129901a
[] (warn_slowpath_fmt+0x0/0x40) from []
(check_unmap+0x19c/0x6f0)
r3:c03110de r2:c0304e6b
[] (check_unmap+0x0/0x6f0) from []
(debug_dma_unmap_page+0x74/0x80)
[] (debug_dma_unmap_page+0x0/0x80) from []
(omap2_mcspi_work+0x514/0xbf0)
[] (omap2_mcspi_work+0x0/0xbf0) from []
(process_one_work+0x294/0x400)
[] (process_one_work+0x0/0x400) from []
(worker_thread+0x220/0x3f8)
[] (worker_thread+0x0/0x3f8) from [] (kthread+0x88/0x90)
[] (kthread+0x0/0x90) from [] (do_exit+0x0/0x5fc)
r7:0013 r6:c005e924 r5:c0073848 r4:c1829ee0
---[ end trace 1b75b31a2719ed20 ]---
I've no idea why this driver uses NULL for dma_unmap_single instead of
the &spi->dev that is laying around just waiting to be used in that
function - but it's an easy fix.
Also replace this comment with a FIXME comment:
/* Do DMA mapping "early" for better error reporting and
* dcache use. Note that if dma_unmap_single() ever starts
* to do real work on ARM, we'd need to clean up mappings
* for previous transfers on *ALL* exits of this loop...
*/
as the comment is not true - we do work in dma_unmap() functions,
particularly on ARMv6 and above. I've corrected the existing unmap
functions but if any others are required they must be added ASAP.
Signed-off-by: Russell King
---
I'm surprised this driver got merged as it has such a comment, and is
abusing the DMA API... well, at least with the DMA API debugging we
can now catch this stuff.
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 951a160..abb1ffb 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -397,7 +397,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (tx != NULL) {
wait_for_completion(&mcspi_dma->dma_tx_completion);
- dma_unmap_single(NULL, xfer->tx_dma, count, DMA_TO_DEVICE);
+ dma_unmap_single(&spi->dev, xfer->tx_dma, count, DMA_TO_DEVICE);
/* for TX_ONLY mode, be sure all words have shifted out */
if (rx == NULL) {
@@ -412,7 +412,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
if (rx != NULL) {
wait_for_completion(&mcspi_dma->dma_rx_completion);
- dma_unmap_single(NULL, xfer->rx_dma, count, DMA_FROM_DEVICE);
+ dma_unmap_single(&spi->dev, xfer->rx_dma, count,
DMA_FROM_DEVICE);
omap2_mcspi_set_enable(spi, 0);
if (l & OMAP2_MCSPI_CHCONF_TURBO) {
@@ -1025,11 +1025,6 @@ static int omap2_mcspi_transfer(struct spi_device *spi,
struct spi_message *m)
if (m->is_dma_mapped || len < DMA_MIN_BYTES)
continue;
- /* Do DMA mapping "early" for better error reporti
RE: 4430SDP boot failure
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, January 07, 2011 7:55 PM > To: Santosh Shilimkar > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: Re: 4430SDP boot failure > > On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: > > Have sent you latest bootloaders and full bootlog on my ES1.0 > > OMAP4430SDP. 2.6.37 just boots fine for me. > > > > Low level debug as you reported seems to be broken though. > > Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on > the board - which should ease the debugging problem as it no longer > requires anything but the reset button pressed to test a new kernel. Glad to hear that. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 06:39:06PM +0530, Santosh Shilimkar wrote: > Have sent you latest bootloaders and full bootlog on my ES1.0 > OMAP4430SDP. 2.6.37 just boots fine for me. > > Low level debug as you reported seems to be broken though. Many thanks, the new mlo and uboot gets dhcp/tftp working nicely on the board - which should ease the debugging problem as it no longer requires anything but the reset button pressed to test a new kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 02:07:53PM +0100, Koen Kooi wrote: > Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende > geschreven: > > This is the command line I've been giving it: > > > > setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G > > console=ttyO2,115200n8 rootdelay=2' > > Why are people still using rootdelay? 'rootwait' is vastly superior and > doesn't need tweaking for every card/controller combo. Does it matter if the effect it produces works? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
Op 7 jan 2011, om 13:51 heeft Russell King - ARM Linux het volgende geschreven: > This is the command line I've been giving it: > > setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G > console=ttyO2,115200n8 rootdelay=2' Why are people still using rootdelay? 'rootwait' is vastly superior and doesn't need tweaking for every card/controller combo. regards, Koen-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, January 07, 2011 6:22 PM > To: Santosh Shilimkar > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: Re: 4430SDP boot failure > > On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote: > > > -Original Message- > > > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > > > Sent: Friday, January 07, 2011 3:23 PM > > Ruessell, > > > > > > > To: Russell King - ARM Linux > > > Cc: linux-omap@vger.kernel.org; Tony Lindgren > > > Subject: RE: 4430SDP boot failure > > > > > > > [] > > > > > > BTW, if it makes any difference to the boot loader, please > note > > > that > > > > I'm > > > > still waiting for the upgrade for the SDP board. > > > That means your board is with ES1.0. I shall try 2.6.37 on > > > ES1.0 > > > > ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing > an > > issue. The console is changed to OMAP serial driver from 8250 > > driver. > > > > Can you try "console=ttyO2" instead of existing ""console=ttyS2" > ?? > > This is the command line I've been giving it: > > setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G > console=ttyO2,115200n8 rootdelay=2' > > and in my .config, I have: > > CONFIG_SERIAL_OMAP=y > CONFIG_SERIAL_OMAP_CONSOLE=y > Yep. Noticed that after the post. > so the driver is also enabled. I found this on the 3430LDP, and so > switched both OMAP3 and OMAP4 stuff over to the new driver. > > That wouldn't explain why I'm getting the "X-loader hangs" message > which brings everything to a halt, and why the low level debug stuff > doesn't work. Have sent you latest bootloaders and full bootlog on my ES1.0 OMAP4430SDP. 2.6.37 just boots fine for me. Low level debug as you reported seems to be broken though. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 05:48:41PM +0530, Santosh Shilimkar wrote: > > -Original Message- > > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > > Sent: Friday, January 07, 2011 3:23 PM > Ruessell, > > > > To: Russell King - ARM Linux > > Cc: linux-omap@vger.kernel.org; Tony Lindgren > > Subject: RE: 4430SDP boot failure > > > > [] > > > > BTW, if it makes any difference to the boot loader, please note > > that > > > I'm > > > still waiting for the upgrade for the SDP board. > > That means your board is with ES1.0. I shall try 2.6.37 on > > ES1.0 > > ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an > issue. The console is changed to OMAP serial driver from 8250 > driver. > > Can you try "console=ttyO2" instead of existing ""console=ttyS2" ?? This is the command line I've been giving it: setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' and in my .config, I have: CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y so the driver is also enabled. I found this on the 3430LDP, and so switched both OMAP3 and OMAP4 stuff over to the new driver. That wouldn't explain why I'm getting the "X-loader hangs" message which brings everything to a halt, and why the low level debug stuff doesn't work. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure
Sorry, > -Original Message- > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > Sent: Friday, January 07, 2011 5:49 PM > To: Russell King - ARM Linux > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: RE: 4430SDP boot failure > > > -Original Message- > > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > > Sent: Friday, January 07, 2011 3:23 PM > Ruessell, > > > > To: Russell King - ARM Linux > > Cc: linux-omap@vger.kernel.org; Tony Lindgren > > Subject: RE: 4430SDP boot failure > > > > [] > > > > BTW, if it makes any difference to the boot loader, please note > > that > > > I'm > > > still waiting for the upgrade for the SDP board. > > That means your board is with ES1.0. I shall try 2.6.37 on > > ES1.0 > > ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an > issue. The console is changed to OMAP serial driver from 8250 > driver. > > Can you try "console=ttyO2" instead of existing ""console=ttyS2" ?? > Ignore my last email. You have tried that already Will send you updated boot-loaders in next few mins. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure
> -Original Message- > From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] > Sent: Friday, January 07, 2011 3:23 PM Ruessell, > To: Russell King - ARM Linux > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: RE: 4430SDP boot failure > [] > > BTW, if it makes any difference to the boot loader, please note > that > > I'm > > still waiting for the upgrade for the SDP board. > That means your board is with ES1.0. I shall try 2.6.37 on > ES1.0 ES1.0 boot nicely on 2.6.37 and I guess I know why you are seeing an issue. The console is changed to OMAP serial driver from 8250 driver. Can you try "console=ttyO2" instead of existing ""console=ttyS2" ?? Will send you the latest boot-loader after doing a boot test. ## Booting image at 8030 ... Image Name: Linux-2.6.37 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2898440 Bytes = 2.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.37 (a0393...@a0393909-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #6 SMP Fri Jan 7 17:12:26 IST 2011 [0.00] CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4430 4430SDP board [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES1.0 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] FIXME: omap44xx_sram_init not implemented [0.00] PERCPU: Embedded 7 pages/cpu @c0f3d000 s6080 r8192 d14400 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 [0.00] Kernel command line: console=ttyO2,115200n8 noinitrd root=/dev/nfs rw nfsroot=172.24.190.46:/ubuntu/nfs-share/omap4_next/,nolock,tcp,rsize=1024, wsize=1024 ip=dhcp [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 512MB = 512MB total [0.00] Memory: 508228k/508228k available, 16060k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xe080 - 0xf800 ( 376 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc004a000 ( 264 kB) [0.00] .text : 0xc004a000 - 0xc056904c (5245 kB) [0.00] .data : 0xc056a000 - 0xc05dadc0 ( 452 kB) [0.00] Hierarchical RCU implementation. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, January 07, 2011 2:58 PM > To: Santosh Shilimkar > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: Re: 4430SDP boot failure > > On Fri, Jan 07, 2011 at 02:09:17PM +0530, Santosh Shilimkar wrote: > > > Can we _please_ have a version of uboot for the SDP4430 platform > > > which > > > can be configured at runtime _and_ which is capable of DHCP/TFTP > ? > > > I really don't want to mess about anymore with buggy boot > loaders. > > Just read this thread. Looks like you are not able to boot the > kernel > > at all. 2.6.37 + Tony's queue booted for me without any issues. > > I can only boot older kernels. I can't debug later kernels because > as soon as I access the UART, I get this very bland 'X-loader hangs' > message which is no help what so ever (for the amount of use it is, > it > might as well not even print that.) > > I don't know whether that's because I'm doing something wrong or > what as > there's no way to get any diagnostics out of the system. > Ok. Will try 2.6.37 major version. > The u-boot SD card issues are just another layer of timewasting > frustration > which really doesn't help. I don't want to spend many hours > debugging > the boot loader because it also doesn't work properly. I want > something > which works every time without fail. > > BTW, if it makes any difference to the boot loader, please note that > I'm > still waiting for the upgrade for the SDP board. That means your board is with ES1.0. I shall try 2.6.37 on ES1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Fri, Jan 07, 2011 at 02:09:17PM +0530, Santosh Shilimkar wrote: > > Can we _please_ have a version of uboot for the SDP4430 platform > > which > > can be configured at runtime _and_ which is capable of DHCP/TFTP ? > > I really don't want to mess about anymore with buggy boot loaders. > Just read this thread. Looks like you are not able to boot the kernel > at all. 2.6.37 + Tony's queue booted for me without any issues. I can only boot older kernels. I can't debug later kernels because as soon as I access the UART, I get this very bland 'X-loader hangs' message which is no help what so ever (for the amount of use it is, it might as well not even print that.) I don't know whether that's because I'm doing something wrong or what as there's no way to get any diagnostics out of the system. The u-boot SD card issues are just another layer of timewasting frustration which really doesn't help. I don't want to spend many hours debugging the boot loader because it also doesn't work properly. I want something which works every time without fail. BTW, if it makes any difference to the boot loader, please note that I'm still waiting for the upgrade for the SDP board. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: 4430SDP boot failure
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Friday, January 07, 2011 5:22 AM > To: Santosh Shilimkar > Cc: linux-omap@vger.kernel.org; Tony Lindgren > Subject: Re: 4430SDP boot failure [..] > > > OMAP44XX SDP # fatls mmc 0 > > 1935000 uimage >149104 u-boot.bin > 18984 mlo > 1836636 uimage-test > 1130288 uimage-ss > 19040 mlo.old > Invalid FAT entry > > 6 file(s), 0 dir(s) > > "Invalid FAT entry" ? I don't think so. The thing actually > contains: > > -rwxr-xr-x. 1 rmk rmk 1935000 Feb 4 2010 uImage > -rwxr-xr-x. 1 rmk rmk 149104 Feb 4 2010 u-boot.bin > -rwxr-xr-x. 1 rmk rmk 18984 Jan 1 2000 mlo > -rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 21:35 uImage-test > -rwxr-xr-x. 1 rmk rmk 1130288 Jan 1 2000 uImage-ss > -rwxr-xr-x. 1 rmk rmk 19040 Feb 4 2010 mlo.old > -rwxr-xr-x. 1 rmk rmk 154904 Jan 1 2000 u-boot.new > [..] > So, uboot's FAT code can't deal with a directory larger than one > sector > that doesn't continue. While we're here, lets confirm by hand that > there's nothing wrong with the uImage-test file and it's yet again > uboot > being idiotic. > [..] > Can we _please_ have a version of uboot for the SDP4430 platform > which > can be configured at runtime _and_ which is capable of DHCP/TFTP ? > I really don't want to mess about anymore with buggy boot loaders. Just read this thread. Looks like you are not able to boot the kernel at all. 2.6.37 + Tony's queue booted for me without any issues. I can give a try on 2.6.37. TFTP is already supported on the latest bootloaders. http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/o map4_dev Will send you binaries in another email. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Russell King - ARM Linux [110106 15:51]: > On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote: > > > > OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G > > console=ttyO2,115200n8 rootdelay=2' > > OMAP44XX SDP # mmcinit 0 > > OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test > > > > 0 bytes read > > OMAP44XX SDP # > > > > However, it can still boot the uImage contained on the SD card, so the > > card must be okay, and the SDP must still be able to successfully read > > from the card. I can only assume that uboot's FAT support is buggered > > in some way. Sorry no idea about this problem, have not seen it myself. > > We _really_ need a _decent_ boot loader on these boards, one which can > > do network booting _and_ can be configured to do so from bootup. SD > > cards just don't hack it for kernel development. It's a far too long- > > winded process for each cycle, and with all the additional problems > > (such as SD cards not being recognised 50% of the time, FAT filesystem > > bugs in boot loaders, etc) it's really not funny. I totally agree. Flipping micro-SD cards for development is no fun. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren [110106 11:52]:
> > > --- a/arch/arm/boot/compressed/head.S
> > > +++ b/arch/arm/boot/compressed/head.S
> > > @@ -71,6 +71,23 @@ wait: mrc p14, 0, pc, c0, c1, 0
> > > mov \rb, #0x5000
> > > add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT
> > > .endm
> > > +#elif defined(CONFIG_ARCH_OMAP2PLUS)
> > > +#include
> > > +#ifdef MULTI_OMAP2)
> > ^
> > Looks like my last change to this patch from if defined to ifdef
> > broke the warning above with an unbalanced bracket..
> >
> > Thanks Nishant for catching that, updated patch below.
>
> Just tried that patch, but I now have bigger problems:
>
> OMAP44XX SDP # mmcinit 0
> OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test
>
> 0 bytes read
> OMAP44XX SDP #
>
> God knows why it's doing this now, as the file is present on the SD
> card:
>
> -rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 20:35 uImage-test
>
> is what's on the SD card - with no FAT errors:
>
> $ fsck.msdos /dev/mmcblk0p1
> dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN
> /dev/mmcblk0p1: 8 files, 10249/142266 clusters
>
> The file's not corrupt either:
>
> $ md5sum /media/boot/uImage-test
> be3edd928f1dbb3c15215b1a8a62fa1f /media/boot/uImage-test
> $ md5sum ../build/omap4/arch/arm/boot/uImage
> be3edd928f1dbb3c15215b1a8a62fa1f ../build/omap4/arch/arm/boot/uImage
>
> Nope, still won't work:
>
> OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G
> console=ttyO2,115200n8 rootdelay=2'
> OMAP44XX SDP # mmcinit 0
> OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test
>
> 0 bytes read
> OMAP44XX SDP #
>
> However, it can still boot the uImage contained on the SD card, so the
> card must be okay, and the SDP must still be able to successfully read
> from the card. I can only assume that uboot's FAT support is buggered
> in some way.
>
> We _really_ need a _decent_ boot loader on these boards, one which can
> do network booting _and_ can be configured to do so from bootup. SD
> cards just don't hack it for kernel development. It's a far too long-
> winded process for each cycle, and with all the additional problems
> (such as SD cards not being recognised 50% of the time, FAT filesystem
> bugs in boot loaders, etc) it's really not funny.
>
> So, I give up at this point with the OMAP4430SDP board. It's not worth
> spending the time with this kind of unreliability.
OMAP44XX SDP # fatls mmc 0
1935000 uimage
149104 u-boot.bin
18984 mlo
1836636 uimage-test
1130288 uimage-ss
19040 mlo.old
Invalid FAT entry
6 file(s), 0 dir(s)
"Invalid FAT entry" ? I don't think so. The thing actually contains:
-rwxr-xr-x. 1 rmk rmk 1935000 Feb 4 2010 uImage
-rwxr-xr-x. 1 rmk rmk 149104 Feb 4 2010 u-boot.bin
-rwxr-xr-x. 1 rmk rmk 18984 Jan 1 2000 mlo
-rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 21:35 uImage-test
-rwxr-xr-x. 1 rmk rmk 1130288 Jan 1 2000 uImage-ss
-rwxr-xr-x. 1 rmk rmk 19040 Feb 4 2010 mlo.old
-rwxr-xr-x. 1 rmk rmk 154904 Jan 1 2000 u-boot.new
The hexdump of the directory on the SD card is:
0011a000 62 6f 6f 74 20 20 20 20 20 20 20 08 00 00 87 b6 |boot .|
0011a010 3e 3c 3e 3c 00 00 87 b6 3e 3c 00 00 00 00 00 00 |><><><..|
0011a020 41 75 00 49 00 6d 00 61 00 67 00 0f 00 46 65 00 |Au.I.m.a.g...Fe.|
0011a030 00 00 ff ff ff ff ff ff ff ff 00 00 ff ff ff ff ||
0011a040 55 49 4d 41 47 45 20 20 20 20 20 20 00 64 6d 65 |UIMAGE .dme|
0011a050 44 3c 26 3e 00 00 6d 65 44 3c 4a 0e 98 86 1d 00 |D<&>..meD..(.!(!-(J..|
0011a0e0 41 75 00 49 00 6d 00 61 00 67 00 0f 00 4e 65 00 |Au.I.m.a.g...Ne.|
0011a0f0 2d 00 74 00 65 00 73 00 74 00 00 00 00 00 ff ff |-.t.e.s.t...|
0011a100 55 49 4d 41 47 45 7e 31 20 20 20 20 00 64 7b ac |UIMAGE~1.d{.|
0011a110 26 3e 26 3e 00 00 7b ac 26 3e ce fb 5c 06 1c 00 |&>&>..{.&>..\...|
0011a120 e5 75 00 2d 00 62 00 6f 00 6f 00 0f 00 14 74 00 |.u.-.b.o.ot.|
0011a130 2e 00 42 00 49 00 32 00 00 00 00 00 ff ff ff ff |..B.I.2.|
0011a140 e5 2d 42 4f 4f 54 20 20 42 49 32 20 00 64 6f 65 |.-BOOT BI2 .doe|
0011a150 44 3c bc 3c 00 00 6f 65 44 3c 0e 1d 70 46 02 00 |D<.<..oeD<..pF..|
0011a160 41 75 00 49 00 6d 00 61 00 67 00 0f 00 6e 65 00 |Au.I.m.a.g...ne.|
0011a170 2d 00 73 00 73 00 00 00 ff ff 00 00 ff ff ff ff |-.s.s...|
0011a180 55 49 4d 41 47 45 7e 32 20 20 20 20 00 64 bb 00 |UIMAGE~2.d..|
0011a190 21 28 26 3e 00 00 bb 00 21 28 76 2e 30 3f 11 00 |!(&>!(v.0?..|
0011a1a0 41 6d 00 6c 00 6f 00 2e 00 6f 00 0f 00 4e 6c 00 |Am.l.o...o...Nl.|
0011a1b0 64 00 00 00 ff ff ff ff ff ff 00 00 ff ff ff ff |d...|
0011a1c0 4d 4c 4f 20 20 20 20 20 4f 4c 44 20 00 64 73 65 |MLO OLD .dse|
0011a1d0 44 3c 6a 3c 00 00 73 65 44 3c 32 1e 60 4a 00 00 |D..=.!(G-.]..|
00a29220 0
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 08:51:07PM +, Russell King - ARM Linux wrote: > We _really_ need a _decent_ boot loader on these boards, one which can > do network booting _and_ can be configured to do so from bootup. SD > cards just don't hack it for kernel development. It's a far too long- > winded process for each cycle, and with all the additional problems > (such as SD cards not being recognised 50% of the time, FAT filesystem > bugs in boot loaders, etc) it's really not funny. > > So, I give up at this point with the OMAP4430SDP board. It's not worth > spending the time with this kind of unreliability. To top it off, the crappy 3rd party ftdi_sio driver I have to use for the SDP board just oopsed my x86 kernel. Do you get the impression that if something can go wrong, it will go wrong... I think I'll leave the 4430SDP alone until I have more patience for it. I might see about setting up the ARM Realview platform as a remote terminal for the 4430SDP so at least these kinds of crashes don't take out my work machine. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 12:34:32PM -0800, Tony Lindgren wrote: > * Tony Lindgren [110106 11:52]: > > --- a/arch/arm/boot/compressed/head.S > > +++ b/arch/arm/boot/compressed/head.S > > @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0 > > mov \rb, #0x5000 > > add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT > > .endm > > +#elif defined(CONFIG_ARCH_OMAP2PLUS) > > +#include > > +#ifdef MULTI_OMAP2) > ^ > Looks like my last change to this patch from if defined to ifdef > broke the warning above with an unbalanced bracket.. > > Thanks Nishant for catching that, updated patch below. Just tried that patch, but I now have bigger problems: OMAP44XX SDP # mmcinit 0 OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test 0 bytes read OMAP44XX SDP # God knows why it's doing this now, as the file is present on the SD card: -rwxr-xr-x. 1 rmk rmk 1836636 Jan 6 20:35 uImage-test is what's on the SD card - with no FAT errors: $ fsck.msdos /dev/mmcblk0p1 dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN /dev/mmcblk0p1: 8 files, 10249/142266 clusters The file's not corrupt either: $ md5sum /media/boot/uImage-test be3edd928f1dbb3c15215b1a8a62fa1f /media/boot/uImage-test $ md5sum ../build/omap4/arch/arm/boot/uImage be3edd928f1dbb3c15215b1a8a62fa1f ../build/omap4/arch/arm/boot/uImage Nope, still won't work: OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk0p2 rw mem=512M vmalloc=1G console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0 OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test 0 bytes read OMAP44XX SDP # However, it can still boot the uImage contained on the SD card, so the card must be okay, and the SDP must still be able to successfully read from the card. I can only assume that uboot's FAT support is buggered in some way. We _really_ need a _decent_ boot loader on these boards, one which can do network booting _and_ can be configured to do so from bootup. SD cards just don't hack it for kernel development. It's a far too long- winded process for each cycle, and with all the additional problems (such as SD cards not being recognised 50% of the time, FAT filesystem bugs in boot loaders, etc) it's really not funny. So, I give up at this point with the OMAP4430SDP board. It's not worth spending the time with this kind of unreliability. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Russell King - ARM Linux [110106 12:32]:
> On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [110106 10:00]:
> > > can't be in the BSS section?
> >
> > BSS works too, got a patch for that?
>
> Yes.
>
> sed -i '/\.pushsection \.data/,/\.popsection/ {
> s/\.data/.bss/;
> s/.word\t0/.space\t4/;
> }' arch/arm/mach-omap2/include/mach/debug-macro.S
That does not work as BSS gets cleared in head-common.S.. See my other patch.
> > Can you please check if you have some older bootloader that passes
> > some wrong machine ID?
>
> If previous kernels didn't explicitly force the SDP4430 platform ID
> number (which they didn't for OMAP back to 2007), then it must be
> correct as previous kernels booted fine when only configured for
> the SDP4430.
>
> It must also be correct as the decompressor can select the correct port
> for outputting the "Decompressing kernel..." message.
>
> So by implication I think we can say that the ID number is correct.
OK thanks.
> I've just tried forcing it to use OMAP4 UART3, which seems to be what
> the decompressor is using for its output:
>
> 090c :
> 90c: e3a03802mov r3, #131072 ; 0x2
> 910: e38314faorr r1, r3, #-100663296 ; 0xfa00
> 914: e3833312orr r3, r3, #1207959552 ; 0x4800
> 918: e4d02001ldrbr2, [r0], #1
> 91c: e332teq r2, #0 ; 0x0
> 920: 01a0f00emoveq pc, lr
> 924: e5c32000strbr2, [r3]
> 928: e3a01802mov r1, #131072 ; 0x2
> 92c: e2511001subsr1, r1, #1 ; 0x1
> 930: 1afdbne 92c
> 934: e332000ateq r2, #10 ; 0xa
> 938: 03a0200dmoveq r2, #13 ; 0xd
> 93c: 0af8beq 924
> 940: e330teq r0, #0 ; 0x0
> 944: 1af3bne 918
> 948: e1a0f00emov pc, lr
>
> 0x4802 is the only UART address contained within the disassembly for
> the decompressor to use, so that must be the correct address.
>
> However, even with that, it causes the 'X-Loader hangs' before producing
> any output. No idea what to try next - and it's soo much hastle to keep
> moving SD cards around - which the laptop sometimes doesn't recognise -
> just to try new kernels that I'm wasting quite a bit of effort on each
> iteration it's untrue.
>
> As I said previously, I think someone else can look into this - someone
> who understands the hardware quirks of OMAP, who has a decent test setup,
> and has the tools necessary to do hardware debug on OMAP.
I think I got it fixed, see the other patch I just posted.
> (If it could do dhcp/tftp - and be configured to do that from powerup
> without interruption, then I might feel differently as that would
> significantly reduce the hastle factor and amount of time involved with
> testing each iteration.)
Yes these new boards badly need the Ethernet working in u-boot..
Anyways, I can debug the DEBUG_LL booting issue further if the patch
I posted does not help.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Tony Lindgren [110106 11:52]: > --- a/arch/arm/boot/compressed/head.S > +++ b/arch/arm/boot/compressed/head.S > @@ -71,6 +71,23 @@ wait: mrc p14, 0, pc, c0, c1, 0 > mov \rb, #0x5000 > add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT > .endm > +#elif defined(CONFIG_ARCH_OMAP2PLUS) > +#include > +#ifdef MULTI_OMAP2) ^ Looks like my last change to this patch from if defined to ifdef broke the warning above with an unbalanced bracket.. Thanks Nishant for catching that, updated patch below. Regards, Tony From: Tony Lindgren Date: Thu, 6 Jan 2011 11:29:39 -0800 Subject: [PATCH] ARM: Fix low-level decompress debug code for omap If DEBUG is enabled for decompress code, the system will hang as the debug UART is not specified. Fix this by adding the necessary code for omap2plus. Note that this won't work properly with multi-omap support compiled in. Also the debug UART used needs to be patched in if not omap UART3. Signed-off-by: Tony Lindgren --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0 mov \rb, #0x5000 add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT .endm +#elif defined(CONFIG_ARCH_OMAP2PLUS) +#include +#ifdef MULTI_OMAP2 +#error Low-level uncompress debug code won't work with multi-omap +#elif defined(CONFIG_ARCH_OMAP2) + .macro loadsp, rb, tmp + ldr \rb, =OMAP2_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP3) + .macro loadsp, rb, tmp + ldr \rb, =OMAP3_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP4) + .macro loadsp, rb, tmp + ldr \rb, =OMAP4_UART3_BASE /* patch accordingly */ + .endm +#endif #else .macro loadsp, rb, tmp addruart \rb, \tmp -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 10:20:23AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [110106 10:00]:
> > On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote:
> > > This looks like something's rather broken on OMAP4 too - even with the
> > > DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with
> > > vanilla 2.6.37. So, no OMAP platform I have seems to be usable with
> > > 2.6.37...
> > >
> > > It's worth noting that the kernel which was originally supplied with the
> > > board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have
> > > previous kernels I've built.
> > >
> > > Is there yet an updated uboot for this platform which works with ethernet,
> > > and which has the uboot environment saving implemented? Or are we stuck
> > > with having to catch uboot before it runs the default settings and paste
> > > the commands in each time? Also, if possible please extend the default
> > > timeout - I can only just get from the board to the terminal to stop it
> > > booting the default environment.
> > >
> > > For TI folk: it may be an idea to make X-loader say why it's hanging so
> > > that we know what is going on.
> >
> > And another thing: turning on DEBUG in the decompressor breaks the build
> > on OMAP:
> >
> > `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o:
> > defined in discarded section `.data' of arch/arm/boot/compressed/head.o
> > `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o:
> > defined in discarded section `.data' of arch/arm/boot/compressed/head.o
> >
> > Is there a reason why this:
> >
> > .pushsection .data
> > omap_uart_phys: .word 0
> > omap_uart_virt: .word 0
> > omap_uart_lsr: .word 0
> > .popsection
> >
> > can't be in the BSS section?
>
> BSS works too, got a patch for that?
Yes.
sed -i '/\.pushsection \.data/,/\.popsection/ {
s/\.data/.bss/;
s/.word\t0/.space\t4/;
}' arch/arm/mach-omap2/include/mach/debug-macro.S
> > With that fixed, and a debug version of the decompressor built, when I
> > load and run this I get the same results - without the debugging output.
> > If I put additional debugging earlier in the decompressor, I don't see
> > it decompressing the kernel at all.
> >
> > Therefore, I believe the debugging address calculation stuff in
> > arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken,
> > causing an abort when it tries to access the serial port.
>
> Can you please check if you have some older bootloader that passes
> some wrong machine ID?
If previous kernels didn't explicitly force the SDP4430 platform ID
number (which they didn't for OMAP back to 2007), then it must be
correct as previous kernels booted fine when only configured for
the SDP4430.
It must also be correct as the decompressor can select the correct port
for outputting the "Decompressing kernel..." message.
So by implication I think we can say that the ID number is correct.
I've just tried forcing it to use OMAP4 UART3, which seems to be what
the decompressor is using for its output:
090c :
90c: e3a03802mov r3, #131072 ; 0x2
910: e38314faorr r1, r3, #-100663296 ; 0xfa00
914: e3833312orr r3, r3, #1207959552 ; 0x4800
918: e4d02001ldrbr2, [r0], #1
91c: e332teq r2, #0 ; 0x0
920: 01a0f00emoveq pc, lr
924: e5c32000strbr2, [r3]
928: e3a01802mov r1, #131072 ; 0x2
92c: e2511001subsr1, r1, #1 ; 0x1
930: 1afdbne 92c
934: e332000ateq r2, #10 ; 0xa
938: 03a0200dmoveq r2, #13 ; 0xd
93c: 0af8beq 924
940: e330teq r0, #0 ; 0x0
944: 1af3bne 918
948: e1a0f00emov pc, lr
0x4802 is the only UART address contained within the disassembly for
the decompressor to use, so that must be the correct address.
However, even with that, it causes the 'X-Loader hangs' before producing
any output. No idea what to try next - and it's soo much hastle to keep
moving SD cards around - which the laptop sometimes doesn't recognise -
just to try new kernels that I'm wasting quite a bit of effort on each
iteration it's untrue.
As I said previously, I think someone else can look into this - someone
who understands the hardware quirks of OMAP, who has a decent test setup,
and has the tools necessary to do hardware debug on OMAP.
(If it could do dhcp/tftp - and be configured to do that from powerup
without interruption, then I might feel differently as that would
significantly reduce the hastle factor and amount of time involved with
testing each iteration.)
--
To unsubscribe from this list: send the line "unsubscrib
Re: 4430SDP boot failure
* Tony Lindgren [110106 10:20]: > * Russell King - ARM Linux [110106 10:00]: > > On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote: > > > > And another thing: turning on DEBUG in the decompressor breaks the build > > on OMAP: > > > > `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: > > defined in discarded section `.data' of arch/arm/boot/compressed/head.o > > `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: > > defined in discarded section `.data' of arch/arm/boot/compressed/head.o > > > > Is there a reason why this: > > > > .pushsection .data > > omap_uart_phys: .word 0 > > omap_uart_virt: .word 0 > > omap_uart_lsr: .word 0 > > .popsection > > > > can't be in the BSS section? > > BSS works too, got a patch for that? Actually BSS won't work here, that's not initialized early enough.. But it seems that the only patch that's needed is the following. Care to give it a try? Here's what I'm getting with this patch and DEBUG enabled for the uncompress code on my omap4 panda: Uncompressing Linux... done, booting the kernel. 00AC3990:0AE7:00C5187F 802C9EBC-80849D3C>80008000 80849D9C 80008000: E321F0D3 EE109F10 EB0F216F E1B0A005 0A0F217E EBD8 E1B08005 0A94 80008020: EBE5 EB0F214B EB04 E59FD008 E28FE000 E28AF010 EA0F213B C00083F4 80008040: E59F4204 E1A4 E3A03000 E2806901 E4803004 E4803004 E4803004 E4803004 80008060: E136 1AF9 E59A7008 E28F0F7D E8900068 E043 E0855000 E0866000 80008080: E1A05A25 E1A06A26 E1873A05 E7843105 E1350006 12855001 1AFA E1A0300F 800080A0: E1A03A23 E1873A03 E2840A03 E5A03000 E59F6198 E284 E0846926 E156 800080C0: E2833601 94803004 9AFB E2840A03 E3876102 E5806000 EE117F10 E3170001 800080E0: 059F716C 159F716C E2873004 E5977000 E5933000 E357 1353 1A43 [0.00] Linux version 2.6.37-1-g98859f0-dirty (tml...@baageli) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #468 SMP Thu Jan 6 11:46:09 PST 2011 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled ... Regards, Tony From: Tony Lindgren Date: Thu, 6 Jan 2011 11:29:39 -0800 Subject: [PATCH] ARM: Fix low-level decompress debug code for omap If DEBUG is enabled for decompress code, the system will hang as the debug UART is not specified. Fix this by adding the necessary code for omap2plus. Note that this won't work properly with multi-omap support compiled in. Also the debug UART used needs to be patched in if not omap UART3. Signed-off-by: Tony Lindgren --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -71,6 +71,23 @@ wait:mrc p14, 0, pc, c0, c1, 0 mov \rb, #0x5000 add \rb, \rb, #0x4000 * CONFIG_S3C_LOWLEVEL_UART_PORT .endm +#elif defined(CONFIG_ARCH_OMAP2PLUS) +#include +#ifdef MULTI_OMAP2) +#error Low-level uncompress debug code won't work with multi-omap +#elif defined(CONFIG_ARCH_OMAP2) + .macro loadsp, rb, tmp + ldr \rb, =OMAP2_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP3) + .macro loadsp, rb, tmp + ldr \rb, =OMAP3_UART3_BASE /* patch accordingly */ + .endm +#elif defined(CONFIG_ARCH_OMAP4) + .macro loadsp, rb, tmp + ldr \rb, =OMAP4_UART3_BASE /* patch accordingly */ + .endm +#endif #else .macro loadsp, rb, tmp addruart \rb, \tmp -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Russell King - ARM Linux [110106 10:17]: > On Thu, Jan 06, 2011 at 06:00:30PM +, Russell King - ARM Linux wrote: > > Therefore, I believe the debugging address calculation stuff in > > arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, > > causing an abort when it tries to access the serial port. > > I'm sorry, I think this crap has to go. Trying to make it fit every > platform in one kernel is just too complicated. It _needs_ to be > something so damned simple that it always works without fail, every > single time someone wants to use it. > > The current code really hasn't a hope of doing that. > > Yes, that means you only configure it when you're not building a multi- > platform kernel, but that's worth giving up if in return we have something > that is 100% reliable. > > As it is, I need to invent new debugging code to debug this mess. Sorry, > I'm actually not going to bother - as the LL debug stuff was my debugging > code to debug exactly these kinds of boot problems. Someone else can have > the pain of sorting out this breakage, and tell me when they expect OMAP > to work again. Something that could help with the DEBUG_LL code is to pass optional debug UART info masked into the machine_id using the high bits.. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
* Russell King - ARM Linux [110106 10:00]: > On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote: > > This looks like something's rather broken on OMAP4 too - even with the > > DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with > > vanilla 2.6.37. So, no OMAP platform I have seems to be usable with > > 2.6.37... > > > > It's worth noting that the kernel which was originally supplied with the > > board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have > > previous kernels I've built. > > > > Is there yet an updated uboot for this platform which works with ethernet, > > and which has the uboot environment saving implemented? Or are we stuck > > with having to catch uboot before it runs the default settings and paste > > the commands in each time? Also, if possible please extend the default > > timeout - I can only just get from the board to the terminal to stop it > > booting the default environment. > > > > For TI folk: it may be an idea to make X-loader say why it's hanging so > > that we know what is going on. > > And another thing: turning on DEBUG in the decompressor breaks the build > on OMAP: > > `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: > defined in discarded section `.data' of arch/arm/boot/compressed/head.o > `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: > defined in discarded section `.data' of arch/arm/boot/compressed/head.o > > Is there a reason why this: > > .pushsection .data > omap_uart_phys: .word 0 > omap_uart_virt: .word 0 > omap_uart_lsr: .word 0 > .popsection > > can't be in the BSS section? BSS works too, got a patch for that? > With that fixed, and a debug version of the decompressor built, when I > load and run this I get the same results - without the debugging output. > If I put additional debugging earlier in the decompressor, I don't see > it decompressing the kernel at all. > > Therefore, I believe the debugging address calculation stuff in > arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, > causing an abort when it tries to access the serial port. Can you please check if you have some older bootloader that passes some wrong machine ID? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 06:00:30PM +, Russell King - ARM Linux wrote: > Therefore, I believe the debugging address calculation stuff in > arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, > causing an abort when it tries to access the serial port. I'm sorry, I think this crap has to go. Trying to make it fit every platform in one kernel is just too complicated. It _needs_ to be something so damned simple that it always works without fail, every single time someone wants to use it. The current code really hasn't a hope of doing that. Yes, that means you only configure it when you're not building a multi- platform kernel, but that's worth giving up if in return we have something that is 100% reliable. As it is, I need to invent new debugging code to debug this mess. Sorry, I'm actually not going to bother - as the LL debug stuff was my debugging code to debug exactly these kinds of boot problems. Someone else can have the pain of sorting out this breakage, and tell me when they expect OMAP to work again. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
On Thu, Jan 06, 2011 at 05:08:05PM +, Russell King - ARM Linux wrote: > This looks like something's rather broken on OMAP4 too - even with the > DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with > vanilla 2.6.37. So, no OMAP platform I have seems to be usable with > 2.6.37... > > It's worth noting that the kernel which was originally supplied with the > board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have > previous kernels I've built. > > Is there yet an updated uboot for this platform which works with ethernet, > and which has the uboot environment saving implemented? Or are we stuck > with having to catch uboot before it runs the default settings and paste > the commands in each time? Also, if possible please extend the default > timeout - I can only just get from the board to the terminal to stop it > booting the default environment. > > For TI folk: it may be an idea to make X-loader say why it's hanging so > that we know what is going on. And another thing: turning on DEBUG in the decompressor breaks the build on OMAP: `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o `.data' referenced in section `.text' of arch/arm/boot/compressed/head.o: defined in discarded section `.data' of arch/arm/boot/compressed/head.o Is there a reason why this: .pushsection .data omap_uart_phys: .word 0 omap_uart_virt: .word 0 omap_uart_lsr: .word 0 .popsection can't be in the BSS section? With that fixed, and a debug version of the decompressor built, when I load and run this I get the same results - without the debugging output. If I put additional debugging earlier in the decompressor, I don't see it decompressing the kernel at all. Therefore, I believe the debugging address calculation stuff in arch/arm/mach-omap2/include/mach/debug-macros.S to be rather broken, causing an abort when it tries to access the serial port. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 4430SDP boot failure
Russell King - ARM Linux had written, on 01/06/2011 11:08 AM, the following: [..] For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on. [..] 1843088 bytes read OMAP44XX SDP # bootm 8030 ## Booting image at 8030 ... Image Name: Linux-2.6.37+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1843024 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. X-Loader hangs http://gitorious.org/x-loader/x-loader/blobs/master/cpu/omap4/start.S#line40 I think we can improve this to provide rationale if data abort/ other causes for the hang. But in this case, I am not sure it might help - what we need to add is "boot reason" information probably. It does look to me that a reset took place (u-boot hooks up it's own handlers for irq,fiq,abort etc, but they were'nt triggered) - so either kernel abort took place and a wdt trigger caused x-loader to come up in some unexpected configuration that it could'nt handle OR a reset of somesort took place. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
4430SDP boot failure
This looks like something's rather broken on OMAP4 too - even with the DEBUG_LL stuff enabled and my printk hack, I get nothing more, same with vanilla 2.6.37. So, no OMAP platform I have seems to be usable with 2.6.37... It's worth noting that the kernel which was originally supplied with the board works fine (2.6.31-00682-g49ab82a-dirty) with this uboot, as have previous kernels I've built. Is there yet an updated uboot for this platform which works with ethernet, and which has the uboot environment saving implemented? Or are we stuck with having to catch uboot before it runs the default settings and paste the commands in each time? Also, if possible please extend the default timeout - I can only just get from the board to the terminal to stop it booting the default environment. For TI folk: it may be an idea to make X-loader say why it's hanging so that we know what is going on. Texas Instruments X-Loader 1.41 (Apr 19 2010 - 13:31:11) mmc read: Invalid size Starting OS Bootloader from MMC/SD1 ... U-Boot 1.1.4-g9e955085-dirty (Nov 19 2009 - 13:01:21) Load address: 0x80e8 DRAM: 512 MB Flash: 0 kB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 OMAP44XX SDP # setenv bootargs 'root=/dev/mmcblk1p2 rw mem=512M console=ttyO2,115200n8 rootdelay=2' OMAP44XX SDP # mmcinit 0 OMAP44XX SDP # fatload mmc 0 0x8030 uImage-test mmc read: Invalid size 1843088 bytes read OMAP44XX SDP # bootm 8030 ## Booting image at 8030 ... Image Name: Linux-2.6.37+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1843024 Bytes = 1.8 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. X-Loader hangs -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
