Porting the EN75xx platform - code style questions.

[Christian Marangi (Ansuel)]

Il giorno lun 20 gen 2025 alle ore 14:42 Caleb James DeLisle via
openwrt-devel <openwrt-devel at lists.openwrt.org> ha scritto:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> ---------- Forwarded message ----------
> From: Caleb James DeLisle <cjd at cjdns.fr>
> To: OpenWrt Development List <openwrt-devel at lists.openwrt.org>
> Cc:
> Bcc:
> Date: Mon, 20 Jan 2025 14:41:15 +0100
> Subject: Porting the EN75xx platform - code style questions.
> Hello folks,
>
>
> I'm back to my old time-waster, trying to port to an EN7526.
>
>
> I'd like some advice on what is the "best" way to code this so that it's easily merged, and not
> excluded from upstreaming for quality reasons.
>

Well most of the time... Nothing hardcoded or minimal and every patch MUST pass
scripts/checkpatch.sh Anything in mach-* is a no no and everything should be
correctly supported in DT.

>
> First question: I'm planning on pretty much rewriting everything from scratch, so I'd like to know
> what is the Gold Standard of MIPS platforms that I should be emulating. I'm currently trying to
> pattern off of the ralink platform in linux upstream, but I don't know if what I'm copying is the best.
>

This really depends... Hope other can answer to this.

>
> Second question: What's the appropriate balance between hard-coding the system type, and trying to
> detect and roll with whatever you have?
>

The appropriate balance is not hard-coding anything... As said,
support everything in DT well documented
make it modular.

> At one extreme, I could make the build be for one SoC only, e.g. EN7526G, and make it panic if it
> boots on anything else (even like an EN7526C which would probably boot ok). At the other extreme, I
> could make the code use runtime detection only and let the user choose from a menu of SoCs and have
> them mutually exclude if they have major differences like byte order.
>

I feel both solution are not ok... Just make different subtarget if
they are different enough.
Or a big .dtsi and different device for each kind of board.

> The 2nd direction makes a lot of sense to me because I can make it so you can select Generic and
> you'll get an OS which tries really hard to boot on whatever you put it on, but if you select a
> specific processor then some function like `static inline bool en75_soc_is(enum en75_soc_type t)`
> will be constant folded, so dead code elimination will clean up any if block that references an
> another SoC.

That kind of function are downstream SDK hacks and laziness... Again
correct DT compatible and
of_device_is_compatible should be the correct way.

>
> The problem is device trees. These boards use an old trx loader so FIT is out of the question, but
> what I could do is append multiple DTs and have plat_mem_setup() just walk them like a linked list
> looking for the index of the identified SoC, but I wanted to ask for opinions first before doing
> something "smart" that might just lead to code nobody wants to go near.

Apply KIS (keep it simple) rule. We don't want massive generic
firmware that can boot on any
kind of router/SoC in the world. We want small image suited for the task.

With this in mind, we build one image for the SoC with the appended
appropriate DTS and be
done with it. No detection and selection of the DTS based on the
strange value detected at
runtime. What should be really understood is how different they are.

If they are GT or E variant (with for example the fact that one board
have wifi chip and another
have an additional ethernet port) then these can be handled with
modular .dtsi and the final
device will include the related dtsi.

If they are different CPU, most of the time it's a different subtarget
if they are different enough.
For the sake of CPU init for first stage, it's DT compatible way and a
switch case in mips march.

>
>
> Third question: Anybody going to be at FOSDEM?
>

A big maybe for me.

>
> Thanks,
>
> Caleb
>
>
>
>
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel