get your self a Khadas VIM3 Basic/Pro if you wanna play around with all that.. Google's source code officially supports it. I have already built 4 roms with only uses googles source.. but tell you the truth, I think that same device tree can be modified to work for other amlogic g12 boards..Thanks! It's too bad that usb burning mode is increasingly being disabled in new model devices. The askey ASK-STI6220 (S905X4) doesn't have it. The uboot menu is missing "update - Enter v2 usbburning mode". They've replaced it with a distinct version of fastboot (different than bootloader fastboot and fastbootd). Even masking the rom brings up only this mini version of fastboot. And it is no where near as capable as usb burning mode.
assert failed: update_dynamic_partitions(package_extract_file("dynamic_partitions_op_list"))
prop files should need no updates - you need to extract them from the deadpool r build, or an existing lineageos build, preferably existing lineageos build.Hi guys, I'm trying to build for the dopinder myself. After couple tweaks (e.g. fixing some paths of proprietary blobs), I got the final zip built without any failures. However, the installation of the new zip via recovery is failing with the following error:
Code:assert failed: update_dynamic_partitions(package_extract_file("dynamic_partitions_op_list"))
What I noticed that the size of the zip I built is almost half size of the original working version. (390MB vs 690M). Comparing side by side on the contents of zips, I see that my build is missing 'bootloader.img' and the huge difference on the size of 'product.new.data.br' (60MB vs 337MB).
I believe that I've followed all the steps according to this. Any hints or advices?
Another question: How do I get a write access on /sys/devices/virtual/? I'm trying to create some files especially under android_usb to enable accessory mode for dopinder. Even magisk's su wont' give me enough permission. It seems to be something with dm-verity which I might need to disable by building the rom myself?
prop files should need no updates - you need to extract them from the deadpool r build, or an existing lineageos build, preferably existing lineageos build.
It's half the size because I build GApps in ;p you won't have that.
Bootloader.img just needs to be the same one from in the lineage package I give out, so as long as you flash that once, you're fine.
as for files on /sys - uh, that's not normally something one does? They should be made by init or the kernel.
!! odm/etc/firmware/firmware.le: file not found in source
!! odm/usr/idc/Vendor_000d_Product_3838.idc: file not found in source
!! odm/usr/idc/Vendor_000d_Product_3839.idc: file not found in source
!! odm/usr/keylayout/Vendor_000d_Product_3838.kl: file not found in source
!! odm/usr/keylayout/Vendor_000d_Product_3839.kl: file not found in source
!! odm/usr/keylayout/Vendor_7545_Product_0021.kl: file not found in source
!! system/etc/audio_effects.conf: file not found in source
!! system/etc/permissions/privapp-permissions-atv-lineage.xml: file not found in source
!! system/etc/permissions/privapp-permissions-google-lineage.xml: file not found in source
!! system/lib/hw/screen_source.amlogic.so: file not found in source
!! system/lib/libmediahal_resman.system.so: file not found in source
!! system/lib/libmediahal_tsplayer.system.so: file not found in source
!! system/lib/libmediahal_videodec.system.so: file not found in source
Yeah you can't extract from a running build, I need to fix that guide, you need to extract it from a pre-built zipThanks. So, my build is OK, and I need to figure out why it doesn't get installed somehow...
For prop files, I used the onn device running the latest lineage to extract those. However, the following files were unable to be extracted.
The problem is that the extract util is appending /system prefix to those paths, and found out that there is no symbolic link for odm under /system in the device. Obviously, it also tries to look for /system/system/... which is invalid path.Code:!! odm/etc/firmware/firmware.le: file not found in source !! odm/usr/idc/Vendor_000d_Product_3838.idc: file not found in source !! odm/usr/idc/Vendor_000d_Product_3839.idc: file not found in source !! odm/usr/keylayout/Vendor_000d_Product_3838.kl: file not found in source !! odm/usr/keylayout/Vendor_000d_Product_3839.kl: file not found in source !! odm/usr/keylayout/Vendor_7545_Product_0021.kl: file not found in source !! system/etc/audio_effects.conf: file not found in source !! system/etc/permissions/privapp-permissions-atv-lineage.xml: file not found in source !! system/etc/permissions/privapp-permissions-google-lineage.xml: file not found in source !! system/lib/hw/screen_source.amlogic.so: file not found in source !! system/lib/libmediahal_resman.system.so: file not found in source !! system/lib/libmediahal_tsplayer.system.so: file not found in source !! system/lib/libmediahal_videodec.system.so: file not found in source
BTW, for /sys to access usb driver, as per your comment, I sort of expected to be tweaking init and kernel anyway once I got the good-to-go builds.
It seems that after another month, the last hope for fixing OMX is Android 12, isn't it? Haven't you experimented with it already? (Asking just because unofficial LOS19 builds are starting to appear all around.)I have a few ideas to try once home from holidays.
I'm hoping 12 just fixes it, but I bricked my Deadpool hard. So. Limited atm. Lol
Yeah I already have 12 booting, OMX is still deadIt seems that after another month, the last hope for fixing OMX is Android 12, isn't it? Haven't you experimented with it already? (Asking just because unofficial LOS19 builds are starting to appear all around.)
What a pain... Are there any positive perspectives left?
At the moment not really
Maybe there is some not-so-elegant way, that although will shut the door to official status, but in return will make things work as they should? I think, a multimedia device without hardware codecs is like a car without seats - it rides of course, but who cares...
There's not even a non-elegant way, we have no clue why it doesn't workMaybe there is some not-so-elegant way, that although will shut the door to official status, but in return will make things work as they should? I think, a multimedia device without hardware codecs is like a car without seats - it rides of course, but who cares...
Anyone have any suggestions for this? I know it's not bricked at the very leastIn the process of trying to update to a new system and recovery build, I think my dopinder is stuck at the bootloader screen (androidtv logo)? Is there any way that I can put it back in a flashable state? fastboot and adb both don't see any device, and I don't know which amlogic tool to use, if any. I'm on linux, but I also have windows.
And even in the "heavy framework changes [...] or small changes in dependencies" we cannot look for any vague hope? That time you said it with the goal of the future official release in mind, but today's situation seems different.There's not even a non-elegant way, we have no clue why it doesn't work
From my side, no, I have nothing left to try sadly.And even in the "heavy framework changes [...] or small changes in dependencies" we cannot look for any vague hope? That time you said it with the goal of the future official release in mind, but today's situation seems different.
Not sure why nobody replied to this. It's completely safe. Your device will downregulate it's charge to match what it was designed to accept.Can anyone tell if the discussed devices have any problems with chargers more powerful than recommended 1000mA?
The power supply for dopinder is piece of garbage, but nowadays it's not too easy to find a high-quality replacement with equal power, so I would like to power it with 2.4A, but still afraid to burn something.
I missed one line in the kernel cmdline when I first brought these devices up to 12! Lol.I was somewhat puzzled when occasionally checked this thread I almost gave up and didn't find the familiar mention of a broken OMX in the description, then found this post of yours and... Wow... Looks like a tiny revolution for Android development on Amlogic. How did you manage to do that?
That is so much... like myselfI missed one line in the kernel cmdline when I first brought these devices up to 12! Lol.
Just follow the usual procedure with the original exploit. Before you do any of that, however, overwrite the incompatible recovery with something that works. If you have root access, you can dd the correct recovery.img before trying anything else.Yes! It boots to OS (I also observed that slight flicker you talked about). What steps should I follow to get back to factory unlocked? Can I just boot to fastboot from OS now?
If you're stuck in a recovery bootloop, it's usually the result of writing an incompatible recovery image to the recovery partition. You will not be able to reboot into fastboot because that's conditional on having a working recovery. If this is your issue, you might be able to escape the bootloop by remapping recovery (temporarily) to boot normally.
- Your warranty is now void.
- You have been warned.
- Use at your own risk.
Yeah, you used the stock recovery. You need to fastboot flash, then fastboot boot recovery, I'll update the docs.
For dopinder, it's needed right now.
adb reboot bootloader
fastboot flash recovery lineage-18.1-20210805-recovery-dopinder.img
fastboot boot lineage-18.1-20210805-recovery-dopinder.img
adb reboot sideload
adb sideload lineage-18.1-20210805-UNOFFICIAL-dopinder.zip
# if successful then load bootloader and factory reset
adb reboot bootloader
fastboot -w
fastboot reboot
this ended up being _wayyyyy_ to much, as this is the full value of the partition vs just the space to reserve, both will work, but we want to split it amongst partitions. One of our guys recalculated it and got it working.I ultimately settled on 1126400000, gives ~1.1GB to the system and accommodates the app adjustments I've been making for my builds without tripping OpenGApps' space check for TV stock
Eh, soon, sure.It's been a month and a half since we discussed the possibility of the tablet-flavored (non-TV) release. It seems that the number of complaints has decreased and the basic quality of builds has improved enough to bother you again in this regard: are there any positive changes in this direction, or it is not worth expecting to get a full-featured Android on dopinder? (I'm still following this thread carefully to make a buying decision.)