All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] configs: am335x_evm: Use default log level
@ 2020-02-26 17:18 Sam Protsenko
  2020-02-28 13:38 ` Lokesh Vutla
  0 siblings, 1 reply; 3+ messages in thread
From: Sam Protsenko @ 2020-02-26 17:18 UTC (permalink / raw)
  To: u-boot

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(-)

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
-- 
2.24.1

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* [PATCH] configs: am335x_evm: Use default log level
  2020-02-26 17:18 [PATCH] configs: am335x_evm: Use default log level Sam Protsenko
@ 2020-02-28 13:38 ` Lokesh Vutla
  2020-02-28 13:45   ` Tom Rini
  0 siblings, 1 reply; 3+ messages in thread
From: Lokesh Vutla @ 2020-02-28 13:38 UTC (permalink / raw)
  To: u-boot



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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH] configs: am335x_evm: Use default log level
  2020-02-28 13:38 ` Lokesh Vutla
@ 2020-02-28 13:45   ` Tom Rini
  0 siblings, 0 replies; 3+ messages in thread
From: Tom Rini @ 2020-02-28 13:45 UTC (permalink / raw)
  To: u-boot

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200228/407c56d0/attachment.sig>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-02-28 13:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 17:18 [PATCH] configs: am335x_evm: Use default log level Sam Protsenko
2020-02-28 13:38 ` Lokesh Vutla
2020-02-28 13:45   ` Tom Rini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.