Dreambox/Dreambox2 S922X device-tree experiments

    • Official Post

    The Beelink G12B devices I have all experience some kind of kernel lockup when using vendor u-boot, with or without chainload of any recent newer u-boot as second stage; although in that case LE boots and generally runs fine until you attempt any large file transfer and then it locks up. Nobody has been able to put their finger on the issue. Beelink shared their u-boot sources so I could see the git history of their changes, but nothing stood out as unusual. Using their sources I extracted the signing FIPs and built mainline u-boot which works without any issues, so this suggests there's an issue in Amlogic u-boot code. G12A/B devices also have confirmed silicon bugs with mmc (there are workarounds in upstream kernel code). So it's hard to comment, but I generally don't trust vendor u-boot + chainload on G12A/B devices.

    If you have Amlogic burning tool and an Android ROM (to restore the box with) you could zero/erase emmc to remove vendor u-boot and see if any of the mainline u-boot images I have in my test folder will boot the box from SD card. Otherwise I don't really have ideas.

    Yes, chain loading brings strange problems.

    Now e.g. with the dreambox two/one.

    The images here worked perfectly. Then I sent it to my developer colleague to try it out with the u-boot.ext packed and it doesn't work.

    Curiously, it's because he didn't have a mini-usb cable on when he tried it out (debug terminal).

    Of course, I didn't notice it because I always had a terminal on it.

    I was able to adjust it here immediately, I don't even have to start the terminal (kermit).

    Only the cable has to be connected to the PC?? - Very strange

    large file transfer: With the exception of the LE, this happens with in all Linux distributions.

    Unfortunately, no mainline boots with the original boot loader on the Dreamboxes.

    With the Dreamboxes, software protection is built into the boot loader, without the manufacturer's operating system no longer works.

    So flashing the boot loader for normal users makes no sense here.

    There is no burnig img for Dreamboxes.

    The box is also not recognized as a device by the Burning tool or the boot loader lacks the mode.

    If I destroy the boot loader, I can only boot from an sd and restore the eMMC from an operating system from sd.

    I tried to contact the developers in vain, I only found out that they are very busy at the moment.

    I hope that I will reach someone someday.

    The other box, dreamTV, is actually not in my main interest.

    I would have thought, because the keymaps are the same, it would be a simple matter - thought wrong.

    There is no burnig img here either.

    I tried one from a custom developer and it worked, but restoring the original image was only possible by hand using the uboot console and fastboot.

    This was the only way I could use the original recovery/update.zip again.

    And by hand I have now put an AndroidTV10 on it, which is very important to me at the moment.

    I'm already thinking about how I could secure that without twpr.

    the Beelink bootloader is then only for the Dremboxes or would that work with both?

    One ugly fix more for the cain mainline-bootloader of the Dreambox.

    Without power or ground on the microUsb (terminal), the hardware writes a few characters "MC: .." when the chain boot loader is started.

    Of course, these characters stop the mainline-uboot pointing to:

    "Hit any key to stop autoboot:% 2d"

    immediately stops.

    with a query on:

    "Hit Enter or space or Ctrl + C key to stop autoboot -:

    I was able to solve the problem (as aml-uboot does). That’s good.

    But why do I always get no picture with 2021 versions on Dreamboxes?

    I asked the vendor about the original fip bins.

    I hope something comes from them.

    I want to see how it works in standalone.

    Hopefully the mainline u-boot will work without my 2 ugly patches.

    Are the fips very different for the s922x boxes?

    I once flashed a vim3 bootloader that bricked the box.

    • Official Post

    The FIPs contain RAM timing data (acs.bin) so if this is wrong the box doesn't boot, which is not impossible to recover from but needs you to short emmc pins to prevent [wrong] vendor u-boot from being found/used. If I want to experiment I will take a backup of emmc then zero emmc. The box will then boot the experimental signed u-boot from USB/SD card, and worst case if nothing works I can put vendor u-boot on an SD/USB to recover the system. If you can get u-boot sources it's simple to extract the FIPs. Alternatively, if they will not share the sources, please loop me into an email conversation with the developers and I can explain which files I want.

    I better had to been reading first: If you can get u-boot sources it's simple to extract the FIPs. :D

    I wrote to the manager again (incl. link).

    I haven't got developer emails only:

    irc freenode Channel #enigma2

    Developers are: __Ghost__, [3des], reichi

    or the Forum - Dreamboard

    so I'm still waiting

    • Official Post

    One of their devs confirmed that Dreambox One/Two use encrypted boot, so "FIPs" are no-go and you will need to continue chainloading u-boot, or you switch to the vendor kernel and work with CE sources rather than mainline kernel and LE. I also learned some things about the M4 chip used for MCU functions. They won't share schematics for the boards, but are happy to answer Q's and might share selected pages if we ask them specific questions. I don't have the skillset to debug much more about the boot issue without access to hardware.

    Bad news...

    >> or you switch to the vendor kernel and work with CE sources

    I made that before, worked well incl. dvb. [Dreambox One UHD] - Amlogic s922X - #14 by buzzmarshall - Development & Testing - CoreELEC Forums

    Other team is still working with that src, but never new builds have problem with decoding.

    It is not all about kodi, other things like Linux Distr and the AndroidTV-11 (yukawa) all uses mainline.

    >> I also learned some things about the M4 chip used for MCU functions.

    Does that cause the reboot in other kernels such as the vendor. There for is the fp-dev.ko?

    >> I don't have the skillset to debug much more about the boot issue without access to hardware.

    So hardware could help? I'll tell this the manager.

    chewitt

    The manager wrote to me that he would like to send you hardware.

    If you want a Dreambox, you can send me your address.

    I will handle your data carefully and only pass it on to the managing director.

    Quote from chewitt

    The Beelink G12B devices I have all experience some kind of kernel lockup when using vendor u-boot, with or without chainload of any recent newer u-boot as second stage; although in that case LE boots and generally runs fine until you attempt any large file transfer and then it locks up. Nobody has been able to put their finger on the issue.

    Hi I'm working with a G12B device (s922x), and I had noticed that when reading or writing > ~500MB I would get a kernel crash related to the dmc_monitor node. Do you remember if this was the same cause of the kernel lockups that you observed?

    Was anymore information ever found to the root cause of the kernel lockups with large file transfers?