This thread is closed so it is needed to open a new thread for a question.
@ronnz98 You have build /e/OS for so many devices but the matissevewifi is missing.
It seems that there is really no usable custom build for it.
Are you able to help please?
The main difference is that this tablet has a SD410 CPU (64-Bit) instead of a SD400 CPU (32-Bit).
DART-SD410 / Qualcomm Snapdragon 410
There is a similar thread at Xdaforums for it.
Only a crashing build for lineage 17.1 has been released so far.
It is in a boot loop and not able to perform the start of Android.
The seems not to be a custom ROM for this device, it has a different chipset than the matissewifi
Yes - and you are the last hope to find a solution for it! 
Thank you for your quick reply!
For testing we can communicate directly in german. 
Sorry I can’t, this far exceeds my development skills
Good morning Ronald,
i’m very surprised, because I didn’t expect this answer.
Can you explain this a little bit more please?
It’s for my own understanding, because I never build an Android system.
I only have experience with building firmware for less complex systems like routers.
So for example for OpenWrt there is the same build system for different routers with different CPU’s. Another gcc is used for another CPU and of course a different hardware configuration is needed for the peripherals.
So what is the difference here between the versions of this tablets that makes it impossible to build a working alternate OS for this model SM-T533 only?
Here is the device tree for matissewifi
One of the very first steps in liberating a device is for someone with the device to generate the device tree. No one appears to have published a Lineage suitable device tree, unless you know different.
Here is a link to one method to try to create the device tree GitHub - sebaubuntu-python/aospdtgen: LineageOS device tree generator · GitHub. The next more difficult step is try try to get at least some part of Lineage to build off the new device tree.
Just a guess you mention
while this may look a detail, I would guess it is a generational thing … in AOSP getting the “old” and “new” together, bearing in mind that the firmware is proprietary. Edit, plus perhaps bear in mind the influence of how the 32-Bit transition to 64-Bit was handled by M$ at that time.
Thanks for this practical view!
Why the people from Lineage have the most experience in doing this?
I already asked N3kowarrior @ xdaforums.com what has happened to his build.
Now i have asked for the sources, but the status of his profile is “last seen Jun 20, 2026”.
(Please take the URL from the second post, because it is not allowed to use it again here.
Now i am replying to quickly - it is not easy to communicate here …)
samfw . com/combination/SM-T533/T533XXU1AOB1
(Only 2 Links in a post allowed and waiting 48 min. for the next post!)
Trying the above software.
Yes - and it is getting more and more harder, because now everything should go under the control of Google! https://keepandroidopen.org
Like always trying to use such python tools …
$ dumpyara SAMFW.COM_COMBINATION_SM-T533_T533XXU1AOB1.zip
...
File "~/.local/lib/python3.9/site-packages/dumpyara/dumpyara.py", line 39, in dumpyara
raise RuntimeError(
RuntimeError: You are missing fsck.erofs, please install erofs-utils from your distro's repositories
But the needed package is installed:
ii erofs-utils 1.2.1-2 amd64 Utilities for EROFS File System
The problem with fsck.erofs could be solved in Debian 12 (Debian 13 not installed).
aospdtgen could be installed via pip.
But now there is the next problem installing dumpyara:
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
dumpyara 1.1.0 requires sebaubuntu-libs<3.0.0,>=2.0.0, but you have sebaubuntu-libs 1.6.1 which is incompatible.