[PATCH] pstore: Use root address-cells/size-cells as defaults for reserved-memory

Andre Przywara andre.przywara at arm.com
Sat Aug 26 20:41:27 CEST 2023


On Sat, 26 Aug 2023 15:10:10 +0200
Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:

Hi,

> On 8/26/23 14:16, Andrey Skvortsov wrote:
> > u-boot adds reserve-memory node, if it's missing, with following
> > properties:
> >
> > ```
> >      reserved-memory {
> >           #address-cells = <2>;
> >           #size-cells = <2>;  
> 
> This defines the size of cells for the children of reserved-memory and
> and for the ranges property. If you set the cell sizes to 1 you can no
> longer encode 64 bit addresses.

Yes, this is expected in this case, the Allwinner A64 SoC has its memory
map (including DRAM) completely below 4GB, hence the root node can go
with 1/1.

> 
> >           ranges;
> >      }
> > ```
> >
> > But with these default address-cells and size-cells values, pstore
> > isn't working on A64. Root node for A64 defines 'address-cells' and
> > 'size-cells' as 1.
> >
> > dtc complains if reserved-memory has different address-cells and
> > size-cells.
> >
> > ```
> >       Warning (ranges_format): /reserved-memory:ranges: empty "ranges"
> >       property but its #address-cells (2) differs from / (1)  
> 
> I cannot find any such requirement in the Devicetree Specification 1.4.
> Is this a dtc bug?

I think the culprit here is the *empty* ranges property:
"If the property is defined with an <empty> value, it specifies that the
parent and child address space is identical, and no address translation
is required."
As this is contradicted by the differing #a-c/#s-z properties, it looks
like dtc has good reasons to warn.

> 
> > ```
> >
> > This patch takes into account address-cells and size-cells of the root
> > node and uses them as values for new reserved-memory node.  
> 
> Reservations may be above 4 GiB. How does your patch consider this?

If the root #a-c/#s-c don't allow for more than 4GB, then it's for a
reason (in this case, the A64 being 32-bit only, even with AArch64
capable cores), and keeping it isn't restricting it further. So I think
copying the root properties is the right thing to do. I think almost
every other 64-bit core uses 2/2 anyway, so it's just the odd outlier
here.

Cheers,
Andre

> Best regards
> 
> Heinrich
> 
> >
> > Signed-off-by: Andrey Skvortsov <andrej.skvortzov at gmail.com>
> > ---
> >   cmd/pstore.c | 10 ++++++++--
> >   1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/cmd/pstore.c b/cmd/pstore.c
> > index cd6f6feb2f..9795eea2db 100644
> > --- a/cmd/pstore.c
> > +++ b/cmd/pstore.c
> > @@ -486,6 +486,8 @@ void fdt_fixup_pstore(void *blob)
> >   {
> >   	char node[32];
> >   	int  nodeoffset;	/* node offset from libfdt */
> > +	u32 addr_cells_root;
> > +	u32 size_cells_root;
> >   	u32 addr_cells;
> >   	u32 size_cells;
> >
> > @@ -495,6 +497,8 @@ void fdt_fixup_pstore(void *blob)
> >   		log_err("fdt_path_offset() returned %s\n", fdt_strerror(nodeoffset));
> >   		return;
> >   	}
> > +	addr_cells_root = fdt_getprop_u32_default_node(blob, nodeoffset, 0, "#address-cells", 2);
> > +	size_cells_root = fdt_getprop_u32_default_node(blob, nodeoffset, 0, "#size-cells", 2);
> >
> >   	nodeoffset = fdt_find_or_add_subnode(blob, nodeoffset, "reserved-memory");
> >   	if (nodeoffset < 0) {
> > @@ -503,8 +507,10 @@ void fdt_fixup_pstore(void *blob)
> >   		return;
> >   	}
> >
> > -	addr_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0, "#address-cells", 2);
> > -	size_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0, "#size-cells", 2);
> > +	addr_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0,
> > +						  "#address-cells", addr_cells_root);
> > +	size_cells = fdt_getprop_u32_default_node(blob, nodeoffset, 0,
> > +						  "#size-cells", size_cells_root);
> >   	fdt_setprop_u32(blob, nodeoffset, "#address-cells", addr_cells);
> >   	fdt_setprop_u32(blob, nodeoffset, "#size-cells", size_cells);
> >  
> 



More information about the U-Boot mailing list