From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] mtd, ubi: errormessage handling
Date: Fri, 31 Oct 2014 11:03:38 +0100 [thread overview]
Message-ID: <54535E7A.7030703@denx.de> (raw)
Hello all,
as I just debugged a problem with ubi on cfi flashes [1], the question
raised, if it would be a good idea to enable ubi error messages
by default? I think, if we enable them by default, the error
Andrew had, would be visible immediately:
with ubi errormessages [3]:
=> ubi part misc
UBI error: ubi_attach_mtd_dev: More than 64 PEBs are needed for fastmap, sorry.
UBI: default fastmap pool size: 8
UBI: default fastmap WL pool size: 25
UBI: attaching mtd1 to ubi0
UBI error: io_init: bad write buffer size 0 for 1 min. I/O unit
UBI error: ubi_init: cannot attach mtd1
=>
without ubi errormessages:
=> ubi part misc
UBI: default fastmap pool size: 8
UBI: default fastmap WL pool size: 25
UBI: attaching mtd1 to ubi0
=>
The big con is the space needed for it. I tested on the tqm5200s board
(current mainline).
without pr_err() enabled in "include/linux/mtd/mtd.h"
$ ls -al u-boot.bin
-rwxrwxr-x 1 hs hs 469264 31. Okt 10:21 u-boot.bin
with pr_err() enabled:
$ ls -al u-boot.bin
-rwxrwxr-x 1 hs hs 525584 31. Okt 10:23 u-boot.bin
-> 55k more space needed!!
So there are 2 questions:
a) Do we want to make "pr_err()" configurable seperately?
(I vote for yes, proposal CONFIG_UBI_PRINT_ERRORS)
b) how would/should be the default setting?
(I vote for disabled)
bye,
Heiko
[1] ubi regression
http://lists.denx.de/pipermail/u-boot/2014-October/193098.html
[2] bugfix
Patchwork [U-Boot] mtd, cfi, ubi: add missing writebufsize initialization
http://patchwork.ozlabs.org/patch/405245/
[3] enabled ubi error messages patch
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 8666413..156016f 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -458,8 +458,8 @@ static inline void mtd_erase_callback(struct erase_info *instr)
#endif /* CONFIG_MTD_DEBUG */
#define pr_info(args...) MTDDEBUG(MTD_DEBUG_LEVEL0, args)
#define pr_warn(args...) MTDDEBUG(MTD_DEBUG_LEVEL0, args)
-#define pr_err(args...) MTDDEBUG(MTD_DEBUG_LEVEL0, args)
-#define pr_crit(args...) MTDDEBUG(MTD_DEBUG_LEVEL0, args)
+#define pr_err(args...) printk(KERN_INFO args)
+#define pr_crit(args...) printk(KERN_INFO args)
#define pr_cont(args...) MTDDEBUG(MTD_DEBUG_LEVEL0, args)
#define pr_notice(args...) MTDDEBUG(MTD_DEBUG_LEVEL0, args)
#endif
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
reply other threads:[~2014-10-31 10:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54535E7A.7030703@denx.de \
--to=hs@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox