Walmart ONN Google TV

[treypop]

how do I recover from a soft brick. I'm stuck at the onn. screen after I tried flashing something

 

[Functioner]

Which partition(s) did you flash? You can flash back the original partition(s) using dnl burn mode (adnl).

 

[treypop]

Which partition(s) did you flash? You can flash back the original partition(s) using dnl burn mode (adnl).

vendor_boot I'll do some googling and try to figure out how dnl burn mode works

 

[ziddey]

vendor_boot I'll do some googling and try to figure out how dnl burn mode works

guessing you can't get in recovery either by holding the button?

 

[freddyjuarez]

I'm having the problem where only first time running the command adb devices after installing adb-setup-1.4.3 it works if i do adb devices second time it doesn't work

And yes i have tried both regular CMD and administrator cmd

 

[sharon999]

Sounds like if some more technical minded person can patch it manually we can use that image.
If you have done this can you make your already magisked image available for everyone?
Or can we use a custom os now like lineage without patching anything ??

 

[mad4some]

deleted

 

[the.real.p3y0t3]

Has anyone got serial console working on the 2023 model?

 

[the.real.p3y0t3]

So I bought one of these units yesterday, tore it apart photographed it then proceeded to brick it in spectacular fashion. Things were looking pretty grim; 98% of all fastboot commands rejected, yadda yadda. adnl saved the day, however. Oddly enough, it wouldnt let me flash back the stock boot.img... I had to use the magisk patched one that I thought bricked it in the first place. Anyhow, what I did was flashed the bootloader from the OTA thats floating around first, then my patched magisk boot after the stock one failed. Commands are (in this order, for me anyways):

adnl oem disk_initial
adnl Partition -P bootloader -F bootloader.img
adnl Partition -P boot_b -F boot.img
adnl reboot

...and she booted right up, like nothing ever happened

 

[the.real.p3y0t3]

So can we all agree to disagree about the status of the bootloader is on these gen2 boxes... People keep referring to the fastboot flashing unlock\unlock_critical commands as if they unlocked the BL.. This is not true. Those two commands allow you to flash the boot partition - etc. (flashing unlock) and the bootloader partition (flashing unlock_critical). This gives you just enough rope to hang yourself with if, lets say, you didn't tick that OEM Unlocking switch. Which, as many have found out, is greyed out on these new boxes... Making it kinda difficult to unlock the device. With all that said, it still wiped my install like the BL unlock should; it didnt TEL:L ME it was going to... It just did. Anyhow, I believe the prop ro.oem_unlock_supported is what decides whether yiou can slide that unlock switch... Food for thought

 

[Functioner]

So can we all agree to disagree about the status of the bootloader is on these gen2 boxes...

I agree that we disagree.

People keep referring to the fastboot flashing unlock\unlock_critical commands as if they unlocked the BL.. This is not true

It is true. When the "fastboot flashing unlock" is executed, the following appears in the uart console:

lock state: 10101000
cb_flashing cmd_parameter: flashing unlock
cb_flashing: unlock
avb2: 1
unlocking device.  Erasing userdata partition!
10422272 blocks erased: OK
erased in 136 ms
unlocking device.  Erasing metadata partition!
32768 blocks erased: OK
erased in 4 ms
lock_d state: 10100000
*** Warning - ## defenv_reserve ##, using default environment

Saving Environment to STORAGE... OK

The bootloader is unlocked when it will boot modified bootable partitions on the emmc. It will do so after the "fastboot flashing unlock" command is successfully executed.

With all that said, it still wiped my install like the BL unlock should; it didnt TEL:L ME it was going to... It just did.

Yes, the bootloader will erase the userdata partition as part of executing the "fastboot flashing unlock" command. As you say, "like the BL unlock should", so this is expected.

The oem slider in developer options has no effect on this device, it doesn't matter if it is enabled or not, because the bootloader doesn't recognize the status of the setting.

 

[cynewulff]

TLDR: I was also able to get the bootloader unlocked. Also the UART console for this device can get you into Fastboot reliably if you open the device and solder 3 wires onto the board



I bought the device this morning, thinking it was the older model that had established Lineage OS support ...

Started up the box and turned on the Developer settings and Turned on USB debugging ... found the OEM unlock setting greyed out .. was my first hint that something wasn't right ... but I pressed on

Using adb to reboot to bootloader worked fine ...

fastboot seemed ok .... fastboot flashing unlock and fastboot flashing unlock_critical seemed to work ... but when I flashed the dtb/dtbo/recovery for (what I didn't realize then) was the older model ... the box bricked ... one strange line of garbage on the tv screen ... no adb device ... a fastboot device, but listed as an Amlogic Device and not Fastboot ...

After much fiddling and googling, the found the adnl and adnl_burn_pkg utilities (I run linux) they seemed to be responsive to the box ... think this is called "burn mode"

What I found more helpful was the UART ... pulled the board out of the case, soldered on 3 wires for RX/TX/Gnd and pluged them into my always handy pl2303-based USB to UART dongle (blue casing) ... tried the typical 115200 baud and got garbage ... played with baud rates and finally found that 921600 baud worked and showed UART console output

With the UART working I could start picocom (again linux) and found a message fly by to press any key to interupt boot ... I cycled power and pressed the keys rapidly and it gave me a console with a "s4_ap222#" prompt ... typing help at this prompt gave tons of commands .... I found that typing "fastboot usb 0" would boot the board into fastboot mode ...

Seems like I have a reliable way to get into fastboot mode now whenever I need to from the UART ... even if things are bricked ...

But even then from fastboot I kept flashing the lineage stuff for dopinder and an original factory image for dopinger ... and watching the UART would always see the kernel struggling to boot and/or struggling to find the right device tree (dtb) ... could never get even just recovery started up ... very confusing ...

FINALLY found this thread and the big light-bulb came on that this is a new device! Of course the old kernel wouldn't work right ... of course the dtb/dtbo needed to be correct for this device ...

Basically just sharing all this just in case it helps somebody else out there working on getting this thing up and running ...

Does anybody around here know if anybody is working on getting TWRP/Lineage up and going yet on this device? Does it have a codename? Is there a factory oem set of images anywhere? (boot.img recovery.img dtb.img ... etc etc)

I can test on my setup if that would be helpful ..

 

[Functioner]

Is there a factory oem set of images anywhere? (boot.img recovery.img dtb.img ... etc etc)

The ota with the firmware is in the second post to this thread, but for some reason it does not include the dtb. If you need the dtb to restore your device, I can pull it from my device if you'd like.

Note that the ota is in payload.bin format, so you'll need to use something to extract it. Like the various python scripts that extract payload.bin.

 

[cynewulff]

The ota with the firmware is in the second post to this thread, but for some reason it does not include the dtb. If you need the dtb to restore your device, I can pull it from my device if you'd like.

Note that the ota is in payload.bin format, so you'll need to use something to extract it. Like the various python scripts that extract payload.bin.

Thanks for the breadcrumb on the python script to break apart the OTA payload.bin, I figured it out and have many of the stock pieces from the extraction.

Still can't get the device to fully boot again however, most likely because I still have some of the wrong stuff flashed to it. Earlier today I had flashed the super.img for dopinder which probably wrecked all kinds of havoc ... the kernel does start, but stops very quickly and purposefully reboots the device to bootloader mode ... which does put me in fastboot mode for what it's worth ...

If you could send me your dtb.img and recovery.img ... maybe I can at least get back to booting into a recovery ...

 

[Functioner]

If you could send me your dtb.img

I forgot, the 2nd Gen onn device uses efi partitioning, rather than partitioning via a copy of the dtb stored in the reserved partition (dtb is still used later in the boot process before the kernel loads, but not for the aml partitioning).

You can check if your efi got hosed by running this command at the uart prompt:

amlmmc part 1

If no partition table is shown, then you'll need to repair the efi partition table.

It's the same on every device, so it can be restored. I'll pull that if you don't have a partition table shown after executing the above command at the uart prompt.

recovery.img ... maybe I can at least get back to booting into a recovery ...

vendor_boot devices that use generic kernel image don't use a distinct recovery partition.

The recovery image is at an offset within vendor_boot, after the boot image.

 

[cynewulff]

You can check if your efi got hosed by running this command at the uart prompt:

amlmmc part 1

If no partition table is shown, then you'll need to repair the efi partition table.

It's the same on every device, so it can be restored. I'll pull that if you don't have a partition table shown after executing the above command at the uart prompt.

That command gives a reasonable looking EFI partition setup, tons of partitions ... way too much output to post here ...

I've noticed I have a super partition instead of system in the EFI ... this is probably why fastboot is complaining it can't find a system_a partition when I attempt to flash it? ... my boot output is telling me it is not finding a good hash for system just prior to loading the kernel (which it seems to do anyway) ... probably need to figure out how to reconstruct a super.img file from the pieces ...

(wow this is all so different since when I used to tinker around building JellyBean roms back in the day ...)

 

[Functioner]

Only adnl needs the slot designation when specifying the partition to flash.

For fastboot flashing, fastboot automatically determines the active slot and appends it. So, when flashing using fastboot, you just specify system rather than system_a. Likewise for the other partitions that use slots.

Of course, all of the dynamic partitions need to be flashed using fastbootd rather than bootloader fastboot. You probably already know this:

fastboot reboot fastboot <- to get to fastbootd to flash all of the dynamic partitions.

fastboot reboot bootloader <- to get back to bootloader fastboot from fastbootd.

There is always the possibility that given all of the stuff that you did earlier, that the active slot got changed. If so, change it back to the original value before you flash anything.

 

[cynewulff]

Thanks for the reminders on fastbootd and active slots ... unfortunately that is not it ... it won't write a system.img file ... here is what I'm seeing ...

$ fastboot set_active a
Setting current slot to 'a' OKAY [ 0.006s]
Finished. Total time: 0.007s

$ fastboot reboot fastboot
Rebooting into fastboot OKAY [ 0.000s]
< waiting for any device >
Finished. Total time: 16.739s

$ fastboot devices
GUSA2322040405 fastbootd

$ fastboot flash system system.img -S 128M
Sending sparse 'system' 1/5 (131052 KB) OKAY [ 7.031s]
Writing 'system' FAILED (remote: 'No such file or directory')
fastboot: error: Command failed

$ fastboot flash system system.img
Sending sparse 'system' 1/3 (262108 KB) OKAY [ 14.069s]
Writing 'system' FAILED (remote: 'No such file or directory')
fastboot: error: Command failed

 

[Functioner]

it won't write a system.img file

Probably the base dynamic partition structure within the super partition still consists of whatever it is within the super.img that you flashed that was constructed for the prior generation device.

The prior generation device included super_empty_all.img within ota packages, that could be flashed from bootloader fastboot (rather than fastbootd), so that later, when booting to fastbootd, the base dynamic partition names were already established. The 2nd Gen ota packages do not include a super_empty_all image.

There is a tedious process to manually delete/create partitions within super using fastbootd:

https://source.android.com/docs/core/architecture/bootloader/fastbootd

Or, I've sent you a pm with a link to the super.img from my device. You can try to flash that with adnl, or bootloader fastboot, or using dd from the uart console prompt that is present after booting to recovery in permissive mode, or using one of the other utilities that are available from the u-boot shell prompt, such as:

usb_update - Burning a partition with image file in usb host

If none of that works, maybe just exchange the device and start over.

 

[cynewulff]

Probably the base dynamic partition structure within the super partition still consists of whatever it is within the super.img that you flashed that was constructed for the prior generation device.

The prior generation device included super_empty_all.img within ota packages, that could be flashed from bootloader fastboot (rather than fastbootd), so that later, when booting to fastbootd, the base dynamic partition names were already established. The 2nd Gen ota packages do not include a super_empty_all image.

There is a tedious process to manually delete/create partitions within super using fastbootd:

https://source.android.com/docs/core/architecture/bootloader/fastbootd

Or, I've sent you a pm with a link to the super.img from my device. You can try to flash that with adnl, or bootloader fastboot, or using dd from the uart console prompt that is present after booting to recovery in permissive mode, or using one of the other utilities that are available from the u-boot shell prompt, such as:

usb_update - Burning a partition with image file in usb host

If none of that works, maybe just exchange the device and start over.

Thanks, I've got the file now. Will be out for a bit this morning, then I will tinker around with your recommendations.

I already ordered a Dynalink 4k Android TV (wade) last night ... I'll use that to put together the original setup I had in mind ... however I think I'm keeping this unit to continue learning and tinkering on.