Database Users

[TOOL/WIP] The proper NB management tool

Tired of osnbtool/xidump/nbsplit/nbmerge/nbimagetool/implantxip/imgfstonb/etc? A proper NB extracting tool (without requiring splitting, without having to guess sector size and extra data and without messy additional padding or nasty crashes on unsupported files (ciphone/omnia II/etc.)) is coming soon (and yes, in the future it will also support generating the files without having to keep .nb or .nb.payload files around)!

airxtreme said:
Tired of osnbtool/xidump/nbsplit/nbmerge/nbimagetool/implantxip/imgfstonb/etc? A proper NB extracting tool (without requiring splitting, without having to guess sector size and extra data and without messy additional padding or nasty crashes on unsupported files (ciphone/omnia II/etc.)) is coming soon (and yes, in the future it will also support generating the files without having to keep .nb or .nb.payload files around)!
Click to expand...
Click to collapse
Fantastic!

sounds great!

Yep, bepe done such tool maybe a year ago but he haven't realised it...
But anyway will be interesting too look at it...

Interesting idea,
Waiting for it

No new news? just waiting

Great.. waiting for the release date..

tj_style said:
Great.. waiting for the release date..
Click to expand...
Click to collapse
I have already all the extraction part working on all ROMs for several days but since the sectorinfo data seems to be different between phones (HTCs are non-standard) I think I'll restart from scratch and add stricter checks for all the file structures since writing a wrong sectorinfo means permanently marking the NAND sector as bad.

airxtreme said:
I have already all the extraction part working on all ROMs for several days but since the sectorinfo data seems to be different between phones (HTCs are non-standard) I think I'll restart from scratch and add stricter checks for all the file structures since writing a wrong sectorinfo means permanently marking the NAND sector as bad.
Click to expand...
Click to collapse
are you mean you have trouble on generating back the .nb file?
ok, keep waiting for your great tool on managing the nb file..
keep on the good work bro..
sorry for my bad english..

airxtreme said:
I have already all the extraction part working on all ROMs for several days but since the sectorinfo data seems to be different between phones (HTCs are non-standard) I think I'll restart from scratch and add stricter checks for all the file structures since writing a wrong sectorinfo means permanently marking the NAND sector as bad.
Click to expand...
Click to collapse
Yes, definitely understanding what you say and the key point of your good work is this and should be considered precisely in order to avoiding device brick or some extra work. But since you proved your ability and plenty knowledge of ROM understanding, I'm sure you can figure out this matter finally.

Anyway, I can be your first beta tester.

airxtreme said:
I have already all the extraction part working on all ROMs for several days but since the sectorinfo data seems to be different between phones (HTCs are non-standard) I think I'll restart from scratch and add stricter checks for all the file structures since writing a wrong sectorinfo means permanently marking the NAND sector as bad.
Click to expand...
Click to collapse
Why don't you get in touch with Da_G and continue his libnb project ? He's already finished most of the tool that does all you want to do, and he even posted a version of it I'm sure it'll reduce your devving time quite a bit since he's already figured all that stuff out...

NRGZ28 said:
Why don't you get in touch with Da_G and continue his libnb project ? He's already finished most of the tool that does all you want to do, and he even posted a version of it I'm sure it'll reduce your devving time quite a bit since he's already figured all that stuff out...
Click to expand...
Click to collapse
I would have liked to: I asked him to write me a list of things that had to be done to complete the library since c++ is the language I know best but he still hasn't told me anything regarding that so since I already have to figure out everything by myself and since sharing data between managed/unmanaged code is a mess I'd rather start it from scratch and writing the code myself.
I already have most of the stuff figured out and I can easily write the code to generate the .NB file for all HTC phones however I'm still looking for the weird ROMs that could cause trouble and the fact that most of the tools using to manage non-HTC phone formats (TGTool/osnbtool/os2tool) don't output correct os.nb files seems to make everything more fun.

New Eris ota for those that want to pick it apart

Yanked straight from my Eris.
http://db.tt/w9LQH7N
sent from my phone

Awesome your the hero of the day!

These are flashable from Amon_Ra's recovery. They do not flash the radio or recovery, but I can make versions with those if you want. You have to be on the right most version for them to flash.
OTA_2.37.605.4_2.36.605.1 --> http://46.4.208.146/OTAs/OTA_2.37.605.4_2.36.605.1.zip
OTA_2.41.605.6-2.37.605.4 --> http://46.4.208.146/OTAs/OTA_2.41.605.6-2.37.605.4.zip
I'm working to fix DNS now, so sorry for the direct IPs...

Sweet you guys work fast, not sure what this includes, I rooted real quick so I could pull it per request from eu1 on another forum. Couple folks still stock have installed it though.
sent from my phone

FYI for anyone wanting to play with these files, the zips only contain .P files which are patches. They are designed to be patched against a stock rom.
So if you really wanted something, you'd have to take your system full stock and then apply this and then dump a nandroid or use ABD to transfer files off the phone.

gruss01 said:
Sweet you guys work fast, not sure what this includes, I rooted real quick so I could pull it per request from eu1 on another forum. Couple folks still stock have installed it though.
sent from my phone
Click to expand...
Click to collapse
Well if you have a Mercedes your in luck. Better bluetooth connection. somme MMS tweeks and "better signal" here is a link that I found with a "full description"
http://androidspin.com/2011/03/03/htc-droid-eris-for-verizon-receives-random-ota-update/

gnarlyc said:
These are flashable from Amon_Ra's recovery. They do not flash the radio or recovery, but I can make versions with those if you want. You have to be on the right most version for them to flash.
OTA_2.37.605.4_2.36.605.1 --> http://46.4.208.146/OTAs/OTA_2.37.605.4_2.36.605.1.zip
OTA_2.41.605.6-2.37.605.4 --> http://46.4.208.146/OTAs/OTA_2.41.605.6-2.37.605.4.zip
I'm working to fix DNS now, so sorry for the direct IPs...
Click to expand...
Click to collapse
I would like the new radio as a flashable please. That's probably the only useful thing from this ota. Thanks man.

dreed75 said:
I would like the new radio as a flashable please. That's probably the only useful thing from this ota. Thanks man.
Click to expand...
Click to collapse
Tried to flash and got an installation aborted....no big deal I was thinking of putting a decent Rom on there anyway, stock has been bugging me and traveler testing is about over anyway.
sent from my phone

dreed75 said:
I would like the new radio as a flashable please. That's probably the only useful thing from this ota. Thanks man.
Click to expand...
Click to collapse
As I read on the Verizon description, the radio included on this OTA is 2.42.01.04.27. So the radio did not change. -=/

