Skip to contentSkip to conversation

Without MACH_ option Early printk (DEBUG_LL)

DISCUSSION Vaibhav Hiremath 5 participants 13 messages Aug 31, 2012 – Sep 4, 2012

Subsystems (3)
Arm (32-bit) Arm sub-architectures OMAP2+ support
lore
Share & tools
lore

Vaibhav Hiremath

author
#0 lore raw

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

So I am thinking of changing the config_xxx option to SOC_AM33XX or ARCH_OMAP2PLUS, something like below,

am335xevm SOC_AM33XX AM335XEVM 3589

OR

am335xevm ARCH_OMAP2PLUS AM335XEVM 3589

Can you comment on this? Based on that I will submit the patch.

Thanks,
Vaibhav

maintainer
#1 lore raw
Quoted 10 lines · Vaibhav Hiremath

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.

Quoted 16 lines

#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,

Quoted 8 lines

am335xevm SOC_AM33XX AM335XEVM 3589

OR

am335xevm ARCH_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

author
#2 lore raw
Quoted 39 lines · Tony Lindgren
Quoted 10 lines · Vaibhav Hiremath

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.

Quoted 23 lines

#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,

am335xevm SOC_AM33XX AM335XEVM 3589

OR

am335xevm ARCH_OMAP2PLUS AM335XEVM 3589

Quoted 7 lines
Quoted 1 line

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

maintainer
#3 lore raw
Quoted 42 lines · Hiremath, Vaibhav
Quoted 41 lines · Tony Lindgren
Quoted 10 lines · Vaibhav Hiremath

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.

Quoted 24 lines

#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,

am335xevm SOC_AM33XX AM335XEVM 3589

OR

am335xevm ARCH_OMAP2PLUS AM335XEVM 3589

Can you comment on this? Based on that I will submit the patch.

Quoted 7 lines
Quoted 5 lines

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

author
#4 lore raw
Quoted 49 lines · Tony Lindgren
Quoted 48 lines · Hiremath, Vaibhav
Quoted 46 lines · Tony Lindgren
Quoted 10 lines · Vaibhav Hiremath

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.

Quoted 16 lines

#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,

Quoted 8 lines

am335xevm SOC_AM33XX AM335XEVM 3589

OR

am335xevm ARCH_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.

Quoted 6 lines
Quoted 1 line

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.

Quoted 2 lines

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

Quoted 4 lines

Regards,

Tony

author
#5 lore raw
In reply to Tony Lindgren
Quoted 65 lines · Vaibhav
Quoted 49 lines · Tony Lindgren
Quoted 48 lines · Hiremath, Vaibhav
Quoted 46 lines · Tony Lindgren
Quoted 10 lines · Vaibhav Hiremath

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.

Quoted 16 lines

#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,

Quoted 8 lines

am335xevm SOC_AM33XX AM335XEVM 3589

OR

am335xevm ARCH_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.

Quoted 6 lines
Quoted 1 line

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.

Quoted 7 lines
Quoted 2 lines

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 -

arch/arm/mach-omap2/Kconfig +12 -0
index fccbdf0..eccafb4 100644
@@ -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

maintainer
#6 lore raw
Quoted 4 lines · Hiremath, Vaibhav
Quoted 1 line · Tony Lindgren

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

Quoted 33 lines
arch/arm/mach-omap2/Kconfig +12 -0
index fccbdf0..eccafb4 100644
@@ -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

#7 lore raw
In reply to Vaibhav Hiremath
Quoted 12 lines · Vaibhav Hiremath

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

Quoted 10 lines
# 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.

Quoted 1 line

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.

author
#8 lore raw
Quoted 24 lines · Russell King - ARM Linux
Quoted 12 lines · Vaibhav Hiremath

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

Quoted 10 lines
# 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
Quoted 6 lines

machine types are entirely meaningless for DT based systems.

Quoted 1 line

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

#9 lore raw
Quoted 27 lines · Vaibhav
Quoted 26 lines · Russell King - ARM Linux
Quoted 12 lines · Vaibhav Hiremath

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

Quoted 10 lines
# 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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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

#10 lore raw

Hi,

Quoted 16 lines · Nicolas Pitre
Quoted 15 lines · Vaibhav
Quoted 14 lines · Russell King - ARM Linux
Quoted 8 lines · Vaibhav Hiremath

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.

Quoted 1 line

Can you comment on this? Based on that I will submit the patch.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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

#11 lore raw
Quoted 22 lines · Afzal

Hi,

Quoted 19 lines · Nicolas Pitre
Quoted 18 lines · Vaibhav
Quoted 16 lines · Russell King - ARM Linux
Quoted 8 lines · Vaibhav Hiremath

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.

Quoted 1 line

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.

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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

author
#12 lore raw
Quoted 30 lines · Nicolas Pitre
Quoted 28 lines · Afzal

Hi,

Quoted 24 lines · Nicolas Pitre
Quoted 13 lines · Vaibhav
Quoted 12 lines · Russell King - ARM Linux
Quoted 8 lines · Vaibhav Hiremath

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.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

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.

Quoted 10 lines
Quoted 2 lines

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,

am335xevm SOC_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