[U-Boot] [PATCH] arm: omap5_uevm: Correct the console sys prompt for 5432
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by: Dan Murphy dmurphy@ti.com Reported-by: Lubomir Popov lpopov@mm-sol.com --- include/configs/omap5_uevm.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index 9e0339b..a333c79 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -54,7 +54,7 @@ #define CONFIG_PARTITION_UUIDS #define CONFIG_CMD_PART
-#define CONFIG_SYS_PROMPT "OMAP5430 EVM # " +#define CONFIG_SYS_PROMPT "OMAP5432 uEVM # "
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296 #endif /* __CONFIG_OMAP5_EVM_H */
On Thu, Jun 06, 2013 at 04:30:38PM -0500, Dan Murphy wrote:
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by: Dan Murphy dmurphy@ti.com Reported-by: Lubomir Popov lpopov@mm-sol.com
Reviewed-by: Tom Rini trini@ti.com
But personally, this is why I'm a fan of 'U-Boot # ' as the prompt :)
Hi Tom,
On Tue, 11 Jun 2013 11:53:42 -0400, Tom Rini trini@ti.com wrote:
On Thu, Jun 06, 2013 at 04:30:38PM -0500, Dan Murphy wrote:
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by: Dan Murphy dmurphy@ti.com Reported-by: Lubomir Popov lpopov@mm-sol.com
Reviewed-by: Tom Rini trini@ti.com
But personally, this is why I'm a fan of 'U-Boot # ' as the prompt :)
I'd like it too if we could simply have all boards using the same prompt, but there might be some scripts out there which rely on the prompt being something else than "U-Boot # ' or worse yet, using the prompt to determine which variant of the HW the scripts are dealing with.
Amicalement,
On Sat, Jun 22, 2013 at 11:33:11AM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Tue, 11 Jun 2013 11:53:42 -0400, Tom Rini trini@ti.com wrote:
On Thu, Jun 06, 2013 at 04:30:38PM -0500, Dan Murphy wrote:
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by: Dan Murphy dmurphy@ti.com Reported-by: Lubomir Popov lpopov@mm-sol.com
Reviewed-by: Tom Rini trini@ti.com
But personally, this is why I'm a fan of 'U-Boot # ' as the prompt :)
I'd like it too if we could simply have all boards using the same prompt, but there might be some scripts out there which rely on the prompt being something else than "U-Boot # ' or worse yet, using the prompt to determine which variant of the HW the scripts are dealing with.
True. Looking ahead however, given device trees and the need to know what tree to request/load, I hope more boards will go with enabling CONFIG_ENV_VARS_UBOOT_CONFIG and can then use cpu/board/board_name as needed to determine those things at run-time.
Hi Tom,
On Mon, 24 Jun 2013 16:30:54 -0400, Tom Rini trini@ti.com wrote:
On Sat, Jun 22, 2013 at 11:33:11AM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Tue, 11 Jun 2013 11:53:42 -0400, Tom Rini trini@ti.com wrote:
On Thu, Jun 06, 2013 at 04:30:38PM -0500, Dan Murphy wrote:
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by: Dan Murphy dmurphy@ti.com Reported-by: Lubomir Popov lpopov@mm-sol.com
Reviewed-by: Tom Rini trini@ti.com
But personally, this is why I'm a fan of 'U-Boot # ' as the prompt :)
I'd like it too if we could simply have all boards using the same prompt, but there might be some scripts out there which rely on the prompt being something else than "U-Boot # ' or worse yet, using the prompt to determine which variant of the HW the scripts are dealing with.
True. Looking ahead however, given device trees and the need to know what tree to request/load, I hope more boards will go with enabling CONFIG_ENV_VARS_UBOOT_CONFIG and can then use cpu/board/board_name as needed to determine those things at run-time.
How about announcing (as in, "letting the whole world know by slipping it in our public announcement of 2013.07") that custom prompts will be deprecated starting with 2013.10 and that targets still having them by 2014.01 will be retired?
That's what we did for ARM ELF relocation IIRC.
Of course, that would require a few round of e-mails to maintainers, at least to those whose targets' config header files still have custom prompts when reaching 2014.01-rc1; and there will be some yelling that such or such board has been dropped from U-Boot and why were users not told, etc.
Alternatively, we could announce and deprecate in 2013.10 and remove all custom prompts in 2013.14 ourselves, then wait for annoyed people to yell at us, and advise them to enable CONFIG_ENV_VARS_UBOOT_CONFIG and uptate their scripts. Less prep work, slightly more yelling.
We could even shift the schedule, deprecate for 2013.07 and remove in 2013.10. Same amount of work, yelling goes away earlier.
My vote goes to this last proposal. :)
Amicalement,
On Thu, Jun 27, 2013 at 09:00:59AM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Mon, 24 Jun 2013 16:30:54 -0400, Tom Rini trini@ti.com wrote:
[snip]
True. Looking ahead however, given device trees and the need to know what tree to request/load, I hope more boards will go with enabling CONFIG_ENV_VARS_UBOOT_CONFIG and can then use cpu/board/board_name as needed to determine those things at run-time.
How about announcing (as in, "letting the whole world know by slipping it in our public announcement of 2013.07") that custom prompts will be deprecated starting with 2013.10 and that targets still having them by 2014.01 will be retired?
That's what we did for ARM ELF relocation IIRC.
Of course, that would require a few round of e-mails to maintainers, at least to those whose targets' config header files still have custom prompts when reaching 2014.01-rc1; and there will be some yelling that such or such board has been dropped from U-Boot and why were users not told, etc.
Alternatively, we could announce and deprecate in 2013.10 and remove all custom prompts in 2013.14 ourselves, then wait for annoyed people to yell at us, and advise them to enable CONFIG_ENV_VARS_UBOOT_CONFIG and uptate their scripts. Less prep work, slightly more yelling.
We could even shift the schedule, deprecate for 2013.07 and remove in 2013.10. Same amount of work, yelling goes away earlier.
My vote goes to this last proposal. :)
With the self-inflicted bootm/FIT problems, I set this email aside for a bit longer than I had wanted. My plan, right now, is to just start with letting the wider world know, in the releae email, that hey, we have more reliable methods of determing what board you are on, at run time. And seeing where things go from there.
participants (3)
-
Albert ARIBAUD -
Dan Murphy -
Tom Rini