Porting the EN75xx platform - code style questions.

[Caleb James DeLisle]

Sorry for the late reply, thank you very much for the advice.

I think I I just ignore the SoC ID register entirely since it makes no sense to write a bunch of 
code just to print a warning about a platform mismatch.

Thanks,

Caleb


On 20/01/2025 14:57, Christian Marangi (Ansuel) wrote:
> 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