[OpenWrt-Devel] Current "OpenWrt Style Guide for DTS"?
Chuanhong Guo
gch981213 at gmail.com
Tue Jan 22 22:08:43 EST 2019
Hi!
I picked several things I could answer below :)
On Wed, Jan 23, 2019 at 6:07 AM Jeff Kletsky <lede at allycomm.com> wrote:
...
>
> Choice of Node Naming for Partitions
> ====================================
>
> In some DTS files, the partitions are named using sequential integers.
> In others, the offset of the partition is used.
>
> * Which of the two is preferred?
>
> uboot: u-boot at 0 {
> firmware at 20000 {
> art: art at ff0000 {
>
> vs.
>
> partition at 0 {
> partition at 1 {
> partition at 2 {
> art: partition at 3 {
Neither. It's partition@<start address>:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6dd94c2781b79ffd20f1a57a48fa2314d67ee190
>
...
> TAB vs. SPACE Indentation
> =========================
>
> * It appears that TAB indentation is being used. Is this correct?
Yes.
>
> read-only Partitions
> ====================
>
> * Is it appropriate to mark the boot-loader partition as read-only?
>
> * What about the art partition?
>
> Doing so would seem to be able help prevent users following outdated
> or ill-advised suggestions to write to their file systems using
> low-level access.
Correct. Both of those partitions aren't supposed to be written normally.
>
> Advanced users that, for some reason, want to overwrite these critical
> partitions could always compile their own kernel with the restriction
> removed.
Yes. They are always able to make their custom firmware for this purpose.
>
>
>
> ---
> Context for the following questions is discussed below the "8<" marker
> TL;DR Stable references to partitions for DT modification when "inheriting"
> ---
>
> Partition "label" Properties
> ============================
>
> Some of the "label" properties seem obviously named, like "firmware"
> and "art" and I assume that the kernel and drivers key off of these.
>
> * Is there a list of "reserved" and/or "preferred" values for the
> label property of the partitions?
OpenWrt kernel will try to automatically split "firmware“ into
kernel/rootfs, and it'll auto-attach "ubi" partition as a ubi device.
Besides these two the other names doesn't have any strict
requirements. People usually follow what the manufacturer defined in
their stock firmware.
"art" stands for "Atheros Radio Test" and it's widely used for
calibration data on QCA routers by the manufacturers. There are some
devices using other names for calibration data partition.
We tell the driver where to load calibration data in dts or load it
for drivers using firmware hotplug scripts.
>
>
>
> Labels for Partition Nodes
> ==========================
>
> I've noticed that there are some common labels for partition nodes in
> use. A quick check of the ath79 platform shows
>
> addr, art, ART, caldata, eeprom, firmware, info, mac, mtdparts,
> nvram, partitions, uboot, ubootenv
>
> * Is there a list of any of these that are "reserved" by general DTS
> files under OpenWrt?
As I said above, "firmware" and "ubi" are reserved for special purposes.
Other labels are usually just copied from manufacturers' firmware.
>
> At least as I understand DTS definition, these labels are not passed
> to the kernel, but only during compilation.
No. These labels will be saved in the compiled dtb files and can be
used by drivers.
e.g. mtd partition node labels will be used as mtd partition name.
>
> * Assuming this is the case, is there any guidance for adding
> "commonly used" labels or "device-specific" labels?
>
>
> 8<
>
> The questions above around the "label" property and labels arise
> mainly because I'm working with devices that have both NOR and NAND
> flash. With the goal of easier maintainability and potential utility,
> I'd like to define the partitioning *once* for a physical device and,
> if needed, modify it for the NOR and NAND instances.
>
> These devices that I'm working with can, once the boot loader is
> running off NOR, boot either from NOR or from NAND (with fall-back if
> the preferred one fails). Flashing both variants simultaneously has
> benefits, but how to accomplish that may need to be the subject of
> another thread.
>
> At least as I (weakly) understand the use of
>
> label = "firmware"
> compatible = "denx,uimage"
>
> from https://openwrt.org/docs/guide-developer/defining-firmware-partitions
> there is some magic in the boot loader to know that the kernel is in the
> "firmware" partition and that the kernel, once running, can split the
> firmware partition into kernel and filesystem partitions, on the
> fly.
Incorrect. They are used by the kernel to properly split firmware
partition into kernel/rootfs.
OpenWrt dynamically determine the sizes of these two partitions to
avoid space wasted in a fixed kernel partition.
This compatible string was introduced upstream and OpenWrt folks wants
to use it to get rid of the current hack for firmware partition.
Currently OpenWrt patched the mtd framework so that when registering a
partition named 'firmware' it tries to apply every available mtdsplit
drivers on it until one successfully split firmware into
kernel/rootfs.
> This would suggest to me that "it would be bad" to have two
> partitions with the "firmware" label
You can't register two partitions with the same label. mtd partition
names are unique and registering two partition with the same name will
fail.
> and likely with the
> "denx,uimage" compatible (or whatever the boot loader and kernel are
> expecting for that device).
Same as above. By doing so you'll try to register two kernel and two
rootfs partition.
>
> This line of thinking suggests to me that if one or both flash storage
> partitions are defined in a common place, "the other" flash storage
> needs to be "de-fanged" at least as a start.
>
> Ideally, I'd like to be able to define the NOR partitioning in a
> common .dsti for the device, then modify it for the NAND variant,
> along the lines of:
>
> partition at 0 {
> label = "u-boot";
> reg = <0x000000 0x040000>;
> read-only;
> };
>
> partition at 40000 {
> label = "u-boot-env";
> reg = <0x040000 0x010000>;
> };
>
> art: partition at 50000 {
> label = "art";
> reg = <0x050000 0x010000>;
> read-only;
> };
>
> firmware_nor: partition at 60000 {
> compatible = "denx,uimage";
> label = "firmware";
> reg = <0x060000 0xfa0000>;
> };
>
> then, for the NAND variant
>
> &firmware_nor {
> /delete-property/ compatible;
> label = "firmware-nor";
> };
I think you could define 'compatible' and 'label' in dts files instead
of defining them in dtsi and overriding them in dts.
Overriding do make the dts shorter but it sometime makes the dtsi confusing.
>
>
> I haven't determined if/how the filesystem within the firmware-nor
> partion could be accessed by a NAND-booted kernel or vice-versa. Yet.
It's currently impossible since you can't do a mtdsplit for the
firmware partition in the other flash.
>
> My preference would be that both the NOR and NAND partitioning would be
> defined *once* in the common .dtsi, with minimal overrides in the
> variant .dts files.
>
>
> * Comments and suggestions on this approach to managing devices with
> both NOR and NAND firmware variants will be greatly appreciated.
>
>
> Jeff
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list