endoki said:
As I read on the Verizon description, the radio included on this OTA is 2.42.01.04.27. So the radio did not change. -=/
Click to expand...
Click to collapse
oh, ok. i forgot i had flashed an old radio to try to clear up a bug so my version was less than the "new" one.

FWIW, here's some "picking it apart" analysis.
I flashed a virginal copy of the July OTA (2.37.605.4) plus it's associated stock recovery to my phone, and then applied this newest (2.41.605.6) OTA (letting the stock recovery for the July OTA do the install). After it completed and rebooted, I used the stock recovery to perform a factory reset. Following that, I made a Nandroid backup.
In both of those configurations (while they were booted), I pulled /proc/config.gz for later comparison.
Then I unpacked (unyaffs) the "system.img" files from each of the respective Nandroid backups, and did an offline comparison of the before & after condition of the /system mount point.
The pastebin with the summary results can be found here. Note that files noted as exhibiting differences only indicates a changed MD5 checksum.
[SIZE=+1]Highlights:[/SIZE]
- most changes are in /system/app (as expected) and 20+ changes in /system/framework
- Library (/system/lib) changes: libandroid_runtime.so, libhtc_ril.so, libopenobex.so
- Native binary ( /system/bin ) changes: vold, wpa_supplicant, dmagent, debuggerd, btipsd
A comparison of the kernel compile options for both (/proc/config.gz) revealed that identical config files were used to build both kernels. There was of course, one minor difference: the time stamps in the config files:
Code:
[email protected]:~$ diff march11OTA/config julyOTA/config
4c4
< # Tue Sep 7 17:35:16 2010
---
> # Thu May 13 12:30:48 2010
After seeing this, I unpacked the boot images, and uncompressed the kernel. Indeed, this newest kernel was built ... wait for it ... nearly 6 months ago. No big deal, I expect VZW/HTC to move at a snails' pace on a "legacy" phone; OTOH, what I find bothersome is that HTC recently released kernel sources "for the Eris" that had time stamps from February 23 of this year. WTF?
I suppose that means that there may not be any reason to believe that there is good correspondence between what VZW is shipping and the sources that HTC is producing under its' GPL obligations.
The ramdisks of the boot.img file were bitwise identical - so, no boot/init changes for this OTA release, either.
cheers
bftb0

bftb0 said:
Code:
[email protected]:~$ diff march11OTA/config julyOTA/config
4c4
< # Tue Sep 7 17:35:16 2010
---
> # Thu May 13 12:30:48 2010
After seeing this, I unpacked the boot images, and uncompressed the kernel. Indeed, this newest kernel was built ... wait for it ... nearly 6 months ago.
Click to expand...
Click to collapse
Sprint had an update to the Hero last fall. Maybe Verizon was just catching up?

bftb0 said:
FWIW, here's some "picking it apart" analysis.
I flashed a virginal copy of the July OTA (2.37.605.4) plus it's associated stock recovery to my phone, and then applied this newest (2.41.605.6) OTA (letting the stock recovery for the July OTA do the install). After it completed and rebooted, I used the stock recovery to perform a factory reset. Following that, I made a Nandroid backup.
In both of those configurations (while they were booted), I pulled /proc/config.gz for later comparison.
Then I unpacked (unyaffs) the "system.img" files from each of the respective Nandroid backups, and did an offline comparison of the before & after condition of the /system mount point.
The pastebin with the summary results can be found here. Note that files noted as exhibiting differences only indicates a changed MD5 checksum.
[SIZE=+1]Highlights:[/SIZE]
- most changes are in /system/app (as expected) and 20+ changes in /system/framework
- Library (/system/lib) changes: libandroid_runtime.so, libhtc_ril.so, libopenobex.so
- Native binary ( /system/bin ) changes: vold, wpa_supplicant, dmagent, debuggerd, btipsd
A comparison of the kernel compile options for both (/proc/config.gz) revealed that identical config files were used to build both kernels. There was of course, one minor difference: the time stamps in the config files:
Code:
[email protected]:~$ diff march11OTA/config julyOTA/config
4c4
< # Tue Sep 7 17:35:16 2010
---
> # Thu May 13 12:30:48 2010
After seeing this, I unpacked the boot images, and uncompressed the kernel. Indeed, this newest kernel was built ... wait for it ... nearly 6 months ago. No big deal, I expect VZW/HTC to move at a snails' pace on a "legacy" phone; OTOH, what I find bothersome is that HTC recently released kernel sources "for the Eris" that had time stamps from February 23 of this year. WTF?
I suppose that means that there may not be any reason to believe that there is good correspondence between what VZW is shipping and the sources that HTC is producing under its' GPL obligations.
The ramdisks of the boot.img file were bitwise identical - so, no boot/init changes for this OTA release, either.
cheers
bftb0
Click to expand...
Click to collapse
As always, a wonderfully thorough and knowledgeable analysis. Thank you.

bftb0 said:
FWIW, here's some "picking it apart" analysis.
I flashed a virginal copy of the July OTA (2.37.605.4) plus it's associated stock recovery to my phone, and then applied this newest (2.41.605.6) OTA (letting the stock recovery for the July OTA do the install). After it completed and rebooted, I used the stock recovery to perform a factory reset. Following that, I made a Nandroid backup.
In both of those configurations (while they were booted), I pulled /proc/config.gz for later comparison.
Then I unpacked (unyaffs) the "system.img" files from each of the respective Nandroid backups, and did an offline comparison of the before & after condition of the /system mount point.
The pastebin with the summary results can be found here. Note that files noted as exhibiting differences only indicates a changed MD5 checksum.
[SIZE=+1]Highlights:[/SIZE]
- most changes are in /system/app (as expected) and 20+ changes in /system/framework
- Library (/system/lib) changes: libandroid_runtime.so, libhtc_ril.so, libopenobex.so
- Native binary ( /system/bin ) changes: vold, wpa_supplicant, dmagent, debuggerd, btipsd
A comparison of the kernel compile options for both (/proc/config.gz) revealed that identical config files were used to build both kernels. There was of course, one minor difference: the time stamps in the config files:
Code:
[email protected]:~$ diff march11OTA/config julyOTA/config
4c4
< # Tue Sep 7 17:35:16 2010
---
> # Thu May 13 12:30:48 2010
After seeing this, I unpacked the boot images, and uncompressed the kernel. Indeed, this newest kernel was built ... wait for it ... nearly 6 months ago. No big deal, I expect VZW/HTC to move at a snails' pace on a "legacy" phone; OTOH, what I find bothersome is that HTC recently released kernel sources "for the Eris" that had time stamps from February 23 of this year. WTF?
I suppose that means that there may not be any reason to believe that there is good correspondence between what VZW is shipping and the sources that HTC is producing under its' GPL obligations.
The ramdisks of the boot.img file were bitwise identical - so, no boot/init changes for this OTA release, either.
cheers
bftb0
Click to expand...
Click to collapse
So, does that mean HTC's kernel sources are more recent, and thus improved? And if so, can/are any XDA devs able to build a kernel from the latest HTC source? Is this something Conap/Decad3nce could/do use?

