[RFC v9 2/5] dt-bindings: pstore-block: new support for blkoops
liaoweixiong at allwinnertech.com
Mon Feb 25 14:20:30 UTC 2019
On 2019-02-22 23:36, Rob Herring wrote:
> +boot-architecture list
> On Tue, Feb 19, 2019 at 07:52:47PM +0800, liaoweixiong wrote:
>> Create DT binding document for blkoops.
>> Signed-off-by: liaoweixiong <liaoweixiong at allwinnertech.com>
>> .../devicetree/bindings/pstore/blkoops.txt | 53 ++++++++++++++++++++++
>> MAINTAINERS | 1 +
>> 2 files changed, 54 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pstore/blkoops.txt
>> diff --git a/Documentation/devicetree/bindings/pstore/blkoops.txt b/Documentation/devicetree/bindings/pstore/blkoops.txt
>> new file mode 100644
>> index 0000000..5462915
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pstore/blkoops.txt
>> @@ -0,0 +1,53 @@
>> +Blkoops oops logger
>> +Blkoops provides a block partition for oops, excluding panics now, so they can
>> +be recovered after a reboot.
>> +Any space of block device will be used for a circular buffer of oops records.
>> +These records have a configurable size, with a size of 0 indicating that they
>> +should be disabled.
>> +At least one of "block-device" and "total_size" must be set.
>> +At least one of "dmesg-size" or "pmsg-size" must be set non-zero.
>> +Required properties:
>> +- compatible: must be "blkoops".
>> +Optional properties:
>> +- block-device: The block device to use. Most of the time, it is a partition of
>> + device. If block-device is NULL, no block device is effective
>> + and the data will be lost after rebooting.
>> + It accept the following variants:
>> + 1) <hex_major><hex_minor> device number in hexadecimal
>> + represents itself no leading 0x, for example b302.
>> + 2) /dev/<disk_name> represents the device number of disk
>> + 3) /dev/<disk_name><decimal> represents the device number of
>> + partition - device number of disk plus the partition number
>> + 4) /dev/<disk_name>p<decimal> - same as the above, that form is
>> + used when disk name of partitioned disk ends on a digit.
>> + 5) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing
>> + the unique id of a partition if the partition table provides
>> + it. The UUID may be either an EFI/GPT UUID, or refer to an
>> + MSDOS partition using the format SSSSSSSS-PP, where SSSSSSSS
>> + is a zero-filled hex representation of the 32-bit
>> + "NT disk signature", and PP is a zero-filled hex
>> + representation of the 1-based partition number.
>> + 6) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in
>> + relation to a partition with a known unique id.
>> + 7) <major>:<minor> major and minor number of the device
>> + separated by a colon.
> I didn't suggest to go look at PARTUUID to copy it into the binding, but
> rather to point out that the kernel can already mount by UUID.
> Specifying the UUID in DT is also not what I suggested. My suggestion is
> to define a known UUID so that the kernel (and bootloaders, userspace,
> the world) can just know the UUID. Just like the EFI system partition.
> Now this means you have to get it defined in the UEFI specification
> (or maybe EBBR). If you want help with how to do that, the
> boot-architecture list is a good place to start.
Thanks for your suggestion. I don't know whether it is a good idea to
define a known UUID for pstore/blk in the UEFI specification. This
property is only used for pstore/blk to know which block device it can
use. It only works on linux. I think more thorough and rigorous
consideration is needed.
Besides that, mbr partition table has no partition UUID, how can it to
be compatible with mbr?
> major/minor numbers are a Linux thing, so they don't go in DT.
> /dev/* is Linux thing, so it doesn't go in DT.
> You can always define all these parameters as kernel command line
> options and avoid DT. That would also make this work on *all* systems,
> not just DT based systems. (Though I still believe that the partition
> should be discoverable.)
The pstore/blk has already support command line. It now has 3
configuration methods, they are kconfig, DT and module parameters. I
will cancel DT support on next version until we discuss a viable
approach by this mail and than i will submit other patches to implement
DT. Is this ok?
>  https://github.com/ARM-software/ebbr
More information about the boot-architecture