| Message ID | 1375224558-8170-1-git-send-email-swarren@wwwdotorg.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: > From: Stephen Warren <swarren@nvidia.com> > > DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to > omap2plus.S's use of .data, which is not allowed in the decompressor. > Solve this by placing that data into .text when building the file into > the decompressor. This relies on .text actually being writable in the > decompressor, which it is in practice. Unless you decide to use ZBOOT and flash the zImage.
On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote: > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: >> From: Stephen Warren <swarren@nvidia.com> >> >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to >> omap2plus.S's use of .data, which is not allowed in the decompressor. >> Solve this by placing that data into .text when building the file into >> the decompressor. This relies on .text actually being writable in the >> decompressor, which it is in practice. > > Unless you decide to use ZBOOT and flash the zImage. I knew there had to be a catch:-) I have no idea if ZBOOT is a use-case that's relevant to OMAP? On Tegra at least (the same issue applies to the other patch I just sent), that use-case is almost impossible; even if the boot ROM directly booted a kernel, the boot ROM is hard-coded to copy whatever it's booting to SDRAM first, although I suppose if that was a boot-loader it could just jump back to a ROM location. That said, NOR flash is extremely rare on Tegra. So, I don't know if we care about this issue. Is it reasonable to just say "If you use ZBOOT, don't enable DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say: default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)?
* Stephen Warren <swarren@wwwdotorg.org> [130730 16:08]: > On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote: > > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: > >> From: Stephen Warren <swarren@nvidia.com> > >> > >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to > >> omap2plus.S's use of .data, which is not allowed in the decompressor. > >> Solve this by placing that data into .text when building the file into > >> the decompressor. This relies on .text actually being writable in the > >> decompressor, which it is in practice. > > > > Unless you decide to use ZBOOT and flash the zImage. > > I knew there had to be a catch:-) > > I have no idea if ZBOOT is a use-case that's relevant to OMAP? > > On Tegra at least (the same issue applies to the other patch I just > sent), that use-case is almost impossible; even if the boot ROM directly > booted a kernel, the boot ROM is hard-coded to copy whatever it's > booting to SDRAM first, although I suppose if that was a boot-loader it > could just jump back to a ROM location. That said, NOR flash is > extremely rare on Tegra. So, I don't know if we care about this issue. > > Is it reasonable to just say "If you use ZBOOT, don't enable > DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove > the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say: > > default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)? I think we're best off removing the remaining uncompress code configured port detection features as the port properties are now defined in kconfig anyways. That simplifies the code quite a bit. Regards, Tony
On 07/31/2013 12:46 AM, Tony Lindgren wrote: > * Stephen Warren <swarren@wwwdotorg.org> [130730 16:08]: >> On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote: >>> On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: >>>> From: Stephen Warren <swarren@nvidia.com> >>>> >>>> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to >>>> omap2plus.S's use of .data, which is not allowed in the decompressor. >>>> Solve this by placing that data into .text when building the file into >>>> the decompressor. This relies on .text actually being writable in the >>>> decompressor, which it is in practice. >>> >>> Unless you decide to use ZBOOT and flash the zImage. >> >> I knew there had to be a catch:-) >> >> I have no idea if ZBOOT is a use-case that's relevant to OMAP? >> >> On Tegra at least (the same issue applies to the other patch I just >> sent), that use-case is almost impossible; even if the boot ROM directly >> booted a kernel, the boot ROM is hard-coded to copy whatever it's >> booting to SDRAM first, although I suppose if that was a boot-loader it >> could just jump back to a ROM location. That said, NOR flash is >> extremely rare on Tegra. So, I don't know if we care about this issue. >> >> Is it reasonable to just say "If you use ZBOOT, don't enable >> DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove >> the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say: >> >> default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)? > > I think we're best off removing the remaining uncompress code > configured port detection features as the port properties are now > defined in kconfig anyways. That simplifies the code quite a bit. If you want to do that with OMAP, I'm happy to drop this patch. For Tegra, automatic determination of the DEBUG_LL UART is rather useful, so I'm not going to give that up:-)
* Stephen Warren <swarren@wwwdotorg.org> [130731 10:04]: > On 07/31/2013 12:46 AM, Tony Lindgren wrote: > > > > I think we're best off removing the remaining uncompress code > > configured port detection features as the port properties are now > > defined in kconfig anyways. That simplifies the code quite a bit. > > If you want to do that with OMAP, I'm happy to drop this patch. Yes on my list of things to do.. > For Tegra, automatic determination of the DEBUG_LL UART is rather > useful, so I'm not going to give that up:-) For omaps there's just too many options to try to detect anything. It seems the best strategy seems to be to just init things later on so DEBUG_LL is only needed when booting breaks really early on during the boot process. Regards, Tony
On Fri, Aug 02, 2013 at 12:29:25AM -0700, Tony Lindgren wrote: > It seems the best strategy seems to be to just init things later on > so DEBUG_LL is only needed when booting breaks really early on > during the boot process. ... which is exactly the whole point and use case of DEBUG_LL. :)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index d8ff7f7..8eb04b1 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1046,7 +1046,7 @@ config DEBUG_UART_8250_FLOW_CONTROL config DEBUG_UNCOMPRESS bool depends on ARCH_MULTIPLATFORM - default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART + default y if DEBUG_LL help This option influences the normal decompressor output for multiplatform kernels. Normally, multiplatform kernels disable diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..364ae35 100644 --- a/arch/arm/include/debug/omap2plus.S +++ b/arch/arm/include/debug/omap2plus.S @@ -58,11 +58,15 @@ #define UART_OFFSET(addr) ((addr) & 0x00ffffff) +#if !defined(ZIMAGE) .pushsection .data +#endif omap_uart_phys: .word 0 omap_uart_virt: .word 0 omap_uart_lsr: .word 0 +#if !defined(ZIMAGE) .popsection +#endif .macro addruart, rp, rv, tmp