KarateExplosion6 said:
So, does that mean HTC's kernel sources are more recent, and thus improved? And if so, can/are any XDA devs able to build a kernel from the latest HTC source? Is this something Conap/Decad3nce could/do use?
Click to expand...
Click to collapse
More recent, yes. Improved is hard to say; "worth the effort" is even harder to say. I did a brief analysis of the differences between the last two HTC kernel source releases, and put that question to Conap last night. Maybe I should have asked him privately, rather than in the forum, though.
To me it seems like a pretty good chunk of work is required to do that, and so it is therefore worthwhile to ask the question: what gain is won through the effort?
It would be pretty easy to just compile the HTC kernel "as is", but no-one would be happy with that, esp. in the areas of overclocking, schedulers and scaling governors.
What has happened over time is that the "dev" Eris 2.6.29 code has been branching away from the HTC code base that zanfur started with, and Decad3nce/Conap have incorporated a lot of new goodies (bfs, cfs, new governors, etc) downstream from zanfur's mods into what is currently "CFSv9". At the same time, the HTC code has also been branching away from that same starting point. Some of those changes more than likely overlap, esp. if code from later mainline Android releases are being back-ported into both "2.6.29" source branches simultaneously.
Maybe the right approach is to start by looking at the HTC code changes in individual areas, and just cherry-pick individual patches out of it where it looks like there is either a performance opportunity, or a "big" bug fix. (I'm not optimistic that we are going to see giant performance leaps twiddling with the kernel; and it's probably a good idea to be conservative about kernel patching anyway.)
bftb0

Why did the phone keep offering the update after I did the AmonRA flash from zip?
Stonent said:
FYI for anyone wanting to play with these files, the zips only contain .P files which are patches. They are designed to be patched against a stock rom.
So if you really wanted something, you'd have to take your system full stock and then apply this and then dump a nandroid or use ABD to transfer files off the phone.
Click to expand...
Click to collapse
My phone is quite vanilla -- stock ROM but rooted. I took the ZIP file from gnarlyc and applied it. It seems to have been successful.
I put details in an androidforum thread. (I'm too new to this forum to post that as a link. The URL, in text form is: androidforums.com/htc-droid-eris/286167-just-had-system-update-eris-4.html#post2483781 )
I did have to re-root the phone.
Surprisingly, after the patching said it was successful, and successfully booting up the phone and confirming the Software number was now 2.41.605.6 instead of the old 2.37.605.4, the phone still kept popping up an alert offering me the update.
How come, if all the files are now in place for the update, does the phone still think I need the update?

wcattey said:
Surprisingly, after the patching said it was successful, and successfully booting up the phone and confirming the Software number was now 2.41.605.6 instead of the old 2.37.605.4, the phone still kept popping up an alert offering me the update.
How come, if all the files are now in place for the update, does the phone still think I need the update?
Click to expand...
Click to collapse
Well, the program logic which normally would initiate the upgrade actually never checks to see whether the update occurs or not - the only thing it seems to be aware of is whether you press the "OK, do the update" button.
This also means that the reverse is also true - if you accept the nag screen, but the update fails, you will no longer be nagged - it only seems to remember whether or not you "pressed the OK button".
And you can be sure that it will fail if you have the Amon_RA recovery on the phone... so go ahead and hit the "OK" button, and be rid of the nagging. (If you are worried that what I am saying might not be true, then make a nandroid backup before you begin)
bftb0

Thanks for the clarification.
I suspect the update initiation logic is not what you or I would have written, had we been the developers of that particular piece.
Indeed, I hit the OK button, watched Amon_RA try and fail as expected, and then the phone quit inviting me to update, also as expected.

[R&D]Android 4.4.4

Hi Folks
I've been working on porting Android 4.4.4 ( CM11 ) to the RaspberryPI .
Using the androidarmv6 project as I base I've created a device tree and made the modification required to get the thing built and booting into a console on the PI the thing that is currently missing is the Graphics Stack implementation which includes the Gralloc, HWComposer and OpenGLES libraries.
If you have an experience/knowledge of how the Android Graphics Stack works especially wrt Surfaceflinger internals how to Implement OpenGLES at the platform level or any of that fun stuff and also have a RaspberryPI to hand then feel free to start hacking on this.
To get started follow the README @ https://github.com/trevd/android_vendor_broadcom_rpi .
Just to be clear. This is not so much a call for help as it is an invitation to anyone who fancies the challenge as I'm pro-actively working on the Graphics stuff myself. I'm coming at this one cold however as upto until 6 weeks ago I had never done any Graphics driver development. I figured this a great opportunity to learn.
DEVELOPERS
If like me you have no experience with Graphics but want to have a go anyway then again feel free. I'll happily answer questions wrt to specifics of the development. I'll caution however that this involves a fair bit of research and the learning curve is fairly steep (IMHO). If you have no experience porting android to devices and thing like debugging device bring-up over adb then this is definitely not the place to start.
OTHER INTERESTED PARTIES
This is going to sound harsh to some folks but here goes. I'd really like to manage expectations by saying expect nothing! I will also report and have removed any non development related posts, Even nice ones! If you feel compelled to offer some encouragement just click the thanks button. It really should also go without saying but for the love of <insert favourite deity> Don't ask for an ETA.
CREDITS
My work is definitely standing on the shoulders of giants here and this wouldn't even be a thing without the fine work of the androidarmv6 project and their efforts to keep Android alive on older hardware. Also the Razdroid folks who prior work in this area has been extremely useful.
Obviously CM, Google et al and lets not forget those 1000's of linux kernel developers too.

I hope this project will come alive, cause I want any form of working Android on my Raspberry, but couldn't get an answer...
Android on that little machine would be great!

Hello everyone,
Thread cleaned.
As you all may or may not know, things had gotten off-topic on this thread. Usually it takes quite a bit of time for that to happen but somehow it began almost out of the gate.
Tempers were getting hot about whether Android is Linux or not. I'm not sure why this debate was going on but it doesn't belong here. Please stick to the topic as it pertains to this thread.
Also, please show one another a little respect. Just because you may have a difference of opinion, there's no need to start insulting one another by name-calling.
Regards

What's new?

I have read that on this site http://www.mesa3d.org/relnotes/10.3.html new gpu drives for the raspberry pi are
V 10.3 is the First one
But i am not sure

Little Bit of an update
Hi Folks OP! here.
Bit of an update. https://www.youtube.com/watch?v=GO10mkZWeA8 ....
This basically shows the PI booting to the Launcher then the whole thing goes a bit mental and fails somewhere around a dequeuing buffer attempt.
A Couple of Technical Details
This is booting without the HWComposer library ( apparently that's a thing ) big thanks @psyke83 on the armv6 who pointed me in the right direction.
The Gralloc in it's current state is pretty standard and I'm trying to get my head wrapped around how the RaspberryPI dispmanx tie's in without allocating and lock graphics buffers. There seems to be at least 3 ways of accessing the Graphics Memory via various kernel drivers.
I added blanking support to the raspberrypi kernel framebuffer driver , which was absent. I did this upstream as I'm too lazy to maintain a separate patch set This seems to have prompted ( who I think ) is the RPi kernel maintainer to extended the Videocore closed source graphics firmware to enabled HDMI power down and also add the FB_WAITFORVYNC which is something Android makes use of in many HWComposer implementations.
As we are using a close to mainline kernel which means we're not constrained to compatibility hacks wrt to the surfaceflinger service layer. at the moment that is about has much as I know. Currently the AOSP Display Stack is a moving target and there's discussions going on with regard to Dma-buf fences vs Android sync driver. https://www.youtube.com/watch?v=rhNRItGn4-M&list=UUIxsmRWj3-795FMlrsikd3A .
As you may gather there's alot of information to soak up ....
Meanwhile over at the RPI Foundation. Fromer Intel GPU driver development Eric Anholt has been working on making a kernel driver for the videocore. http://www.phoronix.com/scan.php?page=news_item&px=MTc3NjQ . I initially thought we could maybe use the A KMS Hwcomposer, Mesa GLES implementation and a DRM ( Display Render Manager ) based gralloc. All these are things today and would just have to be extended to support the vc4 implementation. Eric was working with Mesa as part of his implementation which would leave the gralloc which is available in the android-x86 and libdrm .... libdrm looked like a tricky proposition for someone with my skills and Eric said he had no ( concrete ) plans to do libdrm . However looking at his current codebase I noticed that the videocore driver now supports dma_buf. Arm have made their Mali Gralloc opensource this also supports the use dma_buf and the nature of the beast is to provide a Generic way of accessing the Graphics buffer access many GPU's ( I think ) .
The Current Plan
=============
Merge the vc4 GPU kernel changes into my kernel branch
Port the Mali Gralloc to handle any difference between mali and vc4 ioctl etc
?????
?????
?????
?????
?????
Potentially Profit!
Thanks
trevd

trevd,
As a temporary measure, you could try to disable the opengl renderer by setting USE_OPENGL_RENDERER := false. That may allow you to boot into the home app and do some further debugging. With hwui and hwcomposer both disabled, the UI will be very slow, but it has a better chance of working if your problem is specifically due to an incompatibility with the EGL drivers.
Have you tried running with the full brcm_usrlib driver? As far as I can see, there have been successful cases in which the driver was demonstrated to run on RPi (though not specifically on Android). See here: http://www.raspberrypi.org/quake-iii-bounty-we-have-a-winner/
You mentioned an error with dequeueing buffers; you may have the same issue that I had with the original brcm_usrlib source that was solved by this commit.
BTW, I'd appreciate if you could post a logcat captured during boot (failing or otherwise). I'm curious...

Android Wear on Raspberry Pi?
Hi there!
Nice project. Is there any existing solution to run Android Wear on Raspberry Pi? A prototypical port would be sufficient for my case.
Many thanks in advance!

psyke83 said:
trevd,
As a temporary measure, you could try to disable the opengl renderer by setting USE_OPENGL_RENDERER := false. That may allow you to boot into the home app and do some further debugging. With hwui and hwcomposer both disabled, the UI will be very slow, but it has a better chance of working if your problem is specifically due to an incompatibility with the EGL drivers.
Have you tried running with the full brcm_usrlib driver? As far as I can see, there have been successful cases in which the driver was demonstrated to run on RPi (though not specifically on Android). See here: http://www.raspberrypi.org/quake-iii-bounty-we-have-a-winner/
You mentioned an error with dequeueing buffers; you may have the same issue that I had with the original brcm_usrlib source that was solved by this commit.
BTW, I'd appreciate if you could post a logcat captured during boot (failing or otherwise). I'm curious...
Click to expand...
Click to collapse
@psyke83 Thanks for the tip .wrt USE_OPENGL_RENDERER . It's a good idea but not where I'm at in the process . I know what I need to do it's just a case of doing it lol , i've been lazy the last few weeks and sometimes time is a great leveller in these things . There's smarter people than me doing work in the same area which is presenting some interesting options as I noted .
I did see your dequeue and wait patch and have I think it's something I need to do ... Am I correct in thinking that this is the same as what later Android Graphics Stack implementations are doing in the way sync fencing?
Tbh It was the original broadcom source release that got me going on this and I was quite excited to see the PI "Port" ... After some investigation I thought using that approach was way beyond my level of understanding , Put simply I didn't have the skills or knowledge or the patience to even attempt implementing it ..... That was 6ish months ago ( I think ) so revisiting it is also an options ... again time is the leveller and smarter people ( you and the armv6 team in this case ) have done alot of the hard work and my knowledge is dramatically increased in the area of porting missing Broadcom functionality into the RPI Kernel
The PI's kernel is also virtually mainline which presents more options still as the current state of the art on the Android Graphics Stack is to use the Atomic Display Framework and the AOSP has libraries to work with that [ https://android.googlesource.com/platform/system/core/+/master/adf ] . As a test/hack I compiled/backported the AOSP master surfaceflinger hwui to the androidarmv6 code base so that is ultimately where I'd like to go with this madness ..
I think It's going to be a mix of everything , the full broadcom EGL/GLES library with a dma_buf based gralloc and hwcomposer to suit .
I'd say I've got an embarrassment of riches atm .
Ahh the curious mind of the developer , lol . You know where curiosity gets you? Reading logcats of devices you don't have access to for entertainment on a saturday night but yeah I'll drop a logcat etc when I next power the thing up ... :good:
@Verses There's no Android Anything on the PI and without wanting too sound harsh. If you want it , you have to build it.
If you want to do something with Android Wear today than the PI isn't the device you need. There's better, more powerful SBC's available for not much additional cost. Also there's really no sane reason the latest versions of Android should run on the PI the CPU is legacy by 2 generations the available source code made no provision for Android what so ever and the RPI Foundation decided that Android was not an OS that fulfilled their primary mission of improving (real) computer literacy in the British yoof! But I really like Android and had a spare PI and making the latest version of Android work on "weird" machines is sort of how I get my kicks, hence this!

trevd said:
@psyke83 Thanks for the tip .wrt USE_OPENGL_RENDERER . It's a good idea but not where I'm at in the process . I know what I need to do it's just a case of doing it lol , i've been lazy the last few weeks and sometimes time is a great leveller in these things . There's smarter people than me doing work in the same area which is presenting some interesting options as I noted .
I did see your dequeue and wait patch and have I think it's something I need to do ... Am I correct in thinking that this is the same as what later Android Graphics Stack implementations are doing in the way sync fencing?
Tbh It was the original broadcom source release that got me going on this and I was quite excited to see the PI "Port" ... After some investigation I thought using that approach was way beyond my level of understanding , Put simply I didn't have the skills or knowledge or the patience to even attempt implementing it ..... That was 6ish months ago ( I think ) so revisiting it is also an options ... again time is the leveller and smarter people ( you and the armv6 team in this case ) have done alot of the hard work and my knowledge is dramatically increased in the area of porting missing Broadcom functionality into the RPI Kernel
The PI's kernel is also virtually mainline which presents more options still as the current state of the art on the Android Graphics Stack is to use the Atomic Display Framework and the AOSP has libraries to work with that [ https://android.googlesource.com/platform/system/core/+/master/adf ] . As a test/hack I compiled/backported the AOSP master surfaceflinger hwui to the androidarmv6 code base so that is ultimately where I'd like to go with this madness ..
I think It's going to be a mix of everything , the full broadcom EGL/GLES library with a dma_buf based gralloc and hwcomposer to suit .
I'd say I've got an embarrassment of riches atm .
Ahh the curious mind of the developer , lol . You know where curiosity gets you? Reading logcats of devices you don't have access to for entertainment on a saturday night but yeah I'll drop a logcat etc when I next power the thing up ... :good:
@Verses There's no Android Anything on the PI and without wanting too sound harsh. If you want it , you have to build it.
If you want to do something with Android Wear today than the PI isn't the device you need. There's better, more powerful SBC's available for not much additional cost. Also there's really no sane reason the latest versions of Android should run on the PI the CPU is legacy by 2 generations the available source code made no provision for Android what so ever and the RPI Foundation decided that Android was not an OS that fulfilled their primary mission of improving (real) computer literacy in the British yoof! But I really like Android and had a spare PI and making the latest version of Android work on "weird" machines is sort of how I get my kicks, hence this!
Click to expand...
Click to collapse
We can't give up now

@psyke83 For your viewing pleasure lol ... This is before I've switch the Gralloc over to Arm's DMA Buf based one .
At least the kernel booted with the DMA additions . ... Anywho To Work!! I might get this done before christmas. :good:

@trevd, I'd like to know something. I already build some ROMs for different devices and the output was always a custom recovery flashable zip, some images, ramdisk, kernel etc.
My answer is: How you "flash" this on RPi?
Thanks.

GeekyDroid said:
@trevd, I'd like to know something. I already build some ROMs for different devices and the output was always a custom recovery flashable zip, some images, ramdisk, kernel etc.
My answer is: How you "flash" this on RPi?
Thanks.
Click to expand...
Click to collapse
You can take the files like Kernel and system and so on direct on the SD-card! The whole OS is on the SD by default... You don't have to flash anything! Only put the SD into your PC, copy the files on it and put the SD into to Raspberry... That's the magic... [emoji6]

ph87 said:
You can take the files like Kernel and system and so on direct on the SD-card! The whole OS is on the SD by default... You don't have to flash anything! Only put the SD into your PC, copy the files on it and put the SD into to Raspberry... That's the magic... [emoji6]
Click to expand...
Click to collapse
Well, thanks for the answer. But I was actually asking for the structure how you put it on the SD card. I guess you can't just put system folder and boot.img on the SD card. An Android device has much other folders which are in root directory. Like /proc, /dev, /config and so on. It would be interesting to know this

GeekyDroid said:
Well, thanks for the answer. But I was actually asking for the structure how you put it on the SD card. I guess you can't just put system folder and boot.img on the SD card. An Android device has much other folders which are in root directory. Like /proc, /dev, /config and so on. It would be interesting to know this
Click to expand...
Click to collapse
@GeekyDroid Hi ... Should have mentioned that I threw together an HACKING document in the vendor repo
But Basically I've gone with on an 8GB sd
Code:
Number Name Start End Size Type File system Flags
1 boot 512B 80.0MB 80.0MB primary fat16 lba
2 system 80.7MB 1000MB 920MB primary ext4
3 data 1000MB 7000MB 6000MB primary ext4
4 cache 7000MB 8000MB 999MB primary ext4
The sizes you can pick yourself boot is about 12MB at the moment. The system.img create by the build is and unsparsed ext4 image which is 512MB as specified in the device/broadcom/rpi/BoardConfig.mk . The actual system directory is ~215MB
My basic workflow for sdcard creation is to use a SDCard USB Adaptor. setup the partitions using parted and mount the boot partition. copy out/target/product/rpi/kernel out/target/product/rpi/ramdisk.img and the contents of out/target/product/rpi/bootloader to the mounted directory
then I used make_ext4 on the data and cache device nodes and then I just cat the out/target/product/rpi/kernel out/target/product/system.img to the system parted.
The hacking document explains it way better than I just have ... but I've typed it now so sod it :silly:
Obviously this method leaves gaps between the system and data partitions but for now I ain't to bothered. Recovery does work and there's a switch you can pass to the raspberry reboot which "tells" it to boot recovery ... i believe that's how their ( RPI Official ) noobs installer and like works. I've not got round to creating a updater-script for it yet
Once the system.img is "flashed" onto the sdcard and because of the nature of the task then you don't really need to create another one, I give mine a refresh every now and again just because I've been at it a couple of months now.
Once the PI is Booted as there is no OTG it brings up eth0 and runs netcfg eth0 dhcp as a late_start service and prints the ip address to the console. In my case the PI is connected to my home network so I then use adb over tcp for debugging fun! .. The bootanimation gets in the way of the printip now .. I should fix that .. obviously you can use a static one or whatever you like** The aforementioned services are specified in device/broadcom/rpi/init.bcm2708.rc
You can use mmp from within source directories to make and push whatever module your working on then adb restart to "hot restart" the framework.
you can also quickly replace the ramdisk.img kernel config.txt which has the resolution and kernel command line args by mounting using adb to mount /dev/block/mmcblk0p1 somewhere and just dropping in your replacements and rebooting .... saves constant pulling of the sdcard ; I read in various places that the sdcard slot isn't so robust but that's what you get for £30!
Hopefully that makes a little bit of sense ... I've only just picked the PI development backup after a month "off" ... I'm still a bit confused about GPU/GFX development in general and the fact that there's at least 3 maybe even 5 ways of allocating/locking/mapping the gpu memory and whether it even has to be mapped or whether "we" can just smash it using DMA isn't aiding in my rapid understanding of it .... I'll get there though.
Thanks
trevd
** I think eric anholt who is working on the vc4 drm/kms drivers and actually knows what he's doing wrt all the gfx fun is booting over NFS so is always an option see : http://anholt.livejournal.com/ for that work

trevd said:
@GeekyDroid Hi ... Should have mentioned that I threw together an HACKING document in the vendor repo
But Basically I've gone with on an 8GB sd
Code:
Number Name Start End Size Type File system Flags
1 boot 512B 80.0MB 80.0MB primary fat16 lba
2 system 80.7MB 1000MB 920MB primary ext4
3 data 1000MB 7000MB 6000MB primary ext4
4 cache 7000MB 8000MB 999MB primary ext4
The sizes you can pick yourself boot is about 12MB at the moment. The system.img create by the build is and unsparsed ext4 image which is 512MB as specified in the device/broadcom/rpi/BoardConfig.mk . The actual system directory is ~215MB
My basic workflow for sdcard creation is to use a SDCard USB Adaptor. setup the partitions using parted and mount the boot partition. copy out/target/product/rpi/kernel out/target/product/rpi/ramdisk.img and the contents of out/target/product/rpi/bootloader to the mounted directory
then I used make_ext4 on the data and cache device nodes and then I just cat the out/target/product/rpi/kernel out/target/product/system.img to the system parted.
The hacking document explains it way better than I just have ... but I've typed it now so sod it :silly:
Obviously this method leaves gaps between the system and data partitions but for now I ain't to bothered. Recovery does work and there's a switch you can pass to the raspberry reboot which "tells" it to boot recovery ... i believe that's how their ( RPI Official ) noobs installer and like works. I've not got round to creating a updater-script for it yet
Once the system.img is "flashed" onto the sdcard and because of the nature of the task then you don't really need to create another one, I give mine a refresh every now and again just because I've been at it a couple of months now.
Once the PI is Booted as there is no OTG it brings up eth0 and runs netcfg eth0 dhcp as a late_start service and prints the ip address to the console. In my case the PI is connected to my home network so I then use adb over tcp for debugging fun! .. The bootanimation gets in the way of the printip now .. I should fix that .. obviously you can use a static one or whatever you like** The aforementioned services are specified in device/broadcom/rpi/init.bcm2708.rc
You can use mmp from within source directories to make and push whatever module your working on then adb restart to "hot restart" the framework.
you can also quickly replace the ramdisk.img kernel config.txt which has the resolution and kernel command line args by mounting using adb to mount /dev/block/mmcblk0p1 somewhere and just dropping in your replacements and rebooting .... saves constant pulling of the sdcard ; I read in various places that the sdcard slot isn't so robust but that's what you get for £30!
Hopefully that makes a little bit of sense ... I've only just picked the PI development backup after a month "off" ... I'm still a bit confused about GPU/GFX development in general and the fact that there's at least 3 maybe even 5 ways of allocating/locking/mapping the gpu memory and whether it even has to be mapped or whether "we" can just smash it using DMA isn't aiding in my rapid understanding of it .... I'll get there though.
Thanks
trevd
** I think eric anholt who is working on the vc4 drm/kms drivers and actually knows what he's doing wrt all the gfx fun is booting over NFS so is always an option see : http://anholt.livejournal.com/ for that work
Click to expand...
Click to collapse
Thanks you so much for explaining it to me! It really makes sense now for me! Thanks for doing this project I really appreaciate it, that someone works on it! :victory:
I'm not a developer neither a pro, I just now some source building, however I'd like to help you. But as I said I can't, because of the lack of the knowledge. Anyways keep going and all the best! :good:

With the new quad core raspberry pi that just came out, would this port work with it?

Chrisw_2003 said:
With the new quad core raspberry pi that just came out, would this port work with it?
Click to expand...
Click to collapse
With the work that eric anholt has done on the videocore mesa kms driver ... someone just needs to write a simple pass through gralloc ( in theory ) This port doesn't need to work on it as you'll be able to compile the AOSP master branch without too much trouble.

@trevd I think that you should not use Mesa, but trying every AndroidARMv6 fix instead. (until the DRM driver is merged in the raspberrypi/linux tree as Anholt's tree DOES NOT support the Pi2B)
That dequeue patch is a good thing to try.(it fixed that particular error on another device)
Currently your tree DOES NOT build, it stalls at repo sync:
Code:
21 689k 21 151k 0 0 12202 0 0:00:57 0:00:12 0:00:45 21103Fetching project CyanogenMod/android_bootable_recovery-cm
23 689k 23 164k 0 0 12273 0 0:00:57 0:00:13 0:00:44 23933error: Cannot fetch trevd/android_external_busybox
Fetching project CyanogenMod/android_external_grub
100 689k 100 689k 0 0 12014 0 0:00:58 0:00:58 --:--:-- 17929
Fetching projects: 67% (313/467)

Is anyone still working on this for the gfx port?

Building Lineage OS 14.1 for Grouper - clang error

Hi everyone, I have decided to build LOS 14.1. I know builds already exist, but I thought I would like to do it myself to enable me to update to the latest sources easily.
I have taken @AndDiSa's kernel and device tree for AOSP-7.1.0, and modified them to be compatible (I believe anyway) with LOS sources.
However, when I build, I get a significant way through and then I get the error "clang++: error: unknown argument: "-mapcs" " (I have attached a screenshot of the actual terminal output - There was a lot of text I didn't understand above it)
I have searched and searched, but I cannot find any reference to this argument.
Any help would be much appreciated
Edit: By the way, if you want to see the sources, they are the grouper kernel and device trees on my github (https://github.com/thepiguy0)

@ThePiGuy probably you would like to have a look at my change request. This should help to solve the compile error

AndDiSa said:
@ThePiGuy probably you would like to have a look at my change request. This should help to solve the compile error
Click to expand...
Click to collapse
Thanks for the quick reply I have applied the patch now. I'll update you on the outcome

@AndDiSa following on from that, it does appear to have solved the compilation issue (it has now got further than it did last time). How come your fix hasn't been merged (I noticed that it was submitted last year)?

@ThePiGuy nobody felt responible to review and to merge the fix. I have had submitted two other changes. Not sure whether they are still needed to compile, ...
I have the impression the Nexus 7 is almost abandoned on LineageOS, but I might be wrong.

AndDiSa said:
@ThePiGuy nobody felt responible to review and to merge the fix. I have had submitted two other changes. Not sure whether they are still needed to compile, ...
I have the impression the Nexus 7 is almost abandoned on LineageOS, but I might be wrong.
Click to expand...
Click to collapse
It's a real shame, as LOS is generally one of the best ways to revive a device, and the nexus 7 2012 was immensely popular.
As for compiling, I have hit another error. It states that there is an unknown type name "aligned_u64" in the file if_packet.h which is located in the kernel, under include/linux/.
I have found the line, and it is under the hdr_v1 structure. How should I fix this? I have noticed that LOS default repos and your LOS branch have a different and much shorter version of this file

@ThePiGuy replace by "__aligned_u64" and it should compile as was already posted by @Charles IV

Hope the change works for you.
Most official Lineage development seems halted for grouper, although hazzer does seem to be doing a bit of meddling.
I also just bought a Nexus 7 for 5 LOSCoins, so maybe they're doing something with it

Charles IV said:
Hope the change works for you.
Most official Lineage development seems halted for grouper, although hazzer does seem to be doing a bit of meddling.
I also just bought a Nexus 7 for 5 LOSCoins, so maybe they're doing something with it
Click to expand...
Click to collapse
Your fix worked beautifully - I got to the packaging of the OS at the end (after modifying a few SEPolicies), and then something happened - it was so close
Edit: @AndDiSa any ideas?

@ThePiGuy looks as if you are trying to build the userimage formated as f2fs file system. I am not sure whether this is supported as I never changed there anything and, hostestly speaking, which is not of much use as you can always format the /data partition in recovery. If you have boot.img and system.img everything should be fine and you can flash them using fastboot.

AndDiSa said:
@ThePiGuy looks as if you are trying to build the userimage formated as f2fs file system. I am not sure whether this is supported as I never changed there anything and, hostestly speaking, which is not of much use as you can always format the /data partition in recovery. If you have boot.img and system.img everything should be fine and you can flash them using fastboot.
Click to expand...
Click to collapse
Ok I will do. I didn't change anything relating to the formatting of the userimage (not knowingly anyway), so I'm surprised that is has defaulted to that. Where would I change this to get it back to ext4?

@AndDiSa unfortunately once I flashed the System.img and boot.img, I got into a bootloop where it would show the google logo and unlocked padlock, flash and start again. Could it be due to outdated proprietary blobs? Would I be better off using unlegacy android blobs (they seem to be updated fairly frequently for such an old device)

@ThePiGuy I doubt that the blobs are the reason why ... If it remains on the Google start page it's an indication that there is either a kernel crash or that there are permission issues, i.e. your selinux configuration has some problems. Did you try to boot into TWRP directly and to have a look at /proc/last_kmsg ?

AndDiSa said:
@ThePiGuy I doubt that the blobs are the reason why ... If it remains on the Google start page it's an indication that there is either a kernel crash or that there are permission issues, i.e. your selinux configuration has some problems. Did you try to boot into TWRP directly and to have a look at /proc/last_kmsg ?
Click to expand...
Click to collapse
No I didn't (I'm very new to this - the only other thing I have built is for my G4, which just seemed to work without any issues)
Having had a look now, it looks like it is a kernel panic (I have attached the last_mksg with a .txt extension to get XDA to allow it)

@ThePiGuy which kernel sources do you use? I had similar issues years ago when I was trying to set up the Nougat-Kernel.
Can you please check whether you have the __BRILLO__ option set in system/core/init/Android.mk?
Code:
diff --git a/init/Android.mk b/init/Android.mk
index 67541b8..ff343e9 100644
--- a/init/Android.mk
+++ b/init/Android.mk
@@ -10,7 +10,7 @@ else
init_options += -DALLOW_LOCAL_PROP_OVERRIDE=0 -DALLOW_PERMISSIVE_SELINUX=0
endif
-init_options += -DLOG_UEVENTS=0
+init_options += -DLOG_UEVENTS=0 -D__BRILLO__
init_cflags += \
$(init_options) \

AndDiSa said:
@ThePiGuy which kernel sources do you use? I had similar issues years ago when I was trying to set up the Nougat-Kernel.
Can you please check whether you have the __BRILLO__ option set in system/core/init/Android.mk?
Code:
diff --git a/init/Android.mk b/init/Android.mk
index 67541b8..ff343e9 100644
--- a/init/Android.mk
+++ b/init/Android.mk
@@ -10,7 +10,7 @@ else
init_options += -DALLOW_LOCAL_PROP_OVERRIDE=0 -DALLOW_PERMISSIVE_SELINUX=0
endif
-init_options += -DLOG_UEVENTS=0
+init_options += -DLOG_UEVENTS=0 -D__BRILLO__
init_cflags += \
$(init_options) \
Click to expand...
Click to collapse
I have forked your kernel source (you can see my fork at https://github.com/thepiguy0/android_kernel_asus_grouper).
Unfortunately I can't see that file at all

@ThePiGuy that Android.mk is located in the system/core project in the init directory, not in the kernel.

AndDiSa said:
@ThePiGuy that Android.mk is located in the system/core project in the init directory, not in the kernel.
Click to expand...
Click to collapse
Ah yes I see it now. No I didn't have that option. I'll add it and see if it works

(Accidental duplicate post - see below)

@AndDiSa one thing that has just occurred to me - I have just noticed all the patches in your grouper manifest - will I need to apply all those patches if I use your sources?

I need a little bit of help porting crDroid 6 to the sm-t350

I need a little bit of help portingh crDroid 6 to the sm-t350. Nubianprince started then got pulled away by work. I have initalized the crdroid repo, but i when i run repo sync i think it only downloaded like, 300 mb. i do have an android pie enviroment, does repo link resources? i dont know what is going on there. I will upload my roomservice.xml. I had to remove a couple lines from the original and manually clone them because it keeped giving me an error. the original is here https://github.com/Nubianprince/local_manifests/blob/master/crdroid-ten.xml .
Currently i am using this device tree: https://github.com/Nubianprince/android_vendor_samsung_gt58wifi most custom roms i see are using this: https://github.com/Valera1978/android_device_samsung_gtaxlwifi . I have not seen any non sm-5xx devices using it though, so i hesitate to switch. i worked out a a couple errors of things being defined twice, and then built. but i think i am missing something as the build fails with this: FAILED: ninja: 'out/target/product/gt58wifi/root/init.usb.configfs.rc', needed by 'out/target/product/gt58wifi/ramdisk-recovery.cpio', missing and no known rule to make it
Is there a "quick fix" to provide this file? I am not actually sure what i am missing, or what creates it.
Any help would be appreciated.

This file "init.usb.configfs.rc" is missing from your device tree, somewhere in one of your files you have the path pointing to "init.usb.configfs.rc" which does not exist. Let me know if that makes sense.

nubianprince said:
This file "init.usb.configfs.rc" is missing from your device tree, somewhere in one of your files you have the path pointing to "init.usb.configfs.rc" which does not exist. Let me know if that makes sense.
Click to expand...
Click to collapse
Yes, it does make sense. I just don't know enough about the android environment to know where the file, or what is pointing to it, would / should be.

Okay. I believe there is a missing, or many many missing makefiles. I found the file and manually copied it to out, and then the build fails with another missing file. Rinse and repeat, there are a ton of files not being put where they should be. Now what to do with that information, i am not sure ??. I tried including a couple of the make files from android 9, but they didn't make any difference.
oh yeah, and if i do lunch instead of brunch it fails with a different file missing: FAILED: ninja: 'out/target/product/gt58wifi/system/addon.d/50-lineage.sh', needed by 'out/target/product/gt58wifi/verified_assembled_framework_manifest.xml', missing and no known rule to make it

it makes no sense adding files to the "out" folder, fix the issues in your "device" folder check your device.mk file

Wow. That was really awful. I don't even know what i was thinking there. What i was trying to say, is that i was manual copying the files to see if it was just one or two not being copied. I have been comparing the Pie and Q makefiles to try to determine what file was supposed to be copying it to out, but i cant find it in Pie, all i know for now is that it is being copied in Pie but not Q. For now I'm gonna' keep looking for the correct file.

lividhen99 said:
Wow. That was really awful. I don't even know what i was thinking there. What i was trying to say, is that i was manual copying the files to see if it was just one or two not being copied. I have been comparing the Pie and Q makefiles to try to determine what file was supposed to be copying it to out, but i cant find it in Pie, all i know for now is that it is being copied in Pie but not Q. For now I'm gonna' keep looking for the correct file.
Click to expand...
Click to collapse
What device tree are you using, do you have it on Github?

nubianprince said:
What device tree are you using, do you have it on Github?
Click to expand...
Click to collapse
I am just using the device trees (ten branch) on your GitHub. I haven't made any changes that have gotten me anywhere so i haven't committed my local changes to my GitHub.

That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo

nubianprince said:
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
Click to expand...
Click to collapse
I have been away for a while and haven't followed along, but the last week I spent compiling ROMs. I also tried compiling Android 10 using "stock" lineageos gt58wifi and I got stuck at the logo as well. I also tried another device from the msm8916 repository and got stuck at the logo.
The "stock" gt58wifi build, as we all know, has problems with audio, bluetooth, smart cover, etc, etc in all versions 14.1, 15.0, 16.0 and won't even boot with 17.1.
When I first compiled it, it would fail due an error with a config.xml file. I submitted a patch, like others, but haven't seen anything yet.
https://github.com/Galaxy-MSM8916/android_device_samsung_gt58wifi/pulls

nubianprince said:
That crdroid ten branch still need a lot of work, the last build I did when I was working on it was not getting past the logo
Click to expand...
Click to collapse
I'm working on SM-T560NU 17.1. It too was stuck at the boot logo. I built an eng build and found it was the hardware vibrator that was getting stuck in a loop. If you remove the vibrator hal from
/device/samsung/msm8916-common/manifest.xml
that should work on the SM-T350 because both platforms share the same msm8916 code?
I did build SM-T350 with 17.1 and was stuck at boot logo and gave up. However, I have not rebuilt it knowing this new information. I will try again with the above change in a few days?

So, as retiredtab has said, he got android 10 booting. But it has all the issues android 9 did: no camera, sound, Bluetooth, or Hal sensor (sort of, it can turn the device on but not off). The system ui is also a little funny on crdroid, not sure about lineage. I don't know how to fix these issues, or where the roots of the problems may lay. Do you have any suggestions for learning more about the android source code? I feel like the aosp docs are good, but you kind of have to know what you're looking for.

I think part of the problem with the SM-T350 is that there has never been a fully working build since day 1. Lineageos 14 had problems to begin with and they were never fixed and got carried over to 15, 16 and now 17. If stock Lineageos 16 was fully working, then getting it to work on 17 would be less of a challenge.
The most likely problem to no audio, camera, bluetooth etc is the Samsung proprietary blobs are not in the correct directories or the configuration blob files are pointing to the wrong directory.
When I face this problem, I find it helpful to look at a working roomservice.xml file and do comparisons.
If there is no working roomservice.xml like "stock" lineageos 14, 15, and 16 for the SM-T350, then I look at similar models. For example, the T550 is the bigger brother and it helps to look through it's roomservice.xml file for hints.
Remember that a compiler mainly checks for syntax errors, not semantic. If you make a typo, a compiler will flag that as an error, but if you write correct syntax, but put a file or files in directory ABC instead of XYZ, the compiler won't say anything.
Another thing that might help is doing a logcat of a working build and comparing it to a non working build. There might be a very obvious error message like "can't find audio.hw.msm8916 in directory /device/samsung/msm8916" or something like that.
Learning how to use tools like meld and diff help tremendously in finding file and directory differences in case you put the blobs in the wrong place. See
https://www.tecmint.com/compare-find-difference-between-two-directories-in-linux/
I used meld when troubleshooting the stuck at boot logo.
If you are a visual learner, I found the following youtube channel helping in learning the overall process of building ROMs.
https://www.youtube.com/c/AlaskaLinuxUserAKLU/videos

I think we have lineage 16 fully working. I think the part I'm having trouble with here is the difference between where the files are read from in Android Q vs P.
If I understood what you said incorrectly, please say so.