Hello Wolfgang, Heinrich,
Am 20.03.2020 um 09:08 schrieb Wolfgang Denk:
Dear Heinrich,
In message <a1b7a877-e950-b09a-a0f6-2c9c9cb7e...@gmx.de> you wrote:
To me this sounds very much like what you are adding here (plus a
few features more). Does it make sense to unify such code?
It seems you are relating to
https://lore.kernel.org/lkml/844oyrqvvb....@sauna.l.org/t/
No, I'm not. I was talking of my own code from many, many years
ago.
ramoops in Linux is exactly doing what was suggested in 2009. You can
find the Documentation/admin-guide/ramoops.rst
We had this in U-Boot long before that time. It was a key
requirement when we added POST support in 2002.
git grep -GHrn 'shared log' finds nothing in U-Boot. So if any part of
the old implementation in U-Boot exists, could you, please, point us to
the coding.
The shared log buffer support was added by commit 56f94be3ef63:
commit 56f94be3ef63732384063e110277ed89701b6471 (tag: LABEL_2002_11_05_1735)
Author: Wolfgang Denk <wdenk>
Date: Tue Nov 5 16:35:14 2002 +0000
* Add support for log buffer which can be passed to Linux kernel's
syslog mechanism; used especially for POST results.
* Patch by Klaus Heydeck, 31 Oct 2002:
Add initial support for kup4k board
The code was mainly in common/cmd_log.c, but this got heahily
rewritten and is now in cmd/log.c ; apparently this got lost (like
the original copyright, sic!) when Simon modified / rewrote this
driver.
For history, try: git log --follow -- common/cmd_log.c
If the original design never made it into Linux and there is an
established Linux interface since 2011, I would plead to eliminate any
remaining non-compliant coding from U-Boot should it exist.
I understand what Linus has is one-way, only focussing on crash
dump, i. e. it does not allow to pass information from U-Boot to Linux?
Also, my understanding is that the changes needed in Linux are
pretty small.
Maybe Heiko can comment on that...
Since 2002 the logbuffer support in linux changed, so the old
patch does not work anymore.
First there is now the struct "printk_log" [1]
Unfortunately the size of it is dependend on linux configuration.
Each log entry is prepended from such a struct, just missing
the possibility to detect if entry is valid (as linux was the only
user of it, this was not needed).
There is already a possibilty to set a log buffer length through
kernel commandline parameter "log_buf_len" [2].
If this is passed, kernel already uses a new area (currently
memblock_alloced) for log buffer storage!
So added now the following to linux logbuffer handling:
Pass the persistent logbuffer address and length through a
kernel commandline parameter and use it instead memblock_alloc()
Add a magic field in [1] which I use to detect if there are valid
entries and where is the end of logbuffer entries in the new logbuffer
area (Not that easy as there was may a wrap around, but also this is
detectable)
-> start and end in the new log area is now known.
Now copy the new logbuffer messages from __log_buf with the
already existing functions in linux kernel to the end of the
new logbuffer area ... and you have old linux bootlogs and
the new ones after a reboot.
aditionally changes in U-Boot:
- enable PRAM to reserve RAM at the end of RAM for logbuffer
so U-Boot does not use this memory space. Already in U-Boot.
- add common/log_buffer.c log backend, which uses the functions
from kernel for analysing/writing content of the logbuffer area.
"log rec" U-Boot command appends now also U-Boot log messages to
the logbuffer area.
- add "log show" command, with which you can show current content
of logbuffer area
And now U-Boot log messages also shown in linux bootlog ...
bye
Heiko
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c#n368
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/printk/printk.c#n1114
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
