Hello,

oh, it seems I have to work out again how to get access to the serial of
my RN104. Great there are some efforts for that machine.

@Luca, somewhat related, my RN104 runs Debian and since quite some time
I see issues in the network driver with overruns corrupting transfers.
Do you see these, too?

On Mon, Aug 17, 2026 at 07:51:28AM +0000, Sascha Hauer wrote:
> On 2026-08-13 17:26, Luca Lauro via B4 Relay wrote:
> > +					 filetype_kwbimage_v1);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id rn102_of_match[] = {
> > +	{ .compatible = "netgear,rn102" },
> 
> How is the driver probed? The string "netgear,rn102" is in no dts.
> Unless I am missing something this should be "netgear,readynas-102".
> 
> Same for the rn104 patch.
> 
> > +/*
> > + * NOTE:
> > + * armada_370_xp_barebox_entry() cannot be used here because the
> > + * upstream SDRAM size detection for Armada 370-XP misinterprets
> > + * the DDR_SIZE_CSn registers on this board and reports an incorrect
> > + * memory size (256MB instead of 512MB on RN102).
> > + *
> > + * Until the generic detection code is fixed, we compute the SDRAM
> > + * size manually using the DDR_SIZE_CSn values.
> > + */
> > +static unsigned long armada_370_xp_memory_find(void)
> > +{
> > +	unsigned long mem_size = 0;
> > +
> > +	for (int cs = 0; cs < 4; cs++) {
> > +		u32 ctrl = readl(ARMADA_370_XP_SDRAM_BASE + DDR_SIZE_CSn(cs));
> > +
> > +		/* Skip non-enabled CS */
> > +		if ((ctrl & DDR_SIZE_ENABLED) != DDR_SIZE_ENABLED)
> > +			continue;
> > +
> > +		mem_size += (ctrl | ~DDR_SIZE_MASK) + 1;
> > +	}
> > +
> > +	return mem_size;
> > +}
> 
> The only difference I can spot here between this function and the
> existing variant in arch/arm/mach-mvebu/common.c is:
> 
> #define  DDR_SIZE_MASK                       0xff000000
> 
> whereas the common.c variant uses:
> 
> #define ARMADA_370_XP_DDR_SIZE_MASK     0xffff0000

Apart from the different value, the latter name is the better one B-)

> The latter goes down to this:
> 
> > commit 7351b6b5c59c7a280787998006f39a5cd3a2f18b
> > Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > Date:   Tue Jun 13 00:37:49 2017 +0200
> >
> >     ARM: mvebu: fix size mask for RAM window
> >    
> >     The size field in the window control register occupies bits 31:16. So
> >     adapt ARMADA_370_XP_DDR_SIZE_MASK accordingly. This fixes detection of
> >     RAM chips smaller than 32 MiB and so probably doesn't affect any
> >     supported machine.
> >    
> >     Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >
> > diff --git a/arch/arm/mach-mvebu/common.c b/arch/arm/mach-mvebu/common.c
> > index 06bfb72615..fa971da11e 100644
> > --- a/arch/arm/mach-mvebu/common.c
> > +++ b/arch/arm/mach-mvebu/common.c
> > @@ -47,7 +47,7 @@
> >  #define ARMADA_370_XP_SDRAM_BASE       (IOMEM(MVEBU_REMAP_INT_REG_BASE) + 0x20000)
> >  #define ARMADA_370_XP_DDR_SIZE_CSn(n)  (0x184 + ((n) * 0x8))
> >  #define ARMADA_370_XP_DDR_SIZE_ENABLED BIT(0)
> > -#define ARMADA_370_XP_DDR_SIZE_MASK    0xff000000
> > +#define ARMADA_370_XP_DDR_SIZE_MASK    0xffff0000
> > 
> >  /*
> >   * Marvell MVEBU SoC id and revision can be read from any PCIe
> 
> @Uwe, Where did you get that information from. Could it be that we
> should just revert this one given that it seems to be untested on your
> side?

0xffff0000 is in line with
https://datasheet.datasheetarchive.com/originals/crawler/marvell.com/002fa441a27967d992f905776d519926.pdf
(page 630). So I'd expect that 0xffff0000 is correct, but I don't care
much.

Best regards
Uwe