[PATCH] ipq95xx: Add support for IPQ9574 RDP433

[Elliott Mitchell]

On Fri, Dec 08, 2023 at 06:53:31PM +0100, Thibaut wrote:
> 
> > Le 8 déc. 2023 à 16:39, Elliott Mitchell <ehem+openwrt at m5p.com> a écrit :
> > 
> > On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> >> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz <pepe2k at gmail.com> wrote:
> >>> 
> >>> On 8.12.2023 11:02, Robert Marko wrote:
> >>>> On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz <pepe2k at gmail.com> wrote:
> >>>>> 
> >>>>> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> >>>>> just another subtarget of it (I'm aware of A53 vs. A73)?
> >>>> 
> >>>> That depends on how much is shared between the AX SoC-s and the BE
> >>>> ones(IPQ95xx and IPQ53xx).
> >>> 
> >>> I would say enough to keep them together.
> >>> 
> >>>> But, I would prefer that or qualcommbe target where new BE SoC-s will
> >>>> be subtargets.
> >>> 
> >>> I'm personally more a fan of limiting number of top targets and deal
> >>> with differences under subtargets.
> >> 
> >> Same here, better than to add more targets especially since a lot is shared.
> > 
> > This leads to needing more levels of organization.  Instead of simply
> > TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET.  If
> > this is going to be done, then the implementation should allow for an
> > arbitrary number of levels.
> > 
> > A makefile fragment I created for testing:
> > 
> > foo := foo0
> > SUBfoo := foo1
> > SUBSUBfoo := foo2
> > 
> > define recur
> > $(info current is $(1), value is $($(1))))
> > ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
> > endef
> > 
> > ignore := $(call recur,foo)
> > 
> > all: test.make
> > 	@true
> > 
> > So an arbitrary number of levels seems doable.
> 
> No.
> 
> >  Will mean rather
> > substantial changes to the build system though.  I tend to favor this
> > as the 2 level limitation is already placing restrictions on the scaling
> > of the build count.
> 
> It appears most people do not understand that {sub}+targets use the exact same amount of build resources *each* as a whole target. There is no benefit, from the PoV of the (phase1) builders, to having more subtargets vs more targets: either way, growing either number indefinitely is simply not sustainable. Please don’t do that.
> 

So, you would prefer to have all of a small cupcake, to a slice of a
much larger cake?

You would prefer to be the big fish in the small pond to the small fish
in the much larger lake?

This is not an invalid choice, but usually projects prefer to grow than
shrink.  Also, while having more levels should allow better organization
and then more growth; making growth possible does not force growth to
occur.


What I've observed from rather a lot of wildly different builds in the
past month differs.  Most of any OpenWRT build is unshared, but some
portions are reused and substantially greater portions could be reused.

Notably the compiler was reused.  If steps were taken to allow reusing
unpacked kernel source, the kernel would only need to be unpacked once
(some of the patches I've sent aim in this direction).

One thing I've noticed is the single-thread portions are a *major*
holdback at this point.  The single-thread unpacking of various tarballs
completely overwhelmed the portions of builds which used multiple
processors.

Right now my storage is sick and providing poor write performance (wow,
that battery-backed cache was *impressive*!), yet all OpenWRT builds
averaged less than a single processor in use.  That is rather concerning.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445