| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The FS_PSTORE_RAMOOPS_RO configuration option keeps barebox from zapping
(clearing and fixing header ecc) all ramoops buffers on initialization.
It also stops barebox from zapping invalid buffers. This causes issues
when the console writing code tries to use the uninitialized, invalid
console buffer. Therefore, allow barebox to zap invalid buffers, the
kernel will do so anyway if it finds broken buffers during its
initialization.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
Instead of setting ramoops module parameters on the kernel command line,
add a /reserved-memory/ramoops node to the device tree via of_fixup.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Documentation-added-by: Juergen Borleis <jbe@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
| |
The argument list for the pstore_read() interface is unwieldy. This changes
passes the new struct pstore_record instead. The erst backend was already
doing something similar internally.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When ramoops reserved a memory region in the kernel, it had an unhelpful
label of "persistent ram". When reading iomem, it would be repeated many
times, did not hint that it was ramoops in particular, and didn't
clarify very much about what each was used for:
0x4fdd4000 - 0x4fdf3fff (size 0x00020000) persistent ram
0x4fdf4000 - 0x4fe13fff (size 0x00020000) persistent ram
...
0x4ff74000 - 0x4ff93fff (size 0x00020000) persistent ram
0x4ff94000 - 0x4ffb3fff (size 0x00020000) persistent ram
0x4ffb4000 - 0x4ffd3fff (size 0x00020000) persistent ram
Instead, this adds meaningful labels for how the various regions are
being used:
0x4fdd4000 - 0x4fdf3fff (size 0x00020000) ramoops:dump(0/12)
0x4fdf4000 - 0x4fe13fff (size 0x00020000) ramoops:dump(1/12)
...
0x4ff74000 - 0x4ff93fff (size 0x00020000) ramoops:console
0x4ff94000 - 0x4ffb3fff (size 0x00020000) ramoops:ftrace
0x4ffb4000 - 0x4ffd3fff (size 0x00020000) ramoops:pmsg
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
[p.zabel@pengutronix.de: ported to Barebox from Linux commit 1227daa43bce]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
| |
When setting ramoops record sizes, sometimes it's not clear which
parameters contributed to the allocation failure. This adds a per-zone
name and expands the failure reports.
Signed-off-by: Kees Cook <keescook@chromium.org>
[p.zabel@pengutronix.de: ported to Barebox from Linux commit c443a5f3f1f1]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently ramoops_init_przs() is hard wired only for panic dump zone
array. In preparation for the ftrace zone array (one zone per-cpu) and pmsg
zone array, make the function more generic to be able to handle this case.
Heavily based on similar work from Joel Fernandes.
Signed-off-by: Kees Cook <keescook@chromium.org>
[p.zabel@pengutronix.de: ported to Barebox from Linux commit de83209249d6]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of a ramoops-specific node, use a child node of /reserved-memory.
This requires that of_platform_device_create() be explicitly called
for the node, though, since "/reserved-memory" does not have its own
"compatible" property.
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
[p.zabel@pengutronix.de: ported to Barebox from Linux commit 529182e204db]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ramoops is one of the remaining places where ARM vendors still rely on
board-specific shims. Device Tree lets us replace those shims with
generic code.
These bindings mirror the ramoops module parameters, with two small
differences:
(1) dump_oops becomes an optional "no-dump-oops" property, since ramoops
sets dump_oops=1 by default.
(2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
Signed-off-by: Greg Hackmann <ghackmann@google.com>
[fixed platform_get_drvdata() crash, thanks to Brian Norris]
[switched from u64 to u32 to simplify code, various whitespace fixes]
[use dev_of_node() to gain code-elimination for CONFIG_OF=n]
Signed-off-by: Kees Cook <keescook@chromium.org>
[p.zabel@pengutronix.de: ported to Barebox from Linux commit 35da60941e44]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
| |
Switch to a device driver probed from device tree if CONFIG_OFTREE is
enabled. Also switch from postcore_initcall to device_initcall, to make
sure that memory banks have been initialized before request_sdram_region
is called.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Ramoops may be useful even without oftree support, as kernels
booted without a DT may have other means to reserve the
ramoops memory.
Fixes:
In function `ramoops_probe':
undefined reference to `of_add_reserve_entry'
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
| |
|
|
|
|
|
| |
Move spinlock related definitions to its original place.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
|
|
pstore is a persistent storage filesystem used for RAMOOPS. It is used
to store console logs, panics, ftrace and other information in case of a
crash/panic/oops/reboot.
pstore is implemented for barebox as a read-only filesystem at the
moment. It may be extended later on. The idea is to provide a way to
extract essential data from the last running kernel.
Most of the code is copied from the kernel. However this is only a
lightweight implementation without real write support yet.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
|
