| Message ID | 20200226171821.13356-1-joe.skb7@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Lokesh Vutla |
| Headers | show |
| Series | configs: am335x_evm: Use default log level | expand |
On 26/02/20 10:48 PM, Sam Protsenko wrote: > Commit 920e33411113 ("configs: am335x_evm: Reduce size of SPL") reduces > log level from 4 (default) to 3 in order to reduce SPL size. Arguably > the disadvantages of such a decision outweigh the benefits: > > (+) reducing SPL footprint by 1 KiB, but even with loglevel=4 we still > have 2 KiB of SRAM left > (-) we are missing error messages printed with pr_err() in U-Boot > proper > > One can argue that loglevel can be increased locally for debugging > purposes, which is true. But this way users are missing helpful messages > when something goes wrong, which is really confusing. E.g. when trying > to do "dfu tftp" without "dfu_alt_info" variable set, the only message > we can see is: > > exit not allowed from main input shell. > > while whith loglevel=4 user can see what is actually missing: > > "dfu_alt_info" env variable not defined! > > Bottom line: U-Boot proper shouldn't suffer of shortcomings because of > premature optimizations in SPL. > > Let's use default loglevel, as we are not running out of SRAM yet. When > (and if) we run out of SRAM, we'll see the error message during the > build, as RAM size value in SPL linker script will be violated. Then we > can think about reducing loglevel only in SPL (e.g. by separating > CONFIG_SPL_LOGLEVEL option from CONFIG_LOGLEVEL). There is SPL_LOGLEVEL already available, can you use it and disable SPL part for am335x? Thanks and regards, Lokesh
On Fri, Feb 28, 2020 at 07:08:15PM +0530, Lokesh Vutla wrote: > > > On 26/02/20 10:48 PM, Sam Protsenko wrote: > > Commit 920e33411113 ("configs: am335x_evm: Reduce size of SPL") reduces > > log level from 4 (default) to 3 in order to reduce SPL size. Arguably > > the disadvantages of such a decision outweigh the benefits: > > > > (+) reducing SPL footprint by 1 KiB, but even with loglevel=4 we still > > have 2 KiB of SRAM left > > (-) we are missing error messages printed with pr_err() in U-Boot > > proper > > > > One can argue that loglevel can be increased locally for debugging > > purposes, which is true. But this way users are missing helpful messages > > when something goes wrong, which is really confusing. E.g. when trying > > to do "dfu tftp" without "dfu_alt_info" variable set, the only message > > we can see is: > > > > exit not allowed from main input shell. > > > > while whith loglevel=4 user can see what is actually missing: > > > > "dfu_alt_info" env variable not defined! > > > > Bottom line: U-Boot proper shouldn't suffer of shortcomings because of > > premature optimizations in SPL. > > > > Let's use default loglevel, as we are not running out of SRAM yet. When > > (and if) we run out of SRAM, we'll see the error message during the > > build, as RAM size value in SPL linker script will be violated. Then we > > can think about reducing loglevel only in SPL (e.g. by separating > > CONFIG_SPL_LOGLEVEL option from CONFIG_LOGLEVEL). > > There is SPL_LOGLEVEL already available, can you use it and disable SPL part for > am335x? We don't (today) allow different LOGLEVEL values between main, SPL and TPL. I don't object to making them visible but also perhaps the problem is that some messages should be moved up in priority?
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 335aa8cfa1..19fec02b5e 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -8,7 +8,6 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_SPL_LOAD_FIT=y CONFIG_OF_BOARD_SETUP=y CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run envboot; run distro_bootcmd" -CONFIG_LOGLEVEL=3 CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_VERSION_VARIABLE=y CONFIG_ARCH_MISC_INIT=y
Commit 920e33411113 ("configs: am335x_evm: Reduce size of SPL") reduces log level from 4 (default) to 3 in order to reduce SPL size. Arguably the disadvantages of such a decision outweigh the benefits: (+) reducing SPL footprint by 1 KiB, but even with loglevel=4 we still have 2 KiB of SRAM left (-) we are missing error messages printed with pr_err() in U-Boot proper One can argue that loglevel can be increased locally for debugging purposes, which is true. But this way users are missing helpful messages when something goes wrong, which is really confusing. E.g. when trying to do "dfu tftp" without "dfu_alt_info" variable set, the only message we can see is: exit not allowed from main input shell. while whith loglevel=4 user can see what is actually missing: "dfu_alt_info" env variable not defined! Bottom line: U-Boot proper shouldn't suffer of shortcomings because of premature optimizations in SPL. Let's use default loglevel, as we are not running out of SRAM yet. When (and if) we run out of SRAM, we'll see the error message during the build, as RAM size value in SPL linker script will be violated. Then we can think about reducing loglevel only in SPL (e.g. by separating CONFIG_SPL_LOGLEVEL option from CONFIG_LOGLEVEL). Fixes: 920e33411113 ("configs: am335x_evm: Reduce size of SPL") Signed-off-by: Sam Protsenko <joe.skb7@gmail.com> --- configs/am335x_evm_defconfig | 1 - 1 file changed, 1 deletion(-)