Some more Allwinner SID details

[ThomasKaiser]

Just to let you know: I did recently some research on Allwinner SIDs and as a former linux-sunxi guy added my insights to the end of https://linux-sunxi.org/SID_Register_Guide#Currently_known_SID.27s

In short: the first 32 bits are not unique in the sense always being exactly the same but likely containing some bits like SoC revision or batch number. So if you rely on the SID for identifying SoCs you might want to exclude these positions :)

[Dr-Noob]

Just to let you know: I did recently some research on Allwinner SIDs and as a former linux-sunxi guy added my insights to the end of https://linux-sunxi.org/SID_Register_Guide#Currently_known_SID.27s

In short: the first 32 bits are not unique in the sense always being exactly the same but likely containing some bits like SoC revision or batch number. So if you rely on the SID for identifying SoCs you might want to exclude these positions :)

Interesting, so there are some bytes that might vary. It worries me the fact that this ? that you have here is just a guess based on the SIDs that the community have collected, but there is no generic rule or rationale behind this, e.g., this might change any moment in the future. But I guess we don't have better choice than doing this? The ? you have match perfectly what I have in get_sunxisoc_from_sid, so it gives me some confidence. I'll definitely implement this.

By the way, I'm curious by what you mean with the percentages? E.g., (87%) and (13%) for A83T.

[ThomasKaiser]

But I guess we don't have better choice than doing this?

Well, at least some years ago an Allwinner employee joined linux-sunxi community and was hanging around also in IRC but I don't know his or her name or presence today. And no idea whether Allwinner would share these internals (at least their management isn't very open to anything, especially not 'open source' communities).

Maybe it's a bit rude to ping @Icenowy on the subject of Allwinner SID internals but since she's a wizard and knows almost everything I give it a try...

By the way, I'm curious by what you mean with the percentages? E.g., (87%) and (13%) for A83T.

Just some data mining through collected info and then doing percentages, e.g. for A83 (Serial number starting with the SID with mainline kernel which fortunately now is the only version running on Banana Pi M3 any more):

grep A83 *.cpuinfo | awk -F":" '{print $1}' | while read ; do grep Serial $REPLY; done | cut -c11-18 | sort | uniq -c`

BTW: my 'data collection' efforts came to a halt ~8 weeks ago since ix.io ist down since then and the fallback upload of info to sprunge.us was faulty and I noticed that only yesterday :(

[Icenowy]

Well I think use on the high 16bit of the first 32-bit word to get the die compatibility ID could be okay, and the remaining 16-bit could be hardcoded with the high 16-bit to differentiate variants (e.g. H3 vs H2+).

This is only my personal understanding.

BTW interesting to know cpufetch ;-)

[Icenowy]

Well my assumption is that the lowest 8 bit of that 32-bit represents chip variant, and the remaining 8-bit represents some kind of batch id.

[Dr-Noob]

Well I think use on the high 16bit of the first 32-bit word to get the die compatibility ID could be okay, and the remaining 16-bit could be hardcoded with the high 16-bit to differentiate variants (e.g. H3 vs H2+).

This is only my personal understanding.

BTW interesting to know cpufetch ;-)

I'm happy to hear you like the project 😃

With the highest 16 bits, we would not be able to distinguish between chips. For example, for V3s and S3 the highest 16 bits would be 0x12c0. So if we need the remaining 16 to differentiate variants then I don't understand the advantage of doing it that way rather than just checking the whole 32 bits. Using the lowest 8 bits does not work either: H616 and H618 would both have 0x00.

@ThomasKaiser about the idea of excluding certain SID positions like in sbc-bench, I still feel like the ? are a bit arbitrary (e.g., one day we might find that for H6 we need to exclude the last 2 values, not only the last one) so I still prefer checking SIDs one by one like it is done in get_sunxisoc_from_sid. I prefer this to trying to find a heuristic that we are unsure if it works for all cases or if it is just good enough for the data we know.

For now, I think I'll just update get_sunxisoc_from_sid using sbc-bench as reference, but please feel free to share your thoughts if you have different opinions on something.

[Dr-Noob]

Thanks for the feedback guys, Allwinner list up-to-date with sbc-bench, closing.

[Dr-Noob]

@ThomasKaiser I think you have contributed a lot to the project in the last months. Have a look at this 🙂