arm: omap5_uevm: Correct the console sys prompt for 5432
PATCH 1/1 arm: omap5_uevm: Correct the console sys prompt for 5432
Correct the console sys prompt to display the correct processor and the corrent board
--- include/configs/omap5_uevm.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
include/configs/omap5_uevm.h +1 -1
@@ -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 */
Signature · 1 line
1.7.5.4
PATCH 1/1 arm: omap5_uevm: Correct the console sys prompt for 5432
Quoted 5 lines · Dan Murphy
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by Dan Murphy <[email protected]>Reported-by Lubomir Popov <[email protected]>
But personally, this is why I'm a fan of 'U-Boot # ' as the prompt :)
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130611/26706fda/attachment.pgp>
PATCH 1/1 arm: omap5_uevm: Correct the console sys prompt for 5432
Hi Tom,
Quoted 11 lines · Tom Rini
Quoted 5 lines · Dan Murphy
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by Dan Murphy <[email protected]>Reported-by Lubomir Popov <[email protected]>Reviewed-by Tom Rini <[email protected]>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,
Signature · 1 line
Albert.
PATCH 1/1 arm: omap5_uevm: Correct the console sys prompt for 5432
Quoted 14 lines · Albert ARIBAUD
Hi Tom,
Quoted 10 lines · Tom Rini
Quoted 5 lines · Dan Murphy
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by Dan Murphy <[email protected]>Reported-by Lubomir Popov <[email protected]>Reviewed-by Tom Rini <[email protected]>
Quoted 7 lines
Quoted 1 line
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.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130624/0f247fb9/attachment.pgp>
PATCH 1/1 arm: omap5_uevm: Correct the console sys prompt for 5432
Hi Tom,
Quoted 23 lines · Tom Rini
Quoted 14 lines · Albert ARIBAUD
Hi Tom,
Quoted 10 lines · Tom Rini
Quoted 5 lines · Dan Murphy
Correct the console sys prompt to display the correct processor and the corrent board
Signed-off-by Dan Murphy <[email protected]>Reported-by Lubomir Popov <[email protected]>Reviewed-by Tom Rini <[email protected]>Quoted 7 lines
Quoted 1 line
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.
Quoted 4 lines
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_CONFIGand 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,
Signature · 1 line
Albert.
PATCH 1/1 arm: omap5_uevm: Correct the console sys prompt for 5432
Quoted 3 lines · Albert ARIBAUD
Hi Tom,
On Mon, 24 Jun 2013 16:30:54 -0400, Tom Rini <[email protected]> wrote:
[snip]
Quoted 23 lines
Quoted 4 lines
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_CONFIGand 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_CONFIGand uptate their scripts. Less prep work, slightly more yelling.
Quoted 4 lines
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.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130715/b569cfce/attachment.pgp>