RE: Without MACH_ option Early printk (DEBUG_LL)
On Mon, 3 Sep 2012, Mohammed, Afzal wrote: Hi, On Fri, Aug 31, 2012 at 23:53:32, Nicolas Pitre wrote: On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Won't having compile time selection of debug uart over machine based runtime detection help here ? It certainly would. But then your kernel won't run on anything but the specific machine for which the compile time UART selection was made. As soon as you have more than one possible UART config for the set of machines you want your kernel binary to run on, you'll have to give up on the early output during kernel decompression. Nicolas -- 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: Without MACH_ option Early printk (DEBUG_LL)
On Tue, Sep 04, 2012 at 07:34:21, Nicolas Pitre wrote: On Mon, 3 Sep 2012, Mohammed, Afzal wrote: Hi, On Fri, Aug 31, 2012 at 23:53:32, Nicolas Pitre wrote: On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Won't having compile time selection of debug uart over machine based runtime detection help here ? It certainly would. But then your kernel won't run on anything but the specific machine for which the compile time UART selection was made. As soon as you have more than one possible UART config for the set of machines you want your kernel binary to run on, you'll have to give up on the early output during kernel decompression. Yes, I understand that, here at this early stage things are very tricky and difficult to handle. Yeah certainly we can ignore this and give up on early output, but just would like to make sure that we explore all options and drop it. Isn't defining something below should solve the purpose, without breaking anything, am335xevmSOC_AM33XX AM335XEVM 3589 It just says, AM33XX based machines (AM335XEVM, Bone and others) depends on CONFIG_SOC_AM33XX. Does it break anything? May be I am missing something here. Also, I was looking at some other platforms and architectures, some of them are trying to detect the uart port runtime, by checking for, - Which UART is enabled/clocked (most likely by bootloader)? - Does it configured or brought out of reset? This brings-in more complexity at this early stage and not sure we really should go down to this patch, assuming the various flavors of devices and architectures we have currently. Thanks, Vaibhav -- 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: Without MACH_ option Early printk (DEBUG_LL)
Hi, On Fri, Aug 31, 2012 at 23:53:32, Nicolas Pitre wrote: On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Won't having compile time selection of debug uart over machine based runtime detection help here ? Regards Afzal -- 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: Without MACH_ option Early printk (DEBUG_LL)
* Vaibhav Hiremath hvaib...@ti.com [120831 07:55]: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, The way we're heading is that the DEBUG_LL options will only work for one hardcoded machine where you need to select the uart type and address in Kconfig. Or just patch it in. #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below, am335xevmSOC_AM33XX AM335XEVM 3589 OR am335xevmARCH_OMAP2PLUS AM335XEVM 3589 Can you comment on this? Based on that I will submit the patch. I think that would at minimum break things for autogenerated mach-types.h where if only some other non-am335xevm machine is selected (like omap-generic) things don't get optimized out any longer as they currently do. 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120831 07:55]: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, The way we're heading is that the DEBUG_LL options will only work for one hardcoded machine where you need to select the uart type and address in Kconfig. Or just patch it in. #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below, am335xevmSOC_AM33XX AM335XEVM 3589 OR am335xevmARCH_OMAP2PLUS AM335XEVM 3589 Can you comment on this? Based on that I will submit the patch. I think that would at minimum break things for autogenerated mach-types.h where if only some other non-am335xevm machine is selected (like omap-generic) things don't get optimized out any longer as they currently do. Agreed. In that case the first option should work here, right? Thanks, Vaibhav -- 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: Without MACH_ option Early printk (DEBUG_LL)
* Hiremath, Vaibhav hvaib...@ti.com [120831 09:06]: On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120831 07:55]: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, The way we're heading is that the DEBUG_LL options will only work for one hardcoded machine where you need to select the uart type and address in Kconfig. Or just patch it in. #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below, am335xevmSOC_AM33XX AM335XEVM 3589 OR am335xevmARCH_OMAP2PLUS AM335XEVM 3589 Can you comment on this? Based on that I will submit the patch. I think that would at minimum break things for autogenerated mach-types.h where if only some other non-am335xevm machine is selected (like omap-generic) things don't get optimized out any longer as they currently do. Agreed. In that case the first option should work here, right? It gets messy if we start mixing mach and soc defines there.. How about just add a hidden Kconfig option to mach-omap2/Kconfig that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set? Or does that require that MACHINE_START is there as well? 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120831 09:06]: On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120831 07:55]: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, The way we're heading is that the DEBUG_LL options will only work for one hardcoded machine where you need to select the uart type and address in Kconfig. Or just patch it in. #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below, am335xevmSOC_AM33XX AM335XEVM 3589 OR am335xevmARCH_OMAP2PLUS AM335XEVM 3589 Can you comment on this? Based on that I will submit the patch. I think that would at minimum break things for autogenerated mach-types.h where if only some other non-am335xevm machine is selected (like omap-generic) things don't get optimized out any longer as they currently do. Agreed. In that case the first option should work here, right? It gets messy if we start mixing mach and soc defines there.. How about just add a hidden Kconfig option to mach-omap2/Kconfig that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set? Great, this is what I had in my mind but since it is hidden option I thought may not be right thing to do. I was just thinking in the direction that, it should be logical and fine if SOC_AM33XX is used for all AM33xx based machines, isn't it? Anyway, I think we are on same page here, I will add it and submit the patch ASAP. Or does that require that MACHINE_START is there as well? I do not think so, they are not related to each other, this option is required only during decompression. I have tested it on BeagleBone and it is working. Thanks, Vaibhav 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 22:07:37, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120831 09:06]: On Fri, Aug 31, 2012 at 21:22:26, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120831 07:55]: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, The way we're heading is that the DEBUG_LL options will only work for one hardcoded machine where you need to select the uart type and address in Kconfig. Or just patch it in. #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below, am335xevmSOC_AM33XX AM335XEVM 3589 OR am335xevmARCH_OMAP2PLUS AM335XEVM 3589 Can you comment on this? Based on that I will submit the patch. I think that would at minimum break things for autogenerated mach-types.h where if only some other non-am335xevm machine is selected (like omap-generic) things don't get optimized out any longer as they currently do. Agreed. In that case the first option should work here, right? It gets messy if we start mixing mach and soc defines there.. How about just add a hidden Kconfig option to mach-omap2/Kconfig that always selects MACH_TYPE_AM335XEVM if SOC_AM33XX is set? Great, this is what I had in my mind but since it is hidden option I thought may not be right thing to do. I was just thinking in the direction that, it should be logical and fine if SOC_AM33XX is used for all AM33xx based machines, isn't it? Anyway, I think we are on same page here, I will add it and submit the patch ASAP. Or does that require that MACHINE_START is there as well? I do not think so, they are not related to each other, this option is required only during decompression. I have tested it on BeagleBone and it is working. Can you please review below patch? If you think its ok, I will send the patch - diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index fccbdf0..eccafb4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -104,6 +104,9 @@ config SOC_AM33XX select CPU_V7 select ARM_CPU_SUSPEND if PM select MULTI_IRQ_HANDLER + select MACH_AM335XEVM + select MACH_AM335XIAEVM + select MACH_TAM335X config OMAP_PACKAGE_ZAF bool @@ -140,6 +143,15 @@ config MACH_OMAP_GENERIC Support for generic TI OMAP2+ boards using Flattened Device Tree. More information at Documentation/devicetree +config MACH_AM335XEVM + bool + +config MACH_AM335XIAEVM + bool + +config MACH_TAM335X + bool + config MACH_OMAP2_TUSB6010 bool depends on ARCH_OMAP2 SOC_OMAP2420 Thanks, Vaibhav -- 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: Without MACH_ option Early printk (DEBUG_LL)
* Hiremath, Vaibhav hvaib...@ti.com [120831 09:47]: On Fri, Aug 31, 2012 at 21:41:22, Tony Lindgren wrote: Can you please review below patch? If you think its ok, I will send the patch - Yeah thanks looks OK to me, at least I can't think of better options for now. Regards, Tony diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index fccbdf0..eccafb4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -104,6 +104,9 @@ config SOC_AM33XX select CPU_V7 select ARM_CPU_SUSPEND if PM select MULTI_IRQ_HANDLER + select MACH_AM335XEVM + select MACH_AM335XIAEVM + select MACH_TAM335X config OMAP_PACKAGE_ZAF bool @@ -140,6 +143,15 @@ config MACH_OMAP_GENERIC Support for generic TI OMAP2+ boards using Flattened Device Tree. More information at Documentation/devicetree +config MACH_AM335XEVM + bool + +config MACH_AM335XIAEVM + bool + +config MACH_TAM335X + bool + config MACH_OMAP2_TUSB6010 bool depends on ARCH_OMAP2 SOC_OMAP2420 Thanks, Vaibhav -- 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. -- 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Thanks, Vaibhav -- 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: Without MACH_ option Early printk (DEBUG_LL)
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Nicolas -- 